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