draft-ietf-nsis-tunnel-09.txt   draft-ietf-nsis-tunnel-10.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: Experimental Columbia U. Intended status: Experimental Columbia U.
Expires: August 19, 2010 S. Lee Expires: October 20, 2010 S. Lee
J. Bang J. Bang
Samsung AIT Samsung AIT
February 15, 2010 April 18, 2010
NSIS Operation Over IP Tunnels NSIS Operation Over IP Tunnels
draft-ietf-nsis-tunnel-09.txt draft-ietf-nsis-tunnel-10.txt
Abstract Abstract
NSIS QoS signaling enables applications to perform QoS reservation NSIS QoS signaling enables applications to perform QoS reservation
along a data flow path. When the data flow path contains IP tunnel along a data flow path. When the data flow path contains IP tunnel
segments, NSIS QoS signaling has no effect within those tunnel segments, NSIS QoS signaling has no effect within those tunnel
segments and the resulting QoS-untended tunnel segments could become segments and the resulting QoS-untended tunnel segments could become
the weakest QoS link which may invalidate the QoS efforts in the rest the weakest QoS link which may invalidate the QoS efforts in the rest
of the end-to-end path. The problem with NSIS signaling within the of the end-to-end path. The problem with NSIS signaling within the
tunnel is caused by the tunnel encapsulation which masks packets' tunnel is caused by the tunnel encapsulation which masks packets'
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
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on October 20, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6 3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 5
3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 8 3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 7
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 9
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11 4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 10
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 14 4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 12
5. NSIS Operation over Tunnels with Pre-configured QoS 5. NSIS Operation over Tunnels with Pre-configured QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 15 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 13
5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15 5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 14
6. NSIS Operation over Tunnels with Dynamically Created QoS 6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17 6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 16
6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 20 6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 18
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 21
7.1. NODE_CAPABILITY Object Format . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.2. Using NODE_CAPABILITY Object . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 29 skipping to change at page 3, line 29
an IP network layer signaling architecture consisting of a Generic an IP network layer signaling architecture consisting of a Generic
Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer
for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) for signaling transport, and an NSIS Signaling Layer Protocol (NSLP)
sub-layer customizable for different applications. We focus on the sub-layer customizable for different applications. We focus on the
Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides
functionalities that extend those of the earlier RSVP [RFC2205] functionalities that extend those of the earlier RSVP [RFC2205]
signaling. In this document the term "NSIS" and "NSIS QoS" are used signaling. In this document the term "NSIS" and "NSIS QoS" are used
interchangeably. interchangeably.
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 tunnel 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 end-to-end NSIS signaling This document defines a mechanism to extend end-to-end NSIS signaling
for QoS reservation into IP tunnels. The NSIS-aware IP tunnel end- for QoS reservation into IP tunnels. The NSIS-aware IP tunnel end-
points that support this mechanism are called NSIS-tunnel-aware end- points that support this mechanism are called NSIS-tunnel-aware end-
skipping to change at page 6, line 40 skipping to change at page 5, line 40
Original Original Original Original
Packet Packet Packet Packet
Source Destination Source Destination
Node Node Node Node
Figure 1: IP Tunnel Figure 1: IP Tunnel
The following definition of IP tunneling is derived from [RFC2473] The following definition of IP tunneling is derived from [RFC2473]
and adapted for both IPv4 and IPv6. and adapted for both IPv4 and IPv6.
IP tunneling is a technique for establishing a "virtual link" between IP tunneling (Figure 1) is a technique for establishing a "virtual
two IP nodes for transmitting data packets as payloads of IP packets link" between two IP nodes for transmitting data packets as payloads
(see Figure 1). From the point of view of the two nodes, this of IP packets. 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.
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. Bi-directional tunneling is achieved by combining two
combining two unidirectional mechanisms, that is, configuring two unidirectional mechanisms, that is, configuring two tunnels, each in
tunnels, each in opposite direction to the other - the entry-point opposite direction to the other - the entry-point node of one tunnel
node of one tunnel is the exit-point node of the other 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, causing the tunnel
tunnel packet to be routed inside the tunnel. The tunnel specific packet to be forwarded in the tunnel. The tunnel specific header
headers in between the tunnel IP header and the original packet in a between the tunnel IP header and the original packet is optional,
tunnel packet are optional, depending on the tunneling protocol in 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 | Header | |
+---------+-----------+-------------------------//--------------+ +---------+-----------+-------------------------//--------------+
< 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
tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and
IPv6GEN contain only a tunnel IP header, and no tunnel specific IPv6GEN contain only a tunnel IP header, and no tunnel specific
headers. All the other tunneling protocols have a tunnel header header. All the other tunneling protocols have a tunnel header
consisting of both a tunnel IP header and a tunnel specific header. consisting of both a tunnel IP header and a tunnel specific header.
The tunnel specific header is the GRE header for GRE and GREIPv4, the The tunnel specific header is the GRE header for GRE and GREIPv4, the
minimum encapsulation header for MINENC and the Encapsulation minimum encapsulation header for MINENC and the Encapsulation
Security Payload (ESP) header for IPSEC tunneling mode. As will be Security Payload (ESP) header for IPSEC tunneling mode. As will be
discussed in Section 4.3, some of the tunnel specific headers may be discussed in Section 4.3, some of the tunnel specific headers may be
used to identify a flow in the tunnel and facilitate NSIS operating used to identify a flow in the tunnel and facilitate NSIS operating
over IP tunnels. over IP tunnels.
3.2. NSIS QoS Signaling in the Presence of IP Tunnels 3.2. NSIS QoS Signaling in the Presence of IP Tunnels
skipping to change at page 8, line 44 skipping to change at page 7, line 43
Node Node Node Node
Figure 3: Example Scenario of NSIS QoS Signaling 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 flow path.
There are two important aspects in the above signaling process that There are two important aspects in the above signaling process that
are worth mentioning. First, the flow sender does not initially know are worth mentioning. First, the flow sender does not initially know
exactly which intermediate nodes are NSIS-aware and should be exactly which intermediate nodes are NSIS-aware and should be
involved in the signaling process for a flow from node A to node E. involved in the signaling process for a flow from node A to node E.
Discovery of those nodes, namely node B, C and D is accomplished by a Discovery of those nodes, namely node B, C and D is accomplished by a
separate NSIS peer discovery process (not shown above, see separate NSIS peer discovery process (not shown above, see
[I-D.ietf-nsis-ntlp]). The NSIS peer discovery messages contain [I-D.ietf-nsis-ntlp]). The NSIS peer discovery messages contain
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.
skipping to change at page 10, line 47 skipping to change at page 9, line 46
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 should limit the necessary upgrade to the tunnel
end-points. Only tunnel end-points need to support the mechanism end-points.
defined in this document. Such tunnel end-points are called NSIS- o The mechanism should provide a method for one NSIS-tunnel-aware
tunnel-aware end-points. All other nodes, both inside and outside end-point to discover whether the other end-point is also NSIS-
the tunnel should be transparent to this mechanism. tunnel-aware, when necessary.
o The mechanism should facilitate its incremental deployment by
providing a method for one NSIS-tunnel-aware end-point to discover
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
skipping to change at page 11, line 31 skipping to change at page 10, line 27
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 unidirectional, 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. An NSIS-tunnel-aware end-
end-point needs to know whether the other tunnel end-point is also point knows whether the other tunnel end-point is NSIS-tunnel-aware
NSIS-tunnel-aware, it may use the NSIS-tunnel capability discovery either through pre-configuration or through an NSIS-tunnel capability
mechanism defined in Section 7. discovery 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 with tunnel QoS. interaction with tunnel QoS.
To facilitate the QoS handling in the tunnel, the end-to-end QoS To facilitate QoS handling in the tunnel, an end-to-end QoS session
session will be mapped to a tunnel QoS session, either pre-configured is mapped to a tunnel QoS session, either pre-configured or
or dynamically created. An important property of a tunnel QoS dynamically created. The tunnel session uses a tunnel Flow ID based
session is its tunnel Flow ID which identifies the end-to-end data on information available in the tunnel headers, thus allowing tunnel-
flow within the tunnel. In both tunnels with and without pre- intermediate nodes to classify flow packets correctly.
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, the tunnel a request to reserve resources for an end-to-end session, the tunnel
end-point maps the end-to-end QoS session to an existing tunnel end-point maps the end-to-end QoS session to an existing tunnel
session. To simplify the design, the mapping decision is always made session. To simplify the design, the mapping decision is always made
by the tunnel entry-point regardless of whether the end-to-end by the tunnel entry-point regardless of whether the end-to-end
session uses sender-initiated or receiver-initiated NSIS signaling session uses sender-initiated or receiver-initiated NSIS signaling
mode. The details about which end-to-end session can be mapped to mode. The details about which end-to-end session can be mapped to
which pre-configured tunnel session depend on policy mechanisms which pre-configured tunnel session depend on policy mechanisms
outside the scope of this document. outside the scope of this document.
skipping to change at page 13, line 6 skipping to change at page 11, line 42
In addition to the tunnel entry-point recording the association In addition to the tunnel entry-point recording the association
between the end-to-end session and its corresponding tunnel session, between the end-to-end session and its corresponding tunnel session,
the tunnel exit-point also needs to maintain the same association for the tunnel exit-point also needs to maintain the same association for
similar reasons. At the signaling plane, this association at the similar reasons. At the signaling plane, this association at the
tunnel exit-point enables the interaction of the end-to-end and the tunnel exit-point enables the interaction of the end-to-end and the
tunnel QoS session such as QoS adjustment in receiver-initiated tunnel QoS session such as QoS adjustment in receiver-initiated
reservations. At the data plane, this association tells the tunnel reservations. At the data plane, this association tells the tunnel
exit-point that the relevant data flow packets need to be exit-point that the relevant data flow packets need to be
decapsulated according to the corresponding tunnel Flow ID. decapsulated according to the corresponding tunnel Flow ID.
The tunnel exit-point learns about the mapping between the tunnel and In tunnels with pre-configured QoS sessions, the tunnel exit-point
the end-to-end QoS sessions, including the tunnel Flow ID and the may learn about the mapping information between the corresponding
tunnel session's Session ID that corresponds to the end-to-end tunnel and end-to-end QoS sessions through pre-configuration as well.
session, through the follow methods. In tunnels with pre-configured In tunnels without pre-configured QoS sessions, the tunnel exit-point
QoS sessions, the mapping information between the corresponding knows the mapping between the corresponding tunnel and end-to-end QoS
tunnel and end-to-end QoS sessions may be pre-configured as well. In sessions through the NSIS signaling process that creates the tunnel
tunnels without pre-configured QoS sessions, the tunnel exit-point QoS sessions inside the tunnel, with the help of appropriate QoS NSLP
knows the tunnel Flow ID through the NSIS signaling process that session binding and message binding mechanisms.
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 One problem for NSIS operating over IP tunnels which dynamically
create QoS sessions is that it involves two signaling sequences. The create QoS sessions is that it involves two signaling sequences. The
outcome of the tunnel signaling session directly affects the outcome outcome of the tunnel signaling session directly affects the outcome
of the end-to-end signaling session. Since the two signaling of the end-to-end signaling session. Since the two signaling
sessions overlap in time, there are circumstances when a tunnel end- sessions overlap in time, there are circumstances when a tunnel end-
point has to decide whether it should proceed with the end-to-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 signaling session while it is still waiting for results of the tunnel
session. Sequential mode and parallel mode are two basic options for session. Sequential mode and parallel mode are two basic options for
this problem. In sequential mode, end-to-end signaling pauses when this problem. In sequential mode, end-to-end signaling pauses when
it is waiting for results of tunnel signaling, and resumes upon it is waiting for results of tunnel signaling, and resumes upon
receipt of the tunnel signaling outcome. In parallel mode, end-to- receipt of the tunnel signaling outcome. In parallel mode, end-to-
end signaling continues outside the tunnel while tunnel signaling is end signaling continues outside the tunnel while tunnel signaling is
still in process and its outcome is unknown. The parallel mode may still in process and its outcome is unknown. The parallel mode may
lead to reduced signaling delays if the QoS resources in the tunnel 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 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 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 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 wasted end-to-end signaling or necessitates re-negotiation after the
tunnel signaling outcome becomes available. In those cases, the tunnel signaling outcome becomes available. In those cases, the
signaling flow of the parallel mode also tends to be more signaling flow of the parallel mode also tends to be complicated.
complicated. This document adopts a sequential mode approach. In This document adopts a sequential mode approach for the two signaling
addition, the actual signaling process uses the QoS NSLP message sequences.
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.
skipping to change at page 14, line 41 skipping to change at page 13, line 13
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 need to be configured with
with the Flow ID of the tunnel QoS session. This is to enable the information about the Flow ID of the tunnel QoS session. This is to
tunnel end-points to correctly perform matching encapsulating and enable the tunnel end-points to correctly perform matching
decapsulating operations. The procedures of NSIS operating over encapsulating and decapsulating operations. The procedures of NSIS
tunnels with pre-configured QoS sessions are slightly different operating over tunnels with pre-configured QoS sessions depend on
depending on whether the end-to-end NSIS signaling is sender- whether the end-to-end NSIS signaling is sender-initiated or
initiated or receiver-initiated. But in either case, it is the receiver-initiated. But in both cases, it is the tunnel entry-point
tunnel entry-point that first creates the mapping between a tunnel that first creates the mapping between a tunnel session and an end-
session and an end-to-end session. to-end session.
5.1. Sender-initiated Reservation 5.1. Sender-initiated Reservation
Figure 6 illustrates the signaling sequence when end-to-end signaling
outside the tunnel is sender-initiated. Upon receiving a RESERVE
message from the sender, Tentry checks tunnel QoS configuration,
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-configuration and outside the scope of this document. Tentry
then tunnels the RESERVE message to Texit. Texit forwards the
RESERVE message to the receiver. The receiver replies with a
RESPONSE message which arrives at Texit, Tentry and finally the
sender. If the RESPONSE message that Tentry receives confirms that
the overall signaling is successful, Tentry starts to encapsulate all
incoming packets of the data flow using the tunnel Flow ID
corresponding to the mapped tunnel session. Texit knows how to
decapsulate the tunnel packets because it recognizes the mapped
tunnel Flow ID based on information supplied during tunnel session
pre-configuration.
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| RESERVE | | | | | RESERVE | | | |
+------------->| | | | +------------->| | | |
| | RESERVE | | | | RESERVE | |
| +---------------------------->| | | +---------------------------->| |
| | | | RESERVE | | | | | RESERVE |
| | | +------------->| | | | +------------->|
skipping to change at page 15, line 42 skipping to change at page 13, line 46
| | RESPONSE | | | | RESPONSE | |
| |<----------------------------+ | | |<----------------------------+ |
| RESPONSE | | | | | RESPONSE | | | |
|<-------------+ | | | |<-------------+ | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 6: Sender-initiated End-to-end Session with Pre-configured Figure 6: Sender-initiated End-to-end Session with Pre-configured
Tunnel QoS Sessions Tunnel QoS Sessions
5.2. Receiver-initiated Reservation Figure 6 illustrates the signaling sequence when end-to-end signaling
outside the tunnel is sender-initiated. Upon receiving a RESERVE
message from the sender, Tentry checks tunnel QoS configuration,
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-configuration and outside the scope of this document. Tentry
then tunnels the RESERVE message to Texit. Texit forwards the
RESERVE message to the receiver. The receiver replies with a
RESPONSE message which arrives at Texit, Tentry and finally the
sender. If the RESPONSE message that Tentry receives confirms that
the overall signaling is successful, Tentry starts to encapsulate all
incoming packets of the data flow using the tunnel Flow ID
corresponding to the mapped tunnel session. Texit knows how to
decapsulate the tunnel packets because it recognizes the mapped
tunnel Flow ID based on information supplied during tunnel session
pre-configuration.
Figure 7 shows the signaling sequence when end-to-end signaling 5.2. Receiver-initiated Reservation
outside the tunnel is receiver-initiated. Upon receiving the first
end-to-end Query message, Tentry examines the tunnel QoS
configuration, updates and tunnels the Query message to Texit. Texit
decapsulates the QUERY message, processes it and forwards it toward
the receiver. Later, the receiver sends back a RESERVE message
passing through Texit and arriving at Tentry. Tentry decides on
whether and how the QoS request for this end-to-end session can be
mapped to a pre-configured tunnel session based on an algorithm
outside the scope of this document. Then Tentry tunnels the RESERVE
message to Texit which forwards it to the receiver. The signaling
continues until a RESPONSE message arrives at Tentry, Texit and
finally the receiver. If the RESPONSE message that Tentry receives
confirms that the overall signaling is successful, Tentry starts to
encapsulate all incoming packets of the data flow using the tunnel
Flow ID corresponding to the mapped tunnel session. Similarly, Texit
knows how to decapsulate the tunnel packets because it recognizes the
mapped tunnel Flow ID based on information supplied during tunnel
session pre-configuration.
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| QUERY | | | | | QUERY | | | |
+------------->| | | | +------------->| | | |
| | QUERY | | | | QUERY | |
| +---------------------------->| | | +---------------------------->| |
| | | | QUERY | | | | | QUERY |
| | | +------------->| | | | +------------->|
skipping to change at page 16, line 43 skipping to change at page 14, line 45
| | 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 Figure 7 shows the signaling sequence when end-to-end signaling
tunnels, Figure 6 and Figure 7 look as if the tunnel is a single outside the tunnel is receiver-initiated. Upon receiving the first
end-to-end Query message, Tentry examines the tunnel QoS
configuration, updates and tunnels the Query message to Texit. Texit
decapsulates the QUERY message, processes it and forwards it toward
the receiver. The receiver sends back a RESERVE message passing
through Texit and arriving at Tentry. Tentry decides on whether and
how the QoS request for this end-to-end session can be mapped to a
pre-configured tunnel session based on criteria outside the scope of
this document. Then Tentry forwards the RESERVE message towards the
sender. The signaling continues until a RESPONSE message arrives at
Tentry, Texit and finally the receiver. If the RESPONSE message that
Tentry receives confirms that the overall signaling is successful,
Tentry starts to encapsulate all incoming packets of the data flow
using the tunnel Flow ID corresponding to the mapped tunnel session.
Similarly, Texit knows how to decapsulate the tunnel packets because
it recognizes the mapped tunnel Flow ID based on information supplied
during tunnel session pre-configuration.
Since separate tunnel QoS signaling is not involved in pre-configured
QoS 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
skipping to change at page 17, line 26 skipping to change at page 15, line 47
When tunnel end-points dynamically create tunnel QoS sessions, the When tunnel end-points dynamically create tunnel QoS sessions, the
initiation mode of the tunnel session always follows the initiation initiation mode of the tunnel session always follows the initiation
mode of the end-to-end session. Specifically, when the end-to-end mode of the end-to-end session. Specifically, when the end-to-end
session is sender-initiated, the tunnel session should also be session is sender-initiated, the tunnel session should also be
sender-initiated; when the end-to-end session is receiver-initiated, sender-initiated; when the end-to-end session is receiver-initiated,
the tunnel session should also be receiver-initiated. the tunnel session should also be receiver-initiated.
The tunnel entry-point conveys the corresponding tunnel Flow ID The tunnel entry-point conveys the corresponding tunnel Flow ID
associated with an end-to-end session to the tunnel exit-point during associated with an end-to-end session to the tunnel exit-point during
the tunnel signaling process. The tunnel entry-point also informs the tunnel signaling process. The tunnel entry-point also informs
the binding between the corresponding tunnel session and the end-to- the exit-point of the binding between the corresponding tunnel
end session to the exit-point through the BOUND_SESSION_ID QoS NSLP session and end-to-end session through the BOUND_SESSION_ID QoS NSLP
message object. The reservation message dependencies between the message object. The reservation message dependencies between the
tunnel session and end-to-end session is resolved using the MSG_ID 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. and BOUND_MSG_ID objects of the QoS NSLP message binding mechanism.
6.1. Sender-initiated Reservation 6.1. 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(1) | | | | | RESERVE(1) | | | |
+------------->| | | | +------------->| | | |
| | RESERVE'(2) | | | | | RESERVE'(2) | | |
| +=============>| | | | +=============>| | |
| | | RESERVE'(2) | | | | | RESERVE'(2) | |
| | +=============>| | | | +=============>| |
| | RESERVE(3) | | | | RESERVE(3) | |
skipping to change at page 18, line 45 skipping to change at page 16, line 41
| | | | | | | | | |
| | | | | | | | | |
(1,5): RESERVE w/o BOUND_MSG_ID and BOUND_SESSION_ID (1,5): RESERVE w/o BOUND_MSG_ID and BOUND_SESSION_ID
(2): RESERVE' w/ MSG_ID (2): RESERVE' w/ MSG_ID
(3): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID (3): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID
Figure 8: Sender-initiated Reservation for Both End-to-end and Tunnel Figure 8: Sender-initiated Reservation for Both End-to-end and Tunnel
Signaling Signaling
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 flags of both the MSG_ID and BOUND_MSG_ID
objects in the RESERVE' and RESERVE messages (2, 3) are 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.
The first possibility is shown in the example messaging flow of The first possibility is shown in the example messaging flow of
Figure 8, where the tunnel RESERVE' message (2), aka the triggering Figure 8, where the tunnel RESERVE' message (2), aka the triggering
message in QoS NSLP message binding terms, arrives first. Since the message in QoS NSLP message binding terms, arrives first. Since the
message binding is bidirectional, Texit records the MSG_ID of the message binding is bidirectional, Texit records the MSG_ID of the
RESERVE' message (2), enques it and starts a MsgIDWait timer waiting RESERVE' message (2), enqueues it and starts a MsgIDWait timer
for the end-to-end RESERVE message (3), aka the bound signaling waiting for the end-to-end RESERVE message (3), aka the bound
message in QoS NSLP message binding terms. The timer value is set to signaling message in QoS NSLP message binding terms. The timer value
the default retransmission timeout period QOSNSLP_REQUEST_RETRY. is set to the default retransmission timeout period
When the end-to-end RESERVE message (3) arrives, Texit notices that QOSNSLP_REQUEST_RETRY. When the end-to-end RESERVE message (3)
there is an existing stored MSG_ID which matches the MSG_ID in the arrives, Texit notices that there is an existing stored MSG_ID which
BOUND_MSG_ID object of the incoming RESERVE message (3). Therefore matches the MSG_ID in the BOUND_MSG_ID object of the incoming RESERVE
the message binding condition has been satisfied. Texit resumes message (3). Therefore the message binding condition has been
processing of the tunnel RESERVE' message (2), creates the satisfied. Texit resumes processing of the tunnel RESERVE' message
reservation state for the tunnel session, and sends a tunnel (2), creates the reservation state for the tunnel session, and sends
RESPONSE' message (4) to Tentry. At the same time, Texit checks the a tunnel RESPONSE' message (4) to Tentry. At the same time, Texit
BOUND_SESSION_ID object of the end-to-end RESERVE message (3) and checks the BOUND_SESSION_ID object of the end-to-end RESERVE message
records the binding of the corresponding tunnel session with the end- (3) and records the binding of the corresponding tunnel session with
to-end session. Texit also updates the end-to-end RESERVE message the end-to-end session. Texit also updates the end-to-end RESERVE
based on the result of the tunnel session reservation, removes its message based on the result of the tunnel session reservation,
tunnel BOUND_SESSION_ID and BOUND_MSG_ID object and forwards the end- removes its tunnel BOUND_SESSION_ID and BOUND_MSG_ID object and
to-end RESERVE message (5) along the path towards the receiver. When forwards the end-to-end RESERVE message (5) along the path towards
the receiver receives the end-to-end RESERVE message (5), it sends an the receiver. When the receiver receives the end-to-end RESERVE
end-to-end RESPONSE message (6) back to the sender. message (5), it sends an end-to-end RESPONSE message (6) back to the
sender.
The second possibility is that the end-to-end RESERVE message arrives The second possibility is that the end-to-end RESERVE message arrives
before the tunnel RESERVE' message at Texit. In that case, Texit before the tunnel RESERVE' message at Texit. In that case, Texit
notices a BOUND_SESSION_ID object and a BOUND_MSG_ID object in the notices a BOUND_SESSION_ID object and a BOUND_MSG_ID object in the
end-to-end RESERVE message, but realizes that the tunnel session does end-to-end RESERVE message, but realizes that the tunnel session does
not exist yet. So Texit enques the RESERVE message and starts a not exist yet. So Texit enqueues the RESERVE message and starts a
MsgIDWait timer. The timer value is set to the default MsgIDWait timer. The timer value is set to the default
retransmission timeout period QOSNSLP_REQUEST_RETRY. When the retransmission timeout period QOSNSLP_REQUEST_RETRY. When the
corresponding tunnel RESERVE' message arrives with a MSG_ID matching corresponding tunnel RESERVE' message arrives with a MSG_ID matching
that of the outstanding BOUND_MSG_ID object, the message binding that of the outstanding BOUND_MSG_ID object, the message binding
condition is satisfied. Texit sends a tunnel RESPONSE' message back condition is satisfied. Texit sends a tunnel RESPONSE' message back
to Tentry and updates the end-to-end RESERVE message by incorporating to Tentry and updates the end-to-end RESERVE message by incorporating
the result of the tunnel session reservation, as well as removing the the result of the tunnel session reservation, as well as removing the
tunnel BOUND_SESSION_ID and BOUND_MSG_ID objects. Texit then tunnel BOUND_SESSION_ID and BOUND_MSG_ID objects. Texit then
forwards the end-to-end RESERVE message along the path towards the forwards the end-to-end RESERVE message along the path towards the
receiver. When the receiver receives the end-to-end RESERVE message, receiver. When the receiver receives the end-to-end RESERVE message,
it sends an end-to-end RESPONSE message back to the sender. it sends an end-to-end RESPONSE message back to the sender.
Yet another possibility is that the tunnel RESERVE' message arrives Yet another possibility is that the tunnel RESERVE' message arrives
at Texit first but the end-to-end RESERVE message never arrives. In at Texit first but the end-to-end RESERVE message never arrives. In
that case, the MsgIDWait timer for the queued tunnel RESERVE' message that case, the MsgIDWait timer for the queued tunnel RESERVE' message
will expire. Texit should send a tunnel RESPONSE' message back to will expire. Texit should then send a tunnel RESPONSE' message back
Tentry indicating a reservation error has occurred, and discard the to Tentry indicating a reservation error has occurred, and discard
tunnel RESERVE' message. The last possibility is that the end-to-end the tunnel RESERVE' message. The last possibility is that the end-
RESERVE message arrives at Texit first but the tunnel RESERVE' to-end RESERVE message arrives at Texit first but the tunnel RESERVE'
message never arrives. And in that case, the MsgIDWait timer for the message never arrives. In that case, the MsgIDWait timer for the
queued end-to-end RESERVE message will expire. Texit should treat queued end-to-end RESERVE message will expire. Texit should then
this situation as a local reservation failure, and according to treat this situation as a local reservation failure, and according to
[I-D.ietf-nsis-qos-nslp], Texit as a stateful QoS NSLP should [I-D.ietf-nsis-qos-nslp], Texit as a stateful QoS NSLP should
generate an end-to-end RESPONSE message indicating the RESERVE error generate an end-to-end RESPONSE message indicating RESERVE error to
to the sender. the sender.
Once the end-to-end and the tunnel QoS session have both been Once the end-to-end and the tunnel QoS session have both been
successfully created and associated, the tunnel end-points Tentry and successfully created and associated, the tunnel end-points Tentry and
Texit coordinate the signaling between the two sessions and make sure Texit coordinate the signaling between the two sessions and make sure
that adjustment or teardown of either session may trigger similar that adjustment or teardown of either session may trigger similar
actions for the other session as necessary, by invoking appropriate actions for the other session as necessary, by invoking appropriate
signaling messages. signaling messages.
6.2. Receiver-initiated Reservation 6.2. Receiver-initiated Reservation
skipping to change at page 20, line 30 skipping to change at page 19, line 6
towards Texit. This tunnel QUERY' message (2) is meant to discover towards Texit. This tunnel QUERY' message (2) is meant to discover
QoS characteristics of the tunnel path, rather than initiating an QoS characteristics of the tunnel path, rather than initiating an
actual reservation. Therefore, it includes a Request Identification actual reservation. Therefore, it includes a Request Identification
Information (RII) object but does not set the RESERVE-INIT flag. The Information (RII) object but does not set the RESERVE-INIT flag. The
tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel
for the flow identified by the tunnel Flow ID. When Texit receives for the flow identified by the tunnel Flow ID. When Texit receives
this tunnel QUERY' message (2), it replies with a corresponding this tunnel QUERY' message (2), it replies with a corresponding
tunnel RESPONSE' message (3) containing the tunnel path tunnel RESPONSE' message (3) containing the tunnel path
characteristics. After receiving the tunnel RESPONSE' message (3), characteristics. After receiving the tunnel RESPONSE' message (3),
Tentry creates the tunnel session, generates an outgoing end-to-end 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.
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 Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| QUERY(1) | | | | | QUERY(1) | | | |
+------------->| | | | +------------->| | | |
| | QUERY'(2) | | | | | QUERY'(2) | | |
| +=============>| | | | +=============>| | |
| | | QUERY'(2) | | | | | QUERY'(2) | |
| | +=============>| | | | +=============>| |
skipping to change at page 21, line 49 skipping to change at page 20, line 4
| +---------------------------->| | | +---------------------------->| |
| | | | RESPONSE(11) | | | | | RESPONSE(11) |
| | | +------------->| | | | +------------->|
| | | | | | | | | |
| | | | | | | | | |
(1,5): QUERY w/ RESERVE-INIT (2): QUERY' w/ RII (1,5): QUERY w/ RESERVE-INIT (2): QUERY' w/ RII
(4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID (4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID
(6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID (6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID
(8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID (8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID
Figure 9: Receiver-initiated Reservation for Both End-to-end and Figure 9: Receiver-initiated Reservation for Both End-to-end and
Tunnel Signaling Tunnel Signaling
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.
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 flags of the
MSG_ID and BOUND_MSG_ID objects in the RESERVE' and RESERVE messages
(7,8) are SET, indicating a bidirectional binding.
At Tentry, the tunnel RESERVE' message (7) and the end-to-end RESERVE At Tentry, the tunnel RESERVE' message (7) and the end-to-end RESERVE
message (8) could arrive in different orders. In a typical case message (8) could arrive in different orders. In a typical case
shown in Figure 9, the tunnel RESERVE' message (7) arrives first. shown in Figure 9, the tunnel RESERVE' message (7) arrives first.
Tentry records the MSG_ID of the tunnel RESERVE' message (7) and Tentry then records the MSG_ID of the tunnel RESERVE' message (7) and
starts a MsgIDWait timer. When the end-to-end RESERVE message (8) starts a MsgIDWait timer. When the end-to-end RESERVE message (8)
with the BOUND_MSG_ID object containing the same MSG_ID arrives, the with the BOUND_MSG_ID object containing the same MSG_ID arrives, the
message binding condition is satisfied. Tentry resumes processing of message binding condition is satisfied. Tentry resumes processing of
the tunnel RESERVE' message (7), creates the reservation state for the tunnel RESERVE' message (7), creates the reservation state for
the tunnel session, and sends a tunnel RESPONSE' message (9) to the tunnel session, and sends a tunnel RESPONSE' message (9) to
Texit. At the same time, Tentry creates the outgoing end-to-end Texit. At the same time, Tentry creates the outgoing end-to-end
RESERVE message (10) by incorporating results of the tunnel session RESERVE message (10) by incorporating results of the tunnel session
reservation and removing the BOUND_SESSION_ID and BOUND_MSG_ID reservation and removing the BOUND_SESSION_ID and BOUND_MSG_ID
objects, and forwards it along the path towards the sender. When the objects, and forwards it along the path towards the sender. When the
sender receives the end-to-end RESERVE message (10), it sends an end- sender receives the end-to-end RESERVE message (10), it sends an end-
skipping to change at page 22, line 48 skipping to change at page 21, line 25
chosen tunnel Flow ID, as well as the possible creation and chosen tunnel Flow ID, as well as the possible creation and
adjustment of the end-to-end and tunnel QoS sessions. Therefore, one adjustment of the end-to-end and tunnel QoS sessions. Therefore, one
NSIS-tunnel-aware end-point needs to know that the other tunnel end- NSIS-tunnel-aware end-point needs to know that the other tunnel end-
point is also NSIS-tunnel-aware before initiating this NSIS operating point is also NSIS-tunnel-aware before initiating this NSIS operating
over IP tunnel mechanism. In some cases, especially for IP tunnels over IP tunnel mechanism. In some cases, especially for IP tunnels
with pre-configured QoS sessions, an NSIS-tunnel-aware end-point can with pre-configured QoS sessions, an NSIS-tunnel-aware end-point can
learn about whether the other tunnel end-point is also NSIS-tunnel- learn about whether the other tunnel end-point is also NSIS-tunnel-
aware through pre-configuration. In other cases where such pre- aware through pre-configuration. In other cases where such pre-
configuration is not available, the initiating NSIS-tunnel-aware end- configuration is not available, the initiating NSIS-tunnel-aware end-
point may dynamically discover the other tunnel end-point's point may dynamically discover the other tunnel end-point's
capability through a QoS NSLP NODE_CAPABILITY object defined in this capability through a QoS NSLP NODE_CAPABILITY_TUNNEL object defined
section. in this section.
7.1. NODE_CAPABILITY Object Format The NODE_CAPABILITY_TUNNEL object is a zero-length object with a
The NODE_CAPABILITY object contains a standard NSLP object header standard NSLP object header as shown in Figure 10.
followed by the object value, as shown in Figure 10.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length | |A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CAPABILITY Object Format
Type: (TBD by IANA) Figure 10: NODE_CAPABILITY_TUNNEL Object Format
Length: 1, measured in units of 32-bit word Type: TBD from the shared NSLP object type space
Value: a single 'T' bit indicating the node supports the NSIS-tunnel Length: 0
handling mechanisms defined in this document. The reserved bits in
the value field can be used to signal other node 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_CAPABILITY object, the desired behavior is "Ignore". That is, NODE_CAPABILITY_TUNNEL object, the desired behavior is "Forward".
the object must be deleted and the rest of the message processed as That is, the object must be retained unchanged and forwarded as a
usual. This can be satisfied by setting 'AB' to '01'. result of message processing. This is satisfied by setting 'AB' to
'10'.
7.2. Using NODE_CAPABILITY Object
The NODE_CAPABILITY object is included in a QUERY or RESERVE message The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or
by a tunnel end-point that needs to learn about the other end-point's RESERVE' message by a tunnel end-point that needs to learn about the
NSIS tunnel handling capability. If the receiving tunnel end-point other end-point's NSIS tunnel handling capability. If the receiving
is indeed NSIS-tunnel-aware, it recognizes this object and knows that tunnel end-point is indeed NSIS-tunnel-aware, it recognizes this
the sending end-point is NSIS-tunnel-aware. The receiving tunnel object and knows that the sending end-point is NSIS-tunnel-aware.
end-point places the same object in a RESPONSE message to inform the The receiving tunnel end-point places the same object in a tunnel
sending end-point that it is also NSIS-tunnel-aware. The use of the RESPONSE' message to inform the sending end-point that it is also
NODE_CAPABILITY object in the cases of sender-initiated reservation NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in
and receiver-initiated reservation are further detailed below. the cases of sender-initiated reservation and receiver-initiated
reservation are as follows.
First, assume that the end-to-end session is sender-initiated and an First, assume that the end-to-end session is sender-initiated as in
NSIS-tunnel-aware Tentry wants to discover the NSIS-tunnel capability Figure 8, and the NSIS-tunnel-aware Tentry wants to discover the
of Texit (e.g., in Figure 8). After receiving the first end-to-end NSIS-tunnel capability of Texit. After receiving the first end-to-
RESERVE message and without initiating a tunnel RESERVE' message, end RESERVE message (1), Tentry inserts an RII object and a
Tentry inserts an RII object and a NODE_CAPABILITY object with T bit NODE_CAPABILITY_TUNNEL object into the tunnel RESERVE' message (2)
set into the end-to-end RESERVE message and sends it to Texit. When and sends it to Texit. If Texit is NSIS-tunnel-aware, it learns from
Texit receives this RESERVE message, if it is also NSIS-tunnel-aware, the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-
it learns that Tentry is NSIS-tunnel-aware and includes the same aware and includes the same object into the tunnel RESPONSE' message
object with T bit set in the following end-to-end RESPONSE message (4) sent back to Tentry.
sent back to Tentry. Otherwise, Texit ignores and deletes the
NODE_CAPABILITY object. When Tentry receives the RESPONSE message,
it knows whether Texit is NSIS-tunnel-aware by checking the T bit in
the NODE_CAPABILITY object.
Second, assume that the end-to-end session is receiver-initiated and Second, assume that the end-to-end session is receiver-initiated as
the NSIS-tunnel-aware Tentry wants to discover the NSIS-tunnel in Figure 9, and the NSIS-tunnel-aware Tentry wants to discover the
capability of Texit (e.g., in Figure 9). Upon receiving the first NSIS-tunnel capability of Texit. Upon receiving the first end-to-end
end-to-end QUERY message and without initiating a tunnel QUERY' QUERY message (1), Tentry inserts an RII object and a
message, Tentry includes an RII object and a NODE_CAPABILITY object NODE_CAPABILITY_TUNNEL object in the tunnel QUERY' message (2) and
with T bit set in the end-to-end QUERY message and sends it toward sends it toward Texit. If Texit is NSIS-tunnel-aware, it learns from
Texit. If Texit is NSIS-tunnel-aware, it learns from the the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-
NODE_CAPABILITY object that Tentry is also NSIS-tunnel-aware and aware and includes the same object tunnel RESPONSE' message (3) sent
includes the same object with T bit in the later end-to-end RESERVE to Tentry.
message sent to Tentry. Otherwise, Texit ignores and deletes the
NODE_CAPABILITY object. When Tentry receives the end-to-end RESERVE
message, it knows whether Texit is NSIS-tunnel-aware by checking the
T bit in the NODE_CAPABILITY object.
8. IANA Considerations 8. IANA Considerations
This document defines a new object type called NODE_CAPABILITY for This document defines a new object type called NODE_CAPABILITY_TUNNEL
QoS NSLP. Its Type value needs to be assigned by IANA. The object for QoS NSLP. Its Type value needs to be assigned by IANA. The
format and the setting of the extensibility bits are defined in object format and the setting of the extensibility bits are defined
Section 7. 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 Roland Bless, Hannes Tschofenig, The authors would like to thank Roland Bless, Georgios Karagiannis,
Georgios Karagiannis and other members of the NSIS working group for Jukka Manner, Martin Rohricht, Martin Stiemerling, Hannes Tschofenig,
comments to this work. 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-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
skipping to change at page 25, line 20 skipping to change at page 23, line 30
[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-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010. (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, "NSIS Protocols operation in Mobile
Mobile Environments", Environments",
draft-ietf-nsis-applicability-mobility-signaling-14 (work draft-ietf-nsis-applicability-mobility-signaling-15 (work
in progress), January 2010. in progress), March 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-23 (work in progress), draft-ietf-nsis-nslp-natfw-24 (work in progress),
February 2010. April 2010.
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
Template", draft-ietf-nsis-qspec-24 (work in progress), Template", draft-ietf-nsis-qspec-24 (work in progress),
January 2010. 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
 End of changes. 54 change blocks. 
304 lines changed or deleted 256 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/