NSIS Working Group Internet Draft H. Cheng K.H. Ling Document: draft-cheng-mobility-issues-00.txt Panasonic Singapore Labs Expires: August 2004 February 2004 Mobility related issues for the QoS NSLP draft-cheng-mobility-issues-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The draft listed out some of the issues related to IP mobility that may have impact on the design and implementation of the NSIS protocols. These issues, namely, the multiple flow support and the ping-pong type of movement, needs to be considered in the context of the QoS NSLP protocol design, so that the NSIS framework would not break when they present. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents Cheng Expires - August 2004 [Page 1] Internet-Draft Mobility related Issues for QoS NSLP February 2004 1. Introduction...................................................2 2. Terminology....................................................3 3. Multiple flow support for QoS NSLP.............................3 3.1 Management of the state on old data path...................4 3.2 The solution for the multiple flow support.................4 4. Fast re-establishment of signaling path (with Ping Pong effect)5 4.1 Problem description........................................5 4.2 Solutions for the Ping-pong type of movement...............7 5. Security Considerations........................................7 6. Conclusions....................................................7 References........................................................7 Acknowledgments...................................................8 Author's Addresses................................................8 Intellectual Property.............................................9 Full Copyright Statement..........................................9 1. Introduction In the defined NSIS framework [3], a two-layer architecture is used, wherein the NSLP layer is the actual signaling application. The QoS NSLP draft [4] specifies an instance of the NSLP signaling application for the QoS provisioning and control. In the QoS NSLP draft, some of the operation for the QoS signaling has been defined, but the impacts of mobility are not considered in detail. When the NSIS signaling involves the mobile nodes, there are different requirements to be considered. Although the NSIS framework depends on the existing mobility protocols to shield it from the detail mobility management, some mobility related problems still present to the NSLP layer in a different form. This draft discussed in detail two of such problems, the multiple- flow support, and the ping-pong type of movement, and their potential impacts on the QoS NSLP. The QoS NSLP deals mainly with the state management for the delivery of data flow. It is in charge of providing necessary forwarding resources for the flow [4]. Therefore, the two problems mentioned above have to be solved at the NSLP layer, since they are related to resources management and require the state information. The discussion of the issues would benefit the design of the QoS NSLP protocol. If these issues are not solved, they could break the normal operation of the QoS signaling. For example, the QoS NSLP would not be able to use with multi-homing devices if it could not support simultaneous multiple flows. Similarly, the QoS NSLP would have a bad performance in face of ping-pong type of movement of the mobile terminal if no proper solution is incorporated into the QoS NSLP. Cheng et al. Expires - August 2004 [Page 2] Internet-Draft Mobility related Issues for QoS NSLP February 2004 2. Terminology The Terminology defined in [4] applies to this draft. In addition, the following terms are used: CRN: Crossover Node NAR: New Access Router OAR: Old Access Router 3. Multiple flow support for QoS NSLP In the NSIS signaling environment, there could be situations that one session contains multiple flows simultaneously. It could be caused by one or a combination of the following reasons: 1. One application session may have several sub flows, and they could go via different data path and owns different QoS requirements. The different data path for the flows could be due to load balancing reasons, or performance optimization reasons. For example, in the Audio-Visual communication, there could be several flows for different media streaming. One session may have several sub-sessions, e.g. sub-layers of the MPEG4 content could be sent over with different flows. Another example is that the FTP session could be using several streaming channels/ports for downloading the same file in order to boost the speed. 2. Multiple access interface for one network node (multi-homing). For example, in the dual/multi mode Mobile Node (MN), there may be more than one interface involved in the communication, both WLAN and UMTS. Some service session would be across both of the interface which could use different IP address. In the 3GPP WLAN interworking specification [3GPP TR22.934] requires the interworking terminal to be able to support simultaneous connections over its WLAN and UMTS interface for scenario 3. 3. When the mobile terminal experiencing a soft handover. During the handover time, the QoS reservation for the new connection would need to be set up, before the QoS reservation for the old connection being torn down. So, there would be multiple flows belonging to the same session co-exists for the transition time. In NSIS, the flow-ID is used to represent the flow information. In most of the mobility discussions, the flow-ID is used to detect the Cheng et al. Expires - August 2004 [Page 3] Internet-Draft Mobility related Issues for QoS NSLP February 2004 movement of the mobile terminal and discover of the Crossover Node (CRN). Therefore, if a signaling message with the same Session ID but different flow-ID reaches a NSIS node, it would be deemed as a route change or mobility event. According to the discussion above, this conclusion is not necessary correct, since it could simply be a multi-homing device utilizing another interface. Therefore, the QoS NSLP should be designed to distinguish the actual route change and a multiple flow case. 3.1 Management of the state on old data path In most of mobility discussions, it is assumed that when the re- establishment of the NSIS state along the new path is finished, the NSIS state along the old path should be removed since it waste of resources. In certain proposals, the CRN could initiate the teardown of the old state. As described above, this kind of assumption may cause problem for the QoS NSLP operation. In certain cases, the MN may want to keep the state along the old path even though the state along new path is set up. For example, a multi-homing MN may want to use multiple interfaces for the same session simultaneously. Also, if a dual mode MN is in a make-before-break handover, the reservation on the old path should be kept until the data traffic is actually switched to the new path. If the CRN initiated the teardown of the reservation on the old path immediately, it would affect the service for the MN. But for most mobility events, the state on the old path is desired to be removed, e.g. a MN did make a movement, or connection to the old path was lost. Fail to immediate initiate the removing of the state on old path would result in resource waste. Therefore, it is desirable for the network or the CRN to obtain information or intension of the MN before initiate the teardown of the state of old path. 3.2 The solution for the multiple flow support Solution to the above problems would not be a simple QoS NSLP issue. It requires coordination between the different layers of the NSIS framework, and possibly the mobility protocols. The general principle for solving the problem is to involve the MN in the state management decision, because it is the node that has the best information about the application session. This would also require the QoS NSLP at the MN to maintain interaction with its lower layers, e.g. obtaining the link status information. Cheng et al. Expires - August 2004 [Page 4] Internet-Draft Mobility related Issues for QoS NSLP February 2004 4. Fast re-establishment of signaling path (with Ping Pong effect) 4.1 Problem description When a MN moves from one access network to another, a handover require the MN to register with the new access network and to establish a new path from the New Access Router (NAR) to the Correspondent Node (CN). Usually, a MN will try to perform a make- before-break handover to achieve minimum service disruption. +--+ +---+ new flow new | |<<<<<<<<<<| |<<<<<<<<<<<<<^ address |MN| |NAR| ^ | |>>>>>>>>>>| |>>>>>>>>>>>v ^ +--+ +---+ v ^ ^| +---+ +--+ || | |<<<<<<<<<<| | ||ping-pong |COR| |CN| ||type of movement | |>>>>>>>>>>| | || +---+ +--+ |v+--+ +---+ v ^ shared original | |<<<<<<<<<<| |<<<<<<<<<<>>>>>>>>>| |>>>>>>>>>>>>>^ +--+ +---+ original flow Figure A: Figure A shows the interactions between the MN and the CN. During a handover, the MN tries to establish the new path either from the NAR or the OAR. A mobile handover requires several cumbersome procedures such as CT/CARD, end-to-end path setup, CRN discovery, etc. A handover requires end-to-end signaling and a fair amount of control load overhead. If the time took for setting up the new state is longer than actual handover process, disruption in services QoS is unavoidable. In the case of a ping-pong type of movement, the MN may moves from one access network to another, and returns to the previous access network in a very short duration. This would most likely happen in a wireless network, where the location change of the MN would cause the data route adjustment. Cheng et al. Expires - August 2004 [Page 5] Internet-Draft Mobility related Issues for QoS NSLP February 2004 ----------------------------- / \ +----+ | NETWORK |---| CN | \ / +----+ ----------------------------- | | +-----+ +-----+ | AR1 | | AR2 | +-----+ +-----+ |subnet 1 |subnet 2 +-----+ +-----+ | AP1 | | AP2 | +-----+ +-----+ ^ ^ \ / --------- ------- \ / v v +-----+ | MN | +-----+ .... .... Figure B: Figure B shows the movement of a MN between two access networks. The problem can be very prominent in a wireless environment when the MN moves along the boundary of two access networks. The movement of the MN may cause frequent switches between the access networks and thus resulting in multiple handovers in a very short duration. Performance of the network can be severely hampered. Typically during a handover, the states of the old path are immediately released after the installation of states in the new path. This is usually for preventing the waste of resources. But this is not desirable when a ping-pong type of movement is involved. If the state is removed before the MN moves back to the old path, the MN needs to re-establish the state along the path again, which would be time consuming. It has been proposed in some draft that the old path can be retained for the remaining refresh period. Typically, the changed path is located inside an access network, where resources are relatively expensive, thus it might be inefficient to wait for typical soft- state timeouts. In the event that the mobile node does not move back to the old path within the refresh period, resources are wasted. For Cheng et al. Expires - August 2004 [Page 6] Internet-Draft Mobility related Issues for QoS NSLP February 2004 example, the normal refresh period is 30 sec, and the MNÆs ping-pong cycle is 40 sec, the solution would not work. This raises the issue of how should this duration be optimized such that it will strike a balance between resource wastage and fast path re-establishment. The problem for this solution is the randomness of the MN movement. 4.2 Solutions for the Ping-pong type of movement As mentioned above, the solution to this problem would always be a tradeoff between the resource wastage and re-establishment performance. A combination of different methods could be used to solve the problem. The general principle is to reuse the old state while reduce the resources wastage. Similar to the multiple flow problem, MN should also be involved in the management decision in solving the problem. 5. Security Considerations Security should be considered in the QoS NSLP as an integrated part. Usually mobility events would complicate the security relationships. For example, the teardown of the old state, reuse of old state in ping-pong type of MN movement all require extra security relationship to be established between signaling peers. Otherwise, any solution would be subject to attacks from the network. Future version of the draft would discuss the relevant security requirements for the solutions in detail. 6. Conclusions This draft discussed two issues, multiple flow support and Ping-pong type of movement, for the QoS NSLP when Mobile Nodes are involved in the signaling. These issues present serious problems for the QoS NSLP. If not properly address, these problems would hamper the correct operation of the NSIS framework. In the draft, some principles for developing the solutions for these problems are discussed. More details on the possible solutions is expected to be available in further version of the draft. References 1. "The Internet Standards Process -- Revision 3", BCP 9, October 1996, Cheng et al. Expires - August 2004 [Page 7] Internet-Draft Mobility related Issues for QoS NSLP February 2004 2. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997, 3. R. Hancock, et. al. ôNext Steps in Signaling: Frameworkö draft- ietf-nsis-fw-05.txt, October 2003 4. Sven Van den Bosch, "NSLP for Quality-of-Service Signalingö, draft-ietf-nsis-qos-nslp-01.txt, October 2003. Acknowledgments This section will contain acknowledgements. Author's Addresses Hong Cheng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #04-3530 Tai Seng Industrial Estate Singapore 534415 Phone: (+65) 6554 5477 Email: hcheng@psl.com.sg Kim Hui Ling Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #04-3530 Tai Seng Industrial Estate Singapore 534415 Phone: (+65) 6554 5418 Email: khling@psl.com.sg Cheng et al. Expires - August 2004 [Page 8] Internet-Draft Mobility related Issues for QoS NSLP February 2004 Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Cheng et al. Expires - August 2004 [Page 9] Internet-Draft Mobility related Issues for QoS NSLP February 2004 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cheng et al. Expires - August 2004 [Page 10]