Next Steps in Signaling (nsis) H. Cheng Internet-Draft Q. Huang Expires: January 16, 2006 T. Sanda T. Ue Panasonic July 15, 2005 NSIS Flow ID and packet classification issues draft-cheng-nsis-flowid-issues-01.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 January 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In current NSIS signaling, Flow ID is used for multiple purposes, e.g., providing routing information for signaling traffic, identifying signaling state on NSIS nodes, and supplying packet classification information regarding the data flow being signaled. Due to the incompatibility of these functions, adverse effects are introduced into NSIS operation, especially when addressing Cheng, et al. Expires January 16, 2006 [Page 1] Internet-Draft NSIS Flow ID issues July 2005 information is complicated. In this draft, three scenarios where the Flow ID cannot function properly are discussed, namely the Multiple address case, Make-before-break case, and Address variation case. In view of this, a solution employing a separate NSLP payload object, i.e., Filter List, is proposed. The solution solves the Flow ID usage problem in the three cases, and its operation details and impacts on different aspects of NSIS system are reviewed in the draft. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Problem analysis for Flow ID usage . . . . . . . . . . . . . 7 4.1 Multiple addresses involved session . . . . . . . . . . . 8 4.2 Make-before-break reservation scenarios . . . . . . . . . 10 4.3 Address information variation case . . . . . . . . . . . . 10 5. Filter List for NSIS siganling . . . . . . . . . . . . . . . 13 5.1 Filter list usage with multiple addresses involved sessions . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Filter list usage with make-before-break reservation . . . 14 5.3 Filter List support of address information variation . . . 15 6. Filter List impact Analysis . . . . . . . . . . . . . . . . 16 6.1 Filter List mpact on the framework/NTLP . . . . . . . . . 16 6.2 Filter List impact on the NSLP . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1 Normative Reference . . . . . . . . . . . . . . . . . . 20 10.2 Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . 23 Cheng, et al. Expires January 16, 2006 [Page 2] Internet-Draft NSIS Flow ID issues July 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]. Cheng, et al. Expires January 16, 2006 [Page 3] Internet-Draft NSIS Flow ID issues July 2005 2. Introduction In NSIS signaling, Flow ID is derived from information such as source and destination IP addresses, protocol identifiers and port numbers, DSCP/TOS field, and etc [2]. It is used for multiple purposes in current NSIS signaling protocol design for different modules related to NSIS signaling. Firstly, at NTLP layer, Flow ID is used to provide routing information for the signaling message such that the signaling flow follows the exact path of the data flow being signaled [2]. Secondly, at NSLP layer, Flow ID is used for state management. For example, in QoS NSLP, the QNE will decide if a state of an old signaling branch should be torn down based on the Flow ID of a newly received RESERVE message. Thirdly, Flow ID is also used to carry information for packet classification for the data flow being signaled. The functionalities of Flow ID described above are proved working for scenarios depicted in NSIS draft [2] [3] [4]. However, for other scenarios, e.g., the three examples described below, Flow ID may not be able to fulfill the requirements of such functions. The main issue of using Flow ID in these scenarios is its dependency on the address information of the data traffic. 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. Besides the issues of working in above scenarios, the current Flow ID usage also requires NTLP to process additional information only meaningful to packet classification. This overburdens the NTLP contrasting to its designed duty, i.e., signaling message transportation [3]. In current NSIS, NTLP has to process this additional information when it process Flow ID for message routing. In view of the above issues for the Flow ID usage, this draft Cheng, et al. Expires January 16, 2006 [Page 4] Internet-Draft NSIS Flow ID issues July 2005 proposes a separate NSLP layer object for the packet classification information. With the introduction of this new object, Flow ID is freed from the strict requirements on the accurately representing data traffic addressing. Therefore, problems presented in the three scenarios can be avoided, and NTLP optimization becomes possible. Operation details and impact analysis in this draft shows that the proposal effectively solves the mentioned Flow ID issues and brings minimum impact on the current NSIS framework. Cheng, et al. Expires January 16, 2006 [Page 5] Internet-Draft NSIS Flow ID issues July 2005 3. Terminology The Terminology defined in [2], [3] and [4] applies to this draft. In addition, the following terms are used: Filter List: A list of address attributes that can be used for classifying the packets associated with a particular flow. Flow ID and MRI are used interchangeably in this draft. Cheng, et al. Expires January 16, 2006 [Page 6] Internet-Draft NSIS Flow ID issues July 2005 4. Problem analysis for Flow ID usage In the existing NSIS Working Group drafts, the Flow ID is defined as an identifier that "provide enough information such that the signaling flow receives the same treatment along the data path as the actual data itself" [2]. It is also identified that information to be used for the identifier includes Source IP address, Destination IP address, protocol identifier and higher layer (port) addressing, flow label, SPI filed of IPsec data, and DSCP/TOS filed. The reason for placing the Flow ID in the NTLP layer is to allow visibility and modification at the address boundaries [2]. There are multiple usages of Flow ID described in NSIS drafts. In the GIMPS document [3], the Flow Identifier is further utilized as the Message-Routing-Information (MRI). The MRI is then required to be set at message sender and is read only by the GIMPS. A formation of the Flow Identifier is provided as: Flow-Identifier = Network-layer-version Source-address prefix-length Destination-address prefix-length IP-protocol Traffic-class [flow-label] [ipsec-SPI/L4-ports] In the signaling applications, it is usually necessary to have information about the flow classification for the enforcement. Based on the description of the signaling applications drafts, the flow should be identified solely by the MRI. For example, in the QoS-NSLP draft [4], only information about the flow is the Flow ID passed from the GIMPS. Even in the QSPEC defined in [5], there is no information about the packet classification. Therefore, it is assumed that the QNE would only be able to set the Packet Classifier in its Traffic Control module based on the Flow ID. In the QoS-NSLP draft [4], it is also mentioned that the Flow ID is used for the signaling state management. For example, it will help the QNE to detect a mobility event. It is obvious from the above that the Flow ID is heavily depended on in the NSIS signaling, and therefore has multiple functions Cheng, et al. Expires January 16, 2006 [Page 7] Internet-Draft NSIS Flow ID issues July 2005 associated. This kind of overloading of the Flow ID works fine with a simplified static network environment. However, with scales of the network growing and complexities increasing, adverse impacts are introduce to NSIS, with the Flow ID striving to meet the requirements of all the functions. Following sections provide detail analysis of three examples where Flow ID of current NSIS design may not function properly. 4.1 Multiple addresses involved session In nowadays network, a communication session usually involves multiple addresses at the end nodes. The multiple addresses could be different IP addresses, e.g. in a multihoming case. With the new development trend, more terminal devices are equipped with multiple communication technology/interfaces. When these different interfaces are used for the same session, for various reasons [6], multiple addresses would be employed for the session, and thus should be supported by the NSIS signaling. The multiple addresses could be also the different higher protocol addresses, e.g. several port numbers used in a multiple thread session. This type of multi-thread method is widely used in some popular FTP clients. Usually, a download session would be limited by the server resource allocation and network condition. The throughput achieved is thus also limited. To boost the downloading speed, the FTP clients can establish multiple connections with the server, and download the file simultaneously. This would achieve much higher throughput. In the process, the terminal device will use multiple ports in the communication for the multiple connections. Since all these concurrent connections belong to the same session, it is better for NSIS to signal all the port numbers in one single signaling message. Taking the current Flow ID design into consideration, it is obvious that the above scenarios could not be properly supported. Due to its simple format, a single Flow ID is not able to represent the complex multiple addresses involved in a session. For example, in the NSIS Framework draft [2], it is mentioned that only limited wildcarding is provided for the Flow ID. However, wildcarding is not able to accurately represent the IP addresses or port numbers that are different on several bits. For example, port number 10001 and 10002 cannot be signaled with simple wildcarding. In the GIMPS draft [3], the MRI object format is provided. In this format, it is clear that only one set of address information could be incorporated. This is acceptable if the MRI is only used for the routing of the signaling message, because most likely the packets for the same flow with the different addresses should be routed through Cheng, et al. Expires January 16, 2006 [Page 8] Internet-Draft NSIS Flow ID issues July 2005 the same data path. On the other hand, if MRI object is also used for the data packet classification, it would create problem. For example, if only one of the addresses is included in the MRI, packets with other addresses will not be correctly classified. This may result in the situation where packets with other addresses cannot enjoy the proper QoS treatment. On the other hand, if a mask is used for the addresses, it may allow a wider address range than actually desired. In the QoS NSLP case, this could result in loss to the user, both on accounting and QoS level because the resource reserved may be shared by other traffic. Some quick remedy to this could be made by tweaking the "Message- Routing-Method" definition, and allow some special bit to indicate multiple address objects. However, this may also creates overhead in the NTLP layer processing. Since the NTLP layer does not need to care about the packet classification details, the multiple addresses in MRI affect the overall signaling speed. Another obvious solution is to use multiple signaling sessions for each set of address information. This solution may face a couple of problems. One problem is the significant increase in signaling, processing, and state management overheads. The increment of the overhead is in proportion to the number of address combinations. For example, when an application session makes use of five different ports on a MN, five separate NSIS sessions needs to be signaled. The other problem is that certain relationships have to be enforced between these signaling sessions. These sessions should share the same fate and probably share the resource reserved because they actually signal for the same application. This kind of relationship enforcement between signaling sessions may further complicate the signaling and state management logics. Another possible way to carry the multiple addresses information is to signal multiple times, each with the same Session ID and a different Flow ID that accurately represents one of the address information in use. Obviously, this creates signaling overhead. Besides that, it may also cause difficulties in state management on NSIS nodes. For example, a QNE receiving several messages with different Flow IDs will not be able to decide the proper action. The REPLACE flag introduced in [4] provides a way to indicate the action to the QNEs. Nevertheless, it requires explicit signaling for the management of these different Flow IDs. For instance, if a mobility event happened, the state with the old Flow IDs should be replaced with a new set with new Flow IDs. Therefore, the signaling message needs to indicate state with which particular Flow IDs should be replaced, and which should be kept. This requires extra state management logic at the QNEs. Cheng, et al. Expires January 16, 2006 [Page 9] Internet-Draft NSIS Flow ID issues July 2005 4.2 Make-before-break reservation scenarios Predictive routing support in NSIS is mentioned in [3], where the signaling is sent along the path that the data flow may or will follow in the future. The use of predictive routing is crucial for make-before-break reservation on predictive paths in mobility scenarios. Make-before-break is necessary for minimum QoS interruption at the time of handover [7] since performing NSIS signaling after the MN's actual handover causes service interruption due to the delay in signaling path establishment. Example procedure of make-before-break is as following: when the MN intends to handover, it obtains the information of new subnetwork and a suitable proxy NE on the predictive path, such as new Access Router (nAR), by using proper mobility protocols e.g. FMIP [8] or CARD [9]; then the MN asks the nAR to perform NSIS signaling along predictive route. At this stage nAR may or may not obtain MN's nCoA which is necessary for generating packet classifier for the predictive path. If the nAR has already obtained MN's nCoA, the nAR could send a RESERVE message to pre-reserve QoS resources so that QoS level can be maintained without interruption. However, since handover is not yet performed, i.e., the MN is still in another subnet, the new packet classification information should not replace the old packet classification information at overlapped path sections. This requires the NSIS signaling over the overlapped path to carry both new and old packet classification information. This requires separate management for Flow ID and packet classification and different operation for packet classification. Even if the nAR doesn't have MN's nCoA, it is still desirable that the nAR prepares QoS reservation by sending a signaling message which does not include packet classification information. For example, the nAR sends QUERY message to check resource availability on the predictive path and installs NSIS path state between the nAR and correspondent node (CN) at NTLP level. However, if Flow ID has to be derived from the actual data flow addressing, no proper Flow ID could be used for the initial signaling. This means nAR cannot send any signaling message until obtaining MN's NCoA. This renders the usage of make-before-break limited. 4.3 Address information variation case In certain cases, the address information, e.g. port number, may change during the process of a flow. According to the current definition of Flow ID and MRI, it may result in the change of the Flow ID (which may trigger further NSIS signaling procedures). Cheng, et al. Expires January 16, 2006 [Page 10] Internet-Draft NSIS Flow ID issues July 2005 An example of the address varying application process is the establishment of a H.323 session [13]. Protocol like H.323 establishes the session progressively with the help of different auxiliary protocols. Figure 1 shows a typical example of a H.323 session establishment process. +--------+ +--------+ | Node A | | Node B | +--------+ +--------+ | | | SETUP (To well known port,e.g. 1720) | ---+ |---------------------------------------->| | | | |Stage 1 | ALERTING | | Q.931 |<----------------------------------------| | (TCP) | | | | Connect (H.245 Address) | | |<----------------------------------------| ---+ | | | H.245 Exchanges | ---+ |<--------------------------------------->| | | | | | Open LogicChannel (RTCP Address) | | |---------------------------------------->| | | | |Stage 2 | Open LogicChannel Ack(RTCP, RTP address)| | H.245 |<----------------------------------------| | (TCP) | | | | Open LogicChannel (RTCP Address) | | |<----------------------------------------| | | | | | Open LogicChannel Ack(RTCP, RTP address)| | |---------------------------------------->| ---+ | | | RTP Stream | ---+ |---------------------------------------->| | | | |Stage 3 | RTP Stream | | RTP |<----------------------------------------| | (UDP) | | | | RTCP Stream | | |<--------------------------------------->| ---+ Figure 1. An example session establishment process using H.323 Cheng, et al. Expires January 16, 2006 [Page 11] Internet-Draft NSIS Flow ID issues July 2005 In the above example, the actual RTP session will only be initiated at stage 3, which means the port address may change several times before the first RTP data packet is sent out. However, the NSIS messaging needs to start in Stage 1, e.g. to open the firewall pinholes. The problem created from this is that when the address information changes, the Flow ID needs to be changed accordingly, so that NSIS aware nodes along the path can obtain the correct packet classification information. Otherwise, the local enforcer, e.g. the RMF, could not perform its function correctly. However, the change in the Flow ID means another round of NTLP layer path establishment according to GIMPS draft [3]. The reason is that the primary key of the message routing state is the combination of MRI, SID and NSLPID. Change of Flow ID means a primary key change and the message routing state has to be re-established. Besides this, in the process mentioned above, there could be multiple ports opened at the same time, and different transport protocol utilized. All these call for a simple way of changing the packet classification information along the signaling path without affecting the signaling state information. Cheng, et al. Expires January 16, 2006 [Page 12] Internet-Draft NSIS Flow ID issues July 2005 5. Filter List for NSIS siganling In view of all the problems of the Flow ID in supporting scenarios described in section 4, two improvement requirements should apply to the NSIS signaling: - MRI or the Flow ID should only carry out its designed function, providing the message routing information. Data packet classification information should be carried over other objects. - There should be ways to modify the data packet classification information along the data path without causing any change to the path state. It is because not all the change in address information means a change in the data path. To this end, this draft proposes to use a separate Filter List in the NSLP layer payload to carry data packet classification information. This way, the MRI/Flow ID is freed from the address dependency. It can then take any form or using any type of masking, as long as it provides enough information to allow the NSIS nodes route the message correctly. The Filter List is now carried in the NSLP layer, and therefore, should be set by the end nodes, which has the ultimate information about the application layer of the session. This means a faster and more accurate interaction between NSIS signaling and application becomes possible. Since the packet classifying is only meaningful to the NSLP application enforcer, e.g. the RMF in QoS NSLP case, having Filter List in the NSLP layer alleviates NTLP layer's burden on the processing of this information. The suggested Filter List resides in the NSLP layer, but is common for all the NSLP applications. Therefore, it could be a common object that can be utilized by different applications. Format of the Filter List could take the form of: Filter List ::= <* Filter Spec>; where the Filter Spec can be any format that provides packet classification information. One simple example can be the Filter Spec object defined in RSVP [10]. List Length indicates the number of Filter Spec included, and the Action indicates how to treat the previous filters of the same Flow ID. Example actions to be taken are: ADD, SUB, and REPLACE. Following subsections provide detail description on how this Filter List provides support for the scenarios described in the previous section. Cheng, et al. Expires January 16, 2006 [Page 13] Internet-Draft NSIS Flow ID issues July 2005 5.1 Filter list usage with multiple addresses involved sessions For the scenarios described in section 4.1, the use of Filter List solves the dilemma of using the Flow ID. As the Filter List allows accurate representation of the multiple addresses involved in the session, it does not require NTLP layer to care about the actual packet addresses. By doing this, the NTLP layer only needs to establish the correct signaling path. Simple wildcarding would then be useful to find out the common routing path. For example, for a session with different addresses, the NTLP layer can use a MRI with wildcarding without worrying the accuracy of the address presentation because the filter information is carried in the NSLP payload. The wildcarded MRI is only used for the route decision of the NSIS message, and the NSLP layer message with the Filter List can be configured by the corresponding entity, e.g. RMF, with correct settings. The introduction of the Filter List does not limit the NTLP layer's choice of Flow ID value. Instead, it gives NTLP more flexibility in selecting a proper Flow ID. Usually the routing does not really require that all the fields of the MRI. For example, a normal router would only decide the route based on the destination address. Therefore most fields of the MRI could be set to a default value, e.g. 0x00. Since the state information stored at the NSIS node is indexed by both the Session ID and the MRI, the above means saving in the key length used. For example, in the current NSIS draft, the key for the MRI would need to at least include source address, destination address, etc, since it also is used for packet classifying. In the proposed scheme with Filter List, the key for the MRI only need to have the destination address if the routing is based on destination address only. 5.2 Filter list usage with make-before-break reservation For the make-before-break scenarios as described in section 4.2, the new scheme could also be fine. Examples of the procedures are as follows. If the nAR can obtain MN's nCoA before MN's handover, nAR will be able to send RESERVE message. As the MN is still in another subnetwork, current filter information should not be replaced with the new filter information at path overlapped section. So, the new filter information is added to current filter list by "ADD" action at the section so that the data packets with both current filter information and new filter information can use reserved resources. On the other hand, if the nAR does not know MN's nCoA, it generates a Flow ID with its own IP address, and sends signaling messages such as QUERY. As the signaling is not for reservation, actual packet Cheng, et al. Expires January 16, 2006 [Page 14] Internet-Draft NSIS Flow ID issues July 2005 classification information, i.e. Filter List, is not necessary. By sending the QUERY, path state between the nAR and CN is installed as well as QoS resource availability along the path is gathered. After the MN connects to the new subnetwork, the MN only has to establish the path state of the rest part of the new path and update the whole path with a RESERVE message containing Filter List. Since it is an update message, and all the signaling states are in place, it is much faster than a new RESERVE message with a different Flow ID. 5.3 Filter List support of address information variation As described earlier, the Filter List provides the object to indicate the actions to take regarding the stored Filter List with the same Flow ID and Session ID. Therefore, it is suitable for supporting the address information variation case depicted in section 4.3. Since the Filter List object introduced supports the action indication, new filter spec could be progressively added when the new address information is available. For example, when a new port has been added to the communication session, the NSLP layer can issue a new message with the Filter List object carrying an Action filed indicating "ADD". The receiving NSLP aware node could take this new port information and merge it with the existing packet classification information for the same Session ID and Flow ID. Cheng, et al. Expires January 16, 2006 [Page 15] Internet-Draft NSIS Flow ID issues July 2005 6. Filter List impact Analysis This section provides a detail analysis of the impact of introducing the Filter List the design of NSIS protocols. 6.1 Filter List mpact on the framework/NTLP By introducing the Filter List object into the NSLP layer, the NTLP layer is relieved from signaling the actual data packet classification information. This looses its dependency on the data plane addressing information. Therefore, the design and operation of the NTLP layer has more flexibility. For example, the state pre- establishment and use of the proxy is much easier. The current design of the Flow ID or the MRI can still be used in the NTLP layer for the message routing information signaling. However, it does not need to be bound by the actual addressing information of the data flow, e.g. the port number, etc. It does not require change in the current design of the GIMPS, but relaxed some of the requirements. Also, the state management can be simplified due to the above reasons. For example, the state information storage and retrieval can be speeded up as described in section 5.1. Since the NTLP does not need to modify the Flow ID or MRI every time the address changes, the state maintained on the NSIS nodes will be more stable, and thus requires less operation in updating. 6.2 Filter List impact on the NSLP Use of the Filter List in the NSLP layer requires some enhancement at the NSLP nodes. The new NSLP layer needs to be able to manage the packet classification information, e.g. the Filter List. It no longer depends on the NTLP layer to obtain the filter information, and therefore need to be able to process them. Most of the time, the Filter List should be passed directly to the local enforcer, e.g. the RMF in the QoS NSLP case together with the QSPEC. This means the NSLP layer does not need to include much extra functions. For the operation of the scheme, the NSLP now need to have some interaction with the application or the addressing management. The NSLP application now needs to obtain all those addressing information from these entities to construct the Filter List at the end nodes. However, it does not mean the NSLP have to communicate with them directly. The current design could still be kept, so that the NSLP can communicate with them via NTLP using some extra APIs. It is for further study if it is better to have the NSLP interacts directly with the application layer. Cheng, et al. Expires January 16, 2006 [Page 16] Internet-Draft NSIS Flow ID issues July 2005 7. Security Considerations Major security issues for NSIS are addressed in [11], where the Section 4.4 mentions use of a Flow ID without source and destination IP addresses. If a Flow ID is used for traffic classification of data packets as well, then identity spoofing and injecting traffic is much easier since a packet only needs to be marked and an adversary can use a nearly arbitrary endpoint identifier to achieve the desired result. The filter List method described in this draft allows the spearation of the Flow ID and packet classification information. Different usage of the Flow can be employed, e.g. as described in [11]. Traffic classifier for data packets, however, may still use the conventional Flow ID information as a filter so that threat does not increase by using a Filter List. Cheng, et al. Expires January 16, 2006 [Page 17] Internet-Draft NSIS Flow ID issues July 2005 8. Conclusion This draft discussed issues faced by the NSIS design regarding its use of the Flow ID for carrying data packet classification information. For example, in the multihoming or multi-thread case, pre-establishment case, etc, the Flow ID would not be able to efficiently or accurately represent the addressing information. Several examples are studied in detail to reveal the problems. A solution to the problems is proposed by introducing a Filter List object in the NSLP layer. This solution provides support for all the scenarios described above. It also requires little change to the current NSIS design. Detail analysis of the impact to different components of the NSIS framework, NTLP and NSLP is provided, and it shows that the proposed solution is effective and easy to incorporate into the current NSIS system. Cheng, et al. Expires January 16, 2006 [Page 18] Internet-Draft NSIS Flow ID issues July 2005 9. Acknowledgements This section contains the acknowledgements. Cheng, et al. Expires January 16, 2006 [Page 19] Internet-Draft NSIS Flow ID issues July 2005 10. References 10.1 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, "GIMPS: General Internet Messaging Protocol for Signaling", Internet Draft draft-ietf-nsis-ntlp-06, Work in progress , May 2005. [4] Bosch, S., "NSLP for Quality-of-Service Signaling", Internet Draft draft-ietf-nsis-qos-nslp-06, Work in progress , February 2005. [5] Ash, J., Bader, A., and C. Kappler, "QoS-NSLP QSpec Template", Internet Darf draft-ietf-nsis-qspec-04, Work in Progress , May 2005. [6] Ernst, T., "Goals and Benefits of Multihoming", Internet Darf draft-ernst-generic-goals-and-benefits-01, Work in Progress , February 2005. [7] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3383, September 2003. [8] Koodli, R., "Fast Handovers for Mobile IPv6", Internet Darf draft-ietf-mipshop-fast-mipv6-03, Work in Progress , October 2004. [9] Liebsch, M., "Candidate Access Router Discovery", Internet Darf draft-ietf-seamoby-card-protocol-08, Work in Progress , September 2004. [10] Braden, R., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [11] Tschofenig, H., "Security Threats for NSIS", RFC 4081, Informational , June 2005. [12] Brunner, M., "Requirement for Signaling Protocols", RFC 3726, April 2004. Cheng, et al. Expires January 16, 2006 [Page 20] Internet-Draft NSIS Flow ID issues July 2005 10.2 Informative References [13] International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T), "Packet-based multimedia communications systems", ITU-T H. 323, July 2003. Authors' Addresses 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 Qijie Huang Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534415 Singapore Phone: +65 6550 5414 Email: jack.huangqj@sg.panasonic.com 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 Cheng, et al. Expires January 16, 2006 [Page 21] Internet-Draft NSIS Flow ID issues July 2005 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 Cheng, et al. Expires January 16, 2006 [Page 22] Internet-Draft NSIS Flow ID issues July 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. Cheng, et al. Expires January 16, 2006 [Page 23]