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