draft-ietf-nsis-tunnel-07.txt   draft-ietf-nsis-tunnel-08.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: Informational Columbia U.
Expires: June 6, 2010 S. Lee Expires: August 13, 2010 S. Lee
J. Bang J. Bang
Samsung AIT Samsung AIT
December 3, 2009 February 9, 2010
NSIS Operation Over IP Tunnels NSIS Operation Over IP Tunnels
draft-ietf-nsis-tunnel-07.txt draft-ietf-nsis-tunnel-08.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 and invalidate the QoS efforts in the rest of the weakest QoS link which may invalidate the QoS efforts in the rest
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'
original IP header fields. Those original IP header fields are original IP header fields. Those original IP header fields are
needed to intercept NSIS signaling messages and classify QoS data needed to intercept NSIS signaling messages and classify QoS data
packets. This document defines a solution to this problem by mapping packets. This document defines a solution to this problem by mapping
end-to-end QoS session requests to corresponding QoS sessions in the end-to-end QoS session requests to corresponding QoS sessions in the
tunnel, thus extending the end-to-end QoS signaling into the IP tunnel, thus extending the end-to-end QoS signaling into the IP
tunnel segments. tunnel segments.
Status of this Memo Status of this Memo
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 June 6, 2010. This Internet-Draft will expire on August 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 5 3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6
3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 7 3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 8
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 9 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 10 4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 12
5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 13
6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Conveying Tunnel Flow ID Between Tunnel End-points . . . . 15 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 15
6.2. Sender-initiated Reservation . . . . . . . . . . . . . . . 15 5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15
6.3. Receiver-initiated Reservation . . . . . . . . . . . . . . 17 6. NSIS Operation over Tunnels with Dynamically Created QoS
6.4. Timing Issues of End-to-end and Tunnel Signaling . . . . . 18 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 19 6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17
7.1. NODE_CHAR Object Format . . . . . . . . . . . . . . . . . 20 6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 20
7.2. Using NODE_CHAR Object . . . . . . . . . . . . . . . . . . 20 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. NODE_CAPABILITY Object Format . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.2. Using NODE_CAPABILITY Object . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
IP tunneling is a technique that allows a packet to be encapsulated IP tunneling is a technique that allows a packet to be encapsulated
and carried as payload within an IP packet. The resulting and carried as payload within an IP packet. The resulting
encapsulated packet is called an IP tunnel packet, and the packet encapsulated packet is called an IP tunnel packet, and the packet
being tunneled is called the original packet. In typical scenarios, being tunneled is called the original packet. In typical scenarios,
IP tunneling is used to exert explicit forwarding path control (e.g., IP tunneling is used to exert explicit forwarding path control (e.g.,
in Mobile IP [RFC3220]), facilitate the secure IP delivery in Mobile IP [RFC3220]), facilitate the secure IP delivery
architecture (e.g., in IPSEC [RFC2401]), and help packet routing in architecture (e.g., in IPSEC [RFC2401]), and help packet routing in
skipping to change at page 4, line 37 skipping to change at page 4, line 37
Without additional efforts, NSIS signaling does not work within IP Without additional efforts, NSIS signaling does not work within IP
tunneling segments of a signaling path. The reason is that tunnel tunneling segments of a signaling path. The reason is that tunnel
encapsulation masks the original packet including its header and encapsulation masks the original packet including its header and
payload. However, information from the original packet is required payload. However, information from the original packet is required
both for NSIS peer node discovery and for QoS data flow packet both for NSIS peer node discovery and for QoS data flow packet
classification. Without access to information from the original classification. Without access to information from the original
packet, an IP tunnel acts as an NSIS-unaware virtual link in the end- packet, an IP tunnel acts as an NSIS-unaware virtual link in the end-
to-end NSIS signaling path. to-end NSIS signaling path.
This document defines a mechanism to extend NSIS signaling for end- This document defines a mechanism to extend end-to-end NSIS signaling
to-end QoS reservation into IP tunnels. The NSIS-aware IP tunnel for QoS reservation into IP tunnels. The NSIS-aware IP tunnel end-
end-points that support this mechanism is called NSIS-tunnel-aware points that support this mechanism are called NSIS-tunnel-aware end-
end-points. There are two main operation modes. On one hand, if the points. There are two main operation modes. On one hand, if the
tunnel already has pre-configured QoS sessions, the NSIS-tunnel-aware tunnel already has pre-configured QoS sessions, the NSIS-tunnel-aware
end-points map end-to-end QoS signaling requests directly to existing end-points map end-to-end QoS signaling requests directly to existing
tunnel sessions as long as there are enough tunnel session resources; tunnel sessions as long as there are enough tunnel session resources;
on the other hand, if no pre-configured tunnel QoS sessions are on the other hand, if no pre-configured tunnel QoS sessions are
available, the NSIS-tunnel-aware end-points dynamically initiate and available, the NSIS-tunnel-aware end-points dynamically initiate and
maintain tunnel QoS sessions that are then associated with the maintain tunnel QoS sessions that are then associated with the
corresponding end-to-end QoS sessions. Note that whether the tunnel corresponding end-to-end QoS sessions. Note that whether the tunnel
pre-configures QoS sessions or not, and which pre-configured tunnel pre-configures QoS sessions or not, and which pre-configured tunnel
QoS sessions a particular end-to-end QoS signaling request should be QoS sessions a particular end-to-end QoS signaling request should be
matched to is a policy issue out of scope of this document. mapped to are policy issues out of scope of this document.
The rest of this document is organized as follows, Section 2 defines The rest of this document is organized as follows. Section 2 defines
terminology. Section 3 presents the problem statement including terminology. Section 3 presents the problem statement including
common IP tunneling protocols, and existing behavior of NSIS QoS common IP tunneling protocols and existing behavior of NSIS QoS
signaling operating over IP tunnels. Section 4 introduces the design signaling operating over IP tunnels. Section 4 introduces the design
requirements and overall approach of our mechanism. More details requirements and overall approach of our mechanism. More details
about how NSIS QoS signaling operates with tunnels that use pre- about how NSIS QoS signaling operates with tunnels that use pre-
configured QoS and dynamic QoS signaling are provided in Section 5 configured QoS and dynamic QoS signaling are provided in Section 5
and Section 6. Section 7 describes a method to automatically and Section 6. Section 7 describes a method to automatically
discover whether a tunnel end-point node supports the NSIS-tunnel discover whether a tunnel end-point node supports the NSIS-tunnel
interoperation mechanism defined in this document. Section 8 interoperation mechanism defined in this document. Section 8
discusses IANA considerations and Section 9 considers security. discusses IANA considerations and Section 9 considers security.
2. Terminology 2. Terminology
skipping to change at page 6, line 15 skipping to change at page 6, line 15
[Adjacent] NSIS Peer: The next node along the signaling path, in the [Adjacent] NSIS Peer: The next node along the signaling path, in the
upstream or downstream direction, with which a NSIS node upstream or downstream direction, with which a NSIS node
explicitly interacts. explicitly interacts.
NSIS-aware Node: A node that supports NSIS signaling. NSIS-aware Node: A node that supports NSIS signaling.
NSIS-aware Tunnel End-point Node: A tunnel end-point node which is NSIS-aware Tunnel End-point Node: A tunnel end-point node which is
also an NSIS node. also an NSIS node.
NSIS-tunnel-aware [Tunnel] End-point Node: An NSIS-aware Tunnel End- NSIS-tunnel-aware [Tunnel] End-point Node: An NSIS-aware Tunnel End-
point node which also supports the NSIS operation over IP tunnels point node which also supports the mechanism for NSIS operating
mechanism defined in this document. over IP tunnels defined in this document.
3. Problem Statement 3. Problem Statement
3.1. IP Tunneling Protocols 3.1. IP Tunneling Protocols
The following definition of IP tunnel is derived from [RFC2473] and Tunnel from node B to node D
adapted for both IPv4 and IPv6. <---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Figure 1: IP Tunnel
The following definition of IP tunneling is derived from [RFC2473]
and adapted for both IPv4 and IPv6.
IP tunneling is a technique for establishing a "virtual link" between IP tunneling is a technique for establishing a "virtual link" between
two IP nodes for transmitting data packets as payloads of IP packets two IP nodes for transmitting data packets as payloads of IP packets
(see Figure 1). From the point of view of the two nodes, this (see Figure 1). From the point of view of the two nodes, this
"virtual link", called an IP tunnel, appears as a point-to-point link "virtual link", called an IP tunnel, appears as a point-to-point link
on which IP acts like a link-layer protocol. The two IP nodes play on which IP acts like a link-layer protocol. The two IP nodes play
specific roles. One node encapsulates original packets received from specific roles. One node encapsulates original packets received from
other nodes or from itself and forwards the resulting tunnel packets other nodes or from itself and forwards the resulting tunnel packets
through the tunnel. The other node decapsulates the received tunnel through the tunnel. The other node decapsulates the received tunnel
packets and forwards the resulting original packets towards their packets and forwards the resulting original packets towards their
destinations, possibly itself. The encapsulating node is called the destinations, possibly itself. The encapsulating node is called the
tunnel entry-point node (Tentry), and it is the source of the tunnel tunnel entry-point node (Tentry), and it is the source of the tunnel
packets. The decapsulating node is called the tunnel exit-point node packets. The decapsulating node is called the tunnel exit-point node
(Texit), and it is the destination of the tunnel packets. (Texit), and it is the destination of the tunnel packets.
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Figure 1: IP Tunnel
An IP tunnel is a unidirectional mechanism - tunnel packet flow takes An IP tunnel is a unidirectional mechanism - tunnel packet flow takes
place in one direction between the IP tunnel entry-point and exit- place in one direction between the IP tunnel entry-point and exit-
point nodes (see Figure 1). Bi-directional tunneling is achieved by point nodes (see Figure 1). Bi-directional tunneling is achieved by
combining two unidirectional mechanisms, that is, configuring two combining two unidirectional mechanisms, that is, configuring two
tunnels, each in opposite direction to the other - the entry-point tunnels, each in opposite direction to the other - the entry-point
node of one tunnel is the exit-point node of the other tunnel. node of one tunnel is the exit-point node of the other tunnel.
Figure 2 illustrates the original packet and the resulting tunnel Figure 2 illustrates the original packet and the resulting tunnel
packet. In a tunnel packet, the original packet is encapsulated packet. In a tunnel packet, the original packet is encapsulated
within the tunnel header. The tunnel header contains two components, within the tunnel header. The tunnel header contains two components,
the tunnel IP header and other tunnel specific headers. The tunnel the tunnel IP header and other tunnel specific headers. The tunnel
IP header specifies tunnel entry-point node as IP source address and IP header specifies tunnel entry-point node as IP source address and
tunnel exit-point node as IP destination address, thus causing the tunnel exit-point node as IP destination address, thus causing the
tunnel packet to be routed inside the tunnel. The tunnel specific tunnel packet to be routed inside the tunnel. The tunnel specific
headers in between the tunnel IP header and the original packet in a headers in between the tunnel IP header and the original packet in a
tunnel packet are optional, depending on the tunneling protocol in tunnel packet are optional, depending on the tunneling protocol in
use. use.
+----------------------------------//-----+ +----------------------------------//-----+
| Original | | | Original | |
| | Original Packet Payload | | | Original Packet Payload |
| Header | | | Header | |
+----------------------------------//-----+ +----------------------------------//-----+
< Original Packet > < Original Packet >
| |
v v
<Tunnel Headers> < Original Packet > < Tunnel Headers > < Original Packet >
+---------+-----------+-------------------------//--------------+
+---------+ - - - - - +-------------------------//--------------+ | Tunnel | Tunnel | |
| Tunnel | Tunnel | | | IP | Specific | Original Packet |
| IP | Specific | Original Packet | | Header | Headers | |
| Header | Headers | | +---------+-----------+-------------------------//--------------+
+---------+ - - - - - +-------------------------//--------------+ < Tunnel IP Packet >
< Tunnel IP Packet >
Figure 2: IP Tunnel Encapsulation Figure 2: IP Tunnel Encapsulation
Commonly used IP tunneling protocols include Generic Routing Commonly used IP tunneling protocols include Generic Routing
Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation
over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP
(IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP
(MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213],
Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473]
and IPSEC tunneling mode (IPSEC) [RFC4301][RFC4303]. Among these and IPSEC tunneling mode (IPSEC) [RFC4301][RFC4303]. Among these
skipping to change at page 8, line 28 skipping to change at page 8, line 27
3.2. NSIS QoS Signaling in the Presence of IP Tunnels 3.2. NSIS QoS Signaling in the Presence of IP Tunnels
Typically, applications use NSIS QoS signaling to reserve resources Typically, applications use NSIS QoS signaling to reserve resources
for a flow along the flow path. NSIS QoS signaling can be initiated for a flow along the flow path. NSIS QoS signaling can be initiated
by either the flow sender or flow receiver. Figure 3 shows an by either the flow sender or flow receiver. Figure 3 shows an
example scenario with five NSIS nodes, including flow sender node A, example scenario with five NSIS nodes, including flow sender node A,
flow receiver node E, and intermediate NSIS nodes B, C and D. Nodes flow receiver node E, and intermediate NSIS nodes B, C and D. Nodes
which are not NSIS QoS capable are not shown. which are not NSIS QoS capable are not shown.
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E| |A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Flow Flow Flow Flow
Sender Receiver Sender Receiver
Node Node Node Node
Figure 3: Example Scenario of Sender-initiated NSIS QoS Signaling
Node A Node B Node C Node D Node E
| | | | |
| RESERVE | | | |
+--------->| | | |
| | RESERVE | | |
| +--------->| | |
| | | RESERVE | |
| | +--------->| |
| | | | RESERVE |
| | | +--------->|
| | | | RESPONSE |
| | | |<---------+
| | | RESPONSE | |
| | |<---------+ |
| | RESPONSE | | |
| |<---------+ | |
| RESPONSE | | | |
|<---------+ | | |
| | | | |
| | | | |
Figure 4: Example Scenario of Sender-initiated NSIS QoS Reservation Figure 3: Example Scenario of NSIS QoS Signaling
Figure 4 illustrates a sender-initiated signaling sequence in the Figure 4 illustrates a sender-initiated signaling sequence in the
scenario of Figure 3. Sender node A sends a RESERVE message towards scenario of Figure 3. Sender node A sends a RESERVE message towards
receiver node E. The RESERVE message gets forwarded by intermediate receiver node E. The RESERVE message gets forwarded by intermediate
NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver
node E then sends back a RESPONSE message confirming the QoS node E then sends back a RESPONSE message confirming the QoS
reservation, again through the previous intermediate NSIS nodes in reservation, again through the previous intermediate NSIS nodes in
the data flow path. the data flow path.
There are two important aspects in the above signaling process that There are two important aspects in the above signaling process that
skipping to change at page 9, line 40 skipping to change at page 9, line 16
special IP header and payload format or include a Router Alert Option special IP header and payload format or include a Router Alert Option
(RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery (RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery
messages allow node B, C and D to intercept them and subsequently messages allow node B, C and D to intercept them and subsequently
insert themselves into the signaling path for the flow in question. insert themselves into the signaling path for the flow in question.
After formation of the signaling path, all signaling messages After formation of the signaling path, all signaling messages
corresponding to this flow will be passed to these nodes for corresponding to this flow will be passed to these nodes for
processing. Other nodes which are not NSIS-aware simply forward all processing. Other nodes which are not NSIS-aware simply forward all
signaling messages like any other IP packets without additional signaling messages like any other IP packets without additional
handling. handling.
Node A Node B Node C Node D Node E
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | | |
| +------------->| | |
| | | RESERVE | |
| | +------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | | RESPONSE | |
| | |<-------------+ |
| | RESPONSE | | |
| |<-------------+ | |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 4: Sender-initiated NSIS QoS Signaling
Second, the goal of QoS signaling is to install control information Second, the goal of QoS signaling is to install control information
to give QoS treatment for the flow being signaled. Basic QoS control to give QoS treatment for the flow being signaled. Basic QoS control
information includes the data flow ID for packets classification and information includes the data Flow ID for packet classification and
type of QoS treatment those packets are entitled to. The flow ID the type of QoS treatment those packets are entitled to. The Flow ID
contains a set of header fields such as flow sender and receiver contains a set of header fields such as flow sender and receiver
addresses, protocol and port numbers. addresses, protocol and port numbers.
Now consider Figure 5 where nodes B, C and D are end-points and Now consider Figure 5 where nodes B, C and D are end-points and
intermediate nodes of an IP tunnel. During the signaling path intermediate nodes of an IP tunnel. During the signaling path
discovery process, node B might still be able to intercept and discovery process, node B can still intercept and process NSIS peer
process NSIS peer discovery messages if it recognizes them before discovery messages if it recognizes them before performing tunnel
performing tunnel encapsulation; node D might be able to identify encapsulation; node D can identify NSIS peer discovery messages after
NSIS peer discovery messages after performing tunnel decapsulation. performing tunnel decapsulation. A tunnel intermediate node such as
A tunnel intermediate node such as node C, however, only sees the node C, however, only sees the tunnel header of the packets and will
tunnel header of the packets and will not be able to identify the not be able to identify the original NSIS peer discovery message or
original NSIS peer discovery message or insert itself in the flow insert itself in the flow signaling path. Furthermore, the Flow ID
signaling path. Furthermore, the flow ID of the original flow is of the original flow is based on IP header fields of the original
based on IP header fields of the original packet. Those fields are packet. Those fields are also hidden in the payload of the tunnel
also hidden in the payload of the tunnel packet. So there is no way packet. So there is no way node C can classify packets belonging to
node C can classify packets belonging to that flow in the tunnel. In that flow in the tunnel. In summary, the problem is that tunnel
summary, the problem is that tunnel intermediate nodes are unable to intermediate nodes are unable to intercept original NSIS signaling
intercept original NSIS signaling messages and unable to classify messages and unable to classify original data flow packets as a
original data flow packets as a result of tunnel encapsulation. An result of tunnel encapsulation. An IP tunnel segment appears just
IP tunnel segment appears just like a QoS-unaware virtual link. like a QoS-unaware virtual link. Since the best QoS of an end-to-end
Since the best QoS of an end-to-end path is judged based on its path is judged based on its weakest segment, leaving the tunnel path
weakest segment, leaving the tunnel path "untended" risks voiding "untended" risks voiding other efforts to provide QoS in the rest of
other efforts to provide QoS in the rest of the path. the path.
Tunnel from node B to node D Tunnel from node B to node D
<----------------------> <---------------------->
Tunnel Tunnel Tunnel Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point Entry-Point Intermediate Exit-Point
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Flow Flow Flow Flow
Sender Receiver Sender Receiver
Node Node Node Node
Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel
4. Design Overview 4. Design Overview
4.1. Design Requirements 4.1. Design Requirements
We identify the following design requirements for NSIS operating over We identify the following design requirements for NSIS operating over
IP tunnels. IP tunnels.
o The mechanism should work with all common IP tunneling protocols o The mechanism should work with all common IP tunneling protocols
listed in Section 3.1. listed in Section 3.1.
o Some IP tunnels maintain pre-configured QoS sessions inside the o Some IP tunnels maintain pre-configured QoS sessions inside the
tunnel. The mechanism should work for IP tunnels both with and tunnel. The mechanism should work for IP tunnels both with and
without pre-configured tunnel QoS sessions. without pre-configured tunnel QoS sessions.
o The mechanism should minimize the required upgrade to existing o The mechanism should minimize the required upgrade to existing
infrastructure in order to facilitate its deployment. infrastructure in order to facilitate its deployment.
Specifically, we limit the necessary upgrade to NSIS-aware tunnel Specifically, we limit the necessary upgrade to NSIS-aware tunnel
end-points. Only tunnel end-points needs to support the mechanism end-points. Only tunnel end-points need to support the mechanism
defined in this document. Such tunnel end-points are called NSIS- defined in this document. Such tunnel end-points are called NSIS-
tunnel-aware end-points. All other nodes, both inside and outside tunnel-aware end-points. All other nodes, both inside and outside
the tunnel should be transparent to this mechanism. the tunnel should be transparent to this mechanism.
o The mechanism should facilitate its incremental deployment by o The mechanism should facilitate its incremental deployment by
providing a method for one NSIS-tunnel-aware end-point to discover providing a method for one NSIS-tunnel-aware end-point to discover
whether the other end-point is also NSIS-tunnel-aware. whether the other end-point is also NSIS-tunnel-aware.
o The mechanism should learn from design experience of previous work o The mechanism should learn from design experience of previous work
on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746], while also on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746], while also
addressing the following major differences of NSIS from RSVP. addressing the following major differences of NSIS from RSVP.
First, NSIS is designed as a generic framework to accommodate First, NSIS is designed as a generic framework to accommodate
various signaling application needs, and therefore is split into a various signaling application needs, and therefore is split into a
signaling transport layer and a signaling application layer; RSVP signaling transport layer and a signaling application layer; RSVP
does not have a layer split and is designed only for QoS does not have a layer split and is designed only for QoS
signaling. Second, NSIS QoS NSLP allows both sender-initiated and signaling. Second, NSIS QoS NSLP allows both sender-initiated and
receiver-initiated reservations; RSVP only supports receiver- receiver-initiated reservations; RSVP only supports receiver-
initiated reservations. Third, NSIS deals only with unicast; RSVP initiated reservations. Third, NSIS deals only with unicast; RSVP
also supports multicast. Fourth, NSIS integrates a new session ID also supports multicast. Fourth, NSIS integrates a new Session ID
feature which is different from the session identification concept feature which is different from the session identification concept
in RSVP. in RSVP.
4.2. Overall Design Approach 4.2. Overall Design Approach
The overall design of this NSIS signaling and IP tunnel interworking The overall design of this NSIS signaling and IP tunnel interworking
mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is
tailored and extended for NSIS operation. tailored and extended for NSIS operation.
Since a flow is considered uni-directional, to accommodate flows in Since a flow is considered unidirectional, to accommodate flows in
both directions of a tunnel, we require both tunnel entry-point and both directions of a tunnel, we require both tunnel entry-point and
tunnel exit-point to be NSIS-tunnel-aware. If an NSIS-tunnel-aware tunnel exit-point to be NSIS-tunnel-aware. If an NSIS-tunnel-aware
end-point needs to know whether the other tunnel end-point is also end-point needs to know whether the other tunnel end-point is also
NSIS-tunnel-aware, it uses the NSIS-tunnel capability discovery NSIS-tunnel-aware, it may use the NSIS-tunnel capability discovery
mechanism defined in Section 7. mechanism defined in Section 7.
Tunnel end-points need to always intercept NSIS peer discovery Tunnel end-points need to always intercept NSIS peer discovery
messages and insert themselves into the NSIS signaling path so they messages and insert themselves into the NSIS signaling path so they
can receive all NSIS signaling messages and coordinate their can receive all NSIS signaling messages and coordinate their
interaction within tunnel QoS. interaction with tunnel QoS.
To facilitate the QoS handling in the tunnel, the end-to-end QoS
session will be mapped to a tunnel QoS session, either pre-configured
or dynamically created. An important property of a tunnel QoS
session is its tunnel Flow ID which identifies the end-to-end data
flow within the tunnel. In both tunnels with and without pre-
configured QoS sessions, the tunnel Flow ID is assigned based on
information available in the tunnel header, therefore solving the
problem for tunnel-intermediate nodes to classify flow packets as
discussed in Section 3.2. An example tunnel Flow ID contains the
tunnel entry-point and exit-point IP addresses and a tunnel inserted
UDP port number. We discuss more details about recommended choices
of tunnel Flow ID for different IP tunneling protocols in
Section 4.3.
For tunnels that maintain pre-configured QoS sessions, upon receiving For tunnels that maintain pre-configured QoS sessions, upon receiving
a request to reserve resources for an end-to-end session, an NSIS- a request to reserve resources for an end-to-end session, the tunnel
tunnel-aware entry-point will try to map the end-to-end QoS session end-point maps the end-to-end QoS session to an existing tunnel
to an existing tunnel session. To simplify the design, the mapping session. To simplify the design, the mapping decision is always made
decision is always made by the tunnel entry-point regardless of by the tunnel entry-point regardless of whether the end-to-end
whether the end-to-end session uses sender-initiated or receiver- session uses sender-initiated or receiver-initiated NSIS signaling
initiated NSIS signaling mode. The details about which end-to-end mode. The details about which end-to-end session can be mapped to
session can be mapped to which pre-configured tunnel session depend which pre-configured tunnel session depend on policy mechanisms
on policy mechanisms outside the scope of this document. outside the scope of this document.
For tunnels that do not maintain pre-configured QoS sessions, the For tunnels that do not maintain pre-configured QoS sessions, the
NSIS-tunnel-aware end-points dynamically initiate and manage a NSIS-tunnel-aware end-points dynamically create and manage a
corresponding tunnel QoS session for each end-to-end session. To corresponding tunnel QoS session for the end-to-end session. Since
keep the handling mechanism consistent with the case for tunnels with the initiation mode of both QoS sessions can be sender-initiated or
pre-configured QoS sessions, the tunnel entry-point always initiates receiver-initiated, to simplify the design, we require that the
the mapping between the tunnel session and the end-to-end session. initiation mode of the tunnel QoS session follow that of the end-to-
end QoS session. In other words, the end-to-end QoS session and its
corresponding tunnel QoS session are either both sender-initiated or
both receiver-initiated. To keep the handling mechanism consistent
with the case for tunnels with pre-configured QoS sessions, the
tunnel entry-point always initiates the mapping between the tunnel
session and the end-to-end session.
An important characteristics of a tunnel QoS session is its tunnel As the mapping initiator, the tunnel entry-point records the
flow ID which identifies the end-to-end data flow within the tunnel. association between the end-to-end session and its corresponding
In both tunnels with and without pre-configured QoS sessions, the tunnel session, both in tunnels with and without pre-configured QoS
tunnel flow ID is assigned based on information available in the sessions. This association serves two purposes, one at the signaling
tunnel header, therefore solving the tunnel-intermediate node flow plane and the other at the data plane. At the signaling plane, the
packet classification problem in Section 3.2. An example tunnel flow association enables the tunnel entry-point to coordinate necessary
ID contains the tunnel entry-point and exit-point IP addresses and a interaction, such as QoS adjustment in sender-initiated reservations,
tunnel inserted UDP port number. We discuss more details about between the end-to-end and the tunnel QoS sessions. At the data
recommended choices of tunnel flow ID for different IP tunneling plane, the association allows the tunnel entry-point to correctly
protocols in Section 4.3. encapsulate data flow packets according to the chosen tunnel Flow ID.
Since the tunnel Flow ID uses header fields that are visible inside
the tunnel, the tunnel intermediate nodes can classify the data flow
packets and apply appropriate QoS treatment.
Ultimately QoS handling needs to be enforced in the data plane. To In addition to the tunnel entry-point recording the association
achieve that, NSIS-tunnel-aware entry-point nodes not only between the end-to-end session and its corresponding tunnel session,
encapsulate data flow packets according to the specific tunnel the tunnel exit-point also needs to maintain the same association for
protocol, but also insert any necessary header fields according to similar reasons. At the signaling plane, this association at the
the chosen tunnel flow ID. All those header fields are visible to tunnel exit-point enables the interaction of the end-to-end and the
tunnel intermediate nodes. Tunnel intermediate nodes then classify tunnel QoS session such as QoS adjustment in receiver-initiated
those data flow packets and apply appropriate QoS treatment. At the reservations. At the data plane, this association tells the tunnel
tunnel exit-point, the data flow packet is decapsulated accordingly exit-point that the relevant data flow packets need to be
and forwarded as usual. decapsulated according to the corresponding tunnel Flow ID.
The tunnel exit-point learns about the mapping between the tunnel and
the end-to-end QoS sessions, including the tunnel Flow ID and the
tunnel session's Session ID that corresponds to the end-to-end
session, through the follow methods. In tunnels with pre-configured
QoS sessions, the mapping information between the corresponding
tunnel and end-to-end QoS sessions may be pre-configured as well. In
tunnels without pre-configured QoS sessions, the tunnel exit-point
knows the tunnel Flow ID through the NSIS signaling process that
creates the tunnel QoS sessions inside the tunnel. Meanwhile, the
tunnel exit-point maps the Session IDs of the tunnel QoS session and
the end-to-end session through the QoS NSLP BOUND_SESSION_ID object
[I-D.ietf-nsis-qos-nslp]. Specifically, when used for NSIS signaling
over IP tunnels, the BOUND_SESSION_ID object carries the Session ID
of the tunnel session and a Binding Code of value 0x01 indicating
tunnel handling. The tunnel entry-point includes this tunnel binding
object in appropriate end-to-end signaling messages. Upon receiving
this binding object, the tunnel exit-point records the association
between the tunnel QoS session and the corresponding end-to-end QoS
session.
One problem for NSIS operating over IP tunnels which dynamically
create QoS sessions is that it involves two signaling sequences. The
outcome of the tunnel signaling session directly affects the outcome
of the end-to-end signaling session. Since the two signaling
sessions overlap in time, there are circumstances when a tunnel end-
point has to decide whether it should proceed with the end-to-end
signaling session while it is still waiting for results of the tunnel
session. Sequential mode and parallel mode are two basic options for
this problem. In sequential mode, end-to-end signaling pauses when
it is waiting for results of tunnel signaling, and resumes upon
receipt of the tunnel signaling outcome. In parallel mode, end-to-
end signaling continues outside the tunnel while tunnel signaling is
still in process and its outcome is unknown. The parallel mode may
lead to reduced signaling delays if the QoS resources in the tunnel
path are sufficient compared to the rest of the end-to-end path. If
the QoS resources in the tunnel path are more constraint than the
rest of the end-to-end path, however, the parallel mode may lead to
wasted end-to-end signaling or necessitates re-negotiation after the
tunnel signaling outcome becomes available. In those cases, the
signaling flow of the parallel mode also tends to be more
complicated. This document adopts a sequential mode approach. In
addition, the actual signaling process uses the QoS NSLP message
binding mechanism [I-D.ietf-nsis-qos-nslp] to convey the dependency
relationship between corresponding messages of the tunnel session and
the end-to-end session.
4.3. Tunnel Flow ID for Different IP Tunneling Protocols 4.3. Tunnel Flow ID for Different IP Tunneling Protocols
A tunnel flow ID identifies the end-to-end flow for packet A tunnel Flow ID identifies the end-to-end flow for packet
classification within the tunnel. The tunnel flow ID is based on a classification within the tunnel. The tunnel Flow ID is based on a
set of tunnel header fields. Different tunnel flow ID can be chosen set of tunnel header fields. Different tunnel Flow ID can be chosen
for different tunneling mechanisms in order to minimize the for different tunneling mechanisms in order to minimize the
classification overhead. This document specifies the following flow classification overhead. This document specifies the following Flow
ID formats for the respective tunneling protocols. ID formats for the respective tunneling protocols.
o For IPv6 tunneling protocols (IPv6GEN), the tunnel flow ID o For IPv6 tunneling protocols (IPv6GEN), the tunnel Flow ID
consists of the tunnel entry-point IPv6 address and the tunnel consists of the tunnel entry-point IPv6 address and the tunnel
exit-point IPv6 addresses plus a unique IPv6 flow label [RFC3697]. exit-point IPv6 address plus a unique IPv6 flow label [RFC3697].
o For IPSEC tunnel mode (IPSEC), the tunnel flow ID contains tunnel o For IPSEC tunnel mode (IPSEC), the tunnel Flow ID contains the
the entry-point IP address and the tunnel exit-point IP address tunnel entry-point IP address and the tunnel exit-point IP address
plus the Security Parameter Index (SPI). plus the Security Parameter Index (SPI).
o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4, o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4,
MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional
UDP header between the tunnel header and the original packet. The UDP header between the tunnel header and the original packet. The
flow ID consists of the tunnel entry-point and tunnel exit-point Flow ID consists of the tunnel entry-point and tunnel exit-point
IP addresses and the source port number in the additional UDP IP addresses and the source port number in the additional UDP
header. In this case, it is especially important that the tunnel header. In these cases, it is especially important that the
exit-point also understands the additional UDP encapsulation, and tunnel exit-point also understands the additional UDP
therefore can correctly decapsulate both the normal tunnel header encapsulation, and therefore can correctly decapsulate both the
and the additional UDP header. This requires both tunnel end- normal tunnel header and the additional UDP header. In other
points to be NSIS-tunnel-aware. words, both tunnel end-points need to be NSIS-tunnel-aware.
The above recommendations about choosing tunnel flow ID apply to The above recommendations about choosing tunnel Flow ID apply to
dynamically created QoS tunnel sessions. For pre-configured QoS dynamically created QoS tunnel sessions. For pre-configured QoS
tunnel sessions, the corresponding flow ID is determined by the tunnel sessions, the corresponding Flow ID is determined by the
configuration mechanism itself. For example, if the tunnel QoS is configuration mechanism itself. For example, if the tunnel QoS is
DiffServ based, the DiffServ Code Point (DSCP) field value may be DiffServ based, the DiffServ Code Point (DSCP) field value may be
used to identify the corresponding tunnel session. used to identify the corresponding tunnel session.
5. NSIS Operation over Tunnels with Pre-configured QoS Sessions 5. NSIS Operation over Tunnels with Pre-configured QoS Sessions
When tunnel QoS is managed by pre-configured QoS sessions, both the When tunnel QoS is managed by pre-configured QoS sessions, both the
tunnel entry-point and tunnel exit-point also need to be configured tunnel entry-point and tunnel exit-point also need to be configured
with the flow ID of the tunnel QoS session. This is to enable the with the Flow ID of the tunnel QoS session. This is to enable the
tunnel end-points to correctly perform matching encapsulating and tunnel end-points to correctly perform matching encapsulating and
decapsulating operations. The procedures of NSIS operating over decapsulating operations. The procedures of NSIS operating over
tunnels with pre-configured QoS sessions are slightly different tunnels with pre-configured QoS sessions are slightly different
depending on whether the end-to-end NSIS signaling is sender- depending on whether the end-to-end NSIS signaling is sender-
initiated or receiver-initiated. But in either case, it is the initiated or receiver-initiated. But in either case, it is the
tunnel entry-point that first creates the mapping between a tunnel tunnel entry-point that first creates the mapping between a tunnel
session and an end-to-end session. session and an end-to-end session.
5.1. Sender-initiated Reservation 5.1. Sender-initiated Reservation
Sender Tentry Tmid Texit Receiver
| | | | |
| RESERVE | | | |
+--------->| | | |
| | RESERVE | |
| +-------------------->| |
| | | | RESERVE |
| | | +--------->|
| | | | RESPONSE |
| | | |<---------+
| | RESPONSE | |
| |<--------------------+ |
| RESPONSE | | | |
|<---------+ | | |
| | | | |
| | | | |
Figure 6: Sender-initiated End-to-end Session with Pre-configured
Tunnel QoS Sessions
Figure 6 illustrates the signaling sequence when end-to-end signaling Figure 6 illustrates the signaling sequence when end-to-end signaling
outside the tunnel is sender-initiated. Upon receiving a RESERVE outside the tunnel is sender-initiated. Upon receiving a RESERVE
message from the sender, Tentry checks tunnel QoS configuration, message from the sender, Tentry checks tunnel QoS configuration,
determines whether and how this end-to-end session can be mapped to a determines whether and how this end-to-end session can be mapped to a
pre-configured tunnel session. The mapping criteria are part of the pre-configured tunnel session. The mapping criteria are part of the
pre-configuration and outside the scope of this document. Tentry pre-configuration and outside the scope of this document. Tentry
indicates success or failure of the mapping between the end-to-end then tunnels the RESERVE message to Texit. Texit forwards the
session and a tunnel session in the RESERVE message being tunneled to RESERVE message to the receiver. The receiver replies with a
Texit. The signaling proceeds as usual until a RESPONSE message RESPONSE message which arrives at Texit, Tentry and finally the
arrives at Texit, Tentry and finally the sender. If the RESPONSE sender. If the RESPONSE message that Tentry receives confirms that
message that Tentry received confirms that the overall signaling is the overall signaling is successful, Tentry starts to encapsulate all
successful, Tentry starts to encapsulate all incoming packets of the incoming packets of the data flow using the tunnel Flow ID
data flow using the tunnel flow ID corresponding to the mapped tunnel corresponding to the mapped tunnel session. Texit knows how to
session. Texit knows how to decapsulate the tunnel packets because decapsulate the tunnel packets because it recognizes the mapped
it recognizes the mapped tunnel flow ID based on information supplied tunnel Flow ID based on information supplied during tunnel session
during tunnel session pre-configuration. pre-configuration.
Sender Tentry Tmid Texit Receiver
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +---------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 6: Sender-initiated End-to-end Session with Pre-configured
Tunnel QoS Sessions
5.2. Receiver-initiated Reservation 5.2. Receiver-initiated Reservation
Figure 7 shows the signaling sequence when end-to-end signaling Figure 7 shows the signaling sequence when end-to-end signaling
outside the tunnel is receiver-initiated. Upon receiving the first outside the tunnel is receiver-initiated. Upon receiving the first
end-to-end Query message, Tentry examines the tunnel QoS end-to-end Query message, Tentry examines the tunnel QoS
configuration, updates the Query message accordingly, and tunnel the configuration, updates and tunnels the Query message to Texit. Texit
Query message to Texit. Texit decapsulates the QUERY message, decapsulates the QUERY message, processes it and forwards it toward
processes it and forwards it toward the receiver. Later the receiver the receiver. Later, the receiver sends back a RESERVE message
sends back a RESERVE message passing through Texit and reaches passing through Texit and arriving at Tentry. Tentry decides on
Tentry. Tentry decides on whether and how the QoS request for this whether and how the QoS request for this end-to-end session can be
end-to-end session can be mapped to a pre-configured tunnel session, mapped to a pre-configured tunnel session based on an algorithm
again based on an algorithm outside the scope of this document, and outside the scope of this document. Then Tentry tunnels the RESERVE
then indicates the outcome in the outgoing RESERVE message. The message to Texit which forwards it to the receiver. The signaling
signaling continues until a RESPONSE message arrives at Tentry, Texit continues until a RESPONSE message arrives at Tentry, Texit and
and finally the receiver. If the RESPONSE message that Tentry finally the receiver. If the RESPONSE message that Tentry receives
received confirms that the overall signaling is successful, Tentry confirms that the overall signaling is successful, Tentry starts to
starts to encapsulate all incoming packets of the data flow using the encapsulate all incoming packets of the data flow using the tunnel
tunnel flow ID corresponding to the mapped tunnel session. Flow ID corresponding to the mapped tunnel session. Similarly, Texit
Similarly, Texit knows how to decapsulate the tunnel packets because knows how to decapsulate the tunnel packets because it recognizes the
it recognizes the mapped tunnel flow ID based on information supplied mapped tunnel Flow ID based on information supplied during tunnel
during tunnel session pre-configuration. session pre-configuration.
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| QUERY | | | | | QUERY | | | |
+--------->| | | | +------------->| | | |
| | QUERY | | | | QUERY | |
| +-------------------->| | | +---------------------------->| |
| | | | QUERY | | | | | QUERY |
| | | +--------->| | | | +------------->|
| | | | RESERVE | | | | | RESERVE |
| | | |<---------+ | | | |<-------------+
| | RESERVE | | | | RESERVE | |
| |<--------------------+ | | |<----------------------------+ |
| RESERVE | | | | | RESERVE | | | |
|<---------+ | | | |<-------------+ | | |
| RESPONSE | | | | | RESPONSE | | | |
+--------->| | | | +------------->| | | |
| | RESPONSE | | | | RESPONSE | |
| +-------------------->| | | +---------------------------->| |
| | | | RESPONSE | | | | | RESPONSE |
| | | +--------->| | | | +------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 7: Receiver-initiated End-to-end Session with Pre-configured Figure 7: Receiver-initiated End-to-end Session with Pre-configured
Tunnel QoS Sessions Tunnel QoS Sessions
Since tunnel QoS signaling is not involved in pre-configured QoS Since tunnel QoS signaling is not involved in pre-configured QoS
tunnels, Figure 6 and Figure 7 look as if the tunnel is a single tunnels, Figure 6 and Figure 7 look as if the tunnel is a single
virtual link. The signaling path simply skips all tunnel virtual link. The signaling path simply skips all tunnel
intermediate nodes. However, both Tentry and Texit need to deploy intermediate nodes. However, both Tentry and Texit need to deploy
NSIS-tunnel related functionalities described above, including acting NSIS-tunnel related functionalities described above, including acting
on the end-to-end NSIS signaling messages based on tunnel QoS status, on the end-to-end NSIS signaling messages based on tunnel QoS status,
mapping end-to-end and tunnel QoS sessions, and correctly mapping end-to-end and tunnel QoS sessions, and correctly
encapsulating and decapsulating tunnel packets according to the encapsulating and decapsulating tunnel packets according to the
tunnel protocol and the configured tunnel flow ID. tunnel protocol and the configured tunnel Flow ID.
6. NSIS Operation over Tunnels with Dynamically Created QoS Sessions 6. NSIS Operation over Tunnels with Dynamically Created QoS Sessions
When there are no pre-configured tunnel QoS sessions, a tunnel can When there are no pre-configured tunnel QoS sessions, a tunnel can
apply the same NSIS QoS signaling mechanism used for the end-to-end apply the same NSIS QoS signaling mechanism used for the end-to-end
path to manage the QoS inside the tunnel. The tunnel NSIS signaling path to manage the QoS inside the tunnel. The tunnel NSIS signaling
involves only those NSIS nodes in the tunnel forwarding path. The involves only those NSIS nodes in the tunnel forwarding path. The
flow IDs for the tunnel signaling are based on tunnel header fields. Flow IDs for the tunnel signaling are based on tunnel header fields.
NSIS peer discovery messages inside the tunnel also distinguish NSIS peer discovery messages inside the tunnel distinguish themselves
themselves using the tunnel header fields, which solves the problem using the tunnel header fields, which solves the problem for tunnel
for tunnel intermediate NSIS nodes to intercept signaling messages as intermediate NSIS nodes to intercept signaling messages.
described in Section 3.2.
When tunnel end-points dynamically create tunnel QoS sessions, they When tunnel end-points dynamically create tunnel QoS sessions, the
need to determine whether the tunnel NSIS signaling is sender- initiation mode of the tunnel session always follows the initiation
initiated or receiver-initiated. In order to reduce complexity, we mode of the end-to-end session. Specifically, when the end-to-end
decide that the end-to-end session and the tunnel session should session is sender-initiated, the tunnel session should also be
share the same signaling initiation mode. Since the end-to-end sender-initiated; when the end-to-end session is receiver-initiated,
session is the originator that causes the establishment of the tunnel the tunnel session should also be receiver-initiated.
session, the tunnel session always follows the initiation mode of the
end-to-end session. Specifically, when the end-to-end session is
sender-initiated, the tunnel session should also be sender-initiated;
when the end-to-end session is receiver-initiated, the tunnel session
should also be receiver-initiated.
6.1. Conveying Tunnel Flow ID Between Tunnel End-points The tunnel entry-point conveys the corresponding tunnel Flow ID
associated with an end-to-end session to the tunnel exit-point during
the tunnel signaling process. The tunnel entry-point also informs
the binding between the corresponding tunnel session and the end-to-
end session to the exit-point through the BOUND_SESSION_ID QoS NSLP
message object. The reservation message dependencies between the
tunnel session and end-to-end session is resolved using the MSG_ID
and BOUND_MSG_ID objects of the QoS NSLP message binding mechanism.
Depending on what type of tunnel flow ID in Section 4.3 is used, 6.1. Sender-initiated Reservation
dynamically created tunnel QoS sessions may involve packet
encapsulation other than standard tunneling mechanisms. For example,
when a particular tunnel session inserts an additional UDP header for
its flow ID, that additional UDP header added by the NSIS-tunnel-
aware entry-point is not part of the standard tunnel encapsulation
process. In these cases, the NSIS-tunnel-aware exit-point needs to
be notified about the special encapsulation so it can perform correct
decapsulation by removing both the standard tunnel header and the
additional UDP header. The NSIS-tunnel-aware exit-point can learn
about the tunnel flow ID through the NSIS signaling process inside
the tunnel that creates the tunnel QoS sessions. However, it needs
to further understand that the specific tunnel QoS session is
associated with an end-to-end session and therefore needs to be
decapsulated based on the corresponding tunnel flow ID. This is
achieved by using one of the objects in QoS NSLP messages called
BOUND_SESSION_ID [I-D.ietf-nsis-qos-nslp]. When used for NSIS
signaling over tunnels, the BOUND_SESSION_ID object carries the
session ID of the corresponding tunnel session and a Binding Code of
value 0x01 indicating tunnel handling. The NSIS-tunnel-aware entry-
point includes this tunnel binding object in appropriate end-to-end
signaling messages. The NSIS-tunnel-aware exit-point that receives
this tunnel session binding object then records the association
between the tunnel QoS session and the end-to-end session. With this
association, the NSIS-tunnel-aware exit-point can perform correct
decapsulation for the data packets belonging to the end-to-end
session.
6.2. Sender-initiated Reservation Figure 8 shows the typical messaging sequence of how NSIS operates
over IP tunnels when both end-to-end session and tunnel session are
sender-initiated. Tunnel signaling messages are distinguished from
end-to-end messages by a prime symbol after the message name. The
sender first sends an end-to-end RESERVE message (1) which arrives at
Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel
session and associates the end-to-end session with the tunnel
session. Tentry then sends a tunnel RESERVE' message (2) matching
the request of the end-to-end session towards Texit to reserve tunnel
resources. This RESERVE' message (2) includes a MSG_ID object which
contains a randomly generated 128-bit MSG_ID. Meanwhile, Tentry
inserts a BOUND_MSG_ID object containing the same MSG_ID as well as a
BOUND_SESSION_ID object containing the Session ID of the tunnel
session into the original RESERVE message, and sends this RESERVE
message (3) towards Texit using normal tunnel encapsulation. The
Message_Binding_Type flag of both the MSG_ID and BOUND_MSG_ID objects
in the RESERVE' and RESERVE messages (2, 3) is SET, indicating a
bidirectional binding. The tunnel RESERVE' message (2) is processed
hop-by-hop inside the tunnel for the flow identified by the chosen
tunnel Flow ID, while the end-to-end RESERVE message (3) passes
through the tunnel intermediate nodes (Tmid) just like other tunneled
packets. These two messages could arrive at Texit in different
orders, and the reaction of Texit in these different situations
should combine the tunnel QoS message processing rules with the QoS
NSLP processing principles for message binding
[I-D.ietf-nsis-qos-nslp], as illustrated below.
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| RESERVE | | | | | RESERVE(1) | | | |
+--------->| | | | +------------->| | | |
| | RESERVE' | | | | | RESERVE'(2) | | |
| +=========>| | | | +=============>| | |
| | | RESERVE' | | | | | RESERVE'(2) | |
| | +=========>| | | | +=============>| |
| | RESERVE | | | | RESERVE(3) | |
| | w/ BOUND_SESSION_ID | | | +---------------------------->| |
| +-------------------->| | | | | RESPONSE'(4) | |
| | | RESPONSE'| | | | |<=============+ |
| | |<=========+ | | | RESPONSE'(4) | | |
| | | | RESERVE | | |<=============+ | |
| | | +--------->| | | | | RESERVE(5) |
| | RESPONSE'| | | | | | +------------->|
| |<=========+ | | | | | | RESPONSE(6) |
| | | | RESPONSE | | | | |<-------------+
| | | |<---------+ | | RESPONSE(6) | |
| | RESPONSE | | | |<----------------------------+ |
| |<--------------------+ | | RESPONSE(6) | | | |
| RESPONSE | | | | |<-------------+ | | |
|<---------+ | | | | | | | |
| | | | | | | | | |
| | | | |
Figure 8: Sender-initiated Reservation for both End-to-end and Tunnel (1,5): RESERVE w/o BOUND_MSG_ID and BOUND_SESSION_ID
(2): RESERVE' w/ MSG_ID
(3): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID
Figure 8: Sender-initiated Reservation for Both End-to-end and Tunnel
Signaling Signaling
Figure 8 shows the messaging sequence of how NSIS operates over IP The first possibility is shown in the example messaging flow of
tunnels when both end-to-end session and tunnel session are sender- Figure 8, where the tunnel RESERVE' message (2), aka the triggering
initiated. Tunnel signaling messages are distinguished from end-to- message in QoS NSLP message binding terms, arrives first. Since the
end messages by a prime symbol after the message name. The sender message binding is bidirectional, Texit records the MSG_ID of the
first sends an end-to-end RESERVE message which arrives at Tentry. RESERVE' message (2), enques it and starts a MsgIDWait timer waiting
Tentry chooses the tunnel flow ID, creates the tunnel session and for the end-to-end RESERVE message (3), aka the bound signaling
associates the end-to-end session with the tunnel session. Tentry message in QoS NSLP message binding terms. The timer value is set to
then sends a tunnel RESERVE' message matching the request of the end- the default retransmission timeout period QOSNSLP_REQUEST_RETRY.
to-end session towards Texit to reserve tunnel resources. Tentry When the end-to-end RESERVE message (3) arrives, Texit notices that
also appends a tunnel BOUND_SESSION_ID object to the original RESERVE there is an existing stored MSG_ID which matches the MSG_ID in the
message containing the session ID of the tunnel session and sends it BOUND_MSG_ID object of the incoming RESERVE message (3). Therefore
towards Texit using normal tunnel encapsulation. the message binding condition has been satisfied. Texit resumes
processing of the tunnel RESERVE' message (2), creates the
reservation state for the tunnel session, and sends a tunnel
RESPONSE' message (4) to Tentry. At the same time, Texit checks the
BOUND_SESSION_ID object of the end-to-end RESERVE message (3) and
records the binding of the corresponding tunnel session with the end-
to-end session. Texit also updates the end-to-end RESERVE message
based on the result of the tunnel session reservation, removes its
tunnel BOUND_SESSION_ID and BOUND_MSG_ID object and forwards the end-
to-end RESERVE message (5) along the path towards the receiver. When
the receiver receives the end-to-end RESERVE message (5), it sends an
end-to-end RESPONSE message (6) back to the sender.
The tunnel RESERVE' message is processed hop-by-hop inside the tunnel The second possibility is that the end-to-end RESERVE message arrives
for the flow identified by the chosen tunnel flow ID. When Texit before the tunnel RESERVE' message at Texit. In that case, Texit
receives the tunnel RESERVE' message, a reservation state for the notices a BOUND_SESSION_ID object and a BOUND_MSG_ID object in the
tunnel session is created. Texit also sends a tunnel RESPONSE' end-to-end RESERVE message, but realizes that the tunnel session does
message to Tentry. On the other hand, the end-to-end RESERVE message not exist yet. So Texit enques the RESERVE message and starts a
passes through the tunnel intermediate nodes (Tmid) just like other MsgIDWait timer. The timer value is set to the default
tunneled packets. When Texit receives the end-to-end RESERVE retransmission timeout period QOSNSLP_REQUEST_RETRY. When the
message, it notices the binding of a tunnel session and updates the corresponding tunnel RESERVE' message arrives with a MSG_ID matching
end-to-end RESERVE message based on the result of the tunnel session that of the outstanding BOUND_MSG_ID object, the message binding
reservation. Then Texit removes the tunnel BOUND_SESSION_ID object condition is satisfied. Texit sends a tunnel RESPONSE' message back
and forwards the end-to-end RESERVE message further along the path to Tentry and updates the end-to-end RESERVE message by incorporating
towards the receiver. When the receiver receives the end-to-end the result of the tunnel session reservation, as well as removing the
RESERVE message, it sends an end-to-end RESPONSE message back to the tunnel BOUND_SESSION_ID and BOUND_MSG_ID objects. Texit then
sender. forwards the end-to-end RESERVE message along the path towards the
receiver. When the receiver receives the end-to-end RESERVE message,
it sends an end-to-end RESPONSE message back to the sender.
6.3. Receiver-initiated Reservation Yet another possibility is that the tunnel RESERVE' message arrives
at Texit first but the end-to-end RESERVE message never arrives. In
that case, the MsgIDWait timer for the queued tunnel RESERVE' message
will expire. Texit should send a tunnel RESPONSE' message back to
Tentry indicating a reservation error has occurred, and discard the
tunnel RESERVE' message. The last possibility is that the end-to-end
RESERVE message arrives at Texit first but the tunnel RESERVE'
message never arrives. And in that case, the MsgIDWait timer for the
queued end-to-end RESERVE message will expire. Texit should treat
this situation as a local reservation failure, and according to
[I-D.ietf-nsis-qos-nslp], Texit as a stateful QoS NSLP should
generate an end-to-end RESPONSE message indicating the RESERVE error
to the sender.
Figure 9 shows the messaging sequence of how NSIS signaling operates Once the end-to-end and the tunnel QoS session have both been
over IP tunnels when both end-to-end and tunnel sessions are successfully created and associated, the tunnel end-points Tentry and
receiver-initiated. Tentry first receives an end-to-end QUERY Texit coordinate the signaling between the two sessions and make sure
message from the sender, it chooses the tunnel flow ID, creates the that adjustment or teardown of either session may trigger similar
tunnel session and sends a tunnel QUERY' message matching the request actions for the other session as necessary, by invoking appropriate
of the end-to-end session towards Texit. Tentry also appends a signaling messages.
tunnel BOUND_SESSION_ID object containing the session ID of the
tunnel session to the original QUERY message and sends it toward
Texit using normal tunnel encapsulation.
The tunnel QUERY' message is processed hop-by-hop inside the tunnel 6.2. Receiver-initiated Reservation
for the flow identified by the chosen tunnel flow ID. When Texit
receives the tunnel QUERY' message, it creates a reservation state
for the tunnel session without sending a tunnel RESERVE' message
immediately.
The end-to-end QUERY message passes along tunnel intermediate nodes Figure 9 shows the typical messaging sequence of how NSIS signaling
like other tunneled packets. When Texit receives the end-to-end operates over IP tunnels when both end-to-end and tunnel sessions are
QUERY message, it notices the binding of a tunnel session and checks receiver-initiated. Upon receiving an end-to-end QUERY message (1)
the state information for the tunnel session. When the tunnel from the sender, Tentry chooses the tunnel Flow ID and sends a tunnel
session state is available, Texit updates the end-to-end QUERY QUERY' message (2) matching the request of the end-to-end session
message with information from tunnel session state (e.g., QoS towards Texit. This tunnel QUERY' message (2) is meant to discover
availability in the tunnel), removes the tunnel BOUND_SESSION_ID QoS characteristics of the tunnel path, rather than initiating an
object and forwards the end-to-end QUERY message further along the actual reservation. Therefore, it includes a Request Identification
path. Information (RII) object but does not set the RESERVE-INIT flag. The
tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel
for the flow identified by the tunnel Flow ID. When Texit receives
this tunnel QUERY' message (2), it replies with a corresponding
tunnel RESPONSE' message (3) containing the tunnel path
characteristics. After receiving the tunnel RESPONSE' message (3),
Tentry creates the tunnel session, generates an outgoing end-to-end
QUERY message (4) considering the tunnel path characteristics,
appends a tunnel BOUND_SESSION_ID object containing the tunnel
Session ID, and sends it toward Texit using normal tunnel
encapsulation. The end-to-end QUERY message (4) passes along tunnel
intermediate nodes like other tunneled packets. Upon receiving this
end-to-end QUERY message (4), Texit notices the tunnel session
binding and creates the tunnel session state, removes the tunnel
BOUND_SESSION_ID object and forwards the end-to-end QUERY message (5)
further along the path.
Sender Tentry Tmid Texit Receiver The end-to-end QUERY message (5) arrives at the receiver and triggers
a RESERVE message (6). When Texit receives the RESERVE message (6),
it notices that the session is bound to a receiver-initiated tunnel
session. Therefore, Texit triggers a RESERVE' message (7) toward
Tentry for the tunnel session reservation. This tunnel RESERVE'
message (7) includes a randomly generated 128-bit MSG_ID. Meanwhile,
Texit inserts a BOUND_MSG_ID object containing the same MSG_ID and a
BOUND_SESSION_ID object containing the tunnel Session ID into the
end-to-end RESERVE message (8), and sends it towards Tentry using
normal tunnel encapsulation. The Message_Binding_Type flag of the
MSG_ID and BOUND_MSG_ID objects in the RESERVE' and RESERVE messages
(7,8) is SET, indicating a bidirectional binding.
| | | | | Sender Tentry Tmid Texit Receiver
| QUERY | | | |
+--------->| | | |
| | QUERY' | | |
| +=========>| | |
| | | QUERY' | |
| | +=========>| |
| | QUERY | |
| | w/ BOUND_SESSION_ID | |
| +-------------------->| |
| | | | QUERY |
| | | +--------->|
| | | | RESERVE |
| | | |<---------+
| | | RESERVE' | |
| | |<=========+ |
| | RESERVE' | | |
| |<=========+ | |
| | RESERVE | |
| |<--------------------+ |
| RESERVE | | | |
|<---------+ | | |
| | RESPONSE'| | |
| +=========>| | |
| | | RESPONSE'| |
| | +=========>| |
| RESPONSE | | | |
+--------->| | | |
| | RESPONSE | |
| +-------------------->| |
| | | | RESPONSE |
| | | +--------->|
| | | | |
| | | | |
Figure 9: Receiver-initiated Reservation for Both End-to-end and | | | | |
Tunnel Signaling | QUERY(1) | | | |
+------------->| | | |
| | QUERY'(2) | | |
| +=============>| | |
| | | QUERY'(2) | |
| | +=============>| |
| | | RESPONSE'(3) | |
| | |<=============+ |
| | RESPONSE'(3) | | |
| |<=============+ | |
| | QUERY(4) | |
| +---------------------------->| |
| | | | QUERY(5) |
| | | +------------->|
| | | | RESERVE(6) |
| | | |<-------------+
| | | RESERVE'(7) | |
| | |<=============+ |
| | RESERVE'(7) | | |
| |<=============+ | |
| | RESERVE(8) | |
| |<----------------------------+ |
| | RESPONSE'(9) | | |
| +=============>| | |
| | | RESPONSE'(9) | |
| | +=============>| |
| RESERVE(10) | | | |
|<-------------+ | | |
| RESPONSE(11) | | | |
+------------->| | | |
| | RESPONSE(11) | |
| +---------------------------->| |
| | | | RESPONSE(11) |
| | | +------------->|
| | | | |
| | | | |
When Texit receives the first end-to-end RESERVE message issued by (1,5): QUERY w/ RESERVE-INIT (2): QUERY' w/ RII
the receiver, it finds the reservation state of the tunnel session (4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID
and triggers a tunnel RESERVE' message for that session. Meanwhile (6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID
Texit forwards the end-to-end RESERVE message towards Tentry. When (8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID
Tentry receives the tunnel RESERVE' message, it creates the
reservation state for the tunnel session and sends a tunnel RESPONSE'
message back to Texit. When Tentry receives the end-to-end RESERVE
message, it updates the end-to-end RESERVE message with the result of
the corresponding tunnel session reservation. Then Tentry forwards
the end-to-end RESERVE message upstream toward the sender. When the
sender receives the end-to-end RESERVE message, it sends an end-to-
end RESPONSE message back to the receiver.
6.4. Timing Issues of End-to-end and Tunnel Signaling Figure 9: Receiver-initiated Reservation for Both End-to-end and
Tunnel Signaling
NSIS operation over tunnels that dynamically create QoS sessions At Tentry, the tunnel RESERVE' message (7) and the end-to-end RESERVE
involves two correlated but separate signaling sessions, the end-to- message (8) could arrive in different orders. In a typical case
end session and the corresponding tunnel session. The outcome of the shown in Figure 9, the tunnel RESERVE' message (7) arrives first.
tunnel signaling session directly affects the outcome of the end-to- Tentry records the MSG_ID of the tunnel RESERVE' message (7) and
end signaling session. Since the two signaling sessions overlap in starts a MsgIDWait timer. When the end-to-end RESERVE message (8)
time, there are circumstances when a tunnel end-point has to decide with the BOUND_MSG_ID object containing the same MSG_ID arrives, the
whether it should proceed with the end-to-end signaling session while message binding condition is satisfied. Tentry resumes processing of
it is still waiting for results of the tunnel session. Sequential the tunnel RESERVE' message (7), creates the reservation state for
mode and parallel mode are two basic options for this problem. In the tunnel session, and sends a tunnel RESPONSE' message (9) to
sequential mode, end-to-end signaling pauses when it is waiting for Texit. At the same time, Tentry creates the outgoing end-to-end
results of tunnel signaling, and resumes upon receipt of the tunnel RESERVE message (10) by incorporating results of the tunnel session
signaling outcome. In parallel mode, end-to-end signaling continues reservation and removing the BOUND_SESSION_ID and BOUND_MSG_ID
outside the tunnel while tunnel signaling is still in process and its objects, and forwards it along the path towards the sender. When the
outcome is unknown. Our design in Section 6 adopts a hybrid mode in sender receives the end-to-end RESERVE message (10), it sends an end-
order to strike a balance between speed and efficiency. The rule is to-end RESPONSE message (11) back to the receiver.
that end-to-end signaling should wait for tunnel signaling if it is
expecting information that is required to initiate the end-to-end
reservation; but end-to-end signaling does not need to wait for
tunnel signaling if the end-to-end QoS reservation is already in
progress.
An example of end-to-end signaling having to wait for tunnel If the end-to-end RESERVE message arrives before the tunnel RESERVE'
signaling outcome is the end-to-end QUERY message from Texit to the message at Tentry, or either of the two messages fails to arrive at
receiver in Figure 9. That Query message needs to wait for the Tentry, the processing rules at Tentry is similar to those of Texit
QUERY' message about the tunnel QoS information and then be forwarded in the same situation discussed in Section 6.1.
toward the receiver. The tunnel QoS information learned from the
QUERY' message supplies important information needed to initiate the
end-to-end reservation. This timing rule ensures that the first end-
to-end RESERVE message originated from the receiver will have the
correct view of the whole path, both inside and outside the tunnel.
An example of end-to-end signaling not having to wait for tunnel Once the end-to-end and the tunnel QoS session have both been
signaling outcome is a RESERVE message which is about to leave the successfully created and associated, the tunnel end-points Tentry and
tunnel, such as the RESERVE message from Texit to the receiver in Texit coordinate the signaling between the two sessions and make sure
Figure 8 and the RESERVE message from Tentry to sender in Figure 9. that adjustment or teardown of either session can trigger similar
Those RESERVE messages can be forwarded immediately even if the actions for the other session as necessary, by invoking appropriate
tunnel QoS reservation outcome is still unknown. However, the tunnel signaling messages.
end-point should try to learn about results of the corresponding
tunnel session reservation either through proactive polling after a
specific amount of time, or before a refresh message is scheduled to
be sent. Once the tunnel session reservation information is
available, the tunnel end-point should immediately trigger an end-to-
end RESERVE message subject to the results of the tunnel reservation.
That is, if the tunnel reservation is successful, the message would
be a normal RESERVE refresh; otherwise, the RESERVE message should
indicate that some error has occurred in the reservation path.
7. NSIS-Tunnel Signaling Capability Discovery 7. NSIS-Tunnel Signaling Capability Discovery
As discussed in Section 6.1, when operating over a tunnel, NSIS- When operating over a tunnel, NSIS-tunnel-aware end-points may need
tunnel-aware end-points may need to perform special encapsulation and to perform special encapsulation and decapsulation such as inserting
decapsulation such as inserting and removal of an extra UDP header. and removal of an extra UDP header, depending on the tunnel Flow ID
format. Therefore, before the NSIS-tunnel-aware end-point decides to
Therefore, before the NSIS-tunnel-aware end-point decides to initiate initiate such encapsulation, it needs to know whether the other
such encapsulation, it needs to know whether the other entry-point is entry-point is also NSIS-tunnel-aware and thus capable of performing
also NSIS-tunnel-aware and thus capable of performing matching matching decapsulation. This section defines a mechanism to enable
decapsulation. This section defines a mechanism to enable this this capability discovery for tunnels using dynamically created
capability discovery for tunnels using dynamically created tunnel QoS tunnel QoS sessions. For tunnels with pre-configured QoS sessions,
sessions. For tunnels with pre-configured QoS sessions, an end-point an end-point can learn the NSIS-tunnel capability information of the
can learn the NSIS-tunnel capability information of the other end- other end-point during the pre-configuration process.
point during the pre-configuration process.
7.1. NODE_CHAR Object Format 7.1. NODE_CAPABILITY Object Format
A GIST NODE_CHAR object is defined to discover the NSIS-tunnel A GIST NODE_CAPABILITY object is defined to discover the NSIS-tunnel
handling capability of a tunnel end-point. The format of the handling capability of a tunnel end-point. The format of the
NODE_CHAR object follows the general object definition in GIST. The NODE_CAPABILITY object follows the general object definition in GIST.
object contains a fixed header specifying the object type and object
length, followed by the object value.
0 1 2 3 The object contains a fixed header specifying the object type and
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 object length, followed by the object value.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CHAR Object Format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: NODE_CHAR Figure 10: NODE_CAPABILITY Object Format
Type: NODE_CAPABILITY
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: Value contains a single 'T' bit, indicating the node supports
the NSIS-tunnel handling mechanisms defined in this document. The the NSIS-tunnel handling mechanisms defined in this document. The
reserved bits in the value field can be used to signal other node reserved bits in the value field can be used to signal other node
characteristics in the future. characteristics in 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_CHAR object, the desired behavior is "Ignore". That is, the NODE_CAPABILITY object, the desired behavior is "Ignore". That is,
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' according to
Appendix A.2 of the GIST specification [I-D.ietf-nsis-ntlp]. Appendix A.2 of the GIST specification [I-D.ietf-nsis-ntlp].
7.2. Using NODE_CHAR Object 7.2. Using NODE_CAPABILITY Object
The NODE_CHAR object is included in a QUERY or RESERVE message by a The NODE_CAPABILITY object is included in a QUERY or RESERVE message
tunnel end-point that needs to learn about the other end-point's NSIS by a tunnel end-point that needs to learn about the other end-point's
tunnel handling capability. If the receiving tunnel end-point is NSIS tunnel handling capability. If the receiving tunnel end-point
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. Example
procedures of how to use the NODE_CHAR object over tunnels that procedures of how to use the NODE_CAPABILITY object over tunnels that
dynamically creates QoS sessions are further detailed below. dynamically creates QoS sessions are further detailed below.
First, assume that both end-to-end and tunnel session are sender- First, assume that both end-to-end and tunnel session are sender-
initiated (Section 6.2) and an NSIS-tunnel-aware Tentry wants to initiated (Section 6.1) and an NSIS-tunnel-aware Tentry wants to
discover the NSIS-tunnel capability of Texit before starting the discover the NSIS-tunnel capability of Texit before starting the
tunnel signaling. Tentry includes a Request Identification tunnel signaling. Tentry includes a Request Identification
Information (RII) object (see [I-D.ietf-nsis-qos-nslp]) and a Information (RII) object (see [I-D.ietf-nsis-qos-nslp]) and a
NODE_CHAR object with T bit set in the first end-to-end RESERVE NODE_CAPABILITY object with T bit set in the first end-to-end RESERVE
message sent to Texit. When Texit receives this RESERVE message, if message sent to Texit. When Texit receives this RESERVE message, if
it is also NSIS-tunnel-aware, it learns that Tentry is NSIS-tunnel- it is also NSIS-tunnel-aware, it learns that Tentry is NSIS-tunnel-
aware and includes the same object with T bit set in the following aware and includes the same object with T bit set in the following
end-to-end RESPONSE message sent back to Tentry. Otherwise, Texit end-to-end RESPONSE message sent back to Tentry. Otherwise, Texit
ignores the NODE_CHAR object. When Tentry receives the RESPONSE ignores the NODE_CAPABILITY object. When Tentry receives the
message, it knows whether Texit is NSIS-tunnel-aware by checking the RESPONSE message, it knows whether Texit is NSIS-tunnel-aware by
existence of the NODE_CHAR object and its T bit. If both tunnel checking the existence of the NODE_CAPABILITY object and its T bit.
endpoints are NSIS-tunnel-aware, the rest of the procedures follows If both tunnel endpoints are NSIS-tunnel-aware, the rest of the
those defined in Section 6.2. procedures follows those defined in Section 6.1.
Second, assume that both end-to-end and tunnel sessions are receiver- Second, assume that both end-to-end and tunnel sessions are receiver-
initiated (Section 6.3) and the NSIS-tunnel-aware Tentry wants to initiated (Section 6.2) and the NSIS-tunnel-aware Tentry wants to
discover the NSIS-tunnel capability of Texit before creating a tunnel discover the NSIS-tunnel capability of Texit before creating a tunnel
session. Tentry includes an RII object and a NODE_CHAR object with T session. Tentry includes an RII object and a NODE_CAPABILITY object
bit set in the first end-to-end QUERY message sent towards Texit. If with T bit set in the first end-to-end QUERY message sent towards
Texit is NSIS-tunnel-aware, it learns from the NODE_CHAR object that Texit. If Texit is NSIS-tunnel-aware, it learns from the
Tentry is also NSIS-tunnel-aware. In the later end-to-end RESPONSE NODE_CAPABILITY object that Tentry is also NSIS-tunnel-aware. In the
message to this QUERY message, Texit includes a NODE_CHAR object with later end-to-end RESPONSE message to this QUERY message, Texit
T bit set to notify Tentry of its NSIS-tunnel capability. If both includes a NODE_CAPABILITY object with T bit set to notify Tentry of
tunnel end-points are NSIS-tunnel-aware, the rest of the procedures its NSIS-tunnel capability. If both tunnel end-points are NSIS-
follows those in Section 6.3. tunnel-aware, the rest of the procedures follows those in
Section 6.2.
8. IANA Considerations 8. IANA Considerations
This document defines a new object type called NODE_CHAR for GIST. This document defines a new object type called NODE_CAPABILITY for
Its OType value needs to be assigned by IANA. The object format and GIST. Its OType value needs to be assigned by IANA. The object
the setting of the extensibility bits are defined in Section 7. format and the setting of the extensibility bits are defined in
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].
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Tannes Tschofenig and other members The authors would like to thank Roland Bless, Hannes Tschofenig,
of the NSIS working group for comments to this work. Georgios Karagiannis and other members of the NSIS working group for
comments to this work.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-17 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), October 2009. (work in progress), January 2010.
11.2. Informative References 11.2. Informative References
[I-D.ietf-nsis-applicability-mobility-signaling] [I-D.ietf-nsis-applicability-mobility-signaling]
Sanda, T., Fu, X., Jeong, S., Manner, J., and H. Sanda, T., Fu, X., Jeong, S., Manner, J., and H.
Tschofenig, "Applicability Statement of NSIS Protocols in Tschofenig, "Applicability Statement of NSIS Protocols in
Mobile Environments", Mobile Environments",
draft-ietf-nsis-applicability-mobility-signaling-13 (work draft-ietf-nsis-applicability-mobility-signaling-14 (work
in progress), July 2009. in progress), January 2010.
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-20 (work in progress), draft-ietf-nsis-nslp-natfw-23 (work in progress),
November 2008. February 2010.
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Bader, A., Ash, G., Kappler, C., and D. Oran, "QoS NSLP Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
QSPEC Template", draft-ietf-nsis-qspec-22 (work in Template", draft-ietf-nsis-qspec-24 (work in progress),
progress), November 2009. January 2010.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702, Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994. October 1994.
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
 End of changes. 92 change blocks. 
542 lines changed or deleted 633 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/