Next Steps in Signaling (nsis) H. Cheng Internet-Draft J. Huang Expires: April 27, 2006 T. Sanda T. Ue Panasonic October 24, 2005 NSIS Flow ID and packet classification issues draft-cheng-nsis-flowid-issues-02.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 In current NSIS signaling, there are two main functions depending on Flow ID, i.e. signaling message routing, data packet classification. Specifically, the same information carried by the MRI is also used to derive the packet classification at NSLP layer. This arrangement assumes that identical information is required by the two functions at two different layers, and thus has limitations. With the Cheng, et al. Expires April 27, 2006 [Page 1] Internet-Draft NSIS Flow ID issues October 2005 introduction of NSIS applications in more complicated scenarios, such assumption can no longer hold. Therefore, keeping the dependency between the two functions hinders the development of NSIS. Efforts have been made in different NSLP layer applications to extend the relationship, e.g. QoS NSLP. This draft studied the possibility of disjoining the information for the two functions. Problems faced by the current system and different remedy options are discussed. With these details, it is intended to help the reader to evaluate the feasibility of redefining the packet classification information signaling in NSIS. 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. Predictive signaling scenario . . . . . . . . . . . . . . 9 4.3. Packet classification information manipulations . . . . . 10 5. Separation of MRI and Packet Classification Information . . . 13 5.1. Considerations with multiple addresses involved sessions . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Different options for multiple addresses support . . . 13 5.1.2. Support of multiple addresses using Filer List . . . . 15 5.2. Considerations with predictive signaling support . . . . . 16 5.3. Considerations for packet classification information manipulation . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Changes at the framework/NTLP layer . . . . . . . . . . . 17 5.5. Changes at the NSLP layer . . . . . . . . . . . . . . . . 18 6. Impact analysis . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Single object vs. separate objects . . . . . . . . . . . . 19 6.2. Location of the packet classification object . . . . . . . 19 6.2.1. Object placed in NTLP layer . . . . . . . . . . . . . 20 6.2.2. Object placed in NSLP layer . . . . . . . . . . . . . 20 6.2.3. Object placed in QSPEC . . . . . . . . . . . . . . . . 21 6.3. General packet classifier vs. model specific classifier . 21 7. Possible optimization with the PACKET_CLASSIFIER object . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 29 Cheng, et al. Expires April 27, 2006 [Page 2] Internet-Draft NSIS Flow ID issues 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]. Cheng, et al. Expires April 27, 2006 [Page 3] Internet-Draft NSIS Flow ID issues October 2005 2. Introduction With the NSIS framework design [2], signaling message routing and data flow classification are two important functions at two layers, i.e. NTLP and NSLP respectively. However, information to support the two functions is derived from the same element, Flow ID. This type of arrangement has limitation on the NSIS application, and creates problem when deployment setting is not as assumed. Therefore, this aspect of the design needs to be reviewed and improved. The linkage between the two functions is based on the path-coupled signaling principle of the framework. In a path coupled MRM, the signaling message is suppose to go through the exact path of the data flow. To this end, NTLP layer protocol needs to use a MRI resembling the flow identification as much as possible. In the GIST draft [3], the MRI has been set as the Flow ID for the path-coupled MRM (or a simplified version of Flow ID for loose-end MRM). This essentially sets the information for the message routing and flow identification (packet classification) to be identical. The MRI is passed from the NSLP through a set of API to the NTLP layer when a NSLP message is to be sent, and passed from NTLP layer up to NSLP layer when a NSLP message is received. Due to the assumption that flow identification is always the same as MRI, NSLP applications, e.g. QoS NSLP [4], no longer has an element to carry the packet classification information. Thus, MRI is used by the NSLP layer to derive the packet classification information. Obviously, such an arrangement brings problem when the routing information does not synchronize with the flow identification information. There are two possible cases, i.e. when the flow identification (classification) information has a wider scope than that used for routing, and when the flow identification information has a more specific scope than that use for routing. Section 4 discusses in detail of the scenarios where problems exist. In an effort to bridge the difference between MRI and flow identification information, some NSLP applications introduced new objects. For example, QoS NSLP [4] included a PACKET_CLASSIFIER object. However, since the new object still heavily relies on the MRI to derive the packet classification information, it does not solve the problem. Rather than trying objects to extend MRI, this draft investigate the possibility of using a disjoint object at NSLP layer to carry the packet classification information. With an extensible format, the new object can easily support multiple address pairs. This helps in a multihoming environment, and makes it possible to signal for flows Cheng, et al. Expires April 27, 2006 [Page 4] Internet-Draft NSIS Flow ID issues October 2005 not specified by the MRI. Different aspects of introducing such an object are discussed in the draft, e.g. place of the object, NAT traversal issues, etc. With the recent discussion in the mailing list regarding packet classification, it is the intension of the draft to provide views on relevant issues to help the WG to reach consensus on the topic. Cheng, et al. Expires April 27, 2006 [Page 5] Internet-Draft NSIS Flow ID issues October 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 Identification and Data Packet Classification are used interchangeably in this draft. Cheng, et al. Expires April 27, 2006 [Page 6] Internet-Draft NSIS Flow ID issues October 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 GIST document [3], for a path-coupled MRM, the Flow ID is utilized as the Message-Routing-Information (MRI). The MRI is then required to be set at NSLP message sender. A formation of the Flow ID 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 packet classification for the enforcement. Based on the description of the signaling applications drafts, this information has to be derived from the MRI. For example, in the QoS- NSLP draft [4], the packet classification information is derived from the MRI fields indicated by the PACKET_CLASSIFIER object. Therefore, it is assumed that the QNE would set the Packet Classifier in its Traffic Control module based on a subset of the MRI information. 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 associated. This kind of overloading of the Flow ID works fine with Cheng, et al. Expires April 27, 2006 [Page 7] Internet-Draft NSIS Flow ID issues October 2005 a simplified static network environment. However, with scales of the network growing and complexities increasing, adverse impacts are introduced 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 According to the definition of the data flow, it is possible that multiple addresses are involved. The multiple addresses could be different IP addresses, different port numbers, or different higher layer protocol types, etc. With the development of the networking technology, it is becoming common to use multiple streams sessions. These streams may make use of different addresses, but could still goes through the same data path. Multihoming, multi-threading, and aggregation, etc., are the possible reasons that require different addresses to be signaled over one session. Below are some of the detail examples: - Edge to edge signaling is a case that may involve multiple addresses in the flow signaled. For example, if several flows are aggregated at a domain entry point, the signaling sent for the aggregated flow would contain several sets of addressing information. - The multiple addresses could also be 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 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. With the current definition of MRI, there is no way for the multiple addresses to be accurately represented. As quoted above, the MRI format only allows a simple prefix for the IP (source and destination) address fields. This may suit for the routing, e.g. to represent a group of address within a subnet. It is not sufficient for signaling the packet classification. For example, with two source addresses belong to the same subnet, the two data flows could be routed along the same path. However, if the source addresses are wildcarded and fed to the NSLP (eventually RMF) for enforcement, Cheng, et al. Expires April 27, 2006 [Page 8] Internet-Draft NSIS Flow ID issues October 2005 every node in that subnet connecting to the same peer (destination address) would be classified into the same session. This is obviously not acceptable for the QoS enforcement. Other than the IP address prefix, current MRI format does not even provide any wildcarding or masking tools for other fields. Therefore, it is not possible to represent multiple address information of other fields, e.g. port number, traffic class, etc. The latest QoS NSLP draft [4] introduced a PACKET_CLASSIFIER object to help deriving the packet classification information. However, due to its simple format, and heavy dependency on the existing MRI, it cannot solve the above problem. For the path-coupled routing MRM, the PACKET_CLASSIFIER data is just a two byte field with 8 bits utilized. It can only simply indicate which field of the MRI should be considered in deriving the packet classifier. Obviously, if the MRI cannot accurately represent the multiple address flow as described above, the PACKET_CLASSIFIER does not help either. The packet classifier constructed would be either too wide, i.e. when one or more fields are omitted, or too narrow, i.e. when every field is used. To solve this problem, a method for signal accurate flow classification information needs to be provided. Different options are discussed in detail in section 5.1. 4.2. Predictive signaling scenario 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 [5], 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 [10] or CARD [11]; 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. Even if the nAR doesn't have MN's nCoA, it is still desirable that the nAR can start the signaling, e.g. establish the NSIS signaling path for the MN, so that when the MN moves into the new network, the Cheng, et al. Expires April 27, 2006 [Page 9] Internet-Draft NSIS Flow ID issues October 2005 QoS path is ready for use with least signaling. For the path coupled MRM, it is obvious that the actual data flow will go pass the nAR. Therefore, it is not a problem for the nAR to act as a proxy for the MN to pre-establish the signaling path, e.g. send out Query messages to find out the QNEs, and check out the resources available over the predictive path. However, with the current definition of NSIS, e.g. QoS NSLP [4], the Flow ID (MRI) in use will also dedicate the packet classifier for the flow, i.e. the PACKET_CLASSIFIER indicates which field of MRI to be used for packet classifier. Therefore, the nAR would not be able to generate a proper Flow ID for this signaling without knowing the MN's nCoA. If the nAR uses an arbitrary address to create the Flow ID, the whole signaling process needs to be repeated when the MN's nCoA is assigned. This means nAR cannot send any signaling message until obtaining MN's NCoA. This renders the usage of make-before-break limited. Obviously, this problem calls for a possibility of separating the message routing information from the actual packet classification information. Different options to achieve that and considerations are discussed in section 5.2. 4.3. Packet classification information manipulations 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). An example of the address varying application process is the establishment of a H.323 session [12]. 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. Cheng, et al. Expires April 27, 2006 [Page 10] Internet-Draft NSIS Flow ID issues October 2005 +--------+ +--------+ | 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 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 Cheng, et al. Expires April 27, 2006 [Page 11] Internet-Draft NSIS Flow ID issues October 2005 RMF, could not perform its function correctly. However, the change in the Flow ID means another round of NTLP layer path establishment according to GIST 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. Another type of scenarios that requires manipulation of the packet classification information of a session is the tunneling case, as described in [13]. In such cases, the flow binding requires the packet classification information to be merged, and modified during the lifetime of the session. All these call for a simple way of changing the packet classification information along the signaling path without affecting the signaling state information. Section 5.3 provides a detail analysis of the options to deal with this requirement. Cheng, et al. Expires April 27, 2006 [Page 12] Internet-Draft NSIS Flow ID issues October 2005 5. Separation of MRI and Packet Classification Information In view of all the problems of the Flow ID in supporting scenarios described in previous section, there are three major issues to be resolved: - NSIS signaling should allow accurate indication of multiple addresses information in the signaling of packet classification information. - NSIS signaling should allow a separation of the message routing information and packet classification information when necessary. This will facilitates the NSIS signaling from non-end hosts. - NSIS signaling should allow modification of the packet classification information without affecting the signaling and routing state. There are different ways to achieve the above goals. Options and considerations are discussed in detail in the following subsections. With the discussion, the authors come to a conclusion that utilizing a separate object for carrying the packet classification information serves the above purpose and is a good trade off between different considerations. The suggested object could take different form. Below is an example format for it: Filter List ::= <* Filter Spec>; where the "Filter Spec" is basically a packet classifier that provides packet classification information. For example, the MF Classifier defined in RFC2475 [14] could be a good candidate. 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 discussion of the considerations for different scenarios. 5.1. Considerations with multiple addresses involved sessions 5.1.1. Different options for multiple addresses support One obvious way to support the multiple address involved communication session is to use multiple signaling sessions for each set of address. However, this solution faces a couple of problems. One problem is the significant increase in signaling, processing, and Cheng, et al. Expires April 27, 2006 [Page 13] Internet-Draft NSIS Flow ID issues October 2005 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 address 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 as well. 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. The root of the issues lies on the incapability of the MRI to carry multiple addresses information. Therefore, solution could be achieved by either modifying the MRI format to accommodate more complicated information or utilizing extra objects. For example, the MRI could add a masking/wildcarding tool for each of the fields. Since the change of MRI format will affect numerous aspects of the NTLP layer implementation, this draft proposes to use a separate Filter List object in NSLP layer 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 a much relaxed criteria for masking, as long as it provides enough information to allow the NSIS nodes to 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. Cheng, et al. Expires April 27, 2006 [Page 14] Internet-Draft NSIS Flow ID issues October 2005 Following subsection describes deployment examples of using the new object. 5.1.2. Support of multiple addresses using Filer List For the scenarios described in section 4.1, the use of Filter List solves the dilemma of using the MRI. 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. When a flow involves multiple addresses, it is possible to experience a divergence in the data path when the flow passes through a network section with load balancing supported. In this case, reservation on some of the split path may not be done correctly. There are several ways to address this issue. One possible method is to require the Load Balancing Initiator (LB-I) to duplicate the signaling message and send over every split path with the QSPEC adjusted accordingly. Another method is to force the LB-I to route all the packets identified by the Filter List to the same link. It is also possible for the QNI to be aware of the load balancing paths through the initial path discovery process, and construct the QSPEC and filter list accordingly. Cheng, et al. Expires April 27, 2006 [Page 15] Internet-Draft NSIS Flow ID issues October 2005 5.2. Considerations with predictive signaling support For the predictive signaling, one possible way to solve the problem is to pre-allocate an address for the MN for the predictive path. In this case, for example, the nAR can reserve an address for the MN when it proxy the signaling for it. When the MN actually moves to the new location, it must make use of the address pre-allocated by the nAR. For this option, there needs to have a mechanism that can guarantee the proper address for the MN can be pre-allocated. It infer a stateful address allocation scheme, since if stateless address formation is used, the nAR would not have the information to generate the new address. Another issue with this scheme is that it may cause waste in the address space. The MN's signaling over the predictive path could be simply a Query of the QoS level supported. MN may not eventually move to the new location. Therefore, requiring an allocation of an address for the MN for such a signaling decreases the utilization efficiency of the resources. The use of a separate object in NSLP layer stands as another option to support the proxy predictive signaling. When 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 using it. Since the actual data flow has not started yet, actual packet classification information, i.e. Filter List, is not necessary. By sending the QUERY, path state between the nAR and CN is installed and QoS resource availability along the path is gathered as well. When the MN connects to the new subnetwork, the signaling path has already been established. The MN only has to update the 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. Comparing the above two options, the use of separate packet classification object obviously provides a more flexible support for the predictive signaling. 5.3. Considerations for packet classification information manipulation With the current NSIS Flow ID definition, the change of packet classification information means a change in the Flow ID, and thus requires another round of signaling. This usually results in a signaling state update on all the QNEs. Certain scenarios require a merge of the original and new flow states to achieve desired QoS enforcement results, e.g. as described in [13]. For this purpose, an intra-session association object, ASSOCIATE_FLOW_SESSION, is introduced in [13]. The new object helps to link different flows within a Session together, so that the packet classification Cheng, et al. Expires April 27, 2006 [Page 16] Internet-Draft NSIS Flow ID issues October 2005 information could be manipulated on the QNEs. Different from the approach taken by [13], the use of a separate Filter List object can achieve the similar purpose. 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 field 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. Comparing the two options, the approach in [13] preserves the current MRI and Flow ID definition. It keeps the change in NSLP layer and slightly modifies the QNE behaviors. The disadvantage of this option is the signaling overhead introduced. Every signaling message needs to carry the new association object, which includes the additional Flow IDs. The other issue is the signaling using a new Flow ID when new packet classification information needs to be added. This may involves the path discovery procedure for the new Flow ID, which could be time consuming. For the Filter List object option, the NSLP layer packet classification definition is modified. The classification information is no longer depending on the MRI. However, to signal for additional address information, the same Flow ID could be used. This means only an update of the signaling state on the QNE is necessary. Therefore, it can be faster. 5.4. Changes at the framework/NTLP layer 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 GIST, 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 previous sections. Cheng, et al. Expires April 27, 2006 [Page 17] Internet-Draft NSIS Flow ID issues October 2005 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. 5.5. Changes at the NSLP layer 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 April 27, 2006 [Page 18] Internet-Draft NSIS Flow ID issues October 2005 6. Impact analysis This section provides a detail analysis of the different aspects of introducing the Filter List object to the design of NSIS protocols. Some of the recent discussions in the mailing list on the topic are also covered. 6.1. Single object vs. separate objects In the current NSIS framework, although the message routing and packet classification are two different functions, they uses the information derived from the same object, MRI. The reasoning for using a single object for the two functions is based on the address boundary traversing consideration. When a single object is used, the address boundary node, e.g. NAT, only need to modify this object. Information derived from the modified object could always be synchronized. Therefore, it is guaranteed that information used for the two functions are referring to the same flow. A possibility of meeting the requirements listed in section 5 using a single object is to modify the MRI format. This way, the extra packet classification information introduced in the Filter List could be incorporated into MRI. However, it will affect almost every aspects of the current GIST operation, and therefore is not appropriate. The use of a single object assumes that the signaled flow must be the same as that defined in MRI. However, in certain case, more flexibility is desirable. For example, the metering application [15], is expecting that some extra filter information could be carried in the NSLP layer other than the MRI. When two disjoining objects are used for the two functions, the address boundary node needs to apply changes twice. In order to guarantee the synchronization of the information, exactly the same rules should be used on the two objects, e.g. same mapping used on the MRI should be used on Filter List. For normal address boundary nodes using a comparatively static rules, this should be easily achievable. No major issue could be envisaged, e.g. passing a NAT. If the address boundary node is using very dynamic rules for the address processing, problem may exist for the data flow, similar to the load balancing case. 6.2. Location of the packet classification object When considering the location of the Filter List object, there are generally three options: in NTLP layer, in NSLP layer, or in QSPEC. These three options all have advantages and disadvantages. Following Cheng, et al. Expires April 27, 2006 [Page 19] Internet-Draft NSIS Flow ID issues October 2005 brief discussions give an overview of the pros and cons. The considerations are focusing on the signaling overhead and NAT traversing. 6.2.1. Object placed in NTLP layer Firstly, when the Filter List is used as NTLP layer object, it introduces unnecessary burden to the NTLP. Placing it in the NTLP layer means that the object needs to be included in every NSIS message. However, the packet classification information is only meaningful to the RMF, and is only necessary in certain NSLP messages, e.g. QoS NSLP RESERVE. Therefore, unnecessary signaling overhead is resulted. When the Filer List is placed in the NTLP layer, it is the easiest to achieve NAT traversal support of the signaling. The NAT node only needs to be NTLP layer aware to process the information. Current NAT behavior specified in the GIST draft [4] will still be usable. 6.2.2. Object placed in NSLP layer When the Filter List object is placed in the NSLP layer, the NSLP application knows when it should be included in the signaling. For example, a QoS NSLP NOTIFY message may not include the packet classification information object. This helps to reduce the overhead of the signaling compared with the case where it is placed in NTLP layer. However, the packet classification object needs to be made stackable to support stackable QSPEC. The main reason for this is due to the direct relationship between the packet classification information and the specific QoS Model. Therefore, when the QSPECs are stacked, the corresponding packet classification information also needs to be preserved so that it could be referred correctly when the QSPECs are popped. The NAT traversal aspect of this option is slightly complicated than the NTLP layer based choice. Basically, in this case, the NAT is required to be able to process the common NSLP layer object other than being NTLP aware. The Filter List object could be placed in a fixed position in NSLP layer when presented, e.g. with a flag indication. Then, the NAT is able to apply the same address mapping rule on the Filter List, similar to what it does on the MRI. It is also possible for the NAT to insert the NAT-Object that contains the mapping rules, so that the next hop NSLP aware node, e.g. QNE, could actually perform the modification to the Filter List. Cheng, et al. Expires April 27, 2006 [Page 20] Internet-Draft NSIS Flow ID issues October 2005 6.2.3. Object placed in QSPEC The last choice is to place the Filter List in the QSPEC. This seems logical, since the packet classification would be utilized directly by the RMF, which is decided by the specific QoS Model. In this case, the QoS Model could optimize the information to be carried in the Filter List. However, this also means that the Filter List object is only accessible for a node with knowledge of the QoS Model of concern. Therefore, it will be extremely difficult for the signaling message to traverse an address boundary, e.g. a NAT. For this option to work in a NATed network, the NAT node must be the specific QoS Model aware, which is a hard requirement to meet. 6.3. General packet classifier vs. model specific classifier As mentioned in section 6.2.3, the packet classification information is relevant to the QoS Model (eventually RMF) in use. Therefore, different QoS Model may have different requirements on packet classification format. For example, intra domain DiffServ signaling may only require DSCP information, whereas edge to edge signaling may require MF classifier. Therefore, there are options to have the packet classification defined according to the QoS Model or kept general. The choice of the packet classifier depends on where the object is placed. In the case of section 6.2.1 and 6.2.2 (i.e. in NTLP layer or NSLP layer), the packet classifier needs to be general, because it is common for all the QoS Models. For the general packet classifier, the MF Classifier defined in the RFC2475 [14] is a good candidate. Only in the case of section 6.2.3 (i.e. in QSPEC), the packet classifier could be made using fields that is required by the specific QoS model associated. In order to achieve this, the QSPEC needs to define a set of basic elements, so that, when needed, QoS Model specific packet classifier could be formed using the basic elements. Cheng, et al. Expires April 27, 2006 [Page 21] Internet-Draft NSIS Flow ID issues October 2005 7. Possible optimization with the PACKET_CLASSIFIER object As discussed in the previous section, the Filter List may not be necessary for all the scenarios. For those static and simple addressing cases, the conventional MRI way is sufficient. Therefore, to optimize the signaling efficiency, the Filter List object could be made optional with a flag set at the signaling header. Below is an example of using an indication derived from the PACKET_CLASSIFIER object in the QoS NSLP case. For example, the modified method specific data format of the PACKET_CLASSIFIER object for a path-coupled routing MRM, as in section 5.1.3.5 of QoS NSLP [4], is specified as following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Y|P|T|F|S|A|B| Reserved |L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wherein, the new flag L is to indicate if a separate Filter List is used in the NSLP for packet classification information. When the flag L is set, all the other fields should be set to zero. Therefore, a QNE first checks if the L bit of the PACKET_CLASSIFIER object is set. If it is not set, the QNE will make use of the MRI and other fields of the PACKET_CLASSIFIER object to derive the packet classifier. When the QNE finds out that the L flag is set, it will obtain the packet classification information directly from the Filter List object instead of the MRI. Cheng, et al. Expires April 27, 2006 [Page 22] Internet-Draft NSIS Flow ID issues October 2005 8. Security Considerations Major security issues for NSIS are addressed in [6], 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 separation of the Flow ID and packet classification information. Different usage of the Flow can be employed, e.g. as described in [6]. 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 April 27, 2006 [Page 23] Internet-Draft NSIS Flow ID issues October 2005 9. Conclusion This draft discussed issues faced by the NSIS design regarding its use of the Flow ID for carrying data packet classification information. A solution to the problems is proposed by introducing a Filter List object in the NSLP layer. This solution provides support for the scenarios that is not supported by the current NSIS framework. 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 be incorporated into the current NSIS system. Cheng, et al. Expires April 27, 2006 [Page 24] Internet-Draft NSIS Flow ID issues October 2005 10. Acknowledgements This section contains the acknowledgements. Cheng, et al. Expires April 27, 2006 [Page 25] Internet-Draft NSIS Flow ID issues October 2005 11. References 11.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, "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-08, Work in progress , October 2005. [5] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3383, September 2003. [6] Tschofenig, H., "Security Threats for NSIS", RFC 4081, Informational , June 2005. [7] Ash, J., Bader, A., and C. Kappler, "QoS-NSLP QSpec Template", Internet Draft draft-ietf-nsis-qspec-06, Work in Progress , October 2005. [8] Brunner, M., "Requirement for Signaling Protocols", RFC 3726, April 2004. [9] Braden, R., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 11.2. Informative References [10] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [11] Liebsch, M., "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005. [12] International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T), "Packet-based multimedia communications systems", ITU-T H. 323, July 2003. [13] Shen, C., "NSIS Operation Over IP Tunnels", Internet Draft draft-shen-nsis-tunnel-00, Work in Progress , July 2005. Cheng, et al. Expires April 27, 2006 [Page 26] Internet-Draft NSIS Flow ID issues October 2005 [14] Blake, S., "An Architecture for Differentiated Services", RFC 2475, Informational , December 1998. [15] Dressler, F., "NSLP for Metering Configuration Signaling", Internet Draft draft-dressler-nsis-metering-nslp-02, Work in Progress , July 2005. Cheng, et al. Expires April 27, 2006 [Page 27] Internet-Draft NSIS Flow ID issues October 2005 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 Jack 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 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 April 27, 2006 [Page 28] Internet-Draft NSIS Flow ID issues 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. Cheng, et al. Expires April 27, 2006 [Page 29]