Next Steps in Signaling (nsis) T. Sanda Internet-Draft T. Ue Expires: April 27, 2006 H. Cheng Panasonic October 24, 2005 Path type support for NSIS signaling draft-sanda-nsis-path-type-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract NSIS state management needs to track data path changes and update the states along the affected data paths. However, in certain scenarios, there are multiple concurrent paths involved in the communication. In this case, the normal NSIS scheme does not provide sufficient support for the state manipulation. Therefore, extra functionality for data path identification and distinction is necessary. In current Internet, with the increasing use of multi-homing devices and Sanda, et al. Expires April 27, 2006 [Page 1] Internet-Draft Path type support for NSIS October 2005 the employment of Mobile IP, the above issue is getting more prominent. This draft discusses in detail the problems and issues involved in the NSIS state management relevant to the data path differentiation. Specific scenarios for multi-homing and Mobile IP route optimization are studied. Potential solution and its impacts on current NSIS protocol design are discussed as well. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Problems in multi-interface terminal scenario . . . . . . 7 4.2. Problems in Mobile IP RO scenario . . . . . . . . . . . . 8 5. Requirement of signaling handling for multiple paths . . . . . 11 6. Path Type ID . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Path Type ID for Multi-link terminal scenario . . . . . . 13 6.2. Path Type ID utilization for Mobile IP scenario . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. Normative Reference . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Sanda, et al. Expires April 27, 2006 [Page 2] Internet-Draft Path type support for NSIS October 2005 1. 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 RFC2119 [1]. Sanda, et al. Expires April 27, 2006 [Page 3] Internet-Draft Path type support for NSIS October 2005 2. Introduction In the defined NSIS framework [2], a two-layer architecture is used, wherein the NTLP layer handles the general message routing and transport and NSLP layer carries out the actual signaling application. The GIMPS draft [3] defines the NTLP layer, and the QoS NSLP draft [4] specifies an instance of the NSLP signaling application for the QoS provisioning and control. These drafts specify that each signaling path state is managed with two identifiers, i.e. the flow identifier (Flow ID) and the session identifier (Session ID). In certain scenarios, communication nodes utilize plural data paths for one session. For example, a terminal that has multiple communication interfaces may communicate with the Correspondent Node (CN) using multiple data paths via multiple links for one session. For these multi-homed cases, the network may observe several path reservations even without any terminal movement. Therefore, special techniques have to be employed to distinguish this from an actual mobility event, so that no mobility handling procedure would be triggered. Another example is the Route Optimization (RO) in the Mobile IP environment. When a successful RO is performed, data will flow directly between the CN and the Mobile Node (MN) without going through the Home Agent (HA). Since the RO procedure makes use of the triangular (TR) path (path via the HA), it will always happen after the TR path is set up. Even after RO procedure is completed, TR path will be used when RO path is down. This means that the MN may use multiple paths to communicate with the CN. In the RO procedure, there is always a data path change involved, even though there is no actual address change. The first scenario where Flow ID doesn't work is when the address information cannot be represented by a single Flow ID, e.g., the multihoming case, or multi-thread case. In these cases, Flow ID in its current form is incapable of carrying the full information for the packet classification. Another scenario is when the NSIS signaling needs to be carried out before the actual data traffic flow starts. It is possible that at this point of time, some address information is not yet available, and thus the Flow ID cannot be generated according to the current specified method. This would happen most likely in the case of make-before-break reservation on predictive paths. In yet another scenario, the address information involved in the Flow ID generation may change during the course of the session, e.g. the port number or the DSCP/TOS fields. This does not necessary mean a route change, and should not always trigger the state change along the data path. Therefore, the Flow ID and the traffic classification information are not always synchronized. Sanda, et al. Expires April 27, 2006 [Page 4] Internet-Draft Path type support for NSIS October 2005 It is obvious from the above that the Flow ID and Session ID defined [3] [4] are not sufficient to support these more complicated reservation management, when multiple data paths are involved. In this draft, details of the problems and requirements for signaling handling multiple paths are discussed. A possible solution using a Path Type ID is also introduced. Sanda, et al. Expires April 27, 2006 [Page 5] Internet-Draft Path type support for NSIS October 2005 3. Terminology The Terminology defined in [2], [3] and [4] applies to this draft. In addition, the following terms are used: TR path: Triangular Path. A route between MN and CN with tunneled RO path: Route Optimized path. A direct route between MN and CN Sanda, et al. Expires April 27, 2006 [Page 6] Internet-Draft Path type support for NSIS October 2005 4. Problem Statement This section introduces two scenarios that multiple data paths are used for one session, one is multi-interface terminal case and the other is Mobile IP RO case, and shows examples NSIS state management cannot work properly. 4.1. Problems in multi-interface terminal scenario It is common nowadays for a terminal to be equipped with multiple communication technologies. For example, it is nature to have a combination of Ethernet, Wireless LAN, InfraRed, and Bluetooth interfaces installed on a laptop. Those best selling PDAs usually have cellular and Wireless LAN interfaces. In this draft, a multi- interface terminal is defined as one that can utilize more than two interfaces for one communication session. With the advance of the interworking study, e.g. IEEE802.11u and IEEE802.21, this may become a normal practice. In this case, multiple data paths are used for the communication simultaneously. Furthermore, if the interfaces are wireless, such as 802.11 WLAN, UMTS and so on, each interface can switch its attachment point independently. This means data paths are changed separately. The scenario discussed here is shown in Figure 1. MN is communicating with CN using two interfaces, "p" and "s", for one session. Interface "p" has a data path (Path1) via AP1, AR1 and QNE1 while interface "s" has a data path (Path2) via AP2, AR2 and QNE1. According to the NSIS draft [3] [4], QoS state would be installed on each data path and the same Session ID and different Flow IDs would be allocated for them. Sanda, et al. Expires April 27, 2006 [Page 7] Internet-Draft Path type support for NSIS October 2005 +--------+ +--------+ | CN | | CN | +--------+ +--------+ * * * * * * * * * * +--------+ +--------+ | QNE1 | | QNE1 | +--------+ +--------+ * * * * * * * * * * * * * * * Path1* *Path2 Path1* *Path2 *Path3 * * * * * * * * * * * * * * * +---+ +---+ +---+ +---+ +---+ |AR1| |AR2| |AR1| |AR2| |AR3| +---+ +---+ +---+ +---+ +---+ * * * * * +---+ +---+ +---+ +---+ +---+ |AP1| |AP2| |AP1| |AP2| |AP3| +---+ +---+ +---+ +---+ +---+ * * * X * * * * X * * * * X * * * * X* p=> | | <=s p=> | | <=s +------+ +------+ | MN | | MN | +------+ +------+ (a) (b) Figure 1. Multi-interface terminal scenario When the interface "s" performs a handover from AP2 to AP3 as shown in Figure 1(b), QoS state for Path2 is replaced by Path3, while Path1 should be maintained. In this case, QNE1 needs to know which path/ state must be replaced by Path3. However, since Flow ID for Path1, Path2 and Path3 are different and Session IDs for all paths are the same, it is impossible for QNE1 to know how to operate each path. 4.2. Problems in Mobile IP RO scenario As described in MIPv6 [5], the RO procedures will be performed if Sanda, et al. Expires April 27, 2006 [Page 8] Internet-Draft Path type support for NSIS October 2005 both the MN and the CN supports it. With optimization, data traffic will flow directly between MN and CN without going through the HA. This improves the efficiency of network resources utilization, and reduces the communication dependency on the MN's Home network. A nature of data path change in RO procedure is different from that resulted from a MN changing its point of attachment. Even after data path is changed from TR path to RO path, they are still related since they have different characteristics. A TR path will be reused when an RO path is aborted as well as when MN moves to a new location. When NSIS QoS state is installed in RO path, reservation state for the old path, i.e. TR path, may be required to be kept because it will be reused. Simultaneously, reserved resource for TR path may have to be reduced not to waste limited resources. Signaling management for each path would also need to be done separately, depending on control policies. Reservation state handling for TR path and RO path requires more flexibility than state handling for path changes caused by MN's move or re-routing. To realize flexible operation, it is desirable that every NSIS Node could differentiate RO path and TR path reservation state with NSIS protocols. Figure 2 shows one example scenario of a TR path and an RO path. When NSIS QoS state is made on a RO path (path "y"), a crossover node (CRN), e.g. a QNE3 needs to operate a TR path (path "x") properly. However, as it cannot differentiate a TR path and an RO path, operation for a TR path cannot be done. Furthermore, when MN moves to a new location (Figure 3), TR path (path "z") followed by RO path (path "w") will be utilized. This case, a CRN, such as QNE3 does not know which path have to be released because it cannot distinguish a path change caused by handover from the one caused by RO procedures. Sanda, et al. Expires April 27, 2006 [Page 9] Internet-Draft Path type support for NSIS October 2005 +----+x x x x +----+x x x x x+----+x x x+----+ | HA | |QNE2| |QNE3| | CN | | | | | | |y y y| | +----+ +----+ y +----+ +----+ x y x y +----+ y |QNE1| y | | y +----+ x y x y +----+ |AR1 | +----+ x y +----+ | MN | xxxxx TR at Location1 +----+ yyyyy RO at Location1 Figure 2. An example of TR path and RO path +----+x x x x +----+x x x x x+----+x x x+----+ | HA |z z z z |QNE2|z z z z z|QNE3|z z z| CN | | | | | | |y y y| | +----+ z +----+ y +----+w w w+----+ x z y w x z y w +----+ y z +----+ |QNE1| y z |QNE4| | | y z | | +----+ +----+ x y z w x y z w +----+ +----+ |AR1 | |AR2 | +----+ +----+ x y z w xxxxx TR at Location1 +----+ +----+ yyyyy RO at Location1 | MN | ------> | MN | zzzzz TR at Location2 +----+ +----+ wwwww RO at Location2 Figure 3. An example of TR path and RO path with MN's movement Sanda, et al. Expires April 27, 2006 [Page 10] Internet-Draft Path type support for NSIS October 2005 5. Requirement of signaling handling for multiple paths In order to handle signaling in scenarios described in previous sections, the NSIS signaling scheme must be modified to meet the following requirements: 1) The signaling identifiers must be able to distinguish each flows/ paths involved in the same session. For example, in Figure 1, Path 1, Path 2, and Path 3 must be clearly separated. 2) The signaling identifiers must be able to reflect the dependency and relationship between the flows/paths involved in the same session. For example, in Figure 1, Path 1 and Path 2 are serving the same session simultaneously, and thus should co-exist. Whereas, Path 2 and Path 3 are two different paths for the same interface at different time, and thus, Path 3 should replace Path 2. The first requirement is achieved in the current NSIS framework by using different Flow IDs for the different paths. Therefore, for the three paths, three separate Flow IDs would be generated, and those help to distinguish the different paths. However, the current NSIS have problem to meet the second requirement completely. Since the paths are all serving the same session, it is nature to use the same Session ID for all the signaling. This could indicate to the NSIS aware nodes, e.g QNEs, that the paths are belonging to the same session. By unsetting the REPLACE flag of the QoS NSLP [4], the signaling is able to indicate to the QNEs that the paths should co-exist. But, this cannot indicate to the QNEs that the Path 3 should replace Path 2. If the signaling message for Path 3 has the REPLACE flag set, it would replace states of both Path 2 and Path 1 over the common section. This is an undesired situation. In the NSIS Operation Over IP Tunnel draft [6], an ASSOCIATE_FLOW_SESSION object is proposed to further indicate the relationship between flows within a session, i.e. with the same Session ID. This will help to meet the requirement 2. However, this new object, which is big (of the size of Flow ID), needs to be embedded into the signaling for all the flows that has relationship with each other. It would be a overhead for the signaling, once the relationships between flows are complicated, it would be quite costly to the signaling. Another possible choice is to use different Session IDs in the signaling. For example, in Figure 1, since the Path 2 and Path 3 cannot co-exist, they will use the same Session ID. And Path 1 and Path 2 should co-exist, and thus would use different Session IDs. In order to indicate their relationship, the BOUND_SESSION_ID object of Sanda, et al. Expires April 27, 2006 [Page 11] Internet-Draft Path type support for NSIS October 2005 QoS NSLP [4] could be used to indicate that the two sessions should be bound so that resources could be shared. This way, the requirement 2 would be met. However, it also creates high overhead for the signaling, since every message needs to carry the BOUND_SESSION_ID object, and every QNE needs to support the session binding. In this draft a simply yet effective method is proposed. Instead of introducing the full-fledged binding/associate object, a simple object Path Type ID is used in conjunction with the use of same Session ID and different Flow IDs for the different flow/paths. This way, the requirement 2 can be met with easy. Following section describe the use of such solution with different scenarios. Sanda, et al. Expires April 27, 2006 [Page 12] Internet-Draft Path type support for NSIS October 2005 6. Path Type ID In order to introduce the dependency and relationship between the flows/paths involved in the same session, a new identifier called "Path Type ID" can be utilized. Path Type ID could be a few bit values or code which is carried by signaling messages and stored in QNEs with other identifiers. Since it is small, certain reserved fields of NSIS message header could be used to carry it. Therefore, minimum overhead would be added to the signaling.By comparing Path Type ID as well as Session ID and Flow ID, QNEs can operate multiple co-related paths properly. 6.1. Path Type ID for Multi-link terminal scenario In the scenario discussed in section 2.1, it is required that QNE1 determines which path/state should be replaced or maintained with minimal signaling exchanges. For this purpose, Path Type ID is utilized. In the scenario in Figure 1(b), Path Type ID for Path2 and Path3 is an identical values or code, which is different from that for Path1. QNE1 in Figure 1 (b) can replace a path2 to a path3 because it explicitly knows these two paths have the same Path Type ID value. MN can decide Path Type ID by information of interfaces, i.e. Path Type ID in this case shows the interface where the signaling message comes from or goes to. 6.2. Path Type ID utilization for Mobile IP scenario As discussed in Sec. 2.2, current NSIS protocol design cannot indicate the complicated relationship between TR path and RO path in the signaling. Since the RO is common for a MIPv6 enable network, NSIS protocols cannot support mobility properly without a solution to this problem. Path Type ID used in this scenario identifies the TR and RO paths. In the scenario in Figure 3, Path Type ID for paths "x" and "z" is an identical code or number (e.g., "TR") while Path Type ID for paths "y" and "w" is also identical but different from that for paths "x" and "z" (e.g., "RO"). MN can decide Path Type ID by the information from MIP layer, e.g. receiving Binding ACK message, and then set the Path Type ID in RESERVE message. Flexible operation for TR and RO paths is also possible. Even when MN A moves to location 2, QNEs could still distinguish the old path and new path by comparing Path Type ID and Flow ID. However, the Sanda, et al. Expires April 27, 2006 [Page 13] Internet-Draft Path type support for NSIS October 2005 method to explicitly associate TR path and RO path at the same location may be required. For supporting this functionality, an object to decide MN's location, such as mobility_event_counter mentioned in Applicability Statement draft [7] could be useful. Sanda, et al. Expires April 27, 2006 [Page 14] Internet-Draft Path type support for NSIS October 2005 7. Security Considerations Security should be considered in the NTLP/NSLP specifications as an integrated part. Specific issues in Route Optimization case will be essentially covered by the Route Optimization security in Mobile IPv6 [5]. Future version of this draft would discuss the relevant security requirements for the solutions in detail. Sanda, et al. Expires April 27, 2006 [Page 15] Internet-Draft Path type support for NSIS October 2005 8. Conclusion This draft discussed potential problems related to NSIS QoS state management for multiple paths caused by multi-interface terminal and Mobile IP RO procedures. As one possible solution, Path Type ID was introduced so that QNEs could perform flexible state management for each path. This draft also includes some other discussions relevant to the problems on usage of Flow ID as a packet classifier. Use cases are analyzed with regarding to the requirements. Sanda, et al. Expires April 27, 2006 [Page 16] Internet-Draft Path type support for NSIS October 2005 9. Acknowledgements This section contains the acknowledgements. 10. Normative Reference [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hancock, R., "Next Steps in Signaling (NSIS): Framework", RFC 4080, Informational , June 2005. [3] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", Internet Draft draft-ietf-nsis-ntlp-08, Work in progress , September 2005. [4] Manner, J., "NSLP for Quality-of-Service Signaling", Internet Draft draft-ietf-nsis-qos-nslp-07, Work in progress , July 2005. [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility support in IPv6", RFC 3775, June 2004. [6] Shen, C., "NSIS Operation Over IP Tunnels", Internet Darf draft-shen-nsis-tunnel-00, Work in Progress , July 2005. [7] Lee, S., "Applicability Statement of NSIS Protocol in Mobile Environments", Internet Draft draft-ietf-nsis-applicability-mobility-signaling-02, Work in progress , July 2005. Sanda, et al. Expires April 27, 2006 [Page 17] Internet-Draft Path type support for NSIS October 2005 Authors' Addresses Takako Sanda Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3, Hikarino-oka, Yokosuka City Kanagawa 239-0847 Japan Phone: +81 46 840 5764 Email: sanda.takako@jp.panasonic.com Toyoki Ue Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3, Hikarino-oka, Yokosuka City Kanagawa 239-0847 Japan Phone: +81 46 840 5816 Email: ue.toyoki@jp.panasonic.com Hong Cheng Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534415 Singapore Phone: +65 6550 5477 Email: hong.cheng@sg.panasonic.com Sanda, et al. Expires April 27, 2006 [Page 18] Internet-Draft Path type support for NSIS October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sanda, et al. Expires April 27, 2006 [Page 19]