draft-ietf-nsis-tunnel-13.txt   rfc5979.txt 
IETF Next Steps in Signaling C. Shen Internet Engineering Task Force (IETF) C. Shen
Internet-Draft H. Schulzrinne Request for Comments: 5979 H. Schulzrinne
Intended status: Experimental Columbia U. Category: Experimental Columbia U.
Expires: January 27, 2011 S. Lee ISSN: 2070-1721 S. Lee
Samsung
J. Bang J. Bang
Samsung AIT Samsung AIT
July 26, 2010 March 2011
NSIS Operation Over IP Tunnels NSIS Operation over IP Tunnels
draft-ietf-nsis-tunnel-13.txt
Abstract Abstract
NSIS Quality of Service (QoS) signaling enables applications to NSIS Quality of Service (QoS) signaling enables applications to
perform QoS reservation along a data flow path. When the data flow perform QoS reservation along a data flow path. When the data flow
path contains IP tunnel segments, NSIS QoS signaling has no effect path contains IP tunnel segments, NSIS QoS signaling has no effect
within those tunnel segments. Therefore, the resulting tunnel within those tunnel segments. Therefore, the resulting tunnel
segments could become the weakest QoS link and invalidate the QoS segments could become the weakest QoS link and invalidate the QoS
efforts in the rest of the end-to-end path. The problem with NSIS efforts in the rest of the end-to-end path. The problem with NSIS
signaling within the tunnel is caused by the tunnel encapsulation signaling within the tunnel is caused by the tunnel encapsulation
which masks packets' original IP header fields. Those original IP that masks packets' original IP header fields. Those original IP
header fields are needed to intercept NSIS signaling messages and header fields are needed to intercept NSIS signaling messages and
classify QoS data packets. This document defines a solution to this classify QoS data packets. This document defines a solution to this
problem by mapping end-to-end QoS session requests to corresponding problem by mapping end-to-end QoS session requests to corresponding
QoS sessions in the tunnel, thus extending the end-to-end QoS QoS sessions in the tunnel, thus extending the end-to-end QoS
signaling into the IP tunnel segments. signaling into the IP tunnel segments.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 27, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5979.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6 3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11 4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13 4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13
5. NSIS Operation over Tunnels with Pre-configured QoS 5. NSIS Operation over Tunnels with Preconfigured QoS Sessions . 14
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14
5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15 5.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS 6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17 6.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 17
6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 19 6.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 19
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
IP tunneling [RFC1853][RFC2003] is a technique that allows a packet IP tunneling [RFC1853] [RFC2003] is a technique that allows a packet
to be encapsulated and carried as payload within an IP packet. The to be encapsulated and carried as payload within an IP packet. The
resulting encapsulated packet is called an IP tunnel packet, and the resulting encapsulated packet is called an IP tunnel packet, and the
packet being tunneled is called the original packet. In typical packet being tunneled is called the original packet. In typical
scenarios, IP tunneling is used to exert explicit forwarding path scenarios, IP tunneling is used to exert explicit forwarding path
control (e.g., in Mobile IP [RFC3344]), facilitate the secure IP control (e.g., in Mobile IP [RFC5944]), implement secure IP data
delivery architecture (e.g., in IPsec [RFC4301]), and help packet delivery (e.g., in IPsec [RFC4301]), and help packet routing in IP
routing in IP networks of different characteristics (e.g., between networks of different characteristics (e.g., between IPv6 and IPv4
IPv6 and IPv4 networks [RFC4213]). Section 3.1 summarizes a list of networks [RFC4213]). Section 3.1 summarizes a list of common IP
common IP tunneling protocols. tunneling protocols.
This document considers the situation when the packet being tunneled This document considers the situation when the packet being tunneled
contains a Next Step In Signaling (NSIS) [RFC4080] packet. NSIS is contains a Next Step In Signaling (NSIS) [RFC4080] packet. NSIS is
an IP signaling architecture consisting of a Generic Internet an IP signaling architecture consisting of a Generic Internet
Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer for Signaling Transport (GIST) [RFC5971] sub-layer for signaling
signaling transport, and an NSIS Signaling Layer Protocol (NSLP) sub- transport, and an NSIS Signaling Layer Protocol (NSLP) sub-layer
layer customizable for different applications. We focus on the customizable for different applications. We focus on the Quality of
Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides Service (QoS) NSLP [RFC5974] which provides functionalities that
functionalities that extend those of the earlier RSVP [RFC2205] extend those of the earlier RSVP [RFC2205] signaling. In this
signaling. In this document the term "NSIS" and "NSIS QoS" are used document, the terms "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
tunnel 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
points that support this mechanism are called NSIS-tunnel-aware end- endpoints that support this mechanism are called NSIS-tunnel-aware
points. There are two main operation modes. On one hand, if the endpoints. 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 preconfigured QoS sessions, the NSIS-tunnel-aware
end-points map end-to-end QoS signaling requests directly to existing endpoints 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 preconfigured tunnel QoS sessions are
available, the NSIS-tunnel-aware end-points dynamically initiate and available, the NSIS-tunnel-aware endpoints 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 or not the
pre-configures QoS sessions or not, and which pre-configured tunnel tunnel preconfigures QoS sessions, and which preconfigured tunnel QoS
QoS sessions a particular end-to-end QoS signaling request should be sessions a particular end-to-end QoS signaling request should be
mapped to are policy issues out of scope of this document. mapped to are policy issues that are 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 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
configured QoS and dynamic QoS signaling are provided in Section 5 preconfigured QoS and dynamic QoS signaling are provided in Sections
and Section 6. Section 7 describes a method to automatically 5 and 6. Section 7 describes a method to automatically discover
discover whether a tunnel end-point node supports the NSIS-tunnel whether a tunnel endpoint 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
This document uses terminology defined in [RFC2473], This document uses terminology defined in [RFC2473], [RFC5971], and
[I-D.ietf-nsis-ntlp], and [I-D.ietf-nsis-qos-nslp]. In addition, the [RFC5974]. In addition, the following terms are used:
following terms are used:
IP Tunnel: A tunnel configured as a virtual link between two IP IP Tunnel: A tunnel that is configured as a virtual link between two
nodes, on which the encapsulating protocol is IP. IP nodes and on which the encapsulating protocol is IP.
Tunnel IP Header: The IP header prepended to the original packet Tunnel IP Header: The IP header prepended to the original packet
during encapsulation. It specifies the tunnel end-points as during encapsulation. It specifies the tunnel endpoints as source
source and destination. and destination.
Tunnel Specific Header: The header fields inserted by the Tunnel-Specific Header: The header fields inserted by the
encapsulation mechanism after the tunnel IP header and before the encapsulation mechanism after the tunnel IP header and before the
original packet. These headers may or may not exist depending on original packet. These headers may or may not exist depending on
the specific tunnel mechanism used. An example of such header the specific tunnel mechanism used. An example of such header
fields is the Encapsulation Security Payload (ESP) header for fields is the Encapsulation Security Payload (ESP) header for
IPsec [RFC4301] tunneling mode. IPsec [RFC4301] tunneling mode.
Tunnel Intermediate Node (Tmid): A node which resides in the middle Tunnel Intermediate Node (Tmid): A node that resides in the middle
of the forwarding path between the tunnel entry-point node and the of the forwarding path between the tunnel entry-point node and the
tunnel exit-point node. tunnel exit-point node.
Flow Identifier (Flow ID): The set of header fields which is used to Flow Identifier (Flow ID): The set of header fields that is used to
identify a data flow. For example, it may include flow sender and identify a data flow. For example, it may include flow sender and
receiver addresses, protocol and port numbers. receiver addresses, and protocol and port numbers.
End-to-end QoS Signaling: The signaling process that manipulates the End-to-End QoS Signaling: The signaling process that manipulates the
QoS control information in the end-to-end path from the flow QoS control information in the end-to-end path from the flow
sender to the flow receiver. When the end-to-end flow path sender to the flow receiver. When the end-to-end flow path
contains tunnel segments, this document uses end-to-end QoS contains tunnel segments, this document uses end-to-end QoS
signaling to refer specially to the QoS signaling outside the signaling to refer to the QoS signaling outside the tunnel
tunnel segments. This document uses "end-to-end QoS signaling" segments. This document uses "end-to-end QoS signaling" and "end-
and "end-to-end signaling" interchangeably. to-end signaling" interchangeably.
Tunnel QoS Signaling: The signaling process that manipulates the QoS Tunnel QoS Signaling: The signaling process that manipulates the QoS
control information in the path inside a tunnel, between the control information in the path inside a tunnel, between the
tunnel entry-point and the tunnel exit-point nodes. This document tunnel entry-point and the tunnel exit-point nodes. This document
uses "tunnel QoS signaling" and "tunnel signaling" uses "tunnel QoS signaling" and "tunnel signaling"
interchangeably. interchangeably.
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 Endpoint Node: A tunnel endpoint node that is also
also an NSIS node. an NSIS node.
NSIS-tunnel-aware Tunnel End-point Node: An NSIS-aware Tunnel End- NSIS-Tunnel-Aware Endpoint Node: An NSIS-aware tunnel endpoint node
point node which also supports the mechanism for NSIS operating that also supports the mechanism for NSIS operating over IP
over IP tunnels defined in this document. This document uses tunnels defined in this document.
"NSIS-tunnel-aware tunnel end-point node" and "NSIS-tunnel-aware
end-point node" interchangeably.
3. Problem Statement 3. Problem Statement
3.1. IP Tunneling Protocols 3.1. IP Tunneling Protocols
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
Node Node Node Node Node Node
skipping to change at page 7, line 15 skipping to change at page 6, line 43
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 - the tunnel packet flow An IP tunnel is a unidirectional mechanism - the tunnel packet flow
takes place in one direction between the IP tunnel entry-point and takes place in one direction between the IP tunnel entry-point and
exit-point nodes. Bi-directional tunneling is achieved by combining exit-point nodes. Bidirectional tunneling is achieved by combining
two unidirectional mechanisms, that is, configuring two tunnels, each two unidirectional mechanisms, that is, configuring two tunnels, each
in opposite direction to the other - the entry-point node of one in opposite direction to the other -- the entry-point node of one
tunnel is the exit-point node of the other tunnel. 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 the tunnel entry-point node as the IP source
tunnel exit-point node as IP destination address, causing the tunnel address and the tunnel exit-point node as the IP destination address,
packet to be forwarded in the tunnel. The tunnel specific header causing the tunnel packet to be forwarded in the tunnel. The tunnel-
between the tunnel IP header and the original packet is optional, specific header between the tunnel IP header and the original packet
depending on the tunneling protocol in use. is optional, depending on the tunneling protocol in 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 | Header | | | 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 [RFC4301] [RFC4303]. Among these tunneling
tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4, and IPv6GEN
IPv6GEN contain only a tunnel IP header, and no tunnel specific contain only a tunnel IP header, and no tunnel-specific header. All
header. All the other tunneling protocols have a tunnel header the other tunneling protocols have a tunnel header consisting of both
consisting of both a tunnel IP header and a tunnel specific header. a tunnel IP header and a tunnel-specific header. The tunnel-specific
The tunnel specific header is the GRE header for GRE and GREIPv4, the header is the GRE header for GRE and GREIPv4, the minimum
minimum encapsulation header for MINENC and the ESP header for IPsec encapsulation header for MINENC, and the ESP header for IPsec
tunneling mode. As will be discussed in Section 4.3, some of the tunneling mode. As will be discussed in Section 4.3, some of the
tunnel specific headers may be used to identify a flow in the tunnel tunnel-specific headers may be used to identify a flow in the tunnel
and facilitate NSIS operating over IP tunnels. and facilitate NSIS operating 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
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. that 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 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 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, nodes B, C, and D) is accomplished
Discovery of those nodes, namely nodes B, C and D is accomplished by by a separate NSIS peer discovery process (not shown above; see
a separate NSIS peer discovery process (not shown above, see [RFC5971]). The NSIS peer discovery messages contain special IP
[I-D.ietf-nsis-ntlp]). The NSIS peer discovery messages contain header and payload formats or include a Router Alert Option (RAO)
special IP header and payload format or include a Router Alert Option [RFC2113] [RFC2711]. The special formats of NSIS discovery messages
(RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery allow nodes B, C, and D to intercept the messages and subsequently
messages allow nodes 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 that are not NSIS-aware simply forward all
signaling messages like any other IP packets without additional signaling messages, as they would any other IP packets that do not
handling. require additional handling.
Node A Node B Node C Node D Node E Node A Node B Node C Node D Node E
| | | | | | | | | |
| RESERVE | | | | | RESERVE | | | |
+------------->| | | | +------------->| | | |
| | RESERVE | | | | | RESERVE | | |
| +------------->| | | | +------------->| | |
| | | RESERVE | | | | | RESERVE | |
| | +------------->| | | | +------------->| |
| | | | RESERVE | | | | | RESERVE |
skipping to change at page 9, line 39 skipping to change at page 9, line 26
| | | |<-------------+ | | | |<-------------+
| | | RESPONSE | | | | | RESPONSE | |
| | |<-------------+ | | | |<-------------+ |
| | RESPONSE | | | | | RESPONSE | | |
| |<-------------+ | | | |<-------------+ | |
| RESPONSE | | | | | RESPONSE | | | |
|<-------------+ | | | |<-------------+ | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 4: Sender-initiated NSIS QoS Signaling 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 packet classification and information includes the data Flow ID for packet classification and
the 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, and 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 endpoints 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 can still intercept and process NSIS peer discovery process, node B can still intercept and process NSIS peer
discovery messages if it recognizes them before performing tunnel discovery messages if it recognizes them before performing tunnel
encapsulation; node D can identify NSIS peer discovery messages after encapsulation; node D can identify NSIS peer discovery messages after
performing tunnel decapsulation. A tunnel intermediate node such as performing tunnel decapsulation. A tunnel intermediate node such as
node C, however, only sees the tunnel header of the packets and will node C, however, only sees the tunnel header of the packets and will
not be able to identify the original NSIS peer discovery message or not be able to identify the original NSIS peer discovery message or
insert itself in the flow signaling path. Furthermore, the Flow ID insert itself in the flow signaling path. Furthermore, the Flow ID
of the original flow is based on IP header fields of the original of the original flow is based on IP header fields of the original
packet. Those fields are also hidden in the payload of the tunnel packet. Those fields are also hidden in the payload of the tunnel
packet. So there is no way node C can classify packets belonging to packet. So, there is no way node C can classify packets belonging to
that flow in the tunnel. that flow in the tunnel.
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|
skipping to change at page 10, line 44 skipping to change at page 10, line 36
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 preconfigured 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 preconfigured 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 should limit the necessary upgrade to the tunnel Specifically, we should limit the necessary upgrade to the tunnel
end-points. endpoints.
o The mechanism should provide a method for one NSIS-tunnel-aware o The mechanism should provide a method for one NSIS-tunnel-aware
end-point to discover whether the other end-point is also NSIS- endpoint to discover whether the other endpoint is also NSIS-
tunnel-aware, when necessary. tunnel-aware, when necessary.
o The mechanism should learn from design experience of previous work
on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746], while also o The mechanism should learn from the design experience of previous
addressing the following major differences of NSIS from RSVP. related work on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746],
First, NSIS is designed as a generic framework to accommodate while also addressing the following major differences of NSIS from
various signaling application needs, and therefore is split into a RSVP. First, NSIS is designed as a generic framework to
signaling transport layer and a signaling application layer; RSVP accommodate various signaling application needs, and therefore is
does not have a layer split and is designed only for QoS split into a signaling transport layer and a signaling application
signaling. Second, NSIS QoS NSLP allows both sender-initiated and layer; RSVP does not have a layer split and is designed only for
receiver-initiated reservations; RSVP only supports receiver- QoS signaling. Second, NSIS QoS NSLP allows both sender-initiated
and 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 we only consider unidirectional flows, to accommodate flows in Since we only consider unidirectional flows, 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. An NSIS-tunnel-aware end- tunnel exit-point to be NSIS-tunnel-aware. An NSIS-tunnel-aware
point knows whether the other tunnel end-point is NSIS-tunnel-aware endpoint knows whether the other tunnel endpoint is NSIS-tunnel-aware
either through pre-configuration or through an NSIS-tunnel capability either through preconfiguration or through an NSIS-tunnel capability
discovery mechanism defined in Section 7. discovery mechanism defined in Section 7.
Tunnel end-points need to always intercept NSIS peer discovery Tunnel endpoints 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 QoS handling in the tunnel, an end-to-end QoS session To facilitate QoS handling in the tunnel, an end-to-end QoS session
is mapped to a tunnel QoS session, either pre-configured or is mapped to a tunnel QoS session, either preconfigured or
dynamically created. The tunnel session uses a tunnel Flow ID based dynamically created. The tunnel session uses a tunnel Flow ID based
on information available in the tunnel headers, thus allowing tunnel- on information available in the tunnel headers, thus allowing tunnel
intermediate nodes to classify flow packets correctly. intermediate nodes to classify flow packets correctly.
For tunnels that maintain pre-configured QoS sessions, upon receiving For tunnels that maintain preconfigured 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 endpoint 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 preconfigured tunnel session depend 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 preconfigured QoS sessions, the
NSIS-tunnel-aware end-points dynamically create and manage a NSIS-tunnel-aware endpoints dynamically create and manage a
corresponding tunnel QoS session for the end-to-end session. Since corresponding tunnel QoS session for the end-to-end session. Since
the initiation mode of both QoS sessions can be sender-initiated or the initiation mode of both QoS sessions can be sender-initiated or
receiver-initiated, to simplify the design, we require that the receiver-initiated, to simplify the design, we require that the
initiation mode of the tunnel QoS session follows that of the end-to- initiation mode of the tunnel QoS session follows that of the end-to-
end QoS session. In other words, the end-to-end QoS session and its end QoS session. In other words, the end-to-end QoS session and its
corresponding tunnel QoS session are either both sender-initiated or corresponding tunnel QoS session are either both sender-initiated or
both receiver-initiated. To keep the handling mechanism consistent both receiver-initiated. To keep the handling mechanism consistent
with the case for tunnels with pre-configured QoS sessions, the with the case for tunnels with preconfigured QoS sessions, the tunnel
tunnel entry-point always initiates the mapping between the tunnel entry-point always initiates the mapping between the tunnel session
session and the end-to-end session. and the end-to-end session.
As the mapping initiator, the tunnel entry-point records the As the mapping initiator, the tunnel entry-point records the
association between the end-to-end session and its corresponding association between the end-to-end session and its corresponding
tunnel session, both in tunnels with and without pre-configured QoS tunnel session, both in tunnels with and without preconfigured QoS
sessions. This association serves two purposes, one at the signaling sessions. This association serves two purposes, one for the
plane and the other at the data plane. For the signaling plane, the signaling plane and the other for the data plane. For the signaling
association enables the tunnel entry-point to coordinate necessary plane, the association enables the tunnel entry-point to coordinate
interaction, such as QoS adjustment in sender-initiated reservations, necessary interactions between the end-to-end and the tunnel QoS
between the end-to-end and the tunnel QoS sessions. For the data sessions, such as QoS adjustment in sender-initiated reservations.
plane, the association allows the tunnel entry-point to correctly For the data plane, the association allows the tunnel entry-point to
encapsulate data flow packets according to the chosen tunnel Flow ID. correctly encapsulate data flow packets according to the chosen
Since the tunnel Flow ID uses header fields that are visible inside tunnel Flow ID. Since the tunnel Flow ID uses header fields that are
the tunnel, the tunnel intermediate nodes can classify the data flow visible inside the tunnel, the tunnel intermediate nodes can classify
packets and apply appropriate QoS treatment. the data flow packets and apply appropriate QoS treatment.
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. For 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. For 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.
In tunnels with pre-configured QoS sessions, the tunnel exit-point In tunnels with preconfigured QoS sessions, the tunnel exit-point may
may also learn about the mapping information between the also learn about the mapping information between the corresponding
corresponding tunnel and end-to-end QoS sessions through pre- tunnel and end-to-end QoS sessions through preconfiguration as well.
configuration as well. In tunnels without pre-configured QoS In tunnels without preconfigured QoS sessions, the tunnel exit-point
sessions, the tunnel exit-point knows the mapping between the knows the mapping between the corresponding tunnel and end-to-end QoS
corresponding tunnel and end-to-end QoS sessions through the NSIS sessions through the NSIS signaling process that creates the tunnel
signaling process that creates the tunnel QoS sessions inside the QoS sessions inside the tunnel, with the help of appropriate QoS NSLP
tunnel, with the help of appropriate QoS NSLP session binding and session-binding and message-binding mechanisms.
message binding mechanisms.
One problem for NSIS operating over IP tunnels which dynamically One problem for NSIS operating over IP tunnels that 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
point has to decide whether it should proceed with the end-to-end endpoint 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. This problem can be addressed in two ways, namely session. This problem can be addressed in two ways, namely
sequential mode and parallel mode. In sequential mode, end-to-end sequential mode and parallel mode. In sequential mode, end-to-end
signaling pauses when it is waiting for results of tunnel signaling, signaling pauses while it is waiting for results of tunnel signaling,
and resumes upon receipt of the tunnel signaling outcome. In and resumes upon receipt of the tunnel signaling outcome. In
parallel mode, end-to-end signaling continues outside the tunnel parallel mode, end-to-end signaling continues outside the tunnel
while tunnel signaling is still in process and its outcome is while tunnel signaling is still in process and its outcome is
unknown. The parallel mode may lead to reduced signaling delays if unknown. The parallel mode may lead to reduced signaling delays if
the QoS resources in the tunnel path are sufficient compared to the 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 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, 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 the parallel mode may lead to wasted end-to-end signaling or may
necessitates re-negotiation after the tunnel signaling outcome necessitate renegotiation after the tunnel signaling outcome becomes
becomes available. In those cases, the signaling flow of the available. In those cases, the signaling flow of the parallel mode
parallel mode also tends to be complicated. This document adopts a also tends to be complicated. This document adopts a sequential mode
sequential mode approach for the two signaling sequences. approach for the two signaling sequences.
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 IDs 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 address 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 the o For IPsec tunnel mode (IPsec), the tunnel Flow ID contains the
tunnel 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. The source port number is dynamically chosen by the header. The source port number is dynamically chosen by the
tunnel entry-point and conveyed to the tunnel exit-point. In tunnel entry-point and conveyed to the tunnel exit-point. In
these cases, it is especially important that the tunnel exit-point these cases, it is especially important that the tunnel exit-point
understands the additional UDP encapsulation, and therefore can understands the additional UDP encapsulation, and therefore can
correctly decapsulate both the normal tunnel header and the correctly decapsulate both the normal tunnel header and the
skipping to change at page 14, line 7 skipping to change at page 13, line 49
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. The source port number is dynamically chosen by the header. The source port number is dynamically chosen by the
tunnel entry-point and conveyed to the tunnel exit-point. In tunnel entry-point and conveyed to the tunnel exit-point. In
these cases, it is especially important that the tunnel exit-point these cases, it is especially important that the tunnel exit-point
understands the additional UDP encapsulation, and therefore can understands the additional UDP encapsulation, and therefore can
correctly decapsulate both the normal tunnel header and the correctly decapsulate both the normal tunnel header and the
additional UDP header. In other words, both tunnel end-points additional UDP header. In other words, both tunnel endpoints need
need to be NSIS-tunnel-aware. to be NSIS-tunnel-aware.
The above recommendations about choosing the tunnel Flow ID apply to The above recommendations about choosing the tunnel Flow ID apply to
dynamically created QoS tunnel sessions. For pre-configured QoS dynamically created QoS tunnel sessions. For preconfigured 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 Preconfigured QoS Sessions
When tunnel QoS is managed by pre-configured QoS sessions, both the When tunnel QoS is managed by preconfigured QoS sessions, both the
tunnel entry-point and tunnel exit-point need to be configured with tunnel entry-point and tunnel exit-point need to be configured with
information about the Flow ID of the tunnel QoS session. This is to information about the Flow ID of the tunnel QoS session. This allows
enable the tunnel end-points to correctly perform matching the tunnel endpoints to correctly perform matching encapsulating and
encapsulating and decapsulating operations. The procedures of NSIS decapsulating operations. The procedures of NSIS operating over
operating over tunnels with pre-configured QoS sessions depend on tunnels with preconfigured QoS sessions depend on whether the end-to-
whether the end-to-end NSIS signaling is sender-initiated or end NSIS signaling is sender-initiated or receiver-initiated. But in
receiver-initiated. But in both cases, it is the tunnel entry-point both cases, it is the tunnel entry-point that first creates the
that first creates the mapping between a tunnel session and an end- mapping between a tunnel 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 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 the 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 preconfigured tunnel session. The mapping criteria are part of the
pre-configuration and outside the scope of this document. Tentry preconfiguration and outside the scope of this document. Tentry then
then tunnels the RESERVE message to Texit. Texit forwards the tunnels the RESERVE message to Texit. Texit forwards the RESERVE
RESERVE message to the receiver. The receiver replies with a message to the receiver. The receiver replies with a RESPONSE
RESPONSE message which arrives at Texit, Tentry and finally the message that arrives at Texit, Tentry, and finally the sender. If
sender. If the RESPONSE message that Tentry receives confirms that the RESPONSE message that Tentry receives confirms that the overall
the overall signaling is successful, Tentry starts to encapsulate all signaling is successful, Tentry starts to encapsulate all incoming
incoming packets of the data flow using the tunnel Flow ID packets of the data flow using the tunnel Flow ID corresponding to
corresponding to the mapped tunnel session. Texit knows how to the mapped tunnel session. Texit knows how to decapsulate the tunnel
decapsulate the tunnel packets because it recognizes the mapped packets because it recognizes the mapped tunnel Flow ID based on
tunnel Flow ID based on information supplied during tunnel session information supplied during tunnel session preconfiguration.
pre-configuration.
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| RESERVE | | | | | RESERVE | | | |
+------------->| | | | +------------->| | | |
| | RESERVE | | | | RESERVE | |
| +---------------------------->| | | +---------------------------->| |
| | | | RESERVE | | | | | RESERVE |
| | | +------------->| | | | +------------->|
| | | | RESPONSE | | | | | RESPONSE |
| | | |<-------------+ | | | |<-------------+
| | RESPONSE | | | | RESPONSE | |
| |<----------------------------+ | | |<----------------------------+ |
| RESPONSE | | | | | RESPONSE | | | |
|<-------------+ | | | |<-------------+ | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 6: Sender-initiated End-to-end Session with Pre-configured Figure 6: Sender-Initiated End-to-End Session with Preconfigured
Tunnel QoS Sessions 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 and tunnels the Query message to Texit. Texit configuration, then updates and tunnels the Query message to Texit.
decapsulates the QUERY message, processes it and forwards it toward Texit decapsulates the QUERY message, processes it, and forwards it
the receiver. The receiver sends back a RESERVE message passing toward the receiver. The receiver sends back a RESERVE message
through Texit and arriving at Tentry. Tentry decides on whether and passing through Texit and arriving at Tentry. Tentry decides on
how the QoS request for this end-to-end session can be mapped to a whether and how the QoS request for this end-to-end session can be
pre-configured tunnel session based on criteria outside the scope of mapped to a preconfigured tunnel session based on criteria outside
this document. Then Tentry forwards the RESERVE message towards the the scope of this document. Then, Tentry forwards the RESERVE
sender. The signaling continues until a RESPONSE message arrives at message towards the sender. The signaling continues until a RESPONSE
Tentry, Texit and finally the receiver. If the RESPONSE message that message arrives at Tentry, Texit, and finally the receiver. If the
Tentry receives confirms that the overall signaling is successful, RESPONSE message that Tentry receives confirms that the overall
Tentry starts to encapsulate all incoming packets of the data flow signaling is successful, Tentry starts to encapsulate all incoming
using the tunnel Flow ID corresponding to the mapped tunnel session. packets of the data flow using the tunnel Flow ID corresponding to
Similarly, Texit knows how to decapsulate the tunnel packets because the mapped tunnel session. Similarly, Texit knows how to decapsulate
it recognizes the mapped tunnel Flow ID based on information supplied the tunnel packets because it recognizes the mapped tunnel Flow ID
during tunnel session pre-configuration. based on information supplied during tunnel session preconfiguration.
Since separate tunnel QoS signaling is not involved in pre-configured Since separate tunnel QoS signaling is not involved in preconfigured
QoS tunnels, Figure 6 and Figure 7 make the tunnel look like a single QoS tunnels, Figures 6 and 7 make the tunnel look like 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 the NSIS-tunnel-related functionalities described above, including
on the end-to-end NSIS signaling messages based on tunnel QoS status, acting on the end-to-end NSIS signaling messages based on tunnel QoS
mapping end-to-end and tunnel QoS sessions, and correctly status, 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.
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| QUERY | | | | | QUERY | | | |
+------------->| | | | +------------->| | | |
| | QUERY | | | | QUERY | |
| +---------------------------->| | | +---------------------------->| |
skipping to change at page 16, line 32 skipping to change at page 16, line 32
|<-------------+ | | | |<-------------+ | | |
| 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 Preconfigured
Tunnel QoS Sessions Tunnel QoS Sessions
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 preconfigured 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 distinguish themselves NSIS peer discovery messages inside the tunnel distinguish themselves
using the tunnel header fields, which solves the problem for tunnel using the tunnel header fields, which solves the problem for tunnel
intermediate NSIS nodes to intercept signaling messages. intermediate NSIS nodes to intercept signaling messages.
When tunnel end-points dynamically create tunnel QoS sessions, the When tunnel endpoints 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 exit-point of the binding between the corresponding tunnel the exit-point of the binding between the corresponding tunnel
session and end-to-end session 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 are 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 Figure 8 shows the typical messaging sequence of how NSIS operates
over IP tunnels when both end-to-end session and tunnel session are over IP tunnels when both the end-to-end session and tunnel session
sender-initiated. Tunnel signaling messages are distinguished from are sender-initiated. Tunnel signaling messages are distinguished
end-to-end messages by a prime symbol after the message name. The from end-to-end messages by a prime symbol after the message name.
sender first sends an end-to-end RESERVE message (1) which arrives at The sender first sends an end-to-end RESERVE message (1) that arrives
Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel at Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel
session and associates the end-to-end session with the tunnel session, and associates the end-to-end session with the tunnel
session. Tentry then sends a tunnel RESERVE' message (2) matching session. Tentry then sends a tunnel RESERVE' message (2) matching
the request of the end-to-end session towards Texit to reserve tunnel the request of the end-to-end session towards Texit to reserve tunnel
resources. This RESERVE' message (2) includes a MSG_ID object which resources. This RESERVE' message (2) includes a MSG-ID object that
contains a randomly generated 128-bit MSG_ID. Meanwhile, Tentry 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 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 BOUND-SESSION-ID object containing the SESSION-ID of the tunnel
session into the original RESERVE message, and sends this RESERVE session into the original RESERVE message, and sends this RESERVE
message (3) towards Texit using normal tunnel encapsulation. The message (3) towards Texit using normal tunnel encapsulation. The
Message_Binding_Type flags of both the MSG_ID and BOUND_MSG_ID Message_Binding_Type flags of both the MSG-ID and BOUND-MSG-ID
objects in the RESERVE' and RESERVE messages (2, 3) are SET, objects in the RESERVE' and RESERVE messages (2, 3) are SET,
indicating a bidirectional binding. The tunnel RESERVE' message (2) indicating a bidirectional binding. The tunnel RESERVE' message (2)
is processed hop-by-hop inside the tunnel for the flow identified by 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) the chosen tunnel Flow ID, while the end-to-end RESERVE message (3)
passes through the tunnel intermediate nodes (Tmid) just like other passes through the tunnel intermediate nodes (Tmid) just like other
tunneled packets. These two messages could arrive at Texit in tunneled packets. These two messages could arrive at Texit in
different orders, and the reaction of Texit in these different different orders, and the reaction of Texit in these different
situations should combine the tunnel QoS message processing rules situations should combine the tunnel QoS message processing rules
with the QoS NSLP processing principles for message binding with the QoS NSLP processing principles for message binding
[I-D.ietf-nsis-qos-nslp], as illustrated below. [RFC5974], 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), also known as the Figure 8, where the tunnel RESERVE' message (2), also known as the
triggering message in QoS NSLP message binding terms, arrives first. triggering message in QoS NSLP message binding terms, arrives first.
Since the message binding is bidirectional, Texit records the MSG_ID Since the message binding is bidirectional, Texit records the MSG-ID
of the RESERVE' message (2), enqueues it and starts a MsgIDWait timer of the RESERVE' message (2), enqueues it and starts a MsgIDWait timer
waiting for the end-to-end RESERVE message (3), also known as the waiting for the end-to-end RESERVE message (3), also known as the
bound signaling message in QoS NSLP message binding terms. The timer bound signaling message in QoS NSLP message binding terms. The timer
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| RESERVE(1) | | | | | RESERVE(1) | | | |
+------------->| | | | +------------->| | | |
| | RESERVE'(2) | | | | | RESERVE'(2) | | |
| +=============>| | | | +=============>| | |
skipping to change at page 18, line 30 skipping to change at page 18, line 30
| | | +------------->| | | | +------------->|
| | | | RESPONSE(6) | | | | | RESPONSE(6) |
| | | |<-------------+ | | | |<-------------+
| | RESPONSE(6) | | | | RESPONSE(6) | |
| |<----------------------------+ | | |<----------------------------+ |
| RESPONSE(6) | | | | | RESPONSE(6) | | | |
|<-------------+ | | | |<-------------+ | | |
| | | | | | | | | |
| | | | | | | | | |
(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
value is set to the default retransmission timeout period value is set to the default retransmission timeout period
QOSNSLP_REQUEST_RETRY. When the end-to-end RESERVE message (3) QOSNSLP_REQUEST_RETRY. When the end-to-end RESERVE message (3)
arrives, Texit notices that there is an existing stored MSG_ID which arrives, Texit notices that there is an existing stored MSG-ID which
matches the MSG_ID in the BOUND_MSG_ID object of the incoming RESERVE matches the MSG-ID in the BOUND-MSG-ID object of the incoming RESERVE
message (3). Therefore the message binding condition has been message (3). Therefore, the message binding condition has been
satisfied. Texit resumes processing of the tunnel RESERVE' message satisfied. Texit resumes processing of the tunnel RESERVE' message
(2), creates the reservation state for the tunnel session, and sends (2), creates the reservation state for the tunnel session, and sends
a tunnel RESPONSE' message (4) to Tentry. At the same time, Texit 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 checks the BOUND-SESSION-ID object of the end-to-end RESERVE message
(3) and records the binding of the corresponding tunnel session with (3) and records the binding of the corresponding tunnel session with
the end-to-end session. Texit also updates the end-to-end RESERVE the end-to-end session. Texit also updates the end-to-end RESERVE
message based on the result of the tunnel session reservation, message based on the result of the tunnel session reservation,
removes its tunnel BOUND_SESSION_ID and BOUND_MSG_ID object and removes its tunnel BOUND-SESSION-ID and BOUND-MSG-ID object and
forwards the end-to-end RESERVE message (5) along the path towards forwards the end-to-end RESERVE message (5) along the path towards
the receiver. When the receiver receives the end-to-end RESERVE 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 message (5), it sends an end-to-end RESPONSE message (6) back to the
sender. 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 enqueues 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 then send a tunnel RESPONSE' message back will expire. Texit should then send a tunnel RESPONSE' message back
to Tentry indicating a reservation error has occurred, and discard to Tentry indicating a reservation error has occurred, and discard
the tunnel RESERVE' message. The last possibility is that the end- the tunnel RESERVE' message. The last possibility is that the end-
to-end RESERVE message arrives at Texit first but the tunnel RESERVE' to-end RESERVE message arrives at Texit first, but the tunnel
message never arrives. In that case, the MsgIDWait timer for the RESERVE' message never arrives. In that case, the MsgIDWait timer
queued end-to-end RESERVE message will expire. Texit should then for the queued end-to-end RESERVE message will expire. Texit should
treat this situation as a local reservation failure, and according to then treat this situation as a local reservation failure, and
[I-D.ietf-nsis-qos-nslp], Texit as a stateful QoS NSLP should according to [RFC5974], Texit as a stateful QoS NSLP should generate
generate an end-to-end RESPONSE message indicating RESERVE error to an end-to-end RESPONSE message indicating RESERVE error to the
the sender. 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 endpoints 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
Figure 9 shows the typical messaging sequence of how NSIS signaling Figure 9 shows the typical messaging sequence of how NSIS signaling
operates over IP tunnels when both end-to-end and tunnel sessions are operates over IP tunnels when both end-to-end and tunnel sessions are
receiver-initiated. Upon receiving an end-to-end QUERY message (1) receiver-initiated. Upon receiving an end-to-end QUERY message (1)
from the sender, Tentry chooses the tunnel Flow ID and sends a tunnel from the sender, Tentry chooses the tunnel Flow ID and sends a tunnel
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| QUERY(1) | | | | | QUERY(1) | | | |
+------------->| | | | +------------->| | | |
skipping to change at page 20, line 43 skipping to change at page 20, line 43
| RESERVE(10) | | | | | RESERVE(10) | | | |
|<-------------+ | | | |<-------------+ | | |
| RESPONSE(11) | | | | | RESPONSE(11) | | | |
+------------->| | | | +------------->| | | |
| | RESPONSE(11) | | | | RESPONSE(11) | |
| +---------------------------->| | | +---------------------------->| |
| | | | RESPONSE(11) | | | | | RESPONSE(11) |
| | | +------------->| | | | +------------->|
| | | | | | | | | |
| | | | | | | | | |
(1), (5): QUERY w/ RESERVE-INIT
(2): QUERY' w/ RII
(4): QUERY w/ RESERVE-INIT and BOUND-SESSION-ID
(6), (10): RESERVE w/o BOUND-SESSION-ID
(7): RESERVE' w/ MSG-ID
(8): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
(1,5): QUERY w/ RESERVE-INIT (2): QUERY' w/ RII Figure 9: Receiver-Initiated Reservation for Both End-to-end and
(4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID
(6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID
(8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID
Figure 9: Receiver-initiated Reservation for Both End-to-end and
Tunnel Signaling Tunnel Signaling
QUERY' message (2) matching the request of the end-to-end session QUERY' message (2) matching the request of the end-to-end session
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 initiate 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, QUERY message (4) considering the tunnel path characteristics,
appends a tunnel BOUND_SESSION_ID object containing the tunnel appends a tunnel BOUND-SESSION-ID object containing the tunnel
Session ID, and sends it toward Texit using normal tunnel SESSION-ID, and sends it toward Texit using normal tunnel
encapsulation. The end-to-end QUERY message (4) passes along tunnel encapsulation. The end-to-end QUERY message (4) passes along tunnel
intermediate nodes like other tunneled packets. Upon receiving this intermediate nodes like other tunneled packets. Upon receiving this
end-to-end QUERY message (4), Texit notices the tunnel session end-to-end QUERY message (4), Texit notices the tunnel session
binding and creates the tunnel session state, removes the tunnel binding, creates the tunnel session state, removes the tunnel BOUND-
BOUND_SESSION_ID object and forwards the end-to-end QUERY message (5) SESSION-ID object, and forwards the end-to-end QUERY message (5)
further along the path. further along the path.
The end-to-end QUERY message (5) arrives at the receiver and triggers The end-to-end QUERY message (5) arrives at the receiver and triggers
a RESERVE message (6). When Texit receives the RESERVE message (6), a RESERVE message (6). When Texit receives the RESERVE message (6),
it notices that the session is bound to a receiver-initiated tunnel it notices that the session is bound to a receiver-initiated tunnel
session. Therefore, Texit triggers a RESERVE' message (7) toward session. Therefore, Texit triggers a RESERVE' message (7) toward
Tentry for the tunnel session reservation. This tunnel RESERVE' Tentry for the tunnel session reservation. This tunnel RESERVE'
message (7) includes a randomly generated 128-bit MSG_ID. Meanwhile, 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 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 BOUND-SESSION-ID object containing the tunnel SESSION-ID into the
end-to-end RESERVE message (8), and sends it towards Tentry using end-to-end RESERVE message (8), and sends it towards Tentry using
normal tunnel encapsulation. The Message_Binding_Type flags of the normal tunnel encapsulation. The Message_Binding_Type flags of the
MSG_ID and BOUND_MSG_ID objects in the RESERVE' and RESERVE messages MSG-ID and BOUND-MSG-ID objects in the RESERVE' and RESERVE messages
(7,8) are SET, indicating a bidirectional binding. (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 either order. In a typical case shown in
shown in Figure 9, the tunnel RESERVE' message (7) arrives first. Figure 9, the tunnel RESERVE' message (7) arrives first. Tentry then
Tentry then records the MSG_ID of the tunnel RESERVE' message (7) and records the MSG-ID of the tunnel RESERVE' message (7) and starts a
starts a MsgIDWait timer. When the end-to-end RESERVE message (8) MsgIDWait timer. When the end-to-end RESERVE message (8) with the
with the BOUND_MSG_ID object containing the same MSG_ID arrives, the BOUND-MSG-ID object containing the same MSG-ID arrives, the message
message binding condition is satisfied. Tentry resumes processing of binding condition is satisfied. Tentry resumes processing of the
the tunnel RESERVE' message (7), creates the reservation state for tunnel RESERVE' message (7), creates the reservation state for the
the tunnel session, and sends a tunnel RESPONSE' message (9) to tunnel session, and sends a tunnel RESPONSE' message (9) to Texit.
Texit. At the same time, Tentry creates the outgoing end-to-end At the same time, Tentry creates the outgoing end-to-end RESERVE
RESERVE message (10) by incorporating results of the tunnel session 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-
to-end RESPONSE message (11) back to the receiver. to-end RESPONSE message (11) back to the receiver.
If the end-to-end RESERVE message arrives before the tunnel RESERVE' If the end-to-end RESERVE message arrives before the tunnel RESERVE'
message at Tentry, or either of the two messages fails to arrive at message at Tentry, or either of the two messages fails to arrive at
Tentry, the processing rules at Tentry is similar to those of Texit Tentry, the processing rules at Tentry are similar to those of Texit
in the same situation discussed in Section 6.1. in the situation discussed in Section 6.1.
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 endpoints Tentry and
Texit coordinate the signaling between the two sessions and make sure Texit coordinate the signaling between the two sessions and make sure
that adjustment or teardown of either session can trigger similar that adjustment or teardown of either session can trigger similar
actions for the other session as necessary, by invoking appropriate actions for the other session as necessary, by invoking appropriate
signaling messages. signaling messages.
7. NSIS-Tunnel Signaling Capability Discovery 7. NSIS-Tunnel Signaling Capability Discovery
The mechanism of NSIS operating over IP tunnels requires the The mechanism of NSIS operating over IP tunnels requires the
coordination of both tunnel end-points in tasks such as special coordination of both tunnel endpoints in tasks such as special
encapsulation and decapsulation of data flow packets according to the encapsulation and decapsulation of data flow packets according to the
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 endpoint needs to know that the other tunnel
point is also NSIS-tunnel-aware before initiating this NSIS operating endpoint is also NSIS-tunnel-aware before initiating this mechanism
over IP tunnel mechanism. In some cases, especially for IP tunnels of NSIS operating over IP tunnels. In some cases, especially for IP
with pre-configured QoS sessions, an NSIS-tunnel-aware end-point can tunnels with preconfigured QoS sessions, an NSIS-tunnel-aware
learn about whether the other tunnel end-point is also NSIS-tunnel- endpoint can learn about whether the other tunnel endpoint is also
aware through pre-configuration. In other cases where such pre- NSIS-tunnel-aware through preconfiguration. In other cases where
configuration is not available, the initiating NSIS-tunnel-aware end- such preconfiguration is not available, the initiating NSIS-tunnel-
point may dynamically discover the other tunnel end-point's aware endpoint may dynamically discover the other tunnel endpoint's
capability through a QoS NSLP NODE_CAPABILITY_TUNNEL object defined capability through a QoS NSLP NODE_CAPABILITY_TUNNEL object defined
in this section. in this section.
The NODE_CAPABILITY_TUNNEL object is a zero-length object with a The NODE_CAPABILITY_TUNNEL object is a zero-length object with a
standard NSLP object header as shown in Figure 10. standard NSLP object header 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CAPABILITY_TUNNEL Object Format Figure 10: NODE_CAPABILITY_TUNNEL Object Format
Type: TBD from the shared NSLP object type space Type: NODE_CAPABILITY_TUNNEL (0x015) from the shared NSLP object type
space
Length: 0 Length: 0
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_TUNNEL object, the desired behavior is "Forward". NODE_CAPABILITY_TUNNEL object, the desired behavior is "Forward".
That is, the object must be retained unchanged and forwarded as a That is, the object must be retained unchanged and forwarded as a
result of message processing. This is satisfied by setting 'AB' to result of message processing. This is satisfied by setting 'AB' to
'10'. '10'.
The 'r' bit stands for 'reserved'. The 'r' bit stands for 'reserved'.
The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or
RESERVE' message by a tunnel end-point that needs to learn about the RESERVE' message by a tunnel endpoint that needs to learn about the
other end-point's NSIS tunnel handling capability. If the receiving other endpoint's capability for NSIS tunnel handling. If the
tunnel end-point is indeed NSIS-tunnel-aware, it recognizes this receiving tunnel endpoint is indeed NSIS-tunnel-aware, it recognizes
object and knows that the sending end-point is NSIS-tunnel-aware. this object and knows that the sending endpoint is NSIS-tunnel-aware.
The receiving tunnel end-point places the same object in a tunnel The receiving tunnel endpoint places the same object in a tunnel
RESPONSE' message to inform the sending end-point that it is also RESPONSE' message to inform the sending endpoint that it is also
NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in
the cases of sender-initiated reservation and receiver-initiated the cases of sender-initiated reservation and receiver-initiated
reservation are as follows. reservation are as follows.
First, assume that the end-to-end session is sender-initiated as in First, assume that the end-to-end session is sender-initiated as in
Figure 8, and the NSIS-tunnel-aware Tentry wants to discover the Figure 8, and the NSIS-tunnel-aware Tentry wants to discover the NSIS
NSIS-tunnel capability of Texit. After receiving the first end-to- tunnel capability of Texit. After receiving the first end-to-end
end RESERVE message (1), Tentry inserts an RII object and a RESERVE message (1), Tentry inserts an RII object and a
NODE_CAPABILITY_TUNNEL object into the tunnel RESERVE' message (2) NODE_CAPABILITY_TUNNEL object into the tunnel RESERVE' message (2)
and sends it to Texit. If Texit is NSIS-tunnel-aware, it learns from and sends it to Texit. If Texit is NSIS-tunnel-aware, it learns from
the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel- the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-
aware and includes the same object into the tunnel RESPONSE' message aware and includes the same object into the tunnel RESPONSE' message
(4) sent back to Tentry. (4) sent back to Tentry.
Second, assume that the end-to-end session is receiver-initiated as Second, assume that the end-to-end session is receiver-initiated as
in Figure 9, and the NSIS-tunnel-aware Tentry wants to discover the in Figure 9, and the NSIS-tunnel-aware Tentry wants to discover the
NSIS-tunnel capability of Texit. Upon receiving the first end-to-end NSIS tunnel capability of Texit. Upon receiving the first end-to-end
QUERY message (1), Tentry inserts an RII object and a QUERY message (1), Tentry inserts an RII object and a
NODE_CAPABILITY_TUNNEL object in the tunnel QUERY' message (2) and NODE_CAPABILITY_TUNNEL object in the tunnel QUERY' message (2) and
sends it toward Texit. If Texit is NSIS-tunnel-aware, it learns from sends it toward Texit. If Texit is NSIS-tunnel-aware, it learns from
the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel- the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel-
aware and includes the same object tunnel RESPONSE' message (3) sent aware and includes the same object tunnel RESPONSE' message (3) sent
to Tentry. to Tentry.
8. IANA Considerations 8. IANA Considerations
This document defines a new object type called NODE_CAPABILITY_TUNNEL This document defines a new object type called NODE_CAPABILITY_TUNNEL
for QoS NSLP. Its Type value needs to be assigned by IANA. The for QoS NSLP. Its Type value (0x015) has been assigned by IANA. The
object format and the setting of the extensibility bits are defined object format and the setting of the extensibility bits are defined
in Section 7. in Section 7.
9. Security Considerations 9. Security Considerations
There are two IPsec related security considerations about using this This NSIS and IP tunnel interoperation mechanism has two IPsec-
NSIS and IP tunnel interoperation mechanism. First, NSIS messages related security implications. First, NSIS messages may require per-
may require per-hop processing within the IPsec tunnel, and that is hop processing within the IPsec tunnel, and that is potentially
potentially incompatible with IPsec. A similar problem exists for incompatible with IPsec. A similar problem exists for RSVP
RSVP interacting with IPsec, when the Router Alert option is used interacting with IPsec, when the Router Alert option is used
(Section A.1 of RFC4302 [RFC4302]). If this mechanism is indeed used (Appendix A.1 of RFC 4302 [RFC4302]). If this mechanism is indeed
for NSIS and IPsec tunnels, a so-called covert channel could exist used for NSIS and IPsec tunnels, a so-called covert channel could
where someone can create spurious NSIS signaling flows within the exist where someone can create spurious NSIS signaling flows within
protected network in order to create signaling in the outside the protected network in order to create signaling in the outside
network, which then someone else is monitoring. For highly secure network, which then someone else is monitoring. For highly secure
networks, this would be seen as a way to smuggle information out of networks, this would be seen as a way to smuggle information out of
the network, and therefore this channel will need to be rate-limited. the network, and therefore this channel will need to be rate-limited.
A similar covert channel rate-limit problem exists for using A similar covert channel rate-limit problem exists for using
Differentiated Service (DS) or Explicit Congestion Notification (ECN) Differentiated Services (DS) or Explicit Congestion Notification
fields with IPsec (Section 5.1.2 of RFC4301 [RFC4301]). (ECN) fields with IPsec (Section 5.1.2 of RFC 4301 [RFC4301]).
Second, since the NSIS-tunnel-aware end-point is responsible for Second, since the NSIS-tunnel-aware endpoint is responsible for
adapting changes between the NSIS signaling both inside and outside adapting changes between the NSIS signaling both inside and outside
the tunnel, there could be additional risks for an IPsec end-point the tunnel, there could be additional risks for an IPsec endpoint
which is also an NSIS-tunnel-aware end-point. For example, security that is also an NSIS-tunnel-aware endpoint. For example, security
vulnerability (e.g., buffer overflow) on the NSIS stack of that IPsec vulnerability (e.g., buffer overflow) on the NSIS stack of that IPsec
tunnel end-point may be exposed to the unprotected outside network. tunnel endpoint may be exposed to the unprotected outside network.
Nevertheless, it should also be noted that if any node along the Nevertheless, it should also be noted that if any node along the
signaling path is compromised, the whole end-to-end QoS signaling signaling path is compromised, the whole end-to-end QoS signaling
could be affected, whether the end-to-end path includes an IPsec could be affected, whether or not the end-to-end path includes an
tunnel or not. IPsec tunnel.
Several other documents discussed security issues for NSIS. General Several other documents discuss security issues for NSIS. General
threats for NSIS can be found in [RFC4081]. Security considerations threats for NSIS can be found in [RFC4081]. Security considerations
for NSIS NTLP and QoS NSLP are discussed in [I-D.ietf-nsis-ntlp] and for NSIS NTLP and QoS NSLP are discussed in [RFC5971] and [RFC5974],
[I-D.ietf-nsis-qos-nslp], respectively. respectively.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Roland Bless, Francis Dupont, Lars The authors would like to thank Roland Bless, Francis Dupont, Lars
Eggert, Adrian Farrel, Russ Housley, Georgios Karagiannis, Jukka Eggert, Adrian Farrel, Russ Housley, Georgios Karagiannis, Jukka
Manner, Martin Rohricht, Peter Saint-Andre, Martin Stiemerling, Manner, Martin Rohricht, Peter Saint-Andre, Martin Stiemerling,
Hannes Tschofenig, and other members of the NSIS working group for Hannes Tschofenig, and other members of the NSIS working group for
comments. Thanks to Yaron Sheffer for pointing out the IPsec related comments. Thanks to Yaron Sheffer for pointing out the IPsec-related
security considerations. security considerations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997. February 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,
skipping to change at page 25, line 41 skipping to change at page 25, line 31
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004. "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005. RFC 4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, October 2010.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
11.2. Informative References 11.2. Informative References
[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.
skipping to change at page 26, line 17 skipping to change at page 26, line 16
October 1996. October 1996.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
Authors' Addresses Authors' Addresses
Charles Shen Charles Shen
Columbia University Columbia University
Department of Computer Science Department of Computer Science
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
Phone: +1 212 854 3109 Phone: +1 212 854 3109
Email: charles@cs.columbia.edu EMail: charles@cs.columbia.edu
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu EMail: hgs@cs.columbia.edu
Sung-Hyuck Lee Sung-Hyuck Lee
SAMSUNG Advanced Institute of Technology Convergence Technologies & Standardization Lab
San 14-1, Nongseo-ri, Giheung-eup Samsung Information System America, INC.
Yongin-si, Gyeonggi-do 449-712 95 West Plumeria Drive
South Korea San Jose, CA 95134
USA
Phone: +82 31 280 9552 Phone: 1-408-544-5809
Email: starsu.lee@samsung.com EMail: sung1.lee@samsung.com
Jong Ho Bang Jong Ho Bang
SAMSUNG Advanced Institute of Technology SAMSUNG Advanced Institute of Technology
San 14-1, Nongseo-ri, Giheung-eup San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712 Yongin-si, Gyeonggi-do 449-712
South Korea South Korea
Phone: +82 31 280 9585 Phone: +82 31 280 9585
Email: jh0278.bang@samsung.com EMail: jh0278.bang@samsung.com
 End of changes. 149 change blocks. 
364 lines changed or deleted 362 lines changed or added

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