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]