IETF Next Steps in Signaling C. Shen Internet-Draft H. Schulzrinne Expires: April 27, 2006 Columbia U. S. Lee J. Bang Samsung AIT October 24, 2005 NSIS Operation Over IP Tunnels draft-shen-nsis-tunnel-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 April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft presents an NSIS operation over IP tunnels scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated reservation modes are discussed. The scheme proposes a separate signaling session inside the tunnel. Packets belonging to qualified tunnel sessions are assigned special flow IDs Shen, et al. Expires April 27, 2006 [Page 1] Internet-Draft NSIS Operation Over IP Tunnels October 2005 to be distinguished from the rest of the tunnel traffic. The end-to- end session and its corresponding tunnel session are associated with each other when necessary; so that adjustment in one session may be reflected in the other. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. IP Tunneling Mechanisms . . . . . . . . . . . . . . . . . 4 2.2. Different Signaling Capabilities of IP Tunnels . . . . . . 5 3. Overall Protocol Design . . . . . . . . . . . . . . . . . . . 6 4. Protocol Design Details . . . . . . . . . . . . . . . . . . . 7 4.1. Packet Classification Over the Tunnel . . . . . . . . . . 7 4.2. Tunnel Signaling and its Association with End-to-End Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Operation for Individual Tunnel Signaling . . . . . . 11 5.1. Basic Sender-Initiated Signaling over IP Tunnels . . . . . 11 5.2. Basic Receiver-Initiated Signaling over IP Tunnels . . . . 12 6. Protocol Operation for Aggregate and Mixed Signaling Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Tunnel With Only One Aggregate Session . . . . . . . . . . 14 6.2. Tunnel With Multiple Aggregate Sessions . . . . . . . . . 14 6.3. Adjustment of Configured Tunnel Sessions . . . . . . . . . 14 6.4. Protocol Operation for Mixed Signaling Tunnels . . . . . . 15 7. Message Processing Rules for Selected End-to-End QoS NSLP Messages at Tunnel Endpoints . . . . . . . . . . . . . . . . . 15 7.1. End-to-End QUERY Message at Tentry . . . . . . . . . . . . 15 7.2. End-to-End QUERY Message at Texit . . . . . . . . . . . . 16 7.3. End-to-End RESERVE Message at Tentry . . . . . . . . . . . 16 7.4. End-to-End RESERVE Message at Texit . . . . . . . . . . . 18 7.5. Special Processing Rules for Many-to-One Mapping Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Other Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. Other Types of NSLP . . . . . . . . . . . . . . . . . . . 19 8.2. IPSEC Flows . . . . . . . . . . . . . . . . . . . . . . . 20 8.3. NSIS-Tunnel and Mobility . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Summary of RSVP Operation Over IP Tunnels . . . . . . . . 21 10.2. Various Design Alternatives . . . . . . . . . . . . . . . 21 10.2.1. Carrying Signaling Messages over the Tunnel . . . . . 21 10.2.2. Packet Classification over the Tunnel . . . . . . . . 22 10.2.3. Tunnel Binding Methods . . . . . . . . . . . . . . . 22 10.2.4. Tunnel Binding Indication . . . . . . . . . . . . . . 23 10.2.5. Carrying the Tunnel Binding Object . . . . . . . . . 23 10.2.6. Alternative Ways of End-to-End and Tunnel Session Shen, et al. Expires April 27, 2006 [Page 2] Internet-Draft NSIS Operation Over IP Tunnels October 2005 Interaction . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Shen, et al. Expires April 27, 2006 [Page 3] Internet-Draft NSIS Operation Over IP Tunnels October 2005 1. Requirements notation 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 [1]. 2. Introduction IP tunnel mechanisms are widely used in the Internet for various purposes. When a tunnel is used to transfer signaling messages, e.g. NSIS messages, the signaling messages themselves usually become invisible inside the tunnel. In other words, the tunnel behaves as a logical link that does not support signaling in the end-to-end path. If end-to-end NSIS signaling support is desired for a path containing tunnels, it is necessary to define a scheme that allows NSIS operation over IP tunnels. This draft describes such a scheme. We assume QoS NSLP as the NSIS signaling application. 2.1. IP Tunneling Mechanisms There are a number of common tunneling mechanisms used in the Internet. A non-exhausted list of them is as follows, o Generic Routing Encapsulation (GRE) [4] is a mechanism for encapsulating arbitrary packets within an arbitrary transport protocol. Generic Routing Encapsulation over IPv4 Networks (GREIP4) [5] addresses the case of using IPv4 as the delivery protocol or the payload protocol and the special case of IPv4 as both the delivery and payload. Generic Routing Encapsulation (GREIP4A) [17] presented a modified version of [4], in particular, some flag bits in the original specification have been deprecated. o IP Encapsulation within IP (IP4INIP4) [7] is a method of tunneling IPv4 packets using an additional IPv4 header. Minimal Encapsulation within IP (MINENC) [8] describes a way to reduce the size of the "inner" IP header used in [7] when the original datagram is not fragmented. o Generic Packet Tunneling in IPv6 Specification (IP6GEN) [11] specifies a method by which a packet is carried as payload within an IPv6 packet by being encapsulated in an IPv6 header, and optionally, a set of IPv6 extension headers. o IPv6 over IPv4 tunneling (IP6INIP4) [6] encapsulates IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures. o IPSEC [9] has a tunnel mode with the use of Encapsulating Security Payload (ESP) [10]. The tunneled IP packets are encrypted and the ESP is placed before the encapsulated IP header. Shen, et al. Expires April 27, 2006 [Page 4] Internet-Draft NSIS Operation Over IP Tunnels October 2005 The above tunneling mechanisms fall into two broad categories according to the encapsulating (delivery) header format: 1. Normal IP in IP Encapsulation: the encapsulating header is just a standard IP header. This group includes IP4INIP4, IP6INIP4, IP6GEN. 2. Modified IP in IP Encapsulation: the encapsulating header is a standard IP header plus additional information. This group includes all GRE-related IP tunneling, MINENC and IPSEC tunneling mode. The additional information in these cases is the GRE header, minimum encapsulation header and ESP header respectively. This information is usually placed between the encapsulating IP header and the original IP header. (MINENC is an exception because it modifies the original IP header). Note that in the IPSEC case, the original IP header is also encrypted along with the original IP payload. 2.2. Different Signaling Capabilities of IP Tunnels By default any end-to-end signaling messages arriving at the tunnel endpoint will be encapsulated the same way as data packets. Tunnel intermediate nodes do not identify them as signaling messages. Therefore the tunnel appears as a signaling unaware logical link to the end-to-end session. A signaling aware tunnel may participate in a signaling network in various ways. For example, RFC 2746 [18] identifies two types of QoS aware tunnels: a tunnel that can promise that some overall level of resources is available to carry traffic, but not to allocate resources specifically to individual data flows; or a tunnel that can make reservations for individual end-to-end data flows. We call these two types of tunnels aggregate signaling tunnel and individual signaling tunnel respectively. The key feature that distinguishes individual signaling tunnels from aggregate signaling tunnels is that in individual signaling tunnels new tunnel sessions are created and torn down dynamically as end-to-end sessions come and go. Note that the tunnel sessions in aggregate signaling tunnels could be a configured tunnel that never gets changed, or could be an aggregate tunnel session that is dynamically adjusted as the actually used session resources increase or decrease. On the other hand, individual signaling tunnels may also contain multiple tunnel sessions for the same application, e.g. an audio and its associated video stream. A tunnel may also be a mixed one that combines the properties of the aggregate signaling tunnel and individual signaling tunnel. Shen, et al. Expires April 27, 2006 [Page 5] Internet-Draft NSIS Operation Over IP Tunnels October 2005 3. Overall Protocol Design This document presents a scheme to enable NSIS operation over IP tunnels with different tunnel capabilities. The design goals of the scheme are as follows, o For best effort tunnel, make sure NSIS messages traverse the link correctly, and the presence of the non-NSIS aware link is detected. o For aggregate and individual signaling tunnels, make sure proper signaling is carried out in the tunnel for the end-to-end flow. o Work with most, if not all, existing IP in IP tunneling schemes. o Place the additional tunnel related functionalities only in one or both of the tunnel endpoints. o If possible, make NSIS tunnel signaling handle specific events in a consistent way as that of NSIS signaling without tunneling. An example is mobility interaction. The overall design of NSIS operation over IP tunnels is conceptually similar to RSVP operation over IP tunnels [18]. (A short summary of [18] is provided in appendix Section 10.1). However, the scheme described in this document also addresses the important differences of NSIS from RSVP, e.g., o NSIS is based on a two-layer architecture, namely a signaling transport layer and a signaling application layer. It is designed as a generic framework to accommodate various signaling application needs. The basic RSVP protocol does not have a layer split and is only for QoS signaling. o NSIS QoS NSLP allows both sender-initiated and receiver-initiated reservations; RSVP only supports receiver-initiated reservations. o NSIS deals only with unicast; RSVP also supports multicast. o NSIS integrates new features, such as the Session ID, to facilitate operation in specific environments (e.g. mobility and multi-homing). From a high level point of view, the main issues in a signaling operation over IP tunnel scheme are, how packet classification is performed inside the tunnel, and how signaling is carried out inside the tunnel. Packets belonging to qualified data flows need to be recognized by tunnel intermediate nodes to receive special treatment. Packet classification is traditionally based on flow ID, which is derived from various fields in Message Routing Information (MRI). The problem is, after a typical IP-in-IP tunnel encapsulation, all packets going through the tunnel appear as having the same flow ID (which consists of the Tunnel Entry (Tentry) address and Tunnel Exit Shen, et al. Expires April 27, 2006 [Page 6] Internet-Draft NSIS Operation Over IP Tunnels October 2005 (Texit) address. Therefore the flow ID for signaled flows needs to contain further demultiplexing fields in order to be distinguished from non-signaled flows, and also from one another among all signaled flows. The special flow ID for signaled flows inside the tunnel then needs to be carried in tunnel signaling messages to set up or modify the state information in tunnel intermediate nodes. The original end-to- end signaling messages do not contain tunnel specific parameters such as the tunnel flow ID and tunnel adjusted QoS parameters. Therefore, separate tunnel signaling sessions are generated and maintained between the tunnel endpoints, as in the case of RSVP operation over IP tunnels [18]. When end-to-end signaling sessions and tunnel signaling sessions are carried out separately, it will be necessary in many cases to maintain the state association between the end-to- end session and its corresponding tunnel session so that any change to one session may be reflected in the other. In the next section, we will illustrate details on packet classification over the tunnel, signaling over the tunnel as well as association of end-to-end and tunnel signaling. 4. Protocol Design Details 4.1. Packet Classification Over the Tunnel Tunnel flows need to be assigned special flow IDs in order to allow tunnel packet classification. A flow can be an individual flow or an aggregate flow. Possible flow ID formats that may be used to identify individual tunnel flows are listed below: o Selected fields from the base IP header of the tunnel encapsulated packet (outer IP header). For example, the IP source and destination address fields, which contain the IP addresses of Tentry and Texit, together with another field for tunnel-wide demultiplexing. This could be the IPv6 flow label field, or the Traffic Class (TC) field. Note that the TC field can also be used in DiffServ to carry DiffServe Code Point (DSCP) and thus represent an aggregate flow. As long as individual flow classification is processed before aggregate flow classification, or a longest match kind of packet classifier is used, the tunnel flow demultiplexing with TC field should work. In the rare cases where these conditions could not be satisfied, it is still possible to choose different range of DSCP values so that the values used for individual tunnel flow demultiplexing do not collide with those used for DiffServ aggregate flows. Compared to the IPv6 flow label approach, the tunnel flow ID containing DSCP Shen, et al. Expires April 27, 2006 [Page 7] Internet-Draft NSIS Operation Over IP Tunnels October 2005 can be applied to both IPv4 and IPv6 and is probably easier to deploy. Its drawback is that the small number of bits in the DSCP field limits the total number of individual flows that can be distinguished in the tunnel. Overall, these flow ID formats in this group enable efficient packet classification over the tunnel without introducing additional processing requirements on the existing infrastructure. They are also easy to deploy. o Selected fields from the tunnel base IP header plus additional information outside the base IP header but still in the tunnel encapsulation header. This applies to modified IP-in-IP encapsulation as we defined in Section 2.1. An example of this additioanl information is the SPI field for IPSEC tunnels. Comparing with the first group, the flow ID formats in this group poses more requirements at the NSIS protocol side because it uses information unique to the specific tunnel mechanism. NSIS thus needs to be specifically tuned to recognize that information as part of a signaling message. This is similar to how RFC 2207 [19] has extended RSVP to accommodate IPSEC. o UDP header insertion. Inserting a new UDP header between the tunnel IP header and the tunnel payload provides additional demultiplexing information for a tunnel flow. The drawback of the flow ID format in this group, as compared to the above two, is the additional UDP header overhead both for bandwidth and processing. In addition, this approach modifies the basic tunneling mechanism at the Tentry, so Texit will also need to be aware of the special encapsulation in order to correctly decapsulate and forward packets further along the path. Most of the above flow ID formats may also be used for aggregate tunnel flows. For example, a common aggregate flow ID contains the addresses of tunnel endpoints and the DSCP value. When additional interfaces at the tunnel endpoints are available, these addresses may also be used to form aggregate flow ID. For example, the IP address of an additional interface for a Tentry plus the IP address of the Texit, constitute an aggregate flow ID. The choice of using which of the above flow ID format is left to a policy mechanism outside the scope of this document. Tunnel signaling is performed based on the chosen flow ID and Tentry should encapsulate all incoming packets for the specific data flows according to the chosen flow ID format. 4.2. Tunnel Signaling and its Association with End-to-End Signaling Tunnel signaling messages contain tunnel specific parameters such as Shen, et al. Expires April 27, 2006 [Page 8] Internet-Draft NSIS Operation Over IP Tunnels October 2005 tunnel MRI and tunnel adjusted QoS parameters. But the formats of tunnel signaling messages are the same as end-to-end signaling messages and tunnel signaling is carried out according to the same signaling flows of the end-to-end signaling. The main challenge is therefore the interaction between tunnel signaling and end-to-end signaling. The interaction is achieved by special functionalities supported in the NSIS-aware tunnel endpoints. These special functionalities include assigning special tunnel flow IDs, creating tunnel session association, notifying the other endpoint about tunnel association, adjusting one session based on change of the other session, encapsulating (decapsulating) packets according to the chosen tunnel flow ID at Tentry (Texit), etc. In most cases, we expect to have bi-directional tunnels, where both endpoints are NSIS- tunnel aware. When both Tentry and Texit need to be NSIS-tunnel aware, it is necessary for one NSIS-tunnel aware endpoint to learn whether the other endpoint also has the same capability. This document assumes that the NSIS-tunnel awareness is optional and only needs to be deployed at tunnel endpoints. Therefore a tunnel capability discovery mechanism will be needed. This mechanism is still considered an open issue. It may be defined at the GIST layer or at the NSLP layer. It may be defined as a general NSIS-tunnel aware indication (for various NSLPs) or it may indicate specifically with which NSLPs the tunnel operation is supported. At the GIST layer, the NSIS-tunnel handling characteristics may be carried in an object similar to Network-Layer-Information. At the NSLP layer, a new NODE_CHAR object similar to that in [18] may be defined and exchanged between the Tentry and Texit. The NSIS-tunnel messaging flows shown in this document assumes both tunnel endpoints already know the other endpoint is also NSIS-tunnel aware, in other words, the NSIS-Tunnel capability discovery has been performed already. When both Tentry and Texit need to be NSIS-tunnel aware, the endpoint that creates the tunnel session needs to notify the other endpoint of the association between the end-to-end and tunnel session. We choose to achieve this by using a modified QoS NSLP BOUND_SESSION_ID object. This object contains the tunnel session SID that should be bound to the SID of the message carrying this object. This modified object is carried in an end-to-end signaling messages and sent between the tunnel endpoints like any other tunneled packets inside the tunnel, so this object will only be recognized and processed at the tunnel endpoint. NSIS-tunnel aware endpoints recognize the object, perform tunnel related procedures and then remove the object. The QoS NSLP BOUND_SESSION_ID object is used to indicate the dependency of two sessions, its format as currently defined does not specify the nature of this dependency. For example, it may be used Shen, et al. Expires April 27, 2006 [Page 9] Internet-Draft NSIS Operation Over IP Tunnels October 2005 for bi-directional flows or flow aggregation as well. According to [3], when receiving a message with a BOUND_SESSION_ID object, a QNE MUST copy the BOUND_SESSION_ID object into all messages it sends for the same session. This is not the desired behavior for its use in the context of this document. For NSIS-tunnel operation, the dependency is maintained by the tunnel endpoints and should not be propagated further outside the tunnel. Therefore we propose to add to the existing BOUND_SESSION_ID a Binding_Code field as follows. Type: BOUND_SESSION_ID Length: Fixed - 5 32-bit words Value: contains an 8-bit Binding_Code that indicates the nature of binding. The rest specifies the Session ID of the session that must be bound to the session associated with the message carrying this object. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Binding_Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: BOUND_SESSION_ID Object Currently defined Binding_Codes are: o 0x01 - Tunnel and end-to-end sessions o 0x02 - Bi-directional sessions o 0x03 - Aggregate sessions o 0x04 - Dependent sessions (one session is alive only if the other session is also alive) More binding codes maybe defined based on the above four atomic binding actions. It is not clear whether we need to allow more than one SESSION ID (SID) in the binding object. We refer to a BOUND_SESSION_ID object carrying the code 0x01 as a tunnel BOUND_SESSION_ID object in this document. Shen, et al. Expires April 27, 2006 [Page 10] Internet-Draft NSIS Operation Over IP Tunnels October 2005 5. Protocol Operation for Individual Tunnel Signaling In an individual signaling tunnel a tunnel session is dynamically created and one-to-one mapped to an end-to-end session. NSIS QoS NSLP allows both sender-initiated and receiver-initiated reservation modes. It is possible that the end-to-end and tunnel session may use the same or different reservation modes. Therefore we have the following four signaling scenarios: o A. End-to-end session is sender-initiated; tunnel session is sender-initiated. o B. End-to-end session is receiver-initiated; tunnel session is receiver-initiated. o C. End-to-end session is sender-initiated; tunnel session is receiver-initiated. o D. End-to-end session is receiver-initiated; tunnel session is sender-initiated. We discuss details of scenario A and B in this document. The other two scenarios will be covered in a later version of this draft. 5.1. Basic Sender-Initiated Signaling over IP Tunnels Sender Tentry Tnode Texit Receiver | | | | | | RESERVE | | | | +--------->| | | | | | RESERVE' | | | | +=========>| | | | | | RESERVE' | | | | +=========>| | | | RESERVE | | | +-------------------->| | | | | RESPONSE'| RESERVE | | | |<=========+--------->| | | RESPONSE'| | | | |<=========+ | | | | | | RESPONSE | | | | |<---------+ | | RESPONSE | | | |<--------------------+ | | RESPONSE | | | | |<---------+ | | | | | | | | | | | | | Shen, et al. Expires April 27, 2006 [Page 11] Internet-Draft NSIS Operation Over IP Tunnels October 2005 Figure 2: Sender-Initiated QoS NSLP over IP Tunnel This scenario assumes both end-to-end and tunnel sessions are sender- initiated. Figure 2 shows the messaging flow of NSIS operation over IP tunnels in this case. Tunnel signaling messages are distinguished from end-to-end messages by a "'" after the message name. The sender first sends an end-to-end RESERVE message which arrives at Tentry. If Tentry supports tunnel signaling and determines that an individual tunnel session needs to be established for the end-to-end session, it chooses the tunnel flow ID, creates the tunnel session and associates the end-to-end session with the tunnel session. It then sends a tunnel RESERVE' message matching the requests of the end-to-end session toward the Texit to reserve tunnel resources. Tentry also appends to the original RESERVE message with a tunnel BOUND_SESSION_ID object containing the SID of the tunnel session and sends it toward Texit using normal tunnel encapsulation. The tunnel RESERVE' message is processed hop by hop inside the tunnel for the flow identified by the chosen tunnel flow ID. When Texit receives the tunnel RESERVE' message, reservation state for the tunnel session will be created. Texit may also send a tunnel RESPONSE' message to Tentry. On the other hand, the end-to-end RESERVE message passes through the tunnel intermediate nodes just like any other tunneled packets. When Texit receives the end-to-end RESERVE message, it notices the binding of a tunnel session and checks the state for the tunnel session. When the tunnel session state is available, it updates the end-to-end reservation state using the tunnel session state, removes the tunnel BOUND_SESSION_ID object and forwards the end-to-end RESERVE message further along the path towards the receiver. When the end-to-end reservation finishes, an end-to-end RESPONSE may be sent back from the receiver to the sender. 5.2. Basic Receiver-Initiated Signaling over IP Tunnels Sender Tentry Tnode Texit Receiver | | | | | | QUERY | | | | +--------->| | | | | | QUERY | | | +-------------------->| | | | QUERY' | | | | +=========>| | | | | | QUERY' | | | | +=========>| | | | | | QUERY | | | | +--------->| Shen, et al. Expires April 27, 2006 [Page 12] Internet-Draft NSIS Operation Over IP Tunnels October 2005 | | | | RESERVE | | | | |<---------+ | | | RESERVE' | | | | |<=========+ | | | RESERVE' | | | | |<=========+ | | | RESERVE | RESPONSE'| | | |<---------+=========>| | | | | | RESPONSE'| | | | +=========>| | | RESPONSE | | | | +--------->| | | | | | RESPONSE | | | +-------------------->| | | | | | RESPONSE | | | | +--------->| | | | | | | | | | | Figure 3: Receiver-Initiated QoS NSLP over IP Tunnel This scenario assumes both end-to-end and tunnel sessions are receiver-initiated. Figure 3 shows the messaging flow of NSIS operation over IP tunnels in this case. When Tentry receives the first end-to-end QUERY message from the sender, it chooses the tunnel flow ID, creates the tunnel session and sends a tunnel QUERY' message matching the requests of the end-to-end session toward the Texit. Tentry also appends to the original QUERY message with a tunnel BOUND_SESSION_ID object containing the SID of the tunnel session and sends it toward the Texit using normal tunnel encapsulation. The tunnel QUERY' message is processed hop by hop inside the tunnel for the flow identified by the chosen tunnel flow ID. When Texit receives the tunnel QUERY' message, it should create a reservation state for the tunnel session, but it should not send out a tunnel RESERVE' message immediately. This conditional reservation processing does not seem to be covered by the current QoS NSLP draft [3], so an additional message-specific flag bit in the common header of QUERY message may be needed. The end-to-end QUERY message passes along tunnel intermediate nodes just like any other tunneled packets. When Texit receives the end- to-end QUERY message, it notices the binding of a tunnel session and checks state for the tunnel session. When the tunnel session state is available, Texit updates the end-to-end QUERY message using the tunnel session state, removes the tunnel BOUND_SESSION_ID object and forwards the end-to-end QUERY message further along the path. Shen, et al. Expires April 27, 2006 [Page 13] Internet-Draft NSIS Operation Over IP Tunnels October 2005 When Texit receives the first end-to-end RESERVE message issued by the receiver, it finds the reservation state of the tunnel session and triggers a tunnel RESERVE' message for that session. Meanwhile the end-to-end RESERVE message will be appended with a tunnel BOUND_SESSION_ID object and forwarded towards Tentry. When Tentry receives the tunnel RESERVE', it creates the reservation state for the tunnel session and may send a tunnel RESPONSE' back to Texit. When Tentry receives the end-to-end RESERVE, it creates the end-to- end reservation state and updates it with information from the associated tunnel session reservation state. Then Tentry further forwards the end-to-end RESERVE upstream toward the sender. 6. Protocol Operation for Aggregate and Mixed Signaling Tunnels An aggregate signaling tunnel may contain one or more aggregate tunnel sessions configured through management interfaces. 6.1. Tunnel With Only One Aggregate Session If only one aggregate session is configured in the tunnel and all traffic will receive the reserved tunnel resources, all the packets just need to be normal IP-in-IP encapsulated. If there is only one aggregate session configured in the tunnel and only some traffic should receive the reserved resources through that aggregate tunnel session, then the aggregate tunnel session should be assigned an appropriate flow ID. Qualified packets need to be encapsulated with this flow ID. The rest of the traffic will be normal IP-in-IP encapsulated. 6.2. Tunnel With Multiple Aggregate Sessions If there are multiple configured aggregate sessions over a tunnel set up by the management interface, these sessions must be distinguished by their aggregate tunnel flow IDs based on appropriate flow ID. In this case it is necessary to explicitly bind the end-to-end sessions with the specific tunnel sessions. This binding is provided by the tunnel BOUND_SESSION_ID object which is carried in the end-to-end signaling message. Once the binding has been established, Tentry should encapsulate qualified data packets from different flows according to the associated aggregate tunnel flow ID. Intermediate nodes in the tunnel will then be able to filter these packets to receive reserved resources. 6.3. Adjustment of Configured Tunnel Sessions The reservation of a configured tunnel session may or may not be adjustable. When the tunnel session is adjustable and there can be a Shen, et al. Expires April 27, 2006 [Page 14] Internet-Draft NSIS Operation Over IP Tunnels October 2005 many-to-one mapping to the tunnel session, related policy mechanism needs to decide how the adjustment to the tunnel reservation should be done to accommodate the end-to-end sessions mapped onto it. As discussed in [18], there could be multiple choices. In the first, the tunnel reservation is never adjusted, which makes the tunnel a rough equivalent of a fixed-capacity hardware link ("hard pipe"). In the second, the tunnel reservation is adjusted whenever a new end-to- end reservation arrives or an old one is torn down ("soft pipe"). Doing this will require the Texit to keep track of the resources allocated to the tunnel and the resources actually in use by end-to- end reservations separately. It is often appropriate to adopt a third choice, where we use some hysteresis in the adjustment of the tunnel reservation parameters. The tunnel reservation is adjusted upwards or downwards occasionally, whenever the end-to-end reservation level has changed enough to warrant the adjustment. This trades off extra resource usage in the tunnel for reduced control traffic and overhead. 6.4. Protocol Operation for Mixed Signaling Tunnels In reality, a tunnel can contain both individual signaling sessions and aggregate sessions; a configured tunnel session also does not have to be an aggregate session. Different types of tunnel sessions in the mixed tunnel can be dealt with using corresponding mechanisms discussed above, the choice of mapping an end-to-end session to a specific type of tunnel session is up to policy control. 7. Message Processing Rules for Selected End-to-End QoS NSLP Messages at Tunnel Endpoints Following are basic message processing rules for involved end-to-end QoS NSLP messages. More details will be provided in later version of this document. 7.1. End-to-End QUERY Message at Tentry When an end-to-end QUERY message is received at Tentry, Tentry checks whether the end-to-end session is entitled to tunnel resources. If the end-to-end session should be bound to a tunnel session yet to be created. Tentry creates a tunnel QUERY' message and sends it to Texit. Tentry also appends a tunnel BOUND_SESSION_ID object to the end-to-end QUERY message. The tunnel BOUND_SESSION_ID object contains the SID of the tunnel session. The end-to-end QUERY message is then encapsulated and sent out through the tunnel interface. If the end-to-end session should be bound to an existing tunnel Shen, et al. Expires April 27, 2006 [Page 15] Internet-Draft NSIS Operation Over IP Tunnels October 2005 session (whether aggregate or individual), Tentry appends a tunnel BOUND_SESSION_ID object to the end-to-end tunnel QUERY message and sends it toward Texit through the tunnel interface. 7.2. End-to-End QUERY Message at Texit When an end-to-end QUERY message containing a tunnel BOUND_SESSION_ID object is received, Texit creates a conditional reservation state for the end-to-end session. It also checks to see if a conditional reservation state for the associated tunnel session is available. If yes, it reads information from the tunnel session state and sends the end-to-end QUERY downstream. If the conditional reservation state for tunnel session is not yet available, it will be created upon receiving the tunnel QUERY', and then Texit should forward the end- to-end QUERY downstream with information from results of the tunnel QUERY'. Note that the latest version of QoS NSLP draft [3] defines an R-bit in the QUERY message. More details about dealing with R-bit of the QUERY message will be discussed in a later version of this document. 7.3. End-to-End RESERVE Message at Tentry When a RESERVE message is received, in addition to normal processing for the request, the following tunnel related functionality is performed. For sender-initiated RESERVE message, If the RESERVE message is received with its T-bit set (RESERVE tear), Tentry removes the local state, then encapsulates the RESERVE message and tunnels it to Texit. If there is a tunnel session associated with this end-to-end session, Tentry also sends a tunnel RESERVE with T-bit set for that tunnel session. If the end-to-end RESERVE message is a refresh for an existing end- to-end session and this session is associated with a tunnel session, the RESERVE message refreshes both two sessions. If the RESERVE message causes changes in resources reserved for the end-to-end session, Tentry may create a new tunnel RESERVE' message to change the tunnel reservation as well. At the same time, Tentry appends a tunnel BOUND_SESSION_ID object to the end-to-end RESERVE message and sends it to Texit through the tunnel interface. If the message is the first RESERVE message for an end-to-end session, Tentry determines whether the end-to-end session is entitled to tunnel resources based on policy control mechanisms outside the scope of this document. If not, no special tunnel related processing Shen, et al. Expires April 27, 2006 [Page 16] Internet-Draft NSIS Operation Over IP Tunnels October 2005 is needed. Otherwise, if this session should be bound to an existing tunnel session (whether aggregate or individual), Tentry creates the association between the end-to-end session and the tunnel session. Then it appends a tunnel BOUND_SESSION_ID object to the end-to-end RESERVE message and sends it through the tunnel interface (i.e. the message is encapsulated and tunneled to Texit as normal). If the end-to-end session should be bound to a tunnel session yet to be created, Tentry assigns the tunnel flow ID, and constructs a tunnel RESERVE' message. The QSPEC in this tunnel RESERVE message may be different from the original QSPEC, taking into consideration the tunnel overhead of the encapsulation of data packets. Tentry then associates the tunnel session with the end-to-end session in the NSLP state and sends the tunnel RESERVE' toward Texit to reserve resources over the tunnel. At the same time, Tentry appends a tunnel BOUND_SESSION_ID object to the end-to-end RESERVE message and sends it through the tunnel interface. For receiver-initiated RESERVE messages, If the RESERVE message is received with its T-bit set (RESERVE tear), Tentry removes the local state and forwards the message upstream. If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID and is the first end-to-end RESERVE message, Tentry checks whether the tunnel session bound to the end-to-end session indicated by the RESERVE message already exists. If yes, Tentry records the association between the end-to-end and the tunnel session, reads information from the tunnel session to create the end-to-end RESERVE message to be forwarded upstream. If the state for the tunnel session is not available yet, Tentry should create state information for the tunnel session and indicate that a conditional reservation is pending. When the actual tunnel RESERVE' arrives, the tunnel session state will be updated. If at this time there is a pending reservation, Tentry should generate an end-to-end RESERVE message and forwards it upstream. If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID and is a refresh, Texit refreshes the end-to-end session. If the RESERVE message causes changes in resources reserved for the end-to- end session, Texit checks the state information of the tunnel session. If the reservation has been updated inside the tunnel, Texit forwards the RESERVE message toward the sender. If the tunnel reservation update failed, Texit MUST sends a RESPONSE with appropriate Error_Spec to the originator of the end-to-end RESERVE message. 7.4. End-to-End RESERVE Message at Texit Shen, et al. Expires April 27, 2006 [Page 17] Internet-Draft NSIS Operation Over IP Tunnels October 2005 When Texit receives a RESERVE message, in addition to normal processing of the request, the Texit performs the following steps, Sender-initiated RESERVE, If the end-to-end RESERVE message is received with its T-bit set (RESERVE tear), Texit removes the local state, then forwards the RESERVE message downstream. If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID and is the first end-to-end RESERVE message, Texit checks whether the state for the tunnel session indicated by the RESERVE message already exists. If yes, Texit records the association between the end-to-end and the tunnel session and reads information from the tunnel session to create the end-to-end RESERVE message to be forwarded downstream. If the state for the tunnel session is not available yet, Texit should create state information for the tunnel session and indicate that a conditional reservation is pending. When the actual tunnel RESERVE' arrives, the tunnel session state will be updated. If at this time there is a pending reservation, Texit will generate an end- to-end RESERVE message and forwards it downstream. If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID and is a refresh, Texit refreshes the end-to-end session. If the RESERVE message causes changes in resources reserved for the end-to- end session, Texit checks the state information of the tunnel session. If the reservation has been updated inside the tunnel, Texit forwards the RESERVE message toward the receiver. If the tunnel reservation update failed, Texit MUST send a RESPONSE with appropriate Error_Spec to the originator of the end-to-end RESERVE message. Note that the processing rules for end-to-end RESERVE at Texit in sender-initiated case is similar to those for end-to-end RESERVE at Tentry in receiver-initiated case. Receiver-initiated RESERVE, If the RESERVE message is received with its T-bit set (RESERVE tear), Texit removes the local state, then forwards the RESERVE message upstream. If there is an individual tunnel session associated with this end-to-end session, Texit also sends a tunnel RESERVE' with T-bit set for that tunnel session. Otherwise Texit checks to see if the end-to-end session is associated with a tunnel session. If only conditional reservation state is found and no actual reservation has been made, this RESERVE is the first end-to-end RESERVE message. Texit appends a tunnel Shen, et al. Expires April 27, 2006 [Page 18] Internet-Draft NSIS Operation Over IP Tunnels October 2005 BOUND_SESSION_ID object to this end-to-end RESERVE message and sends it toward Tentry through the tunnel interface. Meanwhile it sends tunnel RESERVE' message toward Tentry to reserve tunnel resources. If the end-to-end session is bound to a tunnel session and the RESERVE message is a refresh, it refreshes both the end-to-end session and tunnel session. If the RESERVE message causes changes in resources reserved for the end-to-end session, Texit may create a new tunnel RESERVE' message to change the tunnel reservation as well. Meanwhile, the end-to-end RESERVE is appended with the tunnel BOUND_SESSION_ID object and sent to Tentry through the reverse path. 7.5. Special Processing Rules for Many-to-One Mapping Tunnels There are special situations where the end-to-end session is bound to pre-configured tunnel sessions in a many-to-one mapping. If the associated tunnel session is a "hard pipe" session, arrival of a new end-to-end reservation or adjustment of an existing end-to-end session may cause the overall resources needed in the tunnel session to exceed its capacity, this case is treated as admission control failure same as that of a tunnel reservation failure. Tentry should create a RESPONSE message with appropriate Error_Spec and send it to the originator of the RESERVE message. If the associated tunnel session is a "soft pipe" session, arrival of a new end-to-end reservation or adjustment/deletion of existing sessions may cause the tunnel session to be modified. It is recommended that some hysteresis is enforced in the adjustment of the tunnel reservation parameters. This requires tunnel endpoint to keep track of both the allocated tunnel session resources and the resources actually used by end-to-end sessions bound to that tunnel session. 8. Other Considerations 8.1. Other Types of NSLP This document discusses QoS NSLP. It will be good if the scheme in this document could work with other NSLPs as well. Since NSIS-tunnel operation involves specific NSLP itself and different NSLPs have different message exchange semantics, the NSIS-tunnel specification would not be the same for all NSLPs. However the basic aspects behind NSIS-tunnel operation are indeed similar. NATFW NSLP is the only other main NSLP currently developed by the NSIS working group. The most important signaling operation in NATFW NSLP is CREATE. Assuming Tentry is a NATFW NSLP, the tunnel-handling for CREATE Shen, et al. Expires April 27, 2006 [Page 19] Internet-Draft NSIS Operation Over IP Tunnels October 2005 operation will be very similar to the sender-initiated QoS reservation case. There are also a number of reverse directional operations in NATFW NSLP, e.g., RESERVE_EXTERNAL_ADDRESS, UCREATE. It is not very clear whether tunnel will cause problems with these messages in general. But they are likely easier to be dealt with than the receiver-initiated reservation case in QoS NSLP. The next version of this document will discuss more on this topic. 8.2. IPSEC Flows If the tunnel supports IPSEC (especially ESP in Tunnel-Mode with or without AH), it may use the flow label, TC field, or IPSEC SPI along with the tunnel source and destination address, as discussed in Section 4.1, to form the tunnel Flow ID. All these are standard NSIS MRI fields that should be matched by the NSIS packet classifier. We may also define virtual destination ports as in [19] to provide further flow demultiplexing capability at the destination side if necessary. 8.3. NSIS-Tunnel and Mobility The NSIS-tunnel operation needs to interact with IP mobility in an efficient way. For aggregate signaling tunnels, the process is relatively straightforward because tunnel session resources are usually set up in advance. For individual signaling tunnels, one way to improve tunnel NSIS-mobility efficiency is to keep the SESSION_ID of the tunnel session unique when tunnel flow ID changes during mobility as illustrated below. With a mobile IP tunnel, one tunnel endpoint is the Home Agent (HA), and the other is the Mobile Node (MN) if collocated Care-of-Address (CoA) is used, or the Foreign Agent (FA) if FA CoA is used. When MN is a receiver, Tentry is the HA and Texit is the MN or FA. In case of a mobility event, handoff tunnel signaling messages will start from HA, which may use the same SID for the new tunnel session. When MN is a sender and collocated CoA is used, Tentry is the MN and Texit is the HA. Handoff tunnel signaling is started at the MN. It may also use the SID of the previous tunnel session for the new tunnel session. When MN is a sender and FA CoA is used, the situation is complicated, because Tentry has changed from the old FA to the new FA. The new FA does not have the SID of the previous tunnel session. When mobile IP is working on a bi-directional tunneling mode, NSIS- tunnel operation with mobility may be further improved by localizing the handoff tunnel signaling process under the HA (i.e., without going through the path between HA and CN). Shen, et al. Expires April 27, 2006 [Page 20] Internet-Draft NSIS Operation Over IP Tunnels October 2005 9. Security Considerations This draft does not draw new security threats. Security considerations for NSIS NTLP and QoS NSLP are discussed in [2] and [3] respectively. General threats for NSIS can be found in [21]. 10. Appendix 10.1. Summary of RSVP Operation Over IP Tunnels RFC 2746 [18] provides an example scheme for RSVP operation over IP tunnels. The scheme needs to be supported by both the Tentry and Texit. To address the tunnel signaling visibility problem, separate tunnel signaling sessions are performed for end-to-end sessions. A binding between the tunnel sessions and the end-to-end sessions is established. Both the Tentry and Texit must agree on the binding so that changes in the original reservation state can be correctly mapped into changes in the tunnel reservation state, and that errors reported by intermediate routers to the tunnel endpoints can be correctly transformed into errors reported by the tunnel endpoints to the end-to-end RSVP session. To address the tunnel QoS data visibility problem, a UDP header is inserted to all QoS data packets following the tunnel IP header. The additional UDP header provides source and destination ports that allow intermediate tunnel nodes to use standard RSVP filterspec handling and demultiplex different tunnel RSVP sessions. The RFC 2746 scheme also mentions that in the case where the IP-in-IP tunnel supports IPSEC (especially ESP in tunnel-mode with or without AH), the tunnel session uses the GPI SESSION and GPI SENDER_TEMPLATE, FILTER_SPEC as defined in [19] for the PATH and RESV messages. Data packets are not encapsulated with a UDP header since the SPI can be used by the intermediate nodes for classification purposes. 10.2. Various Design Alternatives 10.2.1. Carrying Signaling Messages over the Tunnel The contents of original end-to-end singling messages are not directly examined by tunnel intermediate nodes. To carry out tunnel signaling we choose to generate separate signaling messages for the tunnel signaling session. Another option is to stack tunnel specific objects on top of the original end-to-end message and make these messages visible to tunnel intermediate nodes so they may serve both the end-to-end session and tunnel session. This turns out to be very difficult because the actual tunnel signaling messages differ from the end-to-end signaling message both in GIST layer and NSLP layer Shen, et al. Expires April 27, 2006 [Page 21] Internet-Draft NSIS Operation Over IP Tunnels October 2005 information, such as MRI and QSPEC. Another reason not to choose this approach is that tunnel signaling is a process involving message exchanges in both directions inside the tunnel. A separate tunnel session signaling is much cleaner. 10.2.2. Packet Classification over the Tunnel Packet classification over the tunnel may be done in either of the two ways: first, retaining the end-to-end packet classification rules; second, using tunnel specific classification rules. In the first approach, tunnel packet classification is not tied with tunnel MRI. This is a useful characteristic especially in handling tunnel mobility - as mobility occurs, the tunnel MRI changes, but the packet classification rule does not change. Therefore, the common path after a handover does not need to be updated, resulting in a better handoff performance. The main problem with this approach is that most existing routers do not support inspection of inner IP headers in an IP tunnel, where the tunnel independent packet classification fields usually reside. Therefore this document chose the second approach which does not pose special requirements on intermediate tunnel nodes. 10.2.3. Tunnel Binding Methods In this document, the end-to-end session and tunnel session use different SESSION_IDs and they are associated with each other using the BOUND_SESSION_ID object. This choice is obvious for aggregate signaling tunnels because in that case the original end-to-end session and the corresponding aggregate tunnel session require independent control. Sessions in individual signaling tunnels are created and deleted along with the related end-to-end session. So association between the end-to-end session and the corresponding individual tunnel session has another choice: the two sessions may share the same SESSION_ID, which should be the SESSION_ID of the original end-to-end session. The specific advantage of this choice is that it conforms to the general rule that the SESSION_ID should not be modified end- to-end [13]. It simplifies the handling of NSIS mobility inside the tunnel because the end-to-end session and all associated tunnel sessions share the same SESSION_ID. Problems with this choice arise when there is a need to convey the association from one tunnel endpoint to the other. The BOUND_SESSION_ID object cannot be used because the SESSION_IDs are the same. It may be possible to define a similar BOUND_FLOW_ID object. However, since flow ID is usually derived from MRI, if a NAT is present in the tunnel, this BOUND_FLOW_ID object will have to be modified in the middle, which makes the process fairly complicated. Furthermore, it is not desired Shen, et al. Expires April 27, 2006 [Page 22] Internet-Draft NSIS Operation Over IP Tunnels October 2005 to have different session association mechanisms for aggregate signaling tunnels and individual signaling tunnels. Therefore, we decide to use the same BOUND_SESSION_ID mechanism also in individual signaling tunnels. Note that, in this case the mobility handling inside the tunnel can still be optimized in certain situations, as discussed in Section 8.3 10.2.4. Tunnel Binding Indication In this document we added a Binding_Code field to the existing BOUND_SESSION_ID object in order to indicate the nature of binding. Two other options considered are: 1. Define a designated "tunnel object" to be included when the tunnel binding needs to be conveyed. 2. Define a "tunnel bit" in corresponding NSLP message headers. These options are not chosen because they either need to create entirely new object, or need to change basic message headers. They are also not generic solutions that can cover other binding causes. 10.2.5. Carrying the Tunnel Binding Object There are basically two ways to carry the binding object between Tentry and Texit, using (a) end-to-end signaling messages or (b) tunnel signaling messages. Option (a) is cleaner in the sense that only tunnel endpoints are involved in this process. Option (b) embeds the binding information in the tunnel signaling messages. Since both the tunnel SID and flow ID are available in the tunnel signaling message, it might even be possible to just use a new tunnel bit in the message headers without including the binding object. The disadvantage of option (b) is that intermediate tunnel nodes will be exposed to the binding message, and modifications to basic message formats may be needed. Therefore the choice in this document is option (a). 10.2.6. Alternative Ways of End-to-End and Tunnel Session Interaction There are many other alternatives of integrating the end-to-end and tunnel session signaling. In general, different approaches can be grouped into two modes, sequential mode and parallel mode. In sequential mode, end-to-end signaling pauses when tunnel signaling is started, and resumes upon finish of the tunnel signaling; in parallel mode, end-to-end signaling continues outside the tunnel while tunnel signaling is in process. We have different ways to define when a particular tunnel signaling procedure is completed. For example, a tunnel QUERY' or RESERVE' may be considered finished when the Shen, et al. Expires April 27, 2006 [Page 23] Internet-Draft NSIS Operation Over IP Tunnels October 2005 initiating endpoint receives the corresponding tunnel RESPONSE' message. Compared to the approach we adopted in the main part of this document, this approach introduces more signaling delays. Tunnel session initiation is another issue that is quite flexible. It is also possible to initiate the tunnel session from Texit, or at different points of the end-to-end signaling. For example, the tunnel session can be started when Tentry receives the first end-to- end RESERVE message, as in the case of [18]. Unlike the scheme we presented above, this will not allow the first end-to-end QUERY message to trigger a tunnel QUERY' and gather tunnel characteristics along with the rest of the end-to-end path. But the assumption of our scheme is that Tentry already knows Texit also supports the NSIS- tunnel scheme, so it makes sense to start preparing for tunnel session signaling early. Tentry always needs to be NSIS-Tunnel aware because it at least needs to encapsulate packets into special tunnel flow IDs. Texit needs to be NSIS-tunnel aware if the tunnel reservation is receiver initiated. When the tunnel reservation is sender-initiated, it is possible that Texit is NSIS-Tunnel unaware and the tunnel signaling still works. However, the condition is that no special packet decapsulation is needed (e.g. when UDP insertion is used for tunnel flow ID). Considering that most of the time we might have a bi-directional tunnel and also for more general applicability, we assumed both tunnel endpoints to be NSIS-Tunnel aware in this document. 11. Acknowledgements 12. References 12.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", draft-ietf-nsis-ntlp-08 (work in progress), September 2005. [3] Bosch, S., "NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005. 12.2. Informative References [4] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Shen, et al. Expires April 27, 2006 [Page 24] Internet-Draft NSIS Operation Over IP Tunnels October 2005 Routing Encapsulation (GRE)", RFC 1701, October 1994. [5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. [6] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [7] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [8] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [9] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [10] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [11] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [12] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [13] Hancock, R., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-07 (work in progress), December 2004. [14] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06 (work in progress), October 2005. [15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-07 (work in progress), July 2005. [16] Lee, S., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signaling-02 (work in progress), July 2005. [17] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. Shen, et al. Expires April 27, 2006 [Page 25] Internet-Draft NSIS Operation Over IP Tunnels October 2005 [19] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [20] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [21] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Shen, et al. Expires April 27, 2006 [Page 26] Internet-Draft NSIS Operation Over IP Tunnels October 2005 Authors' Addresses Charles Shen Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Phone: +1 212 854 5599 Email: charles@cs.columbia.edu Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Phone: +1 212 939 7004 Email: schulzrinne@cs.columbia.edu Sung-Hyuck Lee SAMSUNG Advanced Institute of Technology San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9552 Email: starsu.lee@samsung.com Jong Ho Bang SAMSUNG Advanced Institute of Technology San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9585 Email: jh0278.bang@samsung.com Shen, et al. Expires April 27, 2006 [Page 27] Internet-Draft NSIS Operation Over IP Tunnels 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. Shen, et al. Expires April 27, 2006 [Page 28]