draft-ietf-nsis-tunnel-08.txt   draft-ietf-nsis-tunnel-09.txt 
IETF Next Steps in Signaling C. Shen IETF Next Steps in Signaling C. Shen
Internet-Draft H. Schulzrinne Internet-Draft H. Schulzrinne
Intended status: Informational Columbia U. Intended status: Experimental Columbia U.
Expires: August 13, 2010 S. Lee Expires: August 19, 2010 S. Lee
J. Bang J. Bang
Samsung AIT Samsung AIT
February 9, 2010 February 15, 2010
NSIS Operation Over IP Tunnels NSIS Operation Over IP Tunnels
draft-ietf-nsis-tunnel-08.txt draft-ietf-nsis-tunnel-09.txt
Abstract Abstract
NSIS QoS signaling enables applications to perform QoS reservation NSIS QoS signaling enables applications to perform QoS reservation
along a data flow path. When the data flow path contains IP tunnel along a data flow path. When the data flow path contains IP tunnel
segments, NSIS QoS signaling has no effect within those tunnel segments, NSIS QoS signaling has no effect within those tunnel
segments and the resulting QoS-untended tunnel segments could become segments and the resulting QoS-untended tunnel segments could become
the weakest QoS link which may invalidate the QoS efforts in the rest the weakest QoS link which may invalidate the QoS efforts in the rest
of the end-to-end path. The problem with NSIS signaling within the of the end-to-end path. The problem with NSIS signaling within the
tunnel is caused by the tunnel encapsulation which masks packets' tunnel is caused by the tunnel encapsulation which masks packets'
skipping to change at page 2, line 5 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2010. This Internet-Draft will expire on August 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 25 skipping to change at page 3, line 25
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 14 4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 14
5. NSIS Operation over Tunnels with Pre-configured QoS 5. NSIS Operation over Tunnels with Pre-configured QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 15 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 15
5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15 5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS 6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17 6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17
6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 20 6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 20
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
7.1. NODE_CAPABILITY Object Format . . . . . . . . . . . . . . 22 7.1. NODE_CAPABILITY Object Format . . . . . . . . . . . . . . 23
7.2. Using NODE_CAPABILITY Object . . . . . . . . . . . . . . . 23 7.2. Using NODE_CAPABILITY Object . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
skipping to change at page 22, line 35 skipping to change at page 22, line 35
Once the end-to-end and the tunnel QoS session have both been Once the end-to-end and the tunnel QoS session have both been
successfully created and associated, the tunnel end-points Tentry and successfully created and associated, the tunnel end-points Tentry and
Texit coordinate the signaling between the two sessions and make sure Texit coordinate the signaling between the two sessions and make sure
that adjustment or teardown of either session can trigger similar that adjustment or teardown of either session can trigger similar
actions for the other session as necessary, by invoking appropriate actions for the other session as necessary, by invoking appropriate
signaling messages. signaling messages.
7. NSIS-Tunnel Signaling Capability Discovery 7. NSIS-Tunnel Signaling Capability Discovery
When operating over a tunnel, NSIS-tunnel-aware end-points may need The mechanism of NSIS operating over IP tunnels requires the
to perform special encapsulation and decapsulation such as inserting coordination of both tunnel end-points in tasks such as special
and removal of an extra UDP header, depending on the tunnel Flow ID encapsulation and decapsulation of data flow packets according to the
format. Therefore, before the NSIS-tunnel-aware end-point decides to chosen tunnel Flow ID, as well as the possible creation and
initiate such encapsulation, it needs to know whether the other adjustment of the end-to-end and tunnel QoS sessions. Therefore, one
entry-point is also NSIS-tunnel-aware and thus capable of performing NSIS-tunnel-aware end-point needs to know that the other tunnel end-
matching decapsulation. This section defines a mechanism to enable point is also NSIS-tunnel-aware before initiating this NSIS operating
this capability discovery for tunnels using dynamically created over IP tunnel mechanism. In some cases, especially for IP tunnels
tunnel QoS sessions. For tunnels with pre-configured QoS sessions, with pre-configured QoS sessions, an NSIS-tunnel-aware end-point can
an end-point can learn the NSIS-tunnel capability information of the learn about whether the other tunnel end-point is also NSIS-tunnel-
other end-point during the pre-configuration process. aware through pre-configuration. In other cases where such pre-
configuration is not available, the initiating NSIS-tunnel-aware end-
point may dynamically discover the other tunnel end-point's
capability through a QoS NSLP NODE_CAPABILITY object defined in this
section.
7.1. NODE_CAPABILITY Object Format 7.1. NODE_CAPABILITY Object Format
The NODE_CAPABILITY object contains a standard NSLP object header
A GIST NODE_CAPABILITY object is defined to discover the NSIS-tunnel followed by the object value, as shown in Figure 10.
handling capability of a tunnel end-point. The format of the
NODE_CAPABILITY object follows the general object definition in GIST.
The object contains a fixed header specifying the object type and
object length, followed by the object value.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length | |A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | |T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CAPABILITY Object Format Figure 10: NODE_CAPABILITY Object Format
Type: NODE_CAPABILITY Type: (TBD by IANA)
Length: 1, measured in units of 32-bit word Length: 1, measured in units of 32-bit word
Value: Value contains a single 'T' bit, indicating the node supports Value: a single 'T' bit indicating the node supports the NSIS-tunnel
the NSIS-tunnel handling mechanisms defined in this document. The handling mechanisms defined in this document. The reserved bits in
reserved bits in the value field can be used to signal other node the value field can be used to signal other node characteristics in
characteristics in the future. the future.
The bits marked 'A' and 'B' define the desired behavior for objects The bits marked 'A' and 'B' define the desired behavior for objects
whose Type field is not recognized. If a node does not recognize the whose Type field is not recognized. If a node does not recognize the
NODE_CAPABILITY object, the desired behavior is "Ignore". That is, NODE_CAPABILITY object, the desired behavior is "Ignore". That is,
the object must be deleted and the rest of the message processed as the object must be deleted and the rest of the message processed as
usual. This can be satisfied by setting 'AB' to '01' according to usual. This can be satisfied by setting 'AB' to '01'.
Appendix A.2 of the GIST specification [I-D.ietf-nsis-ntlp].
7.2. Using NODE_CAPABILITY Object 7.2. Using NODE_CAPABILITY Object
The NODE_CAPABILITY object is included in a QUERY or RESERVE message The NODE_CAPABILITY object is included in a QUERY or RESERVE message
by a tunnel end-point that needs to learn about the other end-point's by a tunnel end-point that needs to learn about the other end-point's
NSIS tunnel handling capability. If the receiving tunnel end-point NSIS tunnel handling capability. If the receiving tunnel end-point
is indeed NSIS-tunnel-aware, it recognizes this object and knows that is indeed NSIS-tunnel-aware, it recognizes this object and knows that
the sending end-point is NSIS-tunnel-aware. The receiving tunnel the sending end-point is NSIS-tunnel-aware. The receiving tunnel
end-point places the same object in a RESPONSE message to inform the end-point places the same object in a RESPONSE message to inform the
sending end-point that it is also NSIS-tunnel-aware. Example sending end-point that it is also NSIS-tunnel-aware. The use of the
procedures of how to use the NODE_CAPABILITY object over tunnels that NODE_CAPABILITY object in the cases of sender-initiated reservation
dynamically creates QoS sessions are further detailed below. and receiver-initiated reservation are further detailed below.
First, assume that both end-to-end and tunnel session are sender- First, assume that the end-to-end session is sender-initiated and an
initiated (Section 6.1) and an NSIS-tunnel-aware Tentry wants to NSIS-tunnel-aware Tentry wants to discover the NSIS-tunnel capability
discover the NSIS-tunnel capability of Texit before starting the of Texit (e.g., in Figure 8). After receiving the first end-to-end
tunnel signaling. Tentry includes a Request Identification RESERVE message and without initiating a tunnel RESERVE' message,
Information (RII) object (see [I-D.ietf-nsis-qos-nslp]) and a Tentry inserts an RII object and a NODE_CAPABILITY object with T bit
NODE_CAPABILITY object with T bit set in the first end-to-end RESERVE set into the end-to-end RESERVE message and sends it to Texit. When
message sent to Texit. When Texit receives this RESERVE message, if Texit receives this RESERVE message, if it is also NSIS-tunnel-aware,
it is also NSIS-tunnel-aware, it learns that Tentry is NSIS-tunnel- it learns that Tentry is NSIS-tunnel-aware and includes the same
aware and includes the same object with T bit set in the following object with T bit set in the following end-to-end RESPONSE message
end-to-end RESPONSE message sent back to Tentry. Otherwise, Texit sent back to Tentry. Otherwise, Texit ignores and deletes the
ignores the NODE_CAPABILITY object. When Tentry receives the NODE_CAPABILITY object. When Tentry receives the RESPONSE message,
RESPONSE message, it knows whether Texit is NSIS-tunnel-aware by it knows whether Texit is NSIS-tunnel-aware by checking the T bit in
checking the existence of the NODE_CAPABILITY object and its T bit. the NODE_CAPABILITY object.
If both tunnel endpoints are NSIS-tunnel-aware, the rest of the
procedures follows those defined in Section 6.1.
Second, assume that both end-to-end and tunnel sessions are receiver- Second, assume that the end-to-end session is receiver-initiated and
initiated (Section 6.2) and the NSIS-tunnel-aware Tentry wants to the NSIS-tunnel-aware Tentry wants to discover the NSIS-tunnel
discover the NSIS-tunnel capability of Texit before creating a tunnel capability of Texit (e.g., in Figure 9). Upon receiving the first
session. Tentry includes an RII object and a NODE_CAPABILITY object end-to-end QUERY message and without initiating a tunnel QUERY'
with T bit set in the first end-to-end QUERY message sent towards message, Tentry includes an RII object and a NODE_CAPABILITY object
with T bit set in the end-to-end QUERY message and sends it toward
Texit. If Texit is NSIS-tunnel-aware, it learns from the Texit. If Texit is NSIS-tunnel-aware, it learns from the
NODE_CAPABILITY object that Tentry is also NSIS-tunnel-aware. In the NODE_CAPABILITY object that Tentry is also NSIS-tunnel-aware and
later end-to-end RESPONSE message to this QUERY message, Texit includes the same object with T bit in the later end-to-end RESERVE
includes a NODE_CAPABILITY object with T bit set to notify Tentry of message sent to Tentry. Otherwise, Texit ignores and deletes the
its NSIS-tunnel capability. If both tunnel end-points are NSIS- NODE_CAPABILITY object. When Tentry receives the end-to-end RESERVE
tunnel-aware, the rest of the procedures follows those in message, it knows whether Texit is NSIS-tunnel-aware by checking the
Section 6.2. T bit in the NODE_CAPABILITY object.
8. IANA Considerations 8. IANA Considerations
This document defines a new object type called NODE_CAPABILITY for This document defines a new object type called NODE_CAPABILITY for
GIST. Its OType value needs to be assigned by IANA. The object QoS NSLP. Its Type value needs to be assigned by IANA. The object
format and the setting of the extensibility bits are defined in format and the setting of the extensibility bits are defined in
Section 7. Section 7.
9. Security Considerations 9. Security Considerations
This draft does not raise new security threats. Security This draft does not raise new security threats. Security
considerations for NSIS NTLP and QoS NSLP are discussed in considerations for NSIS NTLP and QoS NSLP are discussed in
[I-D.ietf-nsis-ntlp] and [I-D.ietf-nsis-qos-nslp], respectively. [I-D.ietf-nsis-ntlp] and [I-D.ietf-nsis-qos-nslp], respectively.
General threats for NSIS can be found in [RFC4081]. General threats for NSIS can be found in [RFC4081].
 End of changes. 15 change blocks. 
61 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/