[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-nsis-tunnel

IETF Next Steps in Signaling                                     C. Shen
Internet-Draft                                            H. Schulzrinne
Expires: September 7, 2006                                   Columbia U.
                                                                  S. Lee
                                                                 J. Bang
                                                             Samsung AIT
                                                           March 6, 2006


                     NSIS Operation Over IP Tunnels
                     draft-shen-nsis-tunnel-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 the use of separate signaling sessions inside the tunnel for
   the end-to-end sessions.  Packets belonging to qualified tunnel



Shen, et al.            Expires September 7, 2006               [Page 1]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   sessions are assigned special flow IDs 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.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  IP Tunneling Mechanisms  . . . . . . . . . . . . . . .  4
       2.1.2.  Different Signaling Capability of IP Tunnels . . . . .  5
     2.2.  NSIS Tunnel Operation Overview . . . . . . . . . . . . . .  5
   3.  Protocol Design Decisions  . . . . . . . . . . . . . . . . . .  7
     3.1.  Packet Classification over the Tunnel  . . . . . . . . . .  7
     3.2.  Tunnel Signaling and its Association with End-to-end
           Signaling  . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Tunnel Signaling Capability Discovery  . . . . . . . . . .  9
   4.  Protocol Operation with Dynamically Created Tunnel Sessions  .  9
     4.1.  Operation Scenarios  . . . . . . . . . . . . . . . . . . .  9
       4.1.1.  Sender-initiated Reservation for both End-to-end
               and Tunnel Signaling . . . . . . . . . . . . . . . . . 10
       4.1.2.  Receiver-initiated Reservation for both End-to-end
               and Tunnel Signaling . . . . . . . . . . . . . . . . . 11
       4.1.3.  Sender-initiated Reservation for End-to-end and
               Receiver-initiated Reservation for Tunnel Signaling  . 13
       4.1.4.  Receiver-initiated Reservation for End-to-end and
               Sender-initiated Reservation for Tunnel Signaling  . . 15
     4.2.  Implementation Considerations  . . . . . . . . . . . . . . 16
       4.2.1.  End-to-end and Tunnel Signaling Interaction  . . . . . 16
       4.2.2.  Aggregate vs. Individual Tunnel Session Setup  . . . . 18
   5.  Protocol Operation with Pre-configured Tunnel Sessions . . . . 19
     5.1.  Tunnel with Exactly One Pre-configured Aggregate
           Session  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.2.  Tunnel with Multiple Pre-configured Aggregate Sessions . . 19
     5.3.  Adjustment of Pre-configured Tunnel Sessions . . . . . . . 19
     5.4.  Tunnels with both Dynamic and Pre-configured Signaling
           Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 20
   6.  Processing Rules for Selected End-to-end QoS NSLP Messages . . 20
     6.1.  End-to-end QUERY Message at Tentry . . . . . . . . . . . . 20
     6.2.  End-to-end QUERY Message at Texit  . . . . . . . . . . . . 21
     6.3.  End-to-end RESERVE Message at Tentry . . . . . . . . . . . 21
     6.4.  End-to-end RESERVE Message at Texit  . . . . . . . . . . . 23
     6.5.  Special Processing Rules for Tunnels with Aggregate
           Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 24
   7.  Other Considerations . . . . . . . . . . . . . . . . . . . . . 25



Shen, et al.            Expires September 7, 2006               [Page 2]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


     7.1.  Other Types of NSLP  . . . . . . . . . . . . . . . . . . . 25
     7.2.  IPSEC Flows  . . . . . . . . . . . . . . . . . . . . . . . 25
     7.3.  NSIS-Tunnel and Mobility . . . . . . . . . . . . . . . . . 25
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   9.  Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Summary of RSVP Operation Over IP Tunnels  . . . . . . . . 26
     9.2.  Various Design Alternatives  . . . . . . . . . . . . . . . 27
       9.2.1.  End-to-end and Tunnel Signaling Interaction Model  . . 27
       9.2.2.  Packet Classification over the Tunnel  . . . . . . . . 27
       9.2.3.  Tunnel Binding Methods . . . . . . . . . . . . . . . . 28
       9.2.4.  Tunnel Binding Indication  . . . . . . . . . . . . . . 28
       9.2.5.  Carrying the Tunnel Binding Object . . . . . . . . . . 29
     9.3.  Change History . . . . . . . . . . . . . . . . . . . . . . 29
       9.3.1.  Changes in Version -02 . . . . . . . . . . . . . . . . 29
       9.3.2.  Changes in Version -01 . . . . . . . . . . . . . . . . 29
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
     11.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33






























Shen, et al.            Expires September 7, 2006               [Page 3]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


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.  Background

2.1.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



Shen, et al.            Expires September 7, 2006               [Page 4]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


      ESP is placed before the encapsulated IP header.

   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.1.2.  Different Signaling Capability 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, [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.  An
   individual tunnel signaling session may be created and torn down
   dynamically as end-to-end session come and go.  An aggregate tunnel
   sessions could be a pre-configured session that never gets changed,
   or could be dynamically adjusted as the actually used session
   resources increase or decrease.

   A tunnel may also be a mixed one that combines the properties of both
   types of the tunnels.

2.2.  NSIS Tunnel Operation Overview

   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,




Shen, et al.            Expires September 7, 2006               [Page 5]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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 signaling aware tunnels, make sure proper signaling is carried
      out when necessary, to set up the tunnel sessions for use by the
      end-to-end sessions.
   o  Work with most, if not all, existing IP in IP tunneling schemes.
   o  Place the specific tunnel related functionalities only in one or
      both of the tunnel endpoints.

   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 9.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
   (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-



Shen, et al.            Expires September 7, 2006               [Page 6]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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.


3.  Protocol Design Decisions

3.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 grouped 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 DiffServ 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 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.




Shen, et al.            Expires September 7, 2006               [Page 7]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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.1.  An example of this
      additional 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 [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.

3.2.  Tunnel Signaling and its Association with End-to-end Signaling

   Tunnel signaling messages contain tunnel specific parameters such as
   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 tunnel flow IDs, creating tunnel



Shen, et al.            Expires September 7, 2006               [Page 8]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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 are NSIS-tunnel aware, the endpoint that
   creates the tunnel session may need to notify the other endpoint of
   the association between the end-to-end and tunnel session.  This is
   achieved by using the QoS NSLP BOUND_SESSION_ID object with a binding
   code indicating this binding is for tunnel handling.  In the rest of
   this document, we refer to a BOUND_SESSION_ID object with the tunnel
   binding_code as a tunnel BOUND_SESSION_ID object or a tunnel binding
   object.  The tunnel binding object is carried in the end-to-end
   signaling messages with the session ID of the corresponding tunnel
   session.  The NSIS-tunnel aware endpoints that receive this tunnel
   BOUND_SESSION_ID object should perform tunnel related procedures and
   then remove it for any end-to-end signaling messages to be sent out
   of the tunnel.

3.3.  Tunnel Signaling Capability Discovery

   Tunnel signaling may only be initiated when both Tentry and Texit are
   NSIS-tunnel aware.  When prior knowledge of the other endpoint's NSIS
   tunnel capability is not available, we need a discovery mechanism to
   find it out.  This mechanism is expected to be the responsibility of
   the NSLP layer.  One option is to define a ''Tunnel Capable'' bit in
   the INFO_SPEC object of its informational class and exchange it
   between the Tentry and Texit.  More details will be provided in the
   next version of this document.  The messaging flow diagrams in the
   current document assume that the tunnel capability discovery has
   already been made.


4.  Protocol Operation with Dynamically Created Tunnel Sessions

4.1.  Operation Scenarios

   To dynamically create a mapping tunnel session upon receiving an end-
   to-end session, we identify four scenarios based on the sender-
   initiated and receiver-initiated reservation modes of NSIS QoS NSLP:

   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



Shen, et al.            Expires September 7, 2006               [Page 9]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


      receiver-initiated.
   o  D. End-to-end session is receiver-initiated; tunnel session is
      sender-initiated.

   In the following we present a typical NSIS end-to-end and tunnel
   signaling interaction during the tunnel set up phase in each of these
   four scenarios.  The end-to-end QoS flow is assumed to be one that
   qualifies an individual dynamic tunnel session, whose reservation
   must be confirmed.

   It should be noted that different flow requirements and policy
   assumptions may cause the timing sequence of the messaging flow to be
   slightly different, which will be discussed in Section 4.2.

   Once the tunnel session has been created and associated with the end-
   to-end session, any subsequent changes (modification or termination)
   to either session may be communicated to the other one by the binding
   endpoint so the state of the two binding sessions may keep
   consistent.  The exception is when the tunnel session is an aggregate
   session.  In this case, after setup, the adjustment of the tunnel
   session should follow the rules for pre-configured aggregate tunnel
   adjustment in Section 5.

4.1.1.  Sender-initiated Reservation for both End-to-end and Tunnel
        Signaling



     Sender    Tentry      Tnode      Texit     Receiver

       |          |          |          |          |
       | RESERVE  |          |          |          |
       +--------->|          |          |          |
       |          | RESERVE' |          |          |
       |          +=========>|          |          |
       |          |          | RESERVE' |          |
       |          |          +=========>|          |
       |          |       RESERVE       |          |
       |          +-------------------->|          |
       |          |          | RESPONSE'| RESERVE  |
       |          |          |<=========+--------->|
       |          | RESPONSE'|          |          |
       |          |<=========+          |          |
       |          |          |          | RESPONSE |
       |          |          |          |<---------+
       |          |       RESPONSE      |          |
       |          |<--------------------+          |
       | RESPONSE |          |          |          |



Shen, et al.            Expires September 7, 2006              [Page 10]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


       |<---------+          |          |          |
       |          |          |          |          |
       |          |          |          |          |




   Figure 1: Sender-initiated Reservation for both End-to-end and Tunnel
   Signaling

   This scenario assumes both end-to-end and tunnel sessions are sender-
   initiated.  Figure 1 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.  Tnode
   denotes an intermediate tunnel node that participates in tunnel
   signaling.  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 a
   tunnel BOUND_SESSION_ID object containing the session ID 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.

4.1.2.  Receiver-initiated Reservation for both End-to-end and Tunnel
        Signaling


     Sender    Tentry      Tnode      Texit     Receiver




Shen, et al.            Expires September 7, 2006              [Page 11]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


       |          |          |          |          |
       |  QUERY   |          |          |          |
       +--------->|          |          |          |
       |          |        QUERY        |          |
       |          +-------------------->|          |
       |          |  QUERY'  |          |          |
       |          +=========>|          |          |
       |          |          |  QUERY'  |          |
       |          |          +=========>|          |
       |          |          |          |  QUERY   |
       |          |          |          +--------->|
       |          |          |          | RESERVE  |
       |          |          |          |<---------+
       |          |       RESERVE       |          |
       |          |<--------------------+          |
       |          |          | RESERVE' |          |
       |          |          |<=========+          |
       |          | RESERVE' |          |          |
       |          |<=========+          |          |
       |  RESERVE | RESPONSE'|          |          |
       |<---------+=========>|          |          |
       |          |          | RESPONSE'|          |
       |          |          +=========>|          |
       | RESPONSE |          |          |          |
       +--------->|          |          |          |
       |          |       RESPONSE      |          |
       |          +-------------------->|          |
       |          |          |          | RESPONSE |
       |          |          |          +--------->|
       |          |          |          |          |
       |          |          |          |          |


   Figure 2: Receiver-initiated Reservation for both End-to-end and
   Tunnel Signaling

   This scenario assumes both end-to-end and tunnel sessions are
   receiver-initiated.  Figure 2 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 session ID 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



Shen, et al.            Expires September 7, 2006              [Page 12]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   for the flow identified by the chosen tunnel flow ID.  When Texit
   receives the tunnel QUERY' message, it creates a reservation state
   for the tunnel session without sending out a tunnel RESERVE' message
   immediately.

   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.

   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.

4.1.3.  Sender-initiated Reservation for End-to-end and Receiver-
        initiated Reservation for Tunnel Signaling


     Sender    Tentry      Tnode      Texit     Receiver
     |          |          |          |          |
     | RESERVE  |          |          |          |
     +--------->|          |          |          |
     |          |  QUERY'  |          |          |
     |          +=========>|          |          |
     |          |          |  QUERY'  |          |
     |          |          +=========>|          |
     |          |          | RESERVE' |          |
     |          |          |<=========+          |
     |          | RESERVE' |          |          |
     |          |<=========+          |          |
     |          | RESPONSE'|          |          |
     |          +=========>|          |          |
     |          |          | RESPONSE'|          |
     |          |          +=========>|          |
     |          |        RESERVE      |          |
     |          +-------------------->|          |
     |          |          |          | RESERVE  |



Shen, et al.            Expires September 7, 2006              [Page 13]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


     |          |          |          +--------->|
     |          |          |          | RESPONSE |
     |          |          |          |<---------+
     |          |       RESPONSE      |          |
     |          |<--------------------+          |
     | RESPONSE |          |          |          |
     |<---------+          |          |          |
     |          |          |          |          |
     |          |          |          |          |


   Figure 3: Sender-initiated Reservation for End-to-end and Receiver-
   initiated Reservation for Tunnel Signaling

   This scenario assumes the end-to-end signaling mode is sender-
   initiated and the tunnel signaling mode is 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 RESERVE
   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.  This Tunnel
   QUERY' message should have the "RESERVE-INIT" bit set.  Tentry also
   appends to the original QUERY message with a tunnel BOUND_SESSION_ID
   object containing the session ID 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 creates a reservation state
   for the tunnel session and immediately send out a tunnel RESERVE'
   message back to Tentry.

   When the Tentry receives the tunnel RESERVE' message it learns the
   outcome of the tunnel reservation.  So it appends to the end-to-end
   RESERVE message a BOUND_SESSION_ID object containing the tunnel
   session ID and sends it over the tunnel with normal encapsulation.
   It may send out a tunnel RESPONSE' message if requested.

   When Texit receives the end-to-end RESERVE message, it notices the
   binding of a tunnel session and creates the end-to-end reservation
   state with reference to 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.

4.1.4.  Receiver-initiated Reservation for End-to-end and Sender-
        initiated Reservation for Tunnel Signaling



Shen, et al.            Expires September 7, 2006              [Page 14]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


     Sender    Tentry      Tnode      Texit     Receiver
     |          |          |          |          |
     |  QUERY   |          |          |          |
     +--------->|          |          |          |
     |          |        QUERY        |          |
     |          +-------------------->|          |
     |          |  QUERY'  |          |          |
     |          +=========>|          |          |
     |          |          |  QUERY'  |          |
     |          |          +=========>|          |
     |          |          |          |  QUERY   |
     |          |          |          +--------->|
     |          |          |          | RESERVE  |
     |          |          |          |<---------+
     |          |       RESERVE       |          |
     |          |<--------------------+          |
     |          |          | RESERVE' |          |
     |          |          +=========>|          |
     |          | RESERVE' |          |          |
     |          +=========>|          |          |
     |          |          | RESPONSE'|          |
     |          |          |<=========|          |
     |          | RESPONSE'|          |          |
     |          |<=========|          |          |
     | RESERVE  |          |          |          |
     |<---------|          |          |          |
     | RESPONSE |          |          |          |
     +--------->|          |          |          |
     |          |       RESPONSE      |          |
     |          +-------------------->|          |
     |          |          |          | RESPONSE |
     |          |          |          +--------->|
     |          |          |          |          |
     |          |          |          |          |



   Figure 4: Receiver-initiated Reservation for End-to-end and Sender-
   initiated Reservation for Tunnel Signaling

   This scenario assumes the end-to-end signaling mode is receiver-
   initiated and the tunnel signaling mode is sender-initiated.
   Figure 4 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 a tunnel BOUND_SESSION_ID



Shen, et al.            Expires September 7, 2006              [Page 15]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   object containing the session ID 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 creates a reservation state
   for the tunnel session without sending out a tunnel RESERVE' message
   immediately.

   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.

   When Texit receives the first end-to-end RESERVE message issued by
   the receiver, it finds the reservation state of the tunnel session.
   Texit appends to the end-to-end RESERVE message a tunnel
   BOUND_SESSION_ID object containing the matching tunnel session ID and
   sends it upstream to Tentry.

   When Tentry receives the end-to-end RESERVE message, it notices the
   binding and immediately sends out a tunnel RESERVE' message matching
   the end-to-end RESERVE request over the tunnel.  This RESERVE'
   message should include the Request Identification Information (RII)
   to trigger a RESPONSE' from Texit.

   When Tentry receives the result of tunnel reservation from the tunnel
   RESPONSE' message, it updates the end-to-end RESERVE message and
   forwards the end-to-end RESERVE message upstream to the Sender.  The
   Sender may send an end-to-end RESPONSE message to the receiver when
   the whole process completes.

4.2.  Implementation Considerations

4.2.1.  End-to-end and Tunnel Signaling Interaction

   Given the two separate end-to-end and tunnel signaling sessions,
   there are many ways of integrating the signaling of each session.  In
   general, different approaches can be grouped into two modes,
   sequential mode and parallel mode.  In sequential mode, end-to-end
   signaling pauses when it is waiting for results of tunnel signaling,
   and resumes upon receipt of the tunnel signaling outcome; in parallel
   mode, end-to-end signaling continues outside the tunnel while tunnel
   signaling is still in process and its outcome is unknown.  The
   operation outlined in Section 4.1 shows the sequential mode.  While



Shen, et al.            Expires September 7, 2006              [Page 16]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   this mode is ideal for a flow that requires hard guarantee of tunnel
   reservation.  It may not be the best for a flow that can tolerate
   some QoS uncertainty but wants to establish signaling state on the
   path as fast as possible.  The parallel mode is clearly for the
   latter case.

   Therefore, an actual implementation may vary the timing sequence of
   the NSIS-tunnel signaling interaction by taking into account whether
   the end-to-end flow can tolerate the "reservation uncertainly".  The
   root of this problem has to do with the possible racing condition
   that always exists in a separate end-to-end and tunnel session model.
   When an end-to-end session message carrying tunnel binding object
   arrives at one of the tunnel endpoints, if the corresponding tunnel
   session state has already been created, then the tunnel endpoint may
   refer to information from the tunnel session state (e.g. about tunnel
   reservation status, or tunnel resource availability) and construct an
   end-to-end signaling message to be sent out of the tunnel
   immediately.

   On the other hand, if the tunnel endpoint receives an end-to-end
   signaling message carrying tunnel binding referring to a tunnel
   session not yet exists, it may either wait a short period and see if
   the tunnel signaling arrives, or forward the end-to-end session
   immediately but indicate in the outgoing end-to-end signaling message
   that there is a NON-QoSM aware link in the end-to-end path.  The
   period that the node decides to wait is purely implementation
   specific.  In normal cases we expect the tunnel signaling message to
   lag behind (if it does) by only some node processing time (because
   the end-to-end signaling messages are not processed by NSLP inside
   the tunnel).  As to whether wait or not, the decision will be based
   on the flow's toleration about "reservation uncertainly".  With the
   current QSPEC [14], one option is to wait shorter or does not wait
   for end-to-end reservations requirements that are downgradable, and
   to wait until the tunnel session status is known if the end-to-end
   reservations requirement is fixed.  However, to really directly
   address this issue, we suggest that an explicit indication flag, e.g.
   "QoS Unknown - intolerable" be defined as part of the QSPEC.

   In the situation where the end-to-end signaling missed the tunnel
   session state in the tunnel endpoint and proceeds as if the tunnel is
   NON-QoSM aware, the tunnel session may still be created (after some
   delay).  Since the tunnel signaling message does not contain the end-
   to-end session's session ID, it cannot immediately change the state
   of the end-to-end session.  However, the next refresh of the end-to-
   end signaling message will carry the tunnel binding information and
   thus update its own state.  If the period waiting for end-to-end
   refresh is considered too long, the tunnel endpoint may choose to
   actively poll the session state table about the existence of tunnel



Shen, et al.            Expires September 7, 2006              [Page 17]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   session before the refresh timer expires.  In any case, once the end-
   to-end signaling session learns about the tunnel signaling it can
   send an immediate refresh out of the tunnel with the knowledge of
   tunnel session.

   In addition to the broad concept of sequential and parallel modes of
   interaction.  There are also other flexible aspects in the end-to-end
   and tunnel signaling interaction.  One is tunnel session initiation
   location. e.g., it is possible to initiate the tunnel session from
   Texit instead of Tentry.  Second is the tunnel session initiation
   time point.  E.g. in cases when both end-to-end session and tunnel
   session are receiver-initiated, it is possible to start the tunnel
   session when Tentry receives the first end-to-end RESERVE message.
   The drawback of this scheme is that it 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.  A third
   aspect of flexibility is how the tunnel signaling messages are used.
   e.g., in the case where end-to-end session is receiver initiated and
   tunnel session is sender initiated as in Section 4.1.4, the first
   tunnel QUERY' message sent after receiving end-to-end QUERY message
   by Tentry can be replaced by a tunnel RESERVE' message, if the
   application wants to trade temporary oversized or unnecessary (if the
   end-to-end reservation turns out to be unsatisfied) tunnel resource
   reservations for signaling setup delay.  All these may be seen as
   local optimization issues.  An implementation should at least support
   the basic scheme to allow interoperability.

4.2.2.  Aggregate vs. Individual Tunnel Session Setup

   The operation outlined in Section 4.1 applies to a flow that
   qualifies an individual dynamic tunnel session.  For a tunnel that
   contains multiple end-to-end sessions, however, it is generally
   recommended to keep aggregate tunnel session rather than creating
   individual tunnel sessions for each end-to-end session whenever
   possible.  This will save the cost of setting up a new session and
   avoid the set up latency as well as the session establishment racing
   conditions mentioned above.  Therefore, when the tunnel endpoint
   creates the reservation for the tunnel session based on the
   individual end-to-end session, it is up to local policy that whether
   it wants to actually create an aggregate session by requesting more
   resources than the current end-to-end session requires.  If it does,
   other end-to-end sessions arrived later may also make use of this
   tunnel session.  The tunnel endpoint will also need to determine how
   long to keep the tunnel session if no end-to-end session is active.
   The decision may be based on knowledge of likelihood of traffic in
   the future.  It should be noted that once these kinds of on-demand
   aggregate tunnel session is setup, it looks exactly the same as a
   pre-configured tunnel session to future end-to-end sessions.



Shen, et al.            Expires September 7, 2006              [Page 18]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   Therefore, the adjustment of such aggregate sessions should follow
   Section 5.

   Note that the session ID of an aggregate tunnel session should be
   different from that of the end-to-end session because they usually
   have separate lifetime.  If the tunnel endpoint is certain that the
   tunnel session is for an individual end-to-end session alone, it may
   in some cases want to use the same session ID for both sessions.
   This may require additional manipulation of the NSLP state at the
   tunnel endpoints, since the NSLP state is usually keyed by the
   session ID.


5.  Protocol Operation with Pre-configured Tunnel Sessions

   A tunnel may be pre-configured through management interface with one
   or more tunnel sessions.  One or more end-to-end sessions may be
   mapped to each of these pre-configured sessions.  Therefore in most
   cases these pre-configured tunnel sessions are aggregate sessions.

5.1.  Tunnel with Exactly One Pre-configured 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.

5.2.  Tunnel with Multiple Pre-configured 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 messages.  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.

5.3.  Adjustment of Pre-configured Tunnel Sessions




Shen, et al.            Expires September 7, 2006              [Page 19]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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, 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.

5.4.  Tunnels with both Dynamic and Pre-configured Signaling Sessions

   If a tunnel contains both dynamic and pre-configured tunnel sessions,
   it can be handled by 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.


6.  Processing Rules for Selected End-to-end QoS NSLP Messages

   The following lists basic message processing rules for end-to-end QoS
   NSLP messages working in the sequential interaction mode with tunnel
   signaling.  More details may be provided for this section in future
   version of this document.

   Note that in case of aggregate tunnels, the actual tunnel session
   reservation, adjustment and termination are not (necessarily)
   determined by every end-to-end signaling messages, but by
   implementation specific algorithms instead.

6.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



Shen, et al.            Expires September 7, 2006              [Page 20]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   end-to-end QUERY message.  The tunnel BOUND_SESSION_ID object
   contains the session ID 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
   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.

6.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 (i.e., a state is created but the related
   outgoing signaling message, in this case the QUERY message, is held
   until further information is available).  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'.

6.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, depending on whether the tunnel signaling is sender
   initiated or receiver initiated, Tentry should create a new tunnel
   RESERVE' message or tunnel QUERY' message to start changing 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



Shen, et al.            Expires September 7, 2006              [Page 21]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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
   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' or QUERY' message, depending on whether the tunnel
   signaling is sender initiated or receiver initiated.  The QSPEC in
   this tunnel 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 message toward
   Texit to start reserving 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 tunnel signaling is sender initiated, Tentry also sends a tunnel
   RESERVE' message to teardown the tunnel session.

   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.  If tunnel signaling is sender initiated, Tentry also sends
   a tunnel RESERVE' message toward Texit to reserve tunnel resources.
   When the actual tunnel session status is known at Tentry (from a
   tunnel RESERVE' if tunnel signaling is receiver initiated or at
   tunnel RESPONSE' if tunnel signaling is sender initiated) and if at
   this time there is a pending reservation, Tentry should generate an
   end-to-end RESERVE message and forward it upstream.



Shen, et al.            Expires September 7, 2006              [Page 22]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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 and if tunnel signaling is sender initiated, Tentry sends
   a tunnel RESERVE' message to Texit to change the reservation.  In any
   case, Texit checks the state information of the tunnel session.  If
   it finds that the reservation has been updated inside the tunnel,
   Texit forwards the changed RESERVE message toward the sender.  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.

6.4.  End-to-end RESERVE Message at Texit

   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 tunnel signaling is receiver-
   initiated, Texit also sends a tunnel RESERVE tear upstream toward
   Tentry to tear down the tunnel session.

   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.




Shen, et al.            Expires September 7, 2006              [Page 23]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   Note that the processing rules for end-to-end RESERVE at Texit in
   end-to-end sender-initiated case is similar to those for end-to-end
   RESERVE at Tentry in end-to-end 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
   BOUND_SESSION_ID object to this end-to-end RESERVE message and sends
   it toward Tentry through the tunnel interface.  Meanwhile if tunnel
   signaling is receiver initiated Texit 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 and if tunnel signaling
   is receiver initiated, 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.

6.5.  Special Processing Rules for Tunnels with Aggregate Sessions

   In situations where the end-to-end session is bound to aggregate
   tunnel sessions, the handling is similar to that of [18].

   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



Shen, et al.            Expires September 7, 2006              [Page 24]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   track of both the allocated tunnel session resources and the
   resources actually used by end-to-end sessions bound to that tunnel
   session.


7.  Other Considerations

7.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
   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.  This topic
   will be discussed in future version of this document if necessary.

7.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 3.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.

7.3.  NSIS-Tunnel and Mobility

   The NSIS-tunnel operation needs to interact with IP mobility in an
   efficient way.  In places where pre-configured tunnel sessions are
   available, the process is relatively straightforward.  For dynamic
   individual signaling tunnel sessions, one way to improve tunnel NSIS-
   mobility efficiency is to reuse the session ID of the tunnel session
   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 endpoint is the Mobile Node (MN) if collocated Care-of-



Shen, et al.            Expires September 7, 2006              [Page 25]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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 session ID 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 session ID 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 session
   ID 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).


8.  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].


9.  Appendix

9.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



Shen, et al.            Expires September 7, 2006              [Page 26]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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.

9.2.  Various Design Alternatives

9.2.1.  End-to-end and Tunnel Signaling Interaction Model

   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 maintain a separate tunnel session for the
   end-to-end end session by generating separate signaling messages for
   the tunnel signaling session.  Another possibility 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
   difficult because the actual tunnel signaling messages differ from
   the end-to-end signaling message both in GIST layer and NSLP layer
   information, such as MRI, PACKET CLASSIFIER and QSPEC.  Although
   QSPEC can be stacked in an NSLP message, there doesn't seem to be a
   handy way to stack MRI and the PACKET CLASSIFIER in the NSLP layer.
   In addition, the stacking method only applies to individual signaling
   tunnels.

   The separate end-to-end tunnel session signaling model adopted in
   this document handles both individual and aggregate signaling tunnels
   in a consistent way.  Its major drawback is the racing condition we
   mentioned in Section 4.2.  However, this can be readily handled with
   the introducing of a flag indicating whether the flow is willing to
   tolerate "tunnel reservation uncertainty".

   To support tunnel signaling it is natural that at least one of the
   tunnel endpoints will need to understand the NSIS-tunnel operation.
   We see that 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.

9.2.2.  Packet Classification over the Tunnel




Shen, et al.            Expires September 7, 2006              [Page 27]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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 property 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 handoff does not need to be updated about the packet
   classification, 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 chooses the second approach which does not
   pose special requirements on intermediate tunnel nodes.

9.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.  Instead of sending a BOUND_SESSION_ID object, it may be
   possible to define a BOUND_FLOW_ID object, to bind the flow ID of the
   end-to-end session to the flow ID of the tunnel session at the tunnel
   endpoints.  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 to have different
   session association mechanisms for aggregate signaling tunnels and
   individual signaling tunnels.  Therefore, we decide to use the same
   tunnel BOUND_SESSION_ID mechanism 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 7.3.

9.2.4.  Tunnel Binding Indication

   In this document we used the existing BOUND_SESSION_ID object with a
   tunnel Binding_code to indicate the reason of binding.  Two other
   options considered are:




Shen, et al.            Expires September 7, 2006              [Page 28]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   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.

9.2.5.  Carrying the Tunnel Binding Object

   There are basically three ways to carry the binding object between
   Tentry and Texit, using (a) end-to-end signaling messages (b) tunnel
   signaling messages. (c) both end-to-end and tunnel signaling
   messages.

   In option (a) only tunnel endpoints sees the tunnel binding
   information.  While in option (b), every intermediate node sees the
   binding information.  Since there will be no state for the end-to-end
   session in the tunnel intermediate nodes, they will all generate a
   message containing an "INFO_SPEC" object indicating no bound session
   found according to [3], which is not acceptable.  Option (c) has a
   good point that if both end-to-end and tunnel signaling messages have
   tunnel binding information, the racing condition will be resolved
   faster.  However it suffers the same problem as in (b).  Therefore
   the choice in this document is option (a).

9.3.  Change History

9.3.1.  Changes in Version -02

   1.  Rearranged section names to emphasize the difference between
       dynamically created tunnel sessions and pre-configured tunnel
       sessions.
   2.  Added implementation considerations section about how to deal
       with the race condition in the separate session model, and
       allowed the dynamically created tunnel session to be an aggregate
       session.
   3.  Added operation examples on the two scenarios where e2e and
       tunnel session uses different signaling initiation modes.
   4.  Removed the illustration of binding_code for tunnel
       BOUND_SESSION_ID object since it has been added to NSLP
       specification.
   5.  Clarified that tunnel capability discovery is at NSLP layer.
   6.  Updated some of the message processing rules.
   7.  Updated some parts of the appendix.

9.3.2.  Changes in Version -01




Shen, et al.            Expires September 7, 2006              [Page 29]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


   1.  Added message processing rules.
   2.  Put some of the backgrounds and alternative design choices to
       appendix.
   3.  Proposed the binding_code for tunnel BOUND_SESSION_ID object.


10.  Acknowledgements


11.  References

11.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-09 (work in
        progress), February 2006.

   [3]  Manner, J., "NSLP for Quality-of-Service signalling",
        draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006.

11.2.  Informative References

   [4]   Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
         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



Shen, et al.            Expires September 7, 2006              [Page 30]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


         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-08
         (work in progress), December 2005.

   [15]  Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
         (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress),
         February 2006.

   [16]  Lee, S., "Applicability Statement of NSIS Protocols in Mobile
         Environments",
         draft-ietf-nsis-applicability-mobility-signaling-03 (work in
         progress), October 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.

   [21]  Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
         Steps in Signaling (NSIS)", RFC 4081, June 2005.
















Shen, et al.            Expires September 7, 2006              [Page 31]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


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 September 7, 2006              [Page 32]

Internet-Draft       NSIS Operation over IP Tunnels           March 2006


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 (2006).  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 September 7, 2006              [Page 33]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/