draft-ietf-nsis-tunnel-12.txt   draft-ietf-nsis-tunnel-13.txt 
IETF Next Steps in Signaling C. Shen IETF Next Steps in Signaling C. Shen
Internet-Draft H. Schulzrinne Internet-Draft H. Schulzrinne
Intended status: Experimental Columbia U. Intended status: Experimental Columbia U.
Expires: January 7, 2011 S. Lee Expires: January 27, 2011 S. Lee
J. Bang J. Bang
Samsung AIT Samsung AIT
July 6, 2010 July 26, 2010
NSIS Operation Over IP Tunnels NSIS Operation Over IP Tunnels
draft-ietf-nsis-tunnel-12.txt 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 and the resulting tunnel segments could within those tunnel segments. Therefore, the resulting tunnel
become the weakest QoS link which may invalidate the QoS efforts in segments could become the weakest QoS link and invalidate the QoS
the rest of the end-to-end path. The problem with NSIS signaling efforts in the rest of the end-to-end path. The problem with NSIS
within the tunnel is caused by the tunnel encapsulation which masks signaling within the tunnel is caused by the tunnel encapsulation
packets' original IP header fields. Those original IP header fields which masks packets' original IP header fields. Those original IP
are needed to intercept NSIS signaling messages and classify QoS data header fields are needed to intercept NSIS signaling messages and
packets. This document defines a solution to this problem by mapping classify QoS data packets. This document defines a solution to this
end-to-end QoS session requests to corresponding QoS sessions in the problem by mapping end-to-end QoS session requests to corresponding
tunnel, thus extending the end-to-end QoS signaling into the IP QoS sessions in the tunnel, thus extending the end-to-end QoS
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 This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2011. This Internet-Draft will expire on January 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
IP tunneling is a technique that allows a packet to be encapsulated IP tunneling [RFC1853][RFC2003] is a technique that allows a packet
and carried as payload within an IP packet. The resulting to be encapsulated and carried as payload within an IP packet. The
encapsulated packet is called an IP tunnel packet, and the packet resulting encapsulated packet is called an IP tunnel packet, and the
being tunneled is called the original packet. In typical scenarios, packet being tunneled is called the original packet. In typical
IP tunneling is used to exert explicit forwarding path control (e.g., scenarios, IP tunneling is used to exert explicit forwarding path
in Mobile IP [RFC3344]), facilitate the secure IP delivery control (e.g., in Mobile IP [RFC3344]), facilitate the secure IP
architecture (e.g., in IPsec [RFC4301]), and help packet routing in delivery architecture (e.g., in IPsec [RFC4301]), and help packet
IP networks of different characteristics (e.g., between IPv6 and IPv4 routing in IP networks of different characteristics (e.g., between
networks [RFC4213]). IPv6 and IPv4 networks [RFC4213]). Section 3.1 summarizes a list of
common IP 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] message. NSIS is contains a Next Step In Signaling (NSIS) [RFC4080] packet. NSIS is
an IP network layer signaling architecture consisting of a Generic an IP signaling architecture consisting of a Generic Internet
Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer for
for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) signaling transport, and an NSIS Signaling Layer Protocol (NSLP) sub-
sub-layer customizable for different applications. We focus on the layer customizable for different applications. We focus on the
Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides
functionalities that extend those of the earlier RSVP [RFC2205] functionalities that extend those of the earlier RSVP [RFC2205]
signaling. In this document the term "NSIS" and "NSIS QoS" are used signaling. In this document the term "NSIS" and "NSIS QoS" are used
interchangeably. interchangeably.
Without additional efforts, NSIS signaling does not work within IP Without additional efforts, NSIS signaling does not work within IP
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
skipping to change at page 5, line 31 skipping to change at page 5, line 33
IP Tunnel: A tunnel configured as a virtual link between two IP IP Tunnel: A tunnel configured as a virtual link between two IP
nodes, on which the encapsulating protocol is IP. nodes, 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 end-points as
source and destination. source 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. the specific tunnel mechanism used. An example of such header
fields is the Encapsulation Security Payload (ESP) header for
IPsec [RFC4301] tunneling mode.
Tunnel Intermediate Node (Tmid): A node which resides in the middle Tunnel Intermediate Node (Tmid): A node which 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 which is used to
identify a [data] flow. For example, it may include flow sender identify a data flow. For example, it may include flow sender and
and receiver addresses, protocol and port numbers. receiver addresses, 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 specially to the QoS signaling outside the
tunnel segments. This document uses "end-to-end QoS signaling" tunnel segments. This document uses "end-to-end QoS signaling"
and "end-to-end signaling" interchangeably. and "end-to-end signaling" interchangeably.
Tunnel QoS Signaling: The signaling process that manipulates the QoS Tunnel QoS Signaling: The signaling process that manipulates the QoS
skipping to change at page 6, line 38 skipping to change at page 6, line 41
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Original Original Original Original
Packet Packet Packet Packet
Source Destination Source Destination
Node Node Node Node
Figure 1: IP Tunnel Figure 1: IP Tunnel
The following definition of IP tunneling is derived from [RFC2473] The following description about IP tunneling is derived from
and adapted for both IPv4 and IPv6. [RFC2473] and adapted for both IPv4 and IPv6.
IP tunneling (Figure 1) is a technique for establishing a "virtual IP tunneling (Figure 1) is a technique for establishing a "virtual
link" between two IP nodes for transmitting data packets as payloads link" between two IP nodes for transmitting data packets as payloads
of IP packets. From the point of view of the two nodes, this of IP packets. From the point of view of the two nodes, this
"virtual link", called an IP tunnel, appears as a point-to-point link "virtual link", called an IP tunnel, appears as a point-to-point link
on which IP acts like a link-layer protocol. The two IP nodes play on which IP acts like a link-layer protocol. The two IP nodes play
specific roles. One node encapsulates original packets received from specific roles. One node encapsulates original packets received from
other nodes or from itself and forwards the resulting tunnel packets other nodes or from itself and forwards the resulting tunnel packets
through the tunnel. The other node decapsulates the received tunnel through the tunnel. The other node decapsulates the received tunnel
packets and forwards the resulting original packets towards their packets and forwards the resulting original packets towards their
destinations, possibly itself. The encapsulating node is called the destinations, possibly itself. The encapsulating node is called the
tunnel entry-point node (Tentry), and it is the source of the tunnel tunnel entry-point node (Tentry), and it is the source of the tunnel
packets. The decapsulating node is called the tunnel exit-point node packets. The decapsulating node is called the tunnel exit-point node
(Texit), and it is the destination of the tunnel packets. (Texit), and it is the destination of the tunnel packets.
An IP tunnel is a unidirectional mechanism - tunnel packet flow takes An IP tunnel is a unidirectional mechanism - the tunnel packet flow
place in one direction between the IP tunnel entry-point and exit- takes place in one direction between the IP tunnel entry-point and
point nodes. Bi-directional tunneling is achieved by combining two exit-point nodes. Bi-directional tunneling is achieved by combining
unidirectional mechanisms, that is, configuring two tunnels, each in two unidirectional mechanisms, that is, configuring two tunnels, each
opposite direction to the other - the entry-point node of one tunnel in opposite direction to the other - the entry-point node of one
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 tunnel entry-point node as IP source address and
tunnel exit-point node as IP destination address, causing the tunnel tunnel exit-point node as IP destination address, causing the tunnel
packet to be forwarded in the tunnel. The tunnel specific header packet to be forwarded in the tunnel. The tunnel specific header
between the tunnel IP header and the original packet is optional, between the tunnel IP header and the original packet is optional,
depending on the tunneling protocol in use. depending on the tunneling protocol in use.
skipping to change at page 8, line 12 skipping to change at page 8, line 15
over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP
(IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP
(MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213],
Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473]
and IPsec tunneling mode (IPsec) [RFC4301][RFC4303]. Among these and IPsec tunneling mode (IPsec) [RFC4301][RFC4303]. Among these
tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and
IPv6GEN contain only a tunnel IP header, and no tunnel specific IPv6GEN contain only a tunnel IP header, and no tunnel specific
header. All the other tunneling protocols have a tunnel header header. All the other tunneling protocols have a tunnel header
consisting of both a tunnel IP header and a tunnel specific header. consisting of both a tunnel IP header and a tunnel specific header.
The tunnel specific header is the GRE header for GRE and GREIPv4, the The tunnel specific header is the GRE header for GRE and GREIPv4, the
minimum encapsulation header for MINENC and the Encapsulation minimum encapsulation header for MINENC and the ESP header for IPsec
Security Payload (ESP) header for IPsec tunneling mode. As will be tunneling mode. As will be discussed in Section 4.3, some of the
discussed in Section 4.3, some of the tunnel specific headers may be tunnel specific headers may be used to identify a flow in the tunnel
used to identify a flow in the tunnel and facilitate NSIS operating and facilitate NSIS operating over IP tunnels.
over IP tunnels.
3.2. NSIS QoS Signaling in the Presence of IP Tunnels 3.2. NSIS QoS Signaling in the Presence of IP Tunnels
Typically, applications use NSIS QoS signaling to reserve resources Typically, applications use NSIS QoS signaling to reserve resources
for a flow along the flow path. NSIS QoS signaling can be initiated for a flow along the flow path. NSIS QoS signaling can be initiated
by either the flow sender or flow receiver. Figure 3 shows an by either the flow sender or flow receiver. Figure 3 shows an
example scenario with five NSIS nodes, including flow sender node A, example scenario with five NSIS nodes, including flow sender node A,
flow receiver node E, and intermediate NSIS nodes B, C and D. Nodes flow receiver node E, and intermediate NSIS nodes B, C and D. Nodes
which are not NSIS QoS capable are not shown. which are not NSIS QoS capable are not shown.
skipping to change at page 10, line 9 skipping to change at page 10, line 11
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. In summary, the problem is that tunnel that flow in the tunnel.
intermediate nodes are unable to intercept original NSIS signaling
messages and unable to classify original data flow packets as a
result of tunnel encapsulation. An IP tunnel segment appears just
like a QoS-unaware virtual link. Since the best QoS of an end-to-end
path is judged based on its weakest segment, leaving the tunnel path
without QoS risks voiding other efforts to provide QoS in the rest of
the path.
Tunnel from node B to node D Tunnel from node B to node D
<----------------------> <---------------------->
Tunnel Tunnel Tunnel Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point Entry-Point Intermediate Exit-Point
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Flow Flow Flow Flow
Sender Receiver Sender Receiver
Node Node Node Node
Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel
In summary, an IP tunnel segment normally appears like a QoS-unaware
virtual link. Since the best QoS of an end-to-end path is judged
based on its weakest segment, we need a mechanism to extend NSIS into
the IP tunnel segments, which should allow the tunnel intermediate
nodes to intercept original NSIS signaling messages and classify
original data flow packets in the presence of tunnel encapsulation.
4. Design Overview 4. Design Overview
4.1. Design Requirements 4.1. Design Requirements
We identify the following design requirements for NSIS operating over We identify the following design requirements for NSIS operating over
IP tunnels. IP tunnels.
o The mechanism should work with all common IP tunneling protocols o The mechanism should work with all common IP tunneling protocols
listed in Section 3.1. listed in Section 3.1.
o Some IP tunnels maintain pre-configured QoS sessions inside the o Some IP tunnels maintain pre-configured QoS sessions inside the
skipping to change at page 11, line 26 skipping to change at page 11, line 28
also supports multicast. Fourth, NSIS integrates a new Session ID also supports multicast. Fourth, NSIS integrates a new Session ID
feature which is different from the session identification concept feature which is different from the session identification concept
in RSVP. in RSVP.
4.2. Overall Design Approach 4.2. Overall Design Approach
The overall design of this NSIS signaling and IP tunnel interworking The overall design of this NSIS signaling and IP tunnel interworking
mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is
tailored and extended for NSIS operation. tailored and extended for NSIS operation.
Since a flow is considered unidirectional, 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 end-
point knows whether the other tunnel end-point is NSIS-tunnel-aware point knows whether the other tunnel end-point is NSIS-tunnel-aware
either through pre-configuration or through an NSIS-tunnel capability either through pre-configuration 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 end-points need to always intercept NSIS peer discovery
messages and insert themselves into the NSIS signaling path so they messages and insert themselves into the NSIS signaling path so they
can receive all NSIS signaling messages and coordinate their can receive all NSIS signaling messages and coordinate their
interaction with tunnel QoS. interaction with tunnel QoS.
skipping to change at page 12, line 23 skipping to change at page 12, line 25
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 pre-configured QoS sessions, the
tunnel entry-point always initiates the mapping between the tunnel tunnel entry-point always initiates the mapping between the tunnel
session and the end-to-end session. 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 pre-configured QoS
sessions. This association serves two purposes, one at the signaling sessions. This association serves two purposes, one at the signaling
plane and the other at the data plane. At the signaling plane, the plane and the other at the data plane. For the signaling plane, the
association enables the tunnel entry-point to coordinate necessary association enables the tunnel entry-point to coordinate necessary
interaction, such as QoS adjustment in sender-initiated reservations, interaction, such as QoS adjustment in sender-initiated reservations,
between the end-to-end and the tunnel QoS sessions. At the data between the end-to-end and the tunnel QoS sessions. For the data
plane, the association allows the tunnel entry-point to correctly plane, the association allows the tunnel entry-point to correctly
encapsulate data flow packets according to the chosen tunnel Flow ID. encapsulate data flow packets according to the chosen tunnel Flow ID.
Since the tunnel Flow ID uses header fields that are visible inside Since the tunnel Flow ID uses header fields that are visible inside
the tunnel, the tunnel intermediate nodes can classify the data flow the tunnel, the tunnel intermediate nodes can classify the data flow
packets and apply appropriate QoS treatment. 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. At the signaling plane, this association at the
tunnel exit-point enables the interaction of the end-to-end and the tunnel exit-point enables the interaction of the end-to-end and the
tunnel QoS session such as QoS adjustment in receiver-initiated tunnel QoS session such as QoS adjustment in receiver-initiated
reservations. At the data plane, this association tells the tunnel reservations. At the data plane, this association tells the tunnel
exit-point that the relevant data flow packets need to be exit-point that the relevant data flow packets need to be
decapsulated according to the corresponding tunnel Flow ID. decapsulated according to the corresponding tunnel Flow ID.
In tunnels with pre-configured QoS sessions, the tunnel exit-point In tunnels with pre-configured QoS sessions, the tunnel exit-point
may learn about the mapping information between the corresponding may also learn about the mapping information between the
tunnel and end-to-end QoS sessions through pre-configuration as well. corresponding tunnel and end-to-end QoS sessions through pre-
In tunnels without pre-configured QoS sessions, the tunnel exit-point configuration as well. In tunnels without pre-configured QoS
knows the mapping between the corresponding tunnel and end-to-end QoS sessions, the tunnel exit-point knows the mapping between the
sessions through the NSIS signaling process that creates the tunnel corresponding tunnel and end-to-end QoS sessions through the NSIS
QoS sessions inside the tunnel, with the help of appropriate QoS NSLP signaling process that creates the tunnel QoS sessions inside the
session binding and message binding mechanisms. tunnel, with the help of appropriate QoS NSLP session binding and
message binding mechanisms.
One problem for NSIS operating over IP tunnels which dynamically One problem for NSIS operating over IP tunnels which dynamically
create QoS sessions is that it involves two signaling sequences. The create QoS sessions is that it involves two signaling sequences. The
outcome of the tunnel signaling session directly affects the outcome outcome of the tunnel signaling session directly affects the outcome
of the end-to-end signaling session. Since the two signaling of the end-to-end signaling session. Since the two signaling
sessions overlap in time, there are circumstances when a tunnel end- sessions overlap in time, there are circumstances when a tunnel end-
point has to decide whether it should proceed with the end-to-end point has to decide whether it should proceed with the end-to-end
signaling session while it is still waiting for results of the tunnel signaling session while it is still waiting for results of the tunnel
session. Sequential mode and parallel mode are two basic options for session. This problem can be addressed in two ways, namely
this problem. In sequential mode, end-to-end signaling pauses when sequential mode and parallel mode. In sequential mode, end-to-end
it is waiting for results of tunnel signaling, and resumes upon signaling pauses when it is waiting for results of tunnel signaling,
receipt of the tunnel signaling outcome. In parallel mode, end-to- and resumes upon receipt of the tunnel signaling outcome. In
end signaling continues outside the tunnel while tunnel signaling is parallel mode, end-to-end signaling continues outside the tunnel
still in process and its outcome is unknown. The parallel mode may while tunnel signaling is still in process and its outcome is
lead to reduced signaling delays if the QoS resources in the tunnel unknown. The parallel mode may lead to reduced signaling delays if
path are sufficient compared to the rest of the end-to-end path. If the QoS resources in the tunnel path are sufficient compared to the
the QoS resources in the tunnel path are more constraint than the rest of the end-to-end path. If the QoS resources in the tunnel path
rest of the end-to-end path, however, the parallel mode may lead to are more constraint than the rest of the end-to-end path, however,
wasted end-to-end signaling or necessitates re-negotiation after the the parallel mode may lead to wasted end-to-end signaling or
tunnel signaling outcome becomes available. In those cases, the necessitates re-negotiation after the tunnel signaling outcome
signaling flow of the parallel mode also tends to be complicated. becomes available. In those cases, the signaling flow of the
This document adopts a sequential mode approach for the two signaling parallel mode also tends to be complicated. This document adopts a
sequences. sequential mode 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 ID can be chosen
for different tunneling mechanisms in order to minimize the for different tunneling mechanisms in order to minimize the
classification overhead. This document specifies the following Flow classification overhead. This document specifies the following Flow
ID formats for the respective tunneling protocols. ID formats for the respective tunneling protocols.
skipping to change at page 14, line 7 skipping to change at page 14, line 10
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 end-points
need to be NSIS-tunnel-aware. need to be NSIS-tunnel-aware.
The above recommendations about choosing 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 pre-configured QoS
tunnel sessions, the corresponding Flow ID is determined by the tunnel sessions, the corresponding Flow ID is determined by the
configuration mechanism itself. For example, if the tunnel QoS is configuration mechanism itself. For example, if the tunnel QoS is
DiffServ based, the DiffServ Code Point (DSCP) field value may be DiffServ based, the DiffServ Code Point (DSCP) field value may be
used to identify the corresponding tunnel session. used to identify the corresponding tunnel session.
5. NSIS Operation over Tunnels with Pre-configured QoS Sessions 5. NSIS Operation over Tunnels with Pre-configured QoS Sessions
When tunnel QoS is managed by pre-configured QoS sessions, both the When tunnel QoS is managed by pre-configured QoS sessions, both the
tunnel entry-point and tunnel exit-point need to be configured with tunnel entry-point and tunnel exit-point need to be configured with
skipping to change at page 14, line 29 skipping to change at page 14, line 32
enable the tunnel end-points to correctly perform matching enable the tunnel end-points to correctly perform matching
encapsulating and decapsulating operations. The procedures of NSIS encapsulating and decapsulating operations. The procedures of NSIS
operating over tunnels with pre-configured QoS sessions depend on operating over tunnels with pre-configured QoS sessions depend on
whether the end-to-end NSIS signaling is sender-initiated or whether the end-to-end NSIS signaling is sender-initiated or
receiver-initiated. But in both cases, it is the tunnel entry-point receiver-initiated. But in both cases, it is the tunnel entry-point
that first creates the mapping between a tunnel session and an end- that first creates the mapping between a tunnel session and an end-
to-end session. to-end session.
5.1. Sender-initiated Reservation 5.1. Sender-initiated Reservation
Sender Tentry Tmid Texit Receiver
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +---------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 6: Sender-initiated End-to-end Session with Pre-configured
Tunnel QoS Sessions
Figure 6 illustrates the signaling sequence when end-to-end signaling Figure 6 illustrates the signaling sequence when end-to-end signaling
outside the tunnel is sender-initiated. Upon receiving a RESERVE outside the tunnel is sender-initiated. Upon receiving a RESERVE
message from the sender, Tentry checks tunnel QoS configuration, message from the sender, Tentry checks tunnel QoS configuration,
determines whether and how this end-to-end session can be mapped to a determines whether and how this end-to-end session can be mapped to a
pre-configured tunnel session. The mapping criteria are part of the pre-configured tunnel session. The mapping criteria are part of the
pre-configuration and outside the scope of this document. Tentry pre-configuration and outside the scope of this document. Tentry
then tunnels the RESERVE message to Texit. Texit forwards the then tunnels the RESERVE message to Texit. Texit forwards the
RESERVE message to the receiver. The receiver replies with a RESERVE message to the receiver. The receiver replies with a
RESPONSE message which arrives at Texit, Tentry and finally the RESPONSE message which arrives at Texit, Tentry and finally the
sender. If the RESPONSE message that Tentry receives confirms that sender. If the RESPONSE message that Tentry receives confirms that
the overall signaling is successful, Tentry starts to encapsulate all the overall signaling is successful, Tentry starts to encapsulate all
incoming packets of the data flow using the tunnel Flow ID incoming packets of the data flow using the tunnel Flow ID
corresponding to the mapped tunnel session. Texit knows how to corresponding to the mapped tunnel session. Texit knows how to
decapsulate the tunnel packets because it recognizes the mapped decapsulate the tunnel packets because it recognizes the mapped
tunnel Flow ID based on information supplied during tunnel session tunnel Flow ID based on information supplied during tunnel session
pre-configuration. pre-configuration.
5.2. Receiver-initiated Reservation
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| QUERY | | | | | RESERVE | | | |
+------------->| | | | +------------->| | | |
| | QUERY | | | | RESERVE | |
| +---------------------------->| | | +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE | | | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+ | | | |<-------------+
| | RESERVE | | | | RESPONSE | |
| |<----------------------------+ | | |<----------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | | | RESPONSE | | | |
+------------->| | | | |<-------------+ | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | | | | | | |
| | | | | | | | | |
Figure 7: Receiver-initiated End-to-end Session with Pre-configured Figure 6: Sender-initiated End-to-end Session with Pre-configured
Tunnel QoS Sessions Tunnel QoS Sessions
5.2. Receiver-initiated Reservation
Figure 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, updates and tunnels the Query message to Texit. Texit
decapsulates the QUERY message, processes it and forwards it toward decapsulates the QUERY message, processes it and forwards it toward
the receiver. The receiver sends back a RESERVE message passing the receiver. The receiver sends back a RESERVE message passing
through Texit and arriving at Tentry. Tentry decides on whether and through Texit and arriving at Tentry. Tentry decides on whether and
how the QoS request for this end-to-end session can be mapped to a how the QoS request for this end-to-end session can be mapped to a
pre-configured tunnel session based on criteria outside the scope of pre-configured tunnel session based on criteria outside the scope of
this document. Then Tentry forwards the RESERVE message towards the this document. Then Tentry forwards the RESERVE message towards the
sender. The signaling continues until a RESPONSE message arrives at sender. The signaling continues until a RESPONSE message arrives at
Tentry, Texit and finally the receiver. If the RESPONSE message that Tentry, Texit and finally the receiver. If the RESPONSE message that
Tentry receives confirms that the overall signaling is successful, Tentry receives confirms that the overall signaling is successful,
Tentry starts to encapsulate all incoming packets of the data flow Tentry starts to encapsulate all incoming packets of the data flow
using the tunnel Flow ID corresponding to the mapped tunnel session. using the tunnel Flow ID corresponding to the mapped tunnel session.
Similarly, Texit knows how to decapsulate the tunnel packets because Similarly, Texit knows how to decapsulate the tunnel packets because
it recognizes the mapped tunnel Flow ID based on information supplied it recognizes the mapped tunnel Flow ID based on information supplied
during tunnel session pre-configuration. during tunnel session pre-configuration.
Since separate tunnel QoS signaling is not involved in pre-configured Since separate tunnel QoS signaling is not involved in pre-configured
QoS tunnels, Figure 6 and Figure 7 look as if the tunnel is a single QoS tunnels, Figure 6 and Figure 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 NSIS-tunnel related functionalities described above, including acting
on the end-to-end NSIS signaling messages based on tunnel QoS status, on the end-to-end NSIS signaling messages based on tunnel QoS status,
mapping end-to-end and tunnel QoS sessions, and correctly mapping end-to-end and tunnel QoS sessions, and correctly
encapsulating and decapsulating tunnel packets according to the encapsulating and decapsulating tunnel packets according to the
tunnel protocol and the configured tunnel Flow ID. tunnel protocol and the configured tunnel Flow ID.
Sender Tentry Tmid Texit Receiver
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<----------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
| | | | |
Figure 7: Receiver-initiated End-to-end Session with Pre-configured
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 pre-configured tunnel QoS sessions, a tunnel can
apply the same NSIS QoS signaling mechanism used for the end-to-end apply the same NSIS QoS signaling mechanism used for the end-to-end
path to manage the QoS inside the tunnel. The tunnel NSIS signaling path to manage the QoS inside the tunnel. The tunnel NSIS signaling
involves only those NSIS nodes in the tunnel forwarding path. The involves only those NSIS nodes in the tunnel forwarding path. The
Flow IDs for the tunnel signaling are based on tunnel header fields. Flow IDs for the tunnel signaling are based on tunnel header fields.
NSIS peer discovery messages inside the tunnel 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.
skipping to change at page 17, line 12 skipping to change at page 17, line 17
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 is resolved using the MSG_ID
and BOUND_MSG_ID objects of the QoS NSLP message binding mechanism. and BOUND_MSG_ID objects of the QoS NSLP message binding mechanism.
6.1. Sender-initiated Reservation 6.1. Sender-initiated Reservation
Figure 8 shows the typical messaging sequence of how NSIS operates
over IP tunnels when both end-to-end session and tunnel session are
sender-initiated. Tunnel signaling messages are distinguished from
end-to-end messages by a prime symbol after the message name. The
sender first sends an end-to-end RESERVE message (1) which arrives at
Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel
session and associates the end-to-end session with the tunnel
session. Tentry then sends a tunnel RESERVE' message (2) matching
the request of the end-to-end session towards Texit to reserve tunnel
resources. This RESERVE' message (2) includes a MSG_ID object which
contains a randomly generated 128-bit MSG_ID. Meanwhile, Tentry
inserts a BOUND_MSG_ID object containing the same MSG_ID as well as a
BOUND_SESSION_ID object containing the Session ID of the tunnel
session into the original RESERVE message, and sends this RESERVE
message (3) towards Texit using normal tunnel encapsulation. The
Message_Binding_Type flags of both the MSG_ID and BOUND_MSG_ID
objects in the RESERVE' and RESERVE messages (2, 3) are SET,
indicating a bidirectional binding. The tunnel RESERVE' message (2)
is processed hop-by-hop inside the tunnel for the flow identified by
the chosen tunnel Flow ID, while the end-to-end RESERVE message (3)
passes through the tunnel intermediate nodes (Tmid) just like other
tunneled packets. These two messages could arrive at Texit in
different orders, and the reaction of Texit in these different
situations should combine the tunnel QoS message processing rules
with the QoS NSLP processing principles for message binding
[I-D.ietf-nsis-qos-nslp], as illustrated below.
The first possibility is shown in the example messaging flow of
Figure 8, where the tunnel RESERVE' message (2), also known as the
triggering message in QoS NSLP message binding terms, arrives first.
Since the message binding is bidirectional, Texit records the MSG_ID
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
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) | | |
| +=============>| | | | +=============>| | |
| | | RESERVE'(2) | | | | | RESERVE'(2) | |
| | +=============>| | | | +=============>| |
| | RESERVE(3) | | | | RESERVE(3) | |
skipping to change at page 17, line 45 skipping to change at page 18, line 37
| | | | | | | | | |
| | | | | | | | | |
(1,5): RESERVE w/o BOUND_MSG_ID and BOUND_SESSION_ID (1,5): RESERVE w/o BOUND_MSG_ID and BOUND_SESSION_ID
(2): RESERVE' w/ MSG_ID (2): RESERVE' w/ MSG_ID
(3): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID (3): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID
Figure 8: Sender-initiated Reservation for Both End-to-end and Tunnel Figure 8: Sender-initiated Reservation for Both End-to-end and Tunnel
Signaling Signaling
Figure 8 shows the typical messaging sequence of how NSIS operates value is set to the default retransmission timeout period
over IP tunnels when both end-to-end session and tunnel session are
sender-initiated. Tunnel signaling messages are distinguished from
end-to-end messages by a prime symbol after the message name. The
sender first sends an end-to-end RESERVE message (1) which arrives at
Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel
session and associates the end-to-end session with the tunnel
session. Tentry then sends a tunnel RESERVE' message (2) matching
the request of the end-to-end session towards Texit to reserve tunnel
resources. This RESERVE' message (2) includes a MSG_ID object which
contains a randomly generated 128-bit MSG_ID. Meanwhile, Tentry
inserts a BOUND_MSG_ID object containing the same MSG_ID as well as a
BOUND_SESSION_ID object containing the Session ID of the tunnel
session into the original RESERVE message, and sends this RESERVE
message (3) towards Texit using normal tunnel encapsulation. The
Message_Binding_Type flags of both the MSG_ID and BOUND_MSG_ID
objects in the RESERVE' and RESERVE messages (2, 3) are SET,
indicating a bidirectional binding. The tunnel RESERVE' message (2)
is processed hop-by-hop inside the tunnel for the flow identified by
the chosen tunnel Flow ID, while the end-to-end RESERVE message (3)
passes through the tunnel intermediate nodes (Tmid) just like other
tunneled packets. These two messages could arrive at Texit in
different orders, and the reaction of Texit in these different
situations should combine the tunnel QoS message processing rules
with the QoS NSLP processing principles for message binding
[I-D.ietf-nsis-qos-nslp], as illustrated below.
The first possibility is shown in the example messaging flow of
Figure 8, where the tunnel RESERVE' message (2), aka the triggering
message in QoS NSLP message binding terms, arrives first. Since the
message binding is bidirectional, Texit records the MSG_ID of the
RESERVE' message (2), enqueues it and starts a MsgIDWait timer
waiting for the end-to-end RESERVE message (3), aka the bound
signaling message in QoS NSLP message binding terms. The timer 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
skipping to change at page 19, line 47 skipping to change at page 20, line 4
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
QUERY' message (2) matching the request of the end-to-end session
towards Texit. This tunnel QUERY' message (2) is meant to discover
QoS characteristics of the tunnel path, rather than initiating an
actual reservation. Therefore, it includes a Request Identification
Information (RII) object but does not set the RESERVE-INIT flag. The
tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel
for the flow identified by the tunnel Flow ID. When Texit receives
this tunnel QUERY' message (2), it replies with a corresponding
tunnel RESPONSE' message (3) containing the tunnel path
characteristics. After receiving the tunnel RESPONSE' message (3),
Tentry creates the tunnel session, generates an outgoing end-to-end
Sender Tentry Tmid Texit Receiver Sender Tentry Tmid Texit Receiver
| | | | | | | | | |
| QUERY(1) | | | | | QUERY(1) | | | |
+------------->| | | | +------------->| | | |
| | QUERY'(2) | | | | | QUERY'(2) | | |
| +=============>| | | | +=============>| | |
| | | QUERY'(2) | | | | | QUERY'(2) | |
| | +=============>| | | | +=============>| |
| | | RESPONSE'(3) | | | | | RESPONSE'(3) | |
skipping to change at page 21, line 4 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 (1,5): QUERY w/ RESERVE-INIT (2): QUERY' w/ RII
(4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID (4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID
(6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID (6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID
(8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID (8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID
Figure 9: Receiver-initiated Reservation for Both End-to-end and Figure 9: Receiver-initiated Reservation for Both End-to-end and
Tunnel Signaling Tunnel Signaling
QUERY' message (2) matching the request of the end-to-end session
towards Texit. This tunnel QUERY' message (2) is meant to discover
QoS characteristics of the tunnel path, rather than initiating an
actual reservation. Therefore, it includes a Request Identification
Information (RII) object but does not set the RESERVE-INIT flag. The
tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel
for the flow identified by the tunnel Flow ID. When Texit receives
this tunnel QUERY' message (2), it replies with a corresponding
tunnel RESPONSE' message (3) containing the tunnel path
characteristics. After receiving the tunnel RESPONSE' message (3),
Tentry creates the tunnel session, generates an outgoing end-to-end
QUERY message (4) considering the tunnel path characteristics, 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 and creates the tunnel session state, removes the tunnel
BOUND_SESSION_ID object and forwards the end-to-end QUERY message (5) BOUND_SESSION_ID object and forwards the end-to-end QUERY message (5)
further along the path. further along the path.
skipping to change at page 24, line 39 skipping to change at page 24, line 40
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 the end-to-end path includes an IPsec
tunnel or not. tunnel or not.
Several other documents discussed security issues for NSIS. General Several other documents discussed 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 [I-D.ietf-nsis-ntlp] and
[I-D.ietf-nsis-qos-nslp], respectively. [I-D.ietf-nsis-qos-nslp], respectively.
10. Acknowledgements 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, Russ Housley, Georgios Karagiannis, Jukka Manner, Martin Eggert, Adrian Farrel, Russ Housley, Georgios Karagiannis, Jukka
Rohricht, Peter Saint-Andre, Martin Stiemerling, Hannes Tschofenig, Manner, Martin Rohricht, Peter Saint-Andre, Martin Stiemerling,
and other members of the NSIS working group for comments to this Hannes Tschofenig, and other members of the NSIS working group for
work. 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] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
 End of changes. 41 change blocks. 
168 lines changed or deleted 171 lines changed or added

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