NSIS Working Group Internet Draft T. Sanda T. Ue H. Cheng Document: draft-sanda-nsis-path-type-02.txt Panasonic Expires: August 2005 February 2005 Path type support for NSIS signaling draft-sanda-nsis-path-type-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 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 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 T. Sanda et al. Expires - August 2005 [Page 1] Internet-Draft Path type support for NSIS signaling February 2005 studied. Potential solution and its impacts on current NSIS protocol design are discussed as well. 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 [1]. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Multi-interface terminal scenario...........................3 3.1 Problems in multi-interface terminal scenario............3 3.2 Solution with Path Type ID utilization...................5 4. Mobile IP scenario..........................................5 4.1 Problems in Mobile IP RO scenario........................5 4.2 Solution with Path Type ID utilization...................8 5. Other requirements relevant to NSIS identifiers.............9 5.1 Use of packet classifier vs. Flow ID.....................9 6. Security Considerations....................................11 7. Conclusions................................................11 References....................................................11 Author's Addresses............................................12 Intellectual Property.........................................13 Full Copyright Statement......................................13 1. 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 T. Sanda et al. Expires - August 2005 [Page 2] Internet-Draft Path type support for NSIS signaling February 2005 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. 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 a solution using a Path Type ID are discussed. Impacts on the current protocol design, and the advantage and disadvantage of each solution are also analyzed in the subsections of the draft. 2. Terminology The Terminology defined in [3,4,6] 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 3. Multi-interface terminal scenario 3.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 T. Sanda et al. Expires - August 2005 [Page 3] Internet-Draft Path type support for NSIS signaling February 2005 "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. +--------+ +--------+ | 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. T. Sanda et al. Expires - August 2005 [Page 4] Internet-Draft Path type support for NSIS signaling February 2005 A possible solution for this is to have the MN indicate which path to be maintained or replaced explicitly by specifying the specific Flow ID to replace in an extra message exchange with the QNEs, which will increase signaling overhead. 3.2 Solution with Path Type ID utilization In the scenario discussed in sec. 3.1, it is desirable for QNE1 to determine which path/state should be replaced or maintained with minimal signaling exchanges. For this purpose, each QNE could utilize a new identifier called "Path Type ID", which identifies a MN's interface. Path type ID is indicated in RESERVE messages. Each QoS state in QNEs has a Path Type ID as well as a Session ID and a Flow ID so that QNE can differentiate MN's interfaces without explicit signaling. In the scenario in Figure 1(b), Path Type ID for Path2 and Path3 is an identical code or number (e.g., "s"), which is different from that for Path1 (e.g., "p"). 4. Mobile IP scenario 4.1 Problems in Mobile IP RO scenario As described in MIPv6 [6], the RO will be performed if 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. Due to the MIPv6 security requirements, a Return Routability procedure must be carried out during the RO. Therefore, the data path through the HA needs to be available before the RO is carried out. The relationship between a RO path and TR path is special. They are separate data paths, with different characteristics, but they are also related since the MN is actually at the same location using the same CoA. The MN could communicate with the CN using different path at different stage of the session. Moreover, when the MN moves to a new location, the TR path will need to be used again. Therefore, the change of the data path in RO procedure is different from that resulted from a MN changing its point of attachment. The NSIS signaling for the TR path and RO path of the same session may have overlapped sections. When NSIS QoS state is installed, double resource reservation over these paths needs to be avoided. To this end, mechanisms similar to those for a MN handover could be used. However, unlike path change caused by MN's movement, MN is still reachable to CN via the TR path in RO case. TR path would be reused when RO path is aborted, or MN moves to a new location. Therefore T. Sanda et al. Expires - August 2005 [Page 5] Internet-Draft Path type support for NSIS signaling February 2005 reservation state for the old path, i.e. TR path, may have to be kept. 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 TR path and RO path with MN A's movement. Each QNE along overlapping sections needs to recognize each path and decide on how to operate the states, e.g. which paths are required to be replaced or refreshed. T. Sanda et al. Expires - August 2005 [Page 6] Internet-Draft Path type support for NSIS signaling February 2005 +----+x x x x x x x x x x x x+----+x x x x+----+x x x x+----+ | HA |z z z z z z z z z z z z|QNE3|z z z z|QNE4|z z z z|CN B| | | y| |y y y y| |y y y y| | +----+ y +----+ +----+w w w w+----+ x z y w x z y w +----+ y w |QNE2|z y w | | z y w +----+ y z w x y z w x y z w +----+ y z +----+ |QNE1|y z |QNE5| | | z| | +----+ +----+ x y z w x y z w +----+ +----+ |AR1 | |AR2 | +----+ +----+ x y z w x y z w +----+ +----+ |MN A| |MN A| | | ---------------> | | +----+ +----+ location1 location2 xxxxx TR path at Location1 yyyyy RO path at Location1 zzzzz TR path at Location2 wwwww RO path at Location2 Figure2: An example of TR path and RO path with MN's movement When identifiers are manipulated as specified by the current NSIS protocols, there are two ways to differentiate the TR and RO paths. One possible method is to use different Session IDs to identify each path. In this case, each path will be treated as an independent session and would be managed separately. For example in Figure 2, the TR path (between CN B and MN A at location1, i.e. path x) and the RO path (between CN B and MN A at location1, i.e. path y) can be differentiated by QNEs easily since the Session IDs used are different. Differentiations between TR paths at different locations (e.g. path x and path z), and RO paths at different locations (e.g. T. Sanda et al. Expires - August 2005 [Page 7] Internet-Draft Path type support for NSIS signaling February 2005 path y and path w) are also easy because corresponding Flow ID changes when MN moves. However, using different Session IDs for TR and RO paths means that a session binding function is needed to associate the two paths at the same location to avoid double reservation. Besides, when a MN performs handover, session binding needs to be modified according to the change of crossover node between TR and RO paths. This operation could be complicated and will be initiated by MN because only MN knows which path is TR or RO path. This reduces the flexibility of the NSIS protocols, and adds burden to MN that has limited resources, e.g. computation power and memory. Another possible method for TR and RO path handling is to use the same Session ID. In this case, session binding function is not necessary. However, QNEs (such as QNE1 and QNE3 in Figure 2) cannot distinguish the path change caused by RO procedure from that caused by MN's movement. Besides, when a MN performs handover, a crossover node (such as QNE4 in Figure 2) cannot distinguish which path/state must be replaced or maintained without explicit signaling that designates specific Flow ID from MN. 4.2 Solution with Path Type ID utilization As discussed in Sec. 4.1, 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. The general problem is regarding how to differentiate the TR and RO paths. Since the Flow ID is not able to indicate that, some extra information element is necessary. For this purpose, each QNE could utilize "Path Type ID", which identifies the TR and RO paths. Path type ID is indicated in RESERVE messages. Each QoS state in QNEs has a Path Type ID as well as a Session ID and a Flow ID so that QNE can differentiate the TR and RO paths without explicit signaling. In the scenario in Figure 2, 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"). Since it is short, certain reserved fields of NSIS message header could be used to carry it. Therefore, minimum overhead would be added to the signaling. 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. In the case with same Session ID and different Flow IDs, when states for path x followed by path y are installed, QNE1 and QNE3 could T. Sanda et al. Expires - August 2005 [Page 8] Internet-Draft Path type support for NSIS signaling February 2005 distinguish the path change caused by RO procedure from that caused by MN's movement. Flexible operation for these two 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 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 [5] could be useful. 5. Other requirements relevant to NSIS identifiers 5.1 Use of packet classifier vs. Flow ID In the current NSIS protocol [3,4], it is suggesting that the Flow ID should contain the data packet routing information, and that it would be used for classifying the data traffic. However, this may cause problems in a complicated scenario. A few examples are given below: a) In some scenarios, reservation pre-setup would be necessary. One example is the state pre-establishment in a mobile environment, e.g. a proxy establishes a new path before a MN's actual movement. In this case, full information to classify data packets, e.g. MN's new CoA, may not be available at the first time. If the Flow ID is employed as the data packet classifier, it is impossible for a proxy to generate the Flow ID, and time will be wasted for the proxy to wait for MN obtaining the new CoA. However, if the Flow ID is not related to the packet classifier, the proxy can create a Flow ID with, for example, proxy's IP address instead of MN's CoA, and can send signaling messages for installing GIMPS state along the new path and for discovering the CRN. Another example is the scheduled reservation, i.e. resource reservation for pre-set time such as scheduled teleconference. This case, full information to classify data packets, e.g. port numbers, may not be available. However, if Flow ID can only be used for signaling path management, port numbers would not always be necessary in it. Therefore, the separation of Flow ID from data packet classifier information is necessary. b) Nowadays, a communication session usually contains several threads, e.g. a FTP client would create 3 to 5 threads simultaneously to boost up the downloading speed. Therefore, packets for the same session may bear different address attributes. In this case, the current Flow ID is not sufficient for the classification of the data packets for a session. T. Sanda et al. Expires - August 2005 [Page 9] Internet-Draft Path type support for NSIS signaling February 2005 For example, in a FTP session, a user terminal would fork up several threads, with each taking a local port, say 10001 and 10002. When connected to the FTP server, different ports would be allocated for these threads, say 21001 and 21002. If NSIS is to be used for the QoS management for this session, a single Flow ID is not able to represent the different ports involved in the session. Although wildcarding is mentioned in [3], it still does not solve the problem, especially there are other sessions exist between these two nodes. For example, the same user may be accessing AV streaming from the same server at the same time using port 10003 and 10004. Wildcarding would not be able to support separation of the FTP and AV streaming sessions. Multimedia application is another widely used example of multi-port communications. When the RTP is employed for AV streaming/conference, different RTP sessions would be used for audio and video streams. So, NSIS would face the same problem if the audio and video streams are to be managed as one NSIS session. When aggregation happened, the multi-port communication would also be incurred. This mainly occurs on NSIS nodes that is not the communication ends. With the above example, it is clear that using the Flow ID as the packet classifier does not support the most commonly used applications over the Internet. Thus, a classifier that can represent multiple address attributes should be separated from the Flow ID. c) As discussed in draft [3,5], a Flow ID will be generated based on the protocol address information. For the RO path in Mobile IP scenario, it is quite obvious that the Flow ID would be based on the CoA of the MN and the CN address. However for a TR path there are tunnels involved between MN and HA. Therefore, several combinations are possible for the use of Flow IDs to represent the paths in NSIS signaling. Generally, there are three options: - Flow ID based on HoA of MN and CN address for the whole TR path; - Combination of Flow ID based on CoA of MN and HA address for tunneled section and Flow ID based on HoA of MN and CN address for section between HA and CN; - Flow ID based on CoA of MN and CN address for the whole TR path. In first case and third case, Flow ID could not be used as packet classifier because header information for TR path is not the same as what is used to generate Flow ID. Therefore, packet classifier should be considered separately from Flow ID. Usually, the data packet classifying information depends on the NSLP application, e.g. the QoS Model used. Therefore, it would be proper to include that in the NSLP layer, e.g. in the QSpec. Some object T. Sanda et al. Expires - August 2005 [Page 10] Internet-Draft Path type support for NSIS signaling February 2005 like FlowSpec would be useful in QSpec to indicate the actual packet filter information. 6. 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 [6]. Future version of this draft would discuss the relevant security requirements for the solutions in detail. 7. Conclusions 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. References 1. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997, 2. R. Hancock, et al. "Next Steps in Signaling: Framework" draft- ietf-nsis-fw-07, (work in progress) November 2004 3. H. Schulzrinne, R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-04, (work in progress) October 2004 4. Sven Van den Bosch, et al. "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-05, (work in progress) October 2004 5. S. Lee, et al. "Applicability Statement of NSIS Protocol in Mobile Environments", draft-ietf-nsis-applicability-mobility- signaling-00.txt, (Work in progress) October 2004 T. Sanda et al. Expires - August 2005 [Page 11] Internet-Draft Path type support for NSIS signaling February 2005 6. D. Johnson, C. Perkins, J. Arkko "Mobility Support in IPv6", June 2004, 7. Jerry Ash, Attila bader, Cornelia Kappler "QoS-NSLP QSpec Template", draft-ietf-nsis-qspec-02, (work in progress) December 2004 8. F. Baker, et al. "Aggregation of RSVP for IPv4 and IPv6 Reservations", September 2001, Author's 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 Blk 1022 TaiSeng Ave, #06-3530 TaiSeng Ind. Est. Singapore 534415 Phone: (+65) 65505477 Email : hcheng@psl.com.sg T. Sanda et al. Expires - August 2005 [Page 12] Internet-Draft Path type support for NSIS signaling February 2005 Intellectual Property 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. Full 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." "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. T. Sanda et al. Expires - August 2005 [Page 13]