IETF Next Steps in Signaling C. Shen Internet-Draft H. Schulzrinne Expires: January, 2006 Columbia U. S. Lee J. Bang Samsung AIT July, 2005 NSIS Operation Over IP Tunnels draft-shen-nsis-tunnel-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In this draft we briefly review various IP Tunnelling mechanisms and discuss the main problems with signaling operation over IP tunnels. We also summarize the existing RSVP operation over IP tunnels mechanism. Then we present the design details and case examples of an NSIS operation over IP tunnels scheme. QoS NSLP is assumed as the Shen, et al. Expires January 12, 2006 [Page 1] Internet-Draft NSIS Operation Over IP Tunnels July 2005 NSIS signaling application in our discussion. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement and Related Work . . . . . . . . . . . . . . 3 3.1 IP Tunnelling Mechanisms . . . . . . . . . . . . . . . . . 3 3.2 Problems on Signaling Operation over IP Tunnels . . . . . 4 3.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overall Design Approach . . . . . . . . . . . . . . . . . . . 5 4.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Signaling over the Tunnel . . . . . . . . . . . . . . . . 6 4.3 Packet Classification over the Tunnel . . . . . . . . . . 6 4.4 Tunnel Flow Classification Information . . . . . . . . . . 7 4.5 Association of the End-to-End session and Tunnel Session . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Operation for Individual Signaling Tunnels . . . . . 9 5.1 Sender Initiated Signaling . . . . . . . . . . . . . . . . 10 5.2 Receiver-Initiated Signaling . . . . . . . . . . . . . . . 12 6. Protocol Operation for Aggregate Signaling Tunnels . . . . . . 15 6.1 Single Aggregate Tunnel Session . . . . . . . . . . . . . 15 6.2 Multiple Aggregate Tunnel Session . . . . . . . . . . . . 15 6.3 Adjustment of Configured Tunnel Session . . . . . . . . . 16 7. New Object format . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Shen, et al. Expires January 12, 2006 [Page 2] Internet-Draft NSIS Operation Over IP Tunnels July 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 in our discussion. 3. Problem Statement and Related Work 3.1 IP Tunnelling Mechanisms There are a number of common tunnelling mechanisms used in the Internet. A non-exhausted list of them are as follows: o Generic Routing Encapsulation (GRE) [2] is a mechanism for encapsulating arbitrary packets within an arbitrary transport protocol. Generic Routing Encapsulation over IPv4 Networks (GREIP4) [3] 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 [2] , in particular, some flag bits in the original specification have been deprecated. o IP Encapsulation within IP (IP4INIP4) [5] is a method of tunnelling IPv4 packets using an additional IPv4 header. Minimal Encapsulation within IP (MINENC) [6] describes a way to reduce the size of the "inner" IP header used in [5] when the original datagram is not fragmented. o Generic Packet Tunnelling in IPv6 Specification (IP6GEN) [9] 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 tunnelling (IP6INIP4) [4] encapsulates IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures. o IPSEC [7] has a tunnel mode with the use of Encapsulating Security Payload (ESP) [8]. The tunnelled IP packets are encrypted and the Shen, et al. Expires January 12, 2006 [Page 3] Internet-Draft NSIS Operation Over IP Tunnels July 2005 ESP is placed before the encapsulated IP header. The above tunnelling 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 include IP4INIP4, IP6INIP4, IP6GEN and MINENC. Note that MINENC modifies the original IP header. 2. Modified IP in IP Encapsulation: the encapsulating header is a standard IP header plus additional information. This group includes all GRE-related IP tunnelling, and IPSEC tunnelling mode. The additional information in these cases is the GRE header and ESP header respectively. This information is usually placed between the encapsulating IP header and the original IP header. Note that in the IPSEC case, the original IP header is also encrypted along with the original IP payload. 3.2 Problems on Signaling Operation over IP Tunnels RFC 2746 [18] identifies three ways that a tunnel, and in fact any sort of link, may participate in a QoS signaling aware network. o The (logical) link may not support the QoS signaling and resource reservation at all. This is a best-effort link. o The (logical) link may be able to promise that some overall level of resources is available to carry traffic, but not to allocate resources specifically to individual data flows. An example may be a configured resource allocation over a tunnel. We refer to this case as an aggregate signaling tunnel in this note. o The (logical) link may be able to make reservations for individual end-to-end data flows. This is referred to as an aggregate tunnel in this document. The key feature that distinguishes individual signaling tunnels from aggregate signaling tunnels is that in the individual signaling tunnel new tunnel reservations are created and torn down dynamically as end-to-end reservations come and go. Note that an aggregate or individual signaling tunnel does not necessarily mean all the intermediate nodes along the tunnel path support NSIS. This is equivalent to the case of an existing end-to- end NSIS session transparently passing through non-NSIS cloud. There are two basic problems associated with signaling operation over IP tunnels. The first one is identifying signaling messages over the tunnel. Nodes normally intercept signaling messages based on a router alert option or a protocol number (e.g. 46 for RSVP). These information, if present, is carried in the tunnel payload and not examined by a node inside the tunnel. The second problem is QoS data Shen, et al. Expires January 12, 2006 [Page 4] Internet-Draft NSIS Operation Over IP Tunnels July 2005 classification over the tunnel because original QoS data classification fields are also carried in the tunnel payload and not examined by intermediate tunnel nodes. 3.3 Related Work RFC 2746 [18] provides an example scheme for RSVP operation over IP tunnels. The scheme needs to be supported by both the Tunnel Entry (Tentry) and Tunnel Exit (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 end points 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. The design of NSIS operation over IP tunnels in this document is conceptually similar to RSVP operation over IP tunnels. However, it 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). 4. Overall Design Approach Shen, et al. Expires January 12, 2006 [Page 5] Internet-Draft NSIS Operation Over IP Tunnels July 2005 4.1 Design Goals This document presents a scheme to enable NSIS operation over IP tunnels. 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 tunnelling schemes. o Place the additional tunnel related functionalities only in one or both of the tunnel end points. o If possible, make NSIS tunnel signaling handle specific events in a consistent way as that of NSIS signaling without tunnelling. An example is mobility interaction. 4.2 Signaling over the Tunnel When packets enter the IP tunnel, its original header and payloads are put into the tunnel payload and normally not examined by the intermediate tunnel nodes. This is the case for both signaling messages and data packets. So this affects both signaling and data packet classification over the tunnel. To perform signaling over the tunnel, it is not sufficient to make the original end-to-end messages available to intermediate tunnel nodes. For example, consider a Mobile IP forwarding tunnel from the Home Agent (HA) to the Mobile Node (MN), an end-to-end signaling message will carry the Correspondent Node (CN or flow source) address and MN Home Address (HoA or flow destination) as the Message Routing Information (MRI). This MRI cannot be used directly for signaling inside the tunnel. For this reason, the tunnel end points are required to generate separate tunnel signaling messages reflecting the tunnel specific MRI. Tunnel signaling should thus be carried out independent of the end-to-end signaling. For the same signaling session, its end-to-end and tunnel signaling should also be properly associated, so that any change in one of them may be mapped to the other. 4.3 Packet Classification over the Tunnel Packet classification over the tunnel may be done in either of the two ways: first, retain the end-to-end packet classification rule inside the tunnel; second, use tunnel specific classification rule inside the tunnel. We call the specific fields used for packet classification the Flow Classification Information (FCI). In the first approach, the tunnel FCI is not tied to the tunnel MRI. This Shen, et al. Expires January 12, 2006 [Page 6] Internet-Draft NSIS Operation Over IP Tunnels July 2005 is a useful characteristics especially in handling tunnel mobility - as mobility occurs, the tunnel MRI changes, but the FCI does not change. Therefore, the common path after a handover does not need to be updated, resulting in a better handover performance. The main problem with this approach is that most existing routers do not support inspection of inner headers in an IP tunnel. The second approach constructs the tunnel FCI based on the tunnel delivery header, or MRI of the tunnel signaling messages. This approach does not pose special requirements on intermediate tunnel nodes, so it is used in this document. 4.4 Tunnel Flow Classification Information FCI determines the tunnel Flow ID. The Tunnel Flow ID is used to distinguish a properly signalled flow from the rest, none-signaled traffic. Among all signalled traffic, the flow ID also needs to distinguish among each signaled flows. Note that a flow can be an individual flow or an aggregate flow. Possible FCI for individual tunnel flows are: o Selected fields from the tunnel base IP header (outer IP header). Usually this includes both the IP source and destination address and additional fields. When IPv6 flow label is available, the combination of IP source address, destination address and flow label is the recommended FCI. Otherwise, we propose to use the combination of IP source address, destination address and the DSCP field as FCI. This usage will not cause confusion with the use of DSCP for aggregate FCI, as long as individual flow classification is processed before aggregate flow classification, or when a longest match kind of packet classifier is used. In the rare cases where these conditions could not be satisfied, it is still possible to choose different range of DSCP values for individual and aggregate flows respectively. Compared to the IPv6 flow label approach, this new FCI containing DSCP can be applied to both IPv4 and IPv6 and is probably easier to deploy. Its drawback is that the number of bits in the DSCP field limits the total number of individual flows that can be distinguished in the tunnel. Overall, FCI 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. The use of flow label is documented in RFC3697 [20], and the use of DSCP as discussed can be readily achieved by using the MF classifier defined in RFC2475 [10]. o Selected fields from the tunnel base IP header plus additional information outside the base IP header but still in the tunnel Shen, et al. Expires January 12, 2006 [Page 7] Internet-Draft NSIS Operation Over IP Tunnels July 2005 delivery header. This applies to modified IP-in-IP encapsulation as we defined in the problem statement in Section 3. An example of this is the SPI field for IPSEC tunnels, similar to that proposed in [19]. Comparing with the first approach, FCI 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 flow. The drawback of the FCI in this group, as compared to the above two, is the additional UDP header overhead both for bandwidth and processing. Most of the above FCI formats may be used for aggregate tunnel flows as well. A common aggregate FCI contains the DSCP value. When additional interfaces at the tunnel end points are available, we also propose to use these addresses directly for aggregate FCI. E.g., the IP address of an additional interface for a Tentry plus the IP address of the Texit, form an aggregate FCI. When the FCI has been chosen, all subsequent QoS data packets for the flow should be encapsulated using the particular FCI format. Packets belong to these flows can then be filtered by tunnel intermediate nodes for special treatment. 4.5 Association of the End-to-End session and Tunnel Session Assignment of the tunnel FCI may be done by either Tentry or Texit. However, it will generally be simpler for the entity that initiates tunnel QoS reservation to perform this task. That means, the sender in Sender-Initiated scenario and the receiver in Receiver-Initiated scenario will be responsible for tunnel FCI assignment. Once tunnel FCI is chosen, the Flow ID for the tunnel session is also determined. NSIS tunnel signaling requires the coordination between the original end-to-end signaling and the tunnel signaling. Therefore, some association between the end-to-end session and the tunnel session needs to be established in either or both of the tunnel end points. For aggregate signaling tunnels, the original end-to-end session and the associated aggregate tunnel session require independent control. In other words, they end-to-end session and the aggregate session do not need to have the same lifetime. These sessions should use different Session IDs. Individual signaling tunnels are different from aggregate signaling Shen, et al. Expires January 12, 2006 [Page 8] Internet-Draft NSIS Operation Over IP Tunnels July 2005 tunnels in that individual tunnel sessions are created and deleted along with the related end-to-end session. Therefore, the association between the end-to-end session and the corresponding individual tunnel session has two choices: first, they may use two different Session IDs as in the case of aggregate signaling tunnels. Second, they may share the same Session ID, which should be the Session ID of the original end-to-end session. The advantage of the first choice is that we would have a unified session association approach for both aggregate and individual signaling tunnels. The advantage of the second choice is that it conform to the general rule that the Session ID should not be modified end-to-end [11]. It also makes the handling of NSIS mobility inside the tunnel consistent with the NSIS mobility mechanism outside the tunnel. We call the association of two different Session IDs and the convey of this relationship "inter-session binding"; the association of two Flow IDs with the same Session ID and the convey of this relationship is called "intra-session binding". "inter-session binding" can be achieved by the BOUND_SESSION_ID object defined in NSIS QoS NSLP specification [13]. There is no existing object for "intra-session binding", a new BOUND_FLOW_SESSION object is thus defined for this purpose. It is clear that "inter-session binding" should be used for aggregate signaling tunnels. It is less clear which binding format should be used for individual signaling tunnels. In current version of this document we assume "intra-session binding'' is used for individual signaling tunnels. Note that the basic operation flow of NSIS signaling over an individual signaling tunnel is actually similar when either "inter-session binding" or "intra-session binding" is used. The difference is basically on the use of the corresponding BOUND_SESSION_ID or BOUND_FLOW_SESSION object. However, when it comes to advanced features such as mobility handling, the two choices may result in very different behavior. 5. Protocol Operation for Individual Signaling Tunnels For an individual signaling tunnel, a tunnel session is dynamically created and one-to-one mapped to an end-to-end session. In this document we identify four scenarios of NSIS tunnelling operation, two for Sender-Initiated and two for Receiver-Initiated operation. In all these scenarios, we require that all Tentry and Texit be NSIS aware. Furthermore, some or both of the tunnel end points need to be NSIS tunnel aware. An NSIS tunnel aware node should be able to associate an end-to-end session with a tunnel session, and subsequently coordinate the signaling between the end-to-end session and the tunnel session, e.g., setting the NON QoSM HOP flag ([14]) for the end-to-end session before confirmation of the tunnel session Shen, et al. Expires January 12, 2006 [Page 9] Internet-Draft NSIS Operation Over IP Tunnels July 2005 is received, and adjustment of the reservation upon changes either inside or outside the tunnel. All Tentries are also required to encapsulate related QoS data packets according to the chosen FCI so they can be filtered by intermediate nodes along the tunnel. 5.1 Sender Initiated Signaling Sender Tentry Tnode Texit Receiver | | | | | | RESERVE | | | | +--------->| | | | | | RESERVE' | | | | +=========>| | | | | | RESERVE' | | | | +=========>| | | | | RESPONSE'| | | | |<=========+ | | | RESPONSE'| | | | |<=========+ | | | | RESERVE | | | +-------------------->| | | | | | RESERVE | | | | +--------->| | | | | RESPONSE | | | | |<---------+ | | RESPONSE | | | |<--------------------+ | | RESPONSE | | | | |<---------+ | | | | | | | | | | | | | Figure 1: Sender-Initiated QoS NSLP over Tunnel - Scenario A Figure 1 shows the Sender-Initiated Scenario A (SI-A). The sender first sends the 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 creates the tunnel Flow ID by choosing the appropriate tunnel FCI and associates the end-to-end session with the tunnel session. It then sends a tunnel RESERVE message (RESERVE') matching the end-to-end session toward the Texit and requests a response. The RESERVE' message is processed hop by hop inside the tunnel for the tunnel flow identified by the chosen tunnel Flow ID. Upon successfully receiving the tunnel RESPONSE message (RESPONSE') confirming the tunnel Shen, et al. Expires January 12, 2006 [Page 10] Internet-Draft NSIS Operation Over IP Tunnels July 2005 signaling, Tentry encapsulates the end-to-end RESERVE message same as other tunnel packets and sends it to Texit. The Texit encapsulates this RESERVE message, process it and continue to forward it to the receiver. When the RESPONSE to the end-to-end RESERVE message reaches Texit, the Texit processes it and forwards it back toward the sender. Note that all tunnel signaling messages have standard NSIS signaling message formats, but they use tunnel specific MRI and may contain slightly different tunnel adjusted QoS parameters. Sender Tentry Tnode Texit Receiver | | | | | | RESERVE | | | | +--------->| | | | | | RESERVE' | | | | +=========>| | | | | | RESERVE' | | | | +=========>| | | | RESERVE | | | +-------------------->| | | | | | RESERVE | | | | +--------->| | | | | RESPONSE | | | | |<---------+ | | | RESPONSE'| | | | |<=========+ | | | RESPONSE'| | | | |<=========+ | | | | RESPONSE | | | |<--------------------+ | | RESPONSE | | | | |<---------+ | | | | | | | | | | | | | Figure 2: Sender-Initiated QoS NSLP over Tunnel - Scenario B Figure 2 shows the Sender-Initiated Scenario B (SI-B). In this case, Tentry is also responsible for determining the tunnel FCI and associating the end-to-end session with the tunnel session. This scenario differs from SI-A mainly in the sequence of the end-to-end and tunnel signaling. In SI-A, the Tentry does not forward the end- to-end RESERVE message to Texit until the tunnel signaling is confirmed by the tunnel response message. In SI-B, once the Tentry receives the end-to-end RESERVE, it sends out the RESERVE' but also forward the end-to-end RESERVE as normal encapsulated to Texit. Shen, et al. Expires January 12, 2006 [Page 11] Internet-Draft NSIS Operation Over IP Tunnels July 2005 Similarly, the end-to-end RESPONSE message and tunnel RESPONSE messages are forwarded independently and associated with each other at Tentry. If there is any change in either of the sessions, adjustment can be propagated to the other session through Tentry. SI-A can be considered as a sequential signaling approach, while SI-B can be considered as a parallel signaling approach. Note that in SI-B, since the Tentry has no idea whether the tunnel signaling will be successful when it proceeds with the end-to-end signaling, it should set the NON QoSM HOP flag as defined in [14] when it forwards the first end-to-end RESERVE message to Texit. The above description in SI-A and SI-B assumes that Tentry is the only NSIS tunnel aware nodes. Although Texit also sends out tunnel signaling messages, this could be done by standard NSIS signaling behavior. So Texit is NSIS aware but not necessarily NSIS tunnel aware. In some cases, Texit may indeed be NSIS tunnel aware. If Tentry wants to find that out, it MAY include a BOUND_FLOW_SESSION object in the end-to-end RESERVE message sent from Tentry to Texit. The object contains the tunnel Flow ID chosen by Tentry and the Session ID. At the Texit, if this object is not recognized, it should be dropped. But the RESERVE message is processed as normal. If the object is recognizable, then the Texit is NSIS tunnel aware. It will record the association between the end-to-end session identified by the Session ID and the tunnel session identified by the Flow ID. It can then also participate in the tunnel signaling process. For example, the adjustment of reservation due to changes inside or outside of the tunnel or possibly setting the NON QOSM HOP flag during the initial reservation setup in SI-B. 5.2 Receiver-Initiated Signaling Sender Tentry Tnode Texit Receiver | | | | | | QUERY | | | | +--------->| | | | | | QUERY | | | +-------------------->| | | | | | QUERY | | | | +--------->| | | | | RESERVE | | | | |<---------+ | | RESERVE | | | |<--------------------+ | | | QUERY' | | | | +=========>| | | Shen, et al. Expires January 12, 2006 [Page 12] Internet-Draft NSIS Operation Over IP Tunnels July 2005 | | | QUERY' | | | | +=========>| | | | | RESERVE' | | | | |<=========+ | | | RESERVE' | | | | |<=========+ | | | | RESPONSE'| | | | +=========>| | | | | | RESPONSE'| | | | +=========>| | | RESERVE | | | | |<---------+ | | | | RESPONSE | | | | +--------->| | | | | | RESPONSE | | | +-------------------->| | | | | | RESPONSE | | | | +--------->| | | | | | | | | | | Figure 3: Receiver-Initiated QoS NSLP over Tunnel - Scenario A Figure 3 shows the Receiver-Initiated Scenario A (RI-A). The Tentry receives the first end-to-end QUERY message from the Sender. It encapsulates the QUERY and forward it to Texit. Texit further forwards the QUERY to the receiver, which issues an end-to-end RESERVE. The Texit receives the first end-to-end RESERVE. It determines that an individual tunnel session should be created for the end-to-end session. Texit creates the tunnel Flow ID by choosing the appropriate tunnel FCI and associates the end-to-end session with the tunnel session. This tunnel Flow ID must be conveyed to the Tentry because the Tentry needs to trigger a tunnel signaling exchange and is also responsible for encapsulating selected data packets according to the specific Flow ID. Texit does this by appending a BOUND_FLOW_SESSION object to the RESERVE message sent directly back to Tentry. Upon receiving this RESERVE message, if Tentry does not recognize the BOUND_FLOW_SESSION object, it should drop this object and process the RESERVE message as normal. If Tentry recognize the BOUND_FLOW_SESSION object, it is NSIS tunnel aware. So the Tentry should record the association of the tunnel session and the end-to-end session, and send out a tunnel QUERY (QUERY') toward the Texit. Texit replies with a RESERVE' to Tentry. Upon successful tunnel reservation, the Tentry forwards the end-to- end RESERVE upstream toward the Sender and also returns a RESPONSE' to Texit. The Tentry will also receive a RESPONSE from the Sender, which will be tunnelled to Texit. Shen, et al. Expires January 12, 2006 [Page 13] Internet-Draft NSIS Operation Over IP Tunnels July 2005 Sender Tentry Tnode Texit Receiver | | | | | | QUERY | | | | +--------->| | | | | | QUERY | | | +-------------------->| | | | | | QUERY | | | | +--------->| | | | | RESERVE | | | | |<---------+ | | RESERVE | | | |<--------------------+ | | RESERVE | | | | |<---------+ | | | | | QUERY' | | | | +=========>| | | | | | QUERY' | | | | +=========>| | | | | RESERVE' | | | | |<=========+ | | | RESERVE' | | | | |<=========+ | | | | RESPONSE'| | | | +=========>| | | | | | RESPONSE'| | | | +=========>| | | RESPONSE | | | | +--------->| | | | | | RESPONSE | | | +-------------------->| | | | | | RESPONSE | | | | +--------->| | | | | | | | | | | Figure 4: Receiver-Initiated QoS NSLP over Tunnel - Scenario B RI-A represents a sequential signaling approach, where the first RESERVE message is not forwarded upstream until the tunnel reservation has been made. Figure 2 shows the parallel signaling approach. The procedure in RI-B is the same as in RI-A up to the point when Tentry receives the first end-to-end RESERVE message and sends out the QUERY' message. Instead of waiting for the tunnel signaling to finish, Tentry immediately forwards the end-to-end RESERVE upstream. The subsequent RESPONSE' and end-to-end RESPONSE messages are also sent independently and associated with each other Shen, et al. Expires January 12, 2006 [Page 14] Internet-Draft NSIS Operation Over IP Tunnels July 2005 at the tunnel end points. Unlike the Sender-Initiated cases, Receiver-Initiated scenarios require both Tentry and Texit to be NSIS tunnel aware. This means both end points need to keep an association of the tunnel session and the end-to-end session. Adjustment of either session caused by the other may be done through either tunnel end point. Note that in RI-B, when Tentry receives the first RESERVE message from Texit, it has no idea about whether the tunnel session will be successful or whether the tunnel itself contains non QoSM nodes. The Tentry should therefore set the NON QoSM HOP flag before forwarding the first end-to-end RESERVE message. Future versions of this document will contain more details about the procedures and procedures for additional scenarios, such as bidirectional reservations. 6. Protocol Operation for Aggregate Signaling Tunnels An aggregate signaling tunnel may contain one or more aggregate tunnel sessions configured through management interface. 6.1 Single Aggregate Tunnel Session If a single 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 a single 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 a Flow ID based on an appropriate aggregate flow FCI. Qualified packets need to be encapsulated with this FCI. The rest of the traffic will be normal IP-in-IP encapsulated. 6.2 Multiple Aggregate Tunnel Session If there are multiple configured NSIS sessions over a tunnel set up by the management interface, these sessions must be distinguished by their aggregate tunnel Flow IDs based on appropriate FCI. In this case it is necessary to explicitly bind the end-to-end session with the specific tunnel session. As described in Section 4.5, this binding is provided by the BOUND_SESSION_ID object which is carried in the end-to-end RESERVE message. Once the binding has been established, Tentry should encapsulate qualified data packets from different flows according to the associated aggregate tunnel session FCI. Intermediate nodes in the tunnel will then be able to filter these packets to receive reserved resources. Shen, et al. Expires January 12, 2006 [Page 15] Internet-Draft NSIS Operation Over IP Tunnels July 2005 6.3 Adjustment of Configured Tunnel Session The reservation of a configured tunnel session may or may not be adjustable. When the tunnel session is adjustable and there can be a many-to-one mapping to the tunnel session, the tunnel manager 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. In the second, the tunnel reservation is adjusted whenever a new end-to-end reservation arrives or an old one is torn down. 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. 7. New Object format This draft defines a BOUND_FLOW_SESSION object for intra-session binding. It has the Type-Length-Value (TLV) object format shown below. Type: BOUND_FLOW_SESSION Length: Variable Value: specifies the Session ID and a Flow ID that it should be associated with. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Session ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Flow ID (for the tunnel session) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shen, et al. Expires January 12, 2006 [Page 16] Internet-Draft NSIS Operation Over IP Tunnels July 2005 Figure 5: BOUND_FLOW_SESSION Object Note that use of this BOUND_FLOW_SESSION object in the Receiver- Initiated tunnel signaling scenario as specified in Section 5.2 essentially serves as a trigger to initiate a reservation process from a specific node to the node sending this object. If this can be identified as a general behavior applicable also to other scenarios, it may be necessary to create a separate message type for this purpose. 8. Security Considerations 9. References 9.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [3] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [6] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [9] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Shen, et al. Expires January 12, 2006 [Page 17] Internet-Draft NSIS Operation Over IP Tunnels July 2005 9.2 Informative References [11] Hancock, R., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-07 (work in progress), December 2004. [12] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work in progress), May 2005. [13] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in progress), February 2005. [14] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-04 (work in progress), May 2005. [15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress), May 2005. [16] Lee, S., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signaling-01 (work in progress), February 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. [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. 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 Shen, et al. Expires January 12, 2006 [Page 18] Internet-Draft NSIS Operation Over IP Tunnels July 2005 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 9585 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 Email: jh0278.bang@samsung.com Shen, et al. Expires January 12, 2006 [Page 19] Internet-Draft NSIS Operation Over IP Tunnels July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shen, et al. Expires January 12, 2006 [Page 20]