idnits 2.17.1 draft-ietf-nsis-tunnel-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2010) is 5183 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Data' is mentioned on line 179, but not defined == Missing Reference: 'QoS' is mentioned on line 189, but not defined == Missing Reference: 'Adjacent' is mentioned on line 193, but not defined == Missing Reference: 'Tunnel' is mentioned on line 202, but not defined == Unused Reference: 'I-D.ietf-nsis-applicability-mobility-signaling' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-nslp-natfw' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-qspec' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: 'RFC2207' is defined on line 1142, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-nsis-applicability-mobility-signaling-14 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-23 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 3220 (Obsoleted by RFC 3344) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Next Steps in Signaling C. Shen 3 Internet-Draft H. Schulzrinne 4 Intended status: Experimental Columbia U. 5 Expires: August 19, 2010 S. Lee 6 J. Bang 7 Samsung AIT 8 February 15, 2010 10 NSIS Operation Over IP Tunnels 11 draft-ietf-nsis-tunnel-09.txt 13 Abstract 15 NSIS QoS signaling enables applications to perform QoS reservation 16 along a data flow path. When the data flow path contains IP tunnel 17 segments, NSIS QoS signaling has no effect within those tunnel 18 segments and the resulting QoS-untended tunnel segments could become 19 the weakest QoS link which may invalidate the QoS efforts in the rest 20 of the end-to-end path. The problem with NSIS signaling within the 21 tunnel is caused by the tunnel encapsulation which masks packets' 22 original IP header fields. Those original IP header fields are 23 needed to intercept NSIS signaling messages and classify QoS data 24 packets. This document defines a solution to this problem by mapping 25 end-to-end QoS session requests to corresponding QoS sessions in the 26 tunnel, thus extending the end-to-end QoS signaling into the IP 27 tunnel segments. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on August 19, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6 73 3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 8 74 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10 76 4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11 77 4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 14 78 5. NSIS Operation over Tunnels with Pre-configured QoS 79 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 15 81 5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15 82 6. NSIS Operation over Tunnels with Dynamically Created QoS 83 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17 85 6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 20 86 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22 87 7.1. NODE_CAPABILITY Object Format . . . . . . . . . . . . . . 23 88 7.2. Using NODE_CAPABILITY Object . . . . . . . . . . . . . . . 23 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 IP tunneling is a technique that allows a packet to be encapsulated 100 and carried as payload within an IP packet. The resulting 101 encapsulated packet is called an IP tunnel packet, and the packet 102 being tunneled is called the original packet. In typical scenarios, 103 IP tunneling is used to exert explicit forwarding path control (e.g., 104 in Mobile IP [RFC3220]), facilitate the secure IP delivery 105 architecture (e.g., in IPSEC [RFC2401]), and help packet routing in 106 IP networks of different characteristics (e.g., between IPv6 and IPv4 107 networks [RFC4213]). 109 This document considers the situation when the packet being tunneled 110 contains a Next Step In Signaling (NSIS) [RFC4080] message. NSIS is 111 an IP network layer signaling architecture consisting of a Generic 112 Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer 113 for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) 114 sub-layer customizable for different applications. We focus on the 115 Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides 116 functionalities that extend those of the earlier RSVP [RFC2205] 117 signaling. In this document the term "NSIS" and "NSIS QoS" are used 118 interchangeably. 120 Without additional efforts, NSIS signaling does not work within IP 121 tunneling segments of a signaling path. The reason is that tunnel 122 encapsulation masks the original packet including its header and 123 payload. However, information from the original packet is required 124 both for NSIS peer node discovery and for QoS data flow packet 125 classification. Without access to information from the original 126 packet, an IP tunnel acts as an NSIS-unaware virtual link in the end- 127 to-end NSIS signaling path. 129 This document defines a mechanism to extend end-to-end NSIS signaling 130 for QoS reservation into IP tunnels. The NSIS-aware IP tunnel end- 131 points that support this mechanism are called NSIS-tunnel-aware end- 132 points. There are two main operation modes. On one hand, if the 133 tunnel already has pre-configured QoS sessions, the NSIS-tunnel-aware 134 end-points map end-to-end QoS signaling requests directly to existing 135 tunnel sessions as long as there are enough tunnel session resources; 136 on the other hand, if no pre-configured tunnel QoS sessions are 137 available, the NSIS-tunnel-aware end-points dynamically initiate and 138 maintain tunnel QoS sessions that are then associated with the 139 corresponding end-to-end QoS sessions. Note that whether the tunnel 140 pre-configures QoS sessions or not, and which pre-configured tunnel 141 QoS sessions a particular end-to-end QoS signaling request should be 142 mapped to are policy issues out of scope of this document. 144 The rest of this document is organized as follows. Section 2 defines 145 terminology. Section 3 presents the problem statement including 146 common IP tunneling protocols and existing behavior of NSIS QoS 147 signaling operating over IP tunnels. Section 4 introduces the design 148 requirements and overall approach of our mechanism. More details 149 about how NSIS QoS signaling operates with tunnels that use pre- 150 configured QoS and dynamic QoS signaling are provided in Section 5 151 and Section 6. Section 7 describes a method to automatically 152 discover whether a tunnel end-point node supports the NSIS-tunnel 153 interoperation mechanism defined in this document. Section 8 154 discusses IANA considerations and Section 9 considers security. 156 2. Terminology 158 This document uses terminology defined in [RFC2473], 159 [I-D.ietf-nsis-ntlp], and [I-D.ietf-nsis-qos-nslp]. In addition, the 160 following terms are used: 162 Tunnel IP Header: The IP header prepended to the original packet 163 during encapsulation. It specifies the tunnel end-points as 164 source and destination. 166 Tunnel Specific Header: The header fields inserted by the 167 encapsulation mechanism after the tunnel IP header and before the 168 original packet. These headers may or may not exist depending on 169 the specific tunnel mechanism used. 171 Tunnel Intermediate Node (Tmid): A node which resides in the middle 172 of the forwarding path between the tunnel entry-point node and the 173 tunnel exit-point node. 175 IP Tunnel: A tunnel configured as a virtual link between two IP 176 nodes, on which the encapsulating protocol is IP. 178 Flow Identifier (Flow ID): The set of header fields which is used to 179 identify a [Data] flow. For example, it may include flow sender 180 and receiver addresses, protocol and port numbers. 182 End-to-end [QoS] Signaling: The signaling process that manipulates 183 the QoS control information in the end-to-end path from the flow 184 sender to the flow receiver. When the end-to-end flow path 185 contains tunnel segments, this document uses end-to-end [QoS] 186 signaling to refer specially to the [QoS] signaling outside the 187 tunnel segments. 189 Tunnel [QoS] Signaling: The signaling process that manipulates the 190 QoS control information in the path inside a tunnel, between the 191 tunnel entry-point and the tunnel exit-point nodes. 193 [Adjacent] NSIS Peer: The next node along the signaling path, in the 194 upstream or downstream direction, with which a NSIS node 195 explicitly interacts. 197 NSIS-aware Node: A node that supports NSIS signaling. 199 NSIS-aware Tunnel End-point Node: A tunnel end-point node which is 200 also an NSIS node. 202 NSIS-tunnel-aware [Tunnel] End-point Node: An NSIS-aware Tunnel End- 203 point node which also supports the mechanism for NSIS operating 204 over IP tunnels defined in this document. 206 3. Problem Statement 208 3.1. IP Tunneling Protocols 210 Tunnel from node B to node D 211 <----------------------> 212 Tunnel Tunnel Tunnel 213 Entry-Point Intermediate Exit-Point 214 Node Node Node 215 +-+ +-+ +-+ +-+ +-+ 216 |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| 217 +-+ +-+ +-+ +-+ +-+ 218 Original Original 219 Packet Packet 220 Source Destination 221 Node Node 223 Figure 1: IP Tunnel 225 The following definition of IP tunneling is derived from [RFC2473] 226 and adapted for both IPv4 and IPv6. 228 IP tunneling is a technique for establishing a "virtual link" between 229 two IP nodes for transmitting data packets as payloads of IP packets 230 (see Figure 1). From the point of view of the two nodes, this 231 "virtual link", called an IP tunnel, appears as a point-to-point link 232 on which IP acts like a link-layer protocol. The two IP nodes play 233 specific roles. One node encapsulates original packets received from 234 other nodes or from itself and forwards the resulting tunnel packets 235 through the tunnel. The other node decapsulates the received tunnel 236 packets and forwards the resulting original packets towards their 237 destinations, possibly itself. The encapsulating node is called the 238 tunnel entry-point node (Tentry), and it is the source of the tunnel 239 packets. The decapsulating node is called the tunnel exit-point node 240 (Texit), and it is the destination of the tunnel packets. 242 An IP tunnel is a unidirectional mechanism - tunnel packet flow takes 243 place in one direction between the IP tunnel entry-point and exit- 244 point nodes (see Figure 1). Bi-directional tunneling is achieved by 245 combining two unidirectional mechanisms, that is, configuring two 246 tunnels, each in opposite direction to the other - the entry-point 247 node of one tunnel is the exit-point node of the other tunnel. 249 Figure 2 illustrates the original packet and the resulting tunnel 250 packet. In a tunnel packet, the original packet is encapsulated 251 within the tunnel header. The tunnel header contains two components, 252 the tunnel IP header and other tunnel specific headers. The tunnel 253 IP header specifies tunnel entry-point node as IP source address and 254 tunnel exit-point node as IP destination address, thus causing the 255 tunnel packet to be routed inside the tunnel. The tunnel specific 256 headers in between the tunnel IP header and the original packet in a 257 tunnel packet are optional, depending on the tunneling protocol in 258 use. 260 +----------------------------------//-----+ 261 | Original | | 262 | | Original Packet Payload | 263 | Header | | 264 +----------------------------------//-----+ 265 < Original Packet > 266 | 267 v 268 < Tunnel Headers > < Original Packet > 269 +---------+-----------+-------------------------//--------------+ 270 | Tunnel | Tunnel | | 271 | IP | Specific | Original Packet | 272 | Header | Headers | | 273 +---------+-----------+-------------------------//--------------+ 274 < Tunnel IP Packet > 276 Figure 2: IP Tunnel Encapsulation 278 Commonly used IP tunneling protocols include Generic Routing 279 Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation 280 over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP 281 (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP 282 (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], 283 Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] 284 and IPSEC tunneling mode (IPSEC) [RFC4301][RFC4303]. Among these 285 tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and 286 IPv6GEN contain only a tunnel IP header, and no tunnel specific 287 headers. All the other tunneling protocols have a tunnel header 288 consisting of both a tunnel IP header and a tunnel specific header. 289 The tunnel specific header is the GRE header for GRE and GREIPv4, the 290 minimum encapsulation header for MINENC and the Encapsulation 291 Security Payload (ESP) header for IPSEC tunneling mode. As will be 292 discussed in Section 4.3, some of the tunnel specific headers may be 293 used to identify a flow in the tunnel and facilitate NSIS operating 294 over IP tunnels. 296 3.2. NSIS QoS Signaling in the Presence of IP Tunnels 298 Typically, applications use NSIS QoS signaling to reserve resources 299 for a flow along the flow path. NSIS QoS signaling can be initiated 300 by either the flow sender or flow receiver. Figure 3 shows an 301 example scenario with five NSIS nodes, including flow sender node A, 302 flow receiver node E, and intermediate NSIS nodes B, C and D. Nodes 303 which are not NSIS QoS capable are not shown. 305 NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS 306 Node Node Node Node Node 307 +-+ +-+ +-+ +-+ +-+ 308 |A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E| 309 +-+ +-+ +-+ +-+ +-+ 310 Flow Flow 311 Sender Receiver 312 Node Node 314 Figure 3: Example Scenario of NSIS QoS Signaling 316 Figure 4 illustrates a sender-initiated signaling sequence in the 317 scenario of Figure 3. Sender node A sends a RESERVE message towards 318 receiver node E. The RESERVE message gets forwarded by intermediate 319 NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver 320 node E then sends back a RESPONSE message confirming the QoS 321 reservation, again through the previous intermediate NSIS nodes in 322 the data flow path. 324 There are two important aspects in the above signaling process that 325 are worth mentioning. First, the flow sender does not initially know 326 exactly which intermediate nodes are NSIS-aware and should be 327 involved in the signaling process for a flow from node A to node E. 328 Discovery of those nodes, namely node B, C and D is accomplished by a 329 separate NSIS peer discovery process (not shown above, see 331 [I-D.ietf-nsis-ntlp]). The NSIS peer discovery messages contain 332 special IP header and payload format or include a Router Alert Option 333 (RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery 334 messages allow node B, C and D to intercept them and subsequently 335 insert themselves into the signaling path for the flow in question. 336 After formation of the signaling path, all signaling messages 337 corresponding to this flow will be passed to these nodes for 338 processing. Other nodes which are not NSIS-aware simply forward all 339 signaling messages like any other IP packets without additional 340 handling. 342 Node A Node B Node C Node D Node E 343 | | | | | 344 | RESERVE | | | | 345 +------------->| | | | 346 | | RESERVE | | | 347 | +------------->| | | 348 | | | RESERVE | | 349 | | +------------->| | 350 | | | | RESERVE | 351 | | | +------------->| 352 | | | | RESPONSE | 353 | | | |<-------------+ 354 | | | RESPONSE | | 355 | | |<-------------+ | 356 | | RESPONSE | | | 357 | |<-------------+ | | 358 | RESPONSE | | | | 359 |<-------------+ | | | 360 | | | | | 361 | | | | | 363 Figure 4: Sender-initiated NSIS QoS Signaling 365 Second, the goal of QoS signaling is to install control information 366 to give QoS treatment for the flow being signaled. Basic QoS control 367 information includes the data Flow ID for packet classification and 368 the type of QoS treatment those packets are entitled to. The Flow ID 369 contains a set of header fields such as flow sender and receiver 370 addresses, protocol and port numbers. 372 Now consider Figure 5 where nodes B, C and D are end-points and 373 intermediate nodes of an IP tunnel. During the signaling path 374 discovery process, node B can still intercept and process NSIS peer 375 discovery messages if it recognizes them before performing tunnel 376 encapsulation; node D can identify NSIS peer discovery messages after 377 performing tunnel decapsulation. A tunnel intermediate node such as 378 node C, however, only sees the tunnel header of the packets and will 379 not be able to identify the original NSIS peer discovery message or 380 insert itself in the flow signaling path. Furthermore, the Flow ID 381 of the original flow is based on IP header fields of the original 382 packet. Those fields are also hidden in the payload of the tunnel 383 packet. So there is no way node C can classify packets belonging to 384 that flow in the tunnel. In summary, the problem is that tunnel 385 intermediate nodes are unable to intercept original NSIS signaling 386 messages and unable to classify original data flow packets as a 387 result of tunnel encapsulation. An IP tunnel segment appears just 388 like a QoS-unaware virtual link. Since the best QoS of an end-to-end 389 path is judged based on its weakest segment, leaving the tunnel path 390 "untended" risks voiding other efforts to provide QoS in the rest of 391 the path. 393 Tunnel from node B to node D 394 <----------------------> 395 Tunnel Tunnel Tunnel 396 Entry-Point Intermediate Exit-Point 397 NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS 398 Node Node Node Node Node 399 +-+ +-+ +-+ +-+ +-+ 400 |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| 401 +-+ +-+ +-+ +-+ +-+ 402 Flow Flow 403 Sender Receiver 404 Node Node 406 Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel 408 4. Design Overview 410 4.1. Design Requirements 412 We identify the following design requirements for NSIS operating over 413 IP tunnels. 415 o The mechanism should work with all common IP tunneling protocols 416 listed in Section 3.1. 417 o Some IP tunnels maintain pre-configured QoS sessions inside the 418 tunnel. The mechanism should work for IP tunnels both with and 419 without pre-configured tunnel QoS sessions. 420 o The mechanism should minimize the required upgrade to existing 421 infrastructure in order to facilitate its deployment. 422 Specifically, we limit the necessary upgrade to NSIS-aware tunnel 423 end-points. Only tunnel end-points need to support the mechanism 424 defined in this document. Such tunnel end-points are called NSIS- 425 tunnel-aware end-points. All other nodes, both inside and outside 426 the tunnel should be transparent to this mechanism. 427 o The mechanism should facilitate its incremental deployment by 428 providing a method for one NSIS-tunnel-aware end-point to discover 429 whether the other end-point is also NSIS-tunnel-aware. 430 o The mechanism should learn from design experience of previous work 431 on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746], while also 432 addressing the following major differences of NSIS from RSVP. 433 First, NSIS is designed as a generic framework to accommodate 434 various signaling application needs, and therefore is split into a 435 signaling transport layer and a signaling application layer; RSVP 436 does not have a layer split and is designed only for QoS 437 signaling. Second, NSIS QoS NSLP allows both sender-initiated and 438 receiver-initiated reservations; RSVP only supports receiver- 439 initiated reservations. Third, NSIS deals only with unicast; RSVP 440 also supports multicast. Fourth, NSIS integrates a new Session ID 441 feature which is different from the session identification concept 442 in RSVP. 444 4.2. Overall Design Approach 446 The overall design of this NSIS signaling and IP tunnel interworking 447 mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is 448 tailored and extended for NSIS operation. 450 Since a flow is considered unidirectional, to accommodate flows in 451 both directions of a tunnel, we require both tunnel entry-point and 452 tunnel exit-point to be NSIS-tunnel-aware. If an NSIS-tunnel-aware 453 end-point needs to know whether the other tunnel end-point is also 454 NSIS-tunnel-aware, it may use the NSIS-tunnel capability discovery 455 mechanism defined in Section 7. 457 Tunnel end-points need to always intercept NSIS peer discovery 458 messages and insert themselves into the NSIS signaling path so they 459 can receive all NSIS signaling messages and coordinate their 460 interaction with tunnel QoS. 462 To facilitate the QoS handling in the tunnel, the end-to-end QoS 463 session will be mapped to a tunnel QoS session, either pre-configured 464 or dynamically created. An important property of a tunnel QoS 465 session is its tunnel Flow ID which identifies the end-to-end data 466 flow within the tunnel. In both tunnels with and without pre- 467 configured QoS sessions, the tunnel Flow ID is assigned based on 468 information available in the tunnel header, therefore solving the 469 problem for tunnel-intermediate nodes to classify flow packets as 470 discussed in Section 3.2. An example tunnel Flow ID contains the 471 tunnel entry-point and exit-point IP addresses and a tunnel inserted 472 UDP port number. We discuss more details about recommended choices 473 of tunnel Flow ID for different IP tunneling protocols in 474 Section 4.3. 476 For tunnels that maintain pre-configured QoS sessions, upon receiving 477 a request to reserve resources for an end-to-end session, the tunnel 478 end-point maps the end-to-end QoS session to an existing tunnel 479 session. To simplify the design, the mapping decision is always made 480 by the tunnel entry-point regardless of whether the end-to-end 481 session uses sender-initiated or receiver-initiated NSIS signaling 482 mode. The details about which end-to-end session can be mapped to 483 which pre-configured tunnel session depend on policy mechanisms 484 outside the scope of this document. 486 For tunnels that do not maintain pre-configured QoS sessions, the 487 NSIS-tunnel-aware end-points dynamically create and manage a 488 corresponding tunnel QoS session for the end-to-end session. Since 489 the initiation mode of both QoS sessions can be sender-initiated or 490 receiver-initiated, to simplify the design, we require that the 491 initiation mode of the tunnel QoS session follow that of the end-to- 492 end QoS session. In other words, the end-to-end QoS session and its 493 corresponding tunnel QoS session are either both sender-initiated or 494 both receiver-initiated. To keep the handling mechanism consistent 495 with the case for tunnels with pre-configured QoS sessions, the 496 tunnel entry-point always initiates the mapping between the tunnel 497 session and the end-to-end session. 499 As the mapping initiator, the tunnel entry-point records the 500 association between the end-to-end session and its corresponding 501 tunnel session, both in tunnels with and without pre-configured QoS 502 sessions. This association serves two purposes, one at the signaling 503 plane and the other at the data plane. At the signaling plane, the 504 association enables the tunnel entry-point to coordinate necessary 505 interaction, such as QoS adjustment in sender-initiated reservations, 506 between the end-to-end and the tunnel QoS sessions. At the data 507 plane, the association allows the tunnel entry-point to correctly 508 encapsulate data flow packets according to the chosen tunnel Flow ID. 509 Since the tunnel Flow ID uses header fields that are visible inside 510 the tunnel, the tunnel intermediate nodes can classify the data flow 511 packets and apply appropriate QoS treatment. 513 In addition to the tunnel entry-point recording the association 514 between the end-to-end session and its corresponding tunnel session, 515 the tunnel exit-point also needs to maintain the same association for 516 similar reasons. At the signaling plane, this association at the 517 tunnel exit-point enables the interaction of the end-to-end and the 518 tunnel QoS session such as QoS adjustment in receiver-initiated 519 reservations. At the data plane, this association tells the tunnel 520 exit-point that the relevant data flow packets need to be 521 decapsulated according to the corresponding tunnel Flow ID. 523 The tunnel exit-point learns about the mapping between the tunnel and 524 the end-to-end QoS sessions, including the tunnel Flow ID and the 525 tunnel session's Session ID that corresponds to the end-to-end 526 session, through the follow methods. In tunnels with pre-configured 527 QoS sessions, the mapping information between the corresponding 528 tunnel and end-to-end QoS sessions may be pre-configured as well. In 529 tunnels without pre-configured QoS sessions, the tunnel exit-point 530 knows the tunnel Flow ID through the NSIS signaling process that 531 creates the tunnel QoS sessions inside the tunnel. Meanwhile, the 532 tunnel exit-point maps the Session IDs of the tunnel QoS session and 533 the end-to-end session through the QoS NSLP BOUND_SESSION_ID object 534 [I-D.ietf-nsis-qos-nslp]. Specifically, when used for NSIS signaling 535 over IP tunnels, the BOUND_SESSION_ID object carries the Session ID 536 of the tunnel session and a Binding Code of value 0x01 indicating 537 tunnel handling. The tunnel entry-point includes this tunnel binding 538 object in appropriate end-to-end signaling messages. Upon receiving 539 this binding object, the tunnel exit-point records the association 540 between the tunnel QoS session and the corresponding end-to-end QoS 541 session. 543 One problem for NSIS operating over IP tunnels which dynamically 544 create QoS sessions is that it involves two signaling sequences. The 545 outcome of the tunnel signaling session directly affects the outcome 546 of the end-to-end signaling session. Since the two signaling 547 sessions overlap in time, there are circumstances when a tunnel end- 548 point has to decide whether it should proceed with the end-to-end 549 signaling session while it is still waiting for results of the tunnel 550 session. Sequential mode and parallel mode are two basic options for 551 this problem. In sequential mode, end-to-end signaling pauses when 552 it is waiting for results of tunnel signaling, and resumes upon 553 receipt of the tunnel signaling outcome. In parallel mode, end-to- 554 end signaling continues outside the tunnel while tunnel signaling is 555 still in process and its outcome is unknown. The parallel mode may 556 lead to reduced signaling delays if the QoS resources in the tunnel 557 path are sufficient compared to the rest of the end-to-end path. If 558 the QoS resources in the tunnel path are more constraint than the 559 rest of the end-to-end path, however, the parallel mode may lead to 560 wasted end-to-end signaling or necessitates re-negotiation after the 561 tunnel signaling outcome becomes available. In those cases, the 562 signaling flow of the parallel mode also tends to be more 563 complicated. This document adopts a sequential mode approach. In 564 addition, the actual signaling process uses the QoS NSLP message 565 binding mechanism [I-D.ietf-nsis-qos-nslp] to convey the dependency 566 relationship between corresponding messages of the tunnel session and 567 the end-to-end session. 569 4.3. Tunnel Flow ID for Different IP Tunneling Protocols 571 A tunnel Flow ID identifies the end-to-end flow for packet 572 classification within the tunnel. The tunnel Flow ID is based on a 573 set of tunnel header fields. Different tunnel Flow ID can be chosen 574 for different tunneling mechanisms in order to minimize the 575 classification overhead. This document specifies the following Flow 576 ID formats for the respective tunneling protocols. 578 o For IPv6 tunneling protocols (IPv6GEN), the tunnel Flow ID 579 consists of the tunnel entry-point IPv6 address and the tunnel 580 exit-point IPv6 address plus a unique IPv6 flow label [RFC3697]. 581 o For IPSEC tunnel mode (IPSEC), the tunnel Flow ID contains the 582 tunnel entry-point IP address and the tunnel exit-point IP address 583 plus the Security Parameter Index (SPI). 584 o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4, 585 MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional 586 UDP header between the tunnel header and the original packet. The 587 Flow ID consists of the tunnel entry-point and tunnel exit-point 588 IP addresses and the source port number in the additional UDP 589 header. In these cases, it is especially important that the 590 tunnel exit-point also understands the additional UDP 591 encapsulation, and therefore can correctly decapsulate both the 592 normal tunnel header and the additional UDP header. In other 593 words, both tunnel end-points need to be NSIS-tunnel-aware. 595 The above recommendations about choosing tunnel Flow ID apply to 596 dynamically created QoS tunnel sessions. For pre-configured QoS 597 tunnel sessions, the corresponding Flow ID is determined by the 598 configuration mechanism itself. For example, if the tunnel QoS is 599 DiffServ based, the DiffServ Code Point (DSCP) field value may be 600 used to identify the corresponding tunnel session. 602 5. NSIS Operation over Tunnels with Pre-configured QoS Sessions 604 When tunnel QoS is managed by pre-configured QoS sessions, both the 605 tunnel entry-point and tunnel exit-point also need to be configured 606 with the Flow ID of the tunnel QoS session. This is to enable the 607 tunnel end-points to correctly perform matching encapsulating and 608 decapsulating operations. The procedures of NSIS operating over 609 tunnels with pre-configured QoS sessions are slightly different 610 depending on whether the end-to-end NSIS signaling is sender- 611 initiated or receiver-initiated. But in either case, it is the 612 tunnel entry-point that first creates the mapping between a tunnel 613 session and an end-to-end session. 615 5.1. Sender-initiated Reservation 616 Figure 6 illustrates the signaling sequence when end-to-end signaling 617 outside the tunnel is sender-initiated. Upon receiving a RESERVE 618 message from the sender, Tentry checks tunnel QoS configuration, 619 determines whether and how this end-to-end session can be mapped to a 620 pre-configured tunnel session. The mapping criteria are part of the 621 pre-configuration and outside the scope of this document. Tentry 622 then tunnels the RESERVE message to Texit. Texit forwards the 623 RESERVE message to the receiver. The receiver replies with a 624 RESPONSE message which arrives at Texit, Tentry and finally the 625 sender. If the RESPONSE message that Tentry receives confirms that 626 the overall signaling is successful, Tentry starts to encapsulate all 627 incoming packets of the data flow using the tunnel Flow ID 628 corresponding to the mapped tunnel session. Texit knows how to 629 decapsulate the tunnel packets because it recognizes the mapped 630 tunnel Flow ID based on information supplied during tunnel session 631 pre-configuration. 633 Sender Tentry Tmid Texit Receiver 635 | | | | | 636 | RESERVE | | | | 637 +------------->| | | | 638 | | RESERVE | | 639 | +---------------------------->| | 640 | | | | RESERVE | 641 | | | +------------->| 642 | | | | RESPONSE | 643 | | | |<-------------+ 644 | | RESPONSE | | 645 | |<----------------------------+ | 646 | RESPONSE | | | | 647 |<-------------+ | | | 648 | | | | | 649 | | | | | 651 Figure 6: Sender-initiated End-to-end Session with Pre-configured 652 Tunnel QoS Sessions 654 5.2. Receiver-initiated Reservation 656 Figure 7 shows the signaling sequence when end-to-end signaling 657 outside the tunnel is receiver-initiated. Upon receiving the first 658 end-to-end Query message, Tentry examines the tunnel QoS 659 configuration, updates and tunnels the Query message to Texit. Texit 660 decapsulates the QUERY message, processes it and forwards it toward 661 the receiver. Later, the receiver sends back a RESERVE message 662 passing through Texit and arriving at Tentry. Tentry decides on 663 whether and how the QoS request for this end-to-end session can be 664 mapped to a pre-configured tunnel session based on an algorithm 665 outside the scope of this document. Then Tentry tunnels the RESERVE 666 message to Texit which forwards it to the receiver. The signaling 667 continues until a RESPONSE message arrives at Tentry, Texit and 668 finally the receiver. If the RESPONSE message that Tentry receives 669 confirms that the overall signaling is successful, Tentry starts to 670 encapsulate all incoming packets of the data flow using the tunnel 671 Flow ID corresponding to the mapped tunnel session. Similarly, Texit 672 knows how to decapsulate the tunnel packets because it recognizes the 673 mapped tunnel Flow ID based on information supplied during tunnel 674 session pre-configuration. 676 Sender Tentry Tmid Texit Receiver 678 | | | | | 679 | QUERY | | | | 680 +------------->| | | | 681 | | QUERY | | 682 | +---------------------------->| | 683 | | | | QUERY | 684 | | | +------------->| 685 | | | | RESERVE | 686 | | | |<-------------+ 687 | | RESERVE | | 688 | |<----------------------------+ | 689 | RESERVE | | | | 690 |<-------------+ | | | 691 | RESPONSE | | | | 692 +------------->| | | | 693 | | RESPONSE | | 694 | +---------------------------->| | 695 | | | | RESPONSE | 696 | | | +------------->| 697 | | | | | 698 | | | | | 700 Figure 7: Receiver-initiated End-to-end Session with Pre-configured 701 Tunnel QoS Sessions 703 Since tunnel QoS signaling is not involved in pre-configured QoS 704 tunnels, Figure 6 and Figure 7 look as if the tunnel is a single 705 virtual link. The signaling path simply skips all tunnel 706 intermediate nodes. However, both Tentry and Texit need to deploy 707 NSIS-tunnel related functionalities described above, including acting 708 on the end-to-end NSIS signaling messages based on tunnel QoS status, 709 mapping end-to-end and tunnel QoS sessions, and correctly 710 encapsulating and decapsulating tunnel packets according to the 711 tunnel protocol and the configured tunnel Flow ID. 713 6. NSIS Operation over Tunnels with Dynamically Created QoS Sessions 715 When there are no pre-configured tunnel QoS sessions, a tunnel can 716 apply the same NSIS QoS signaling mechanism used for the end-to-end 717 path to manage the QoS inside the tunnel. The tunnel NSIS signaling 718 involves only those NSIS nodes in the tunnel forwarding path. The 719 Flow IDs for the tunnel signaling are based on tunnel header fields. 720 NSIS peer discovery messages inside the tunnel distinguish themselves 721 using the tunnel header fields, which solves the problem for tunnel 722 intermediate NSIS nodes to intercept signaling messages. 724 When tunnel end-points dynamically create tunnel QoS sessions, the 725 initiation mode of the tunnel session always follows the initiation 726 mode of the end-to-end session. Specifically, when the end-to-end 727 session is sender-initiated, the tunnel session should also be 728 sender-initiated; when the end-to-end session is receiver-initiated, 729 the tunnel session should also be receiver-initiated. 731 The tunnel entry-point conveys the corresponding tunnel Flow ID 732 associated with an end-to-end session to the tunnel exit-point during 733 the tunnel signaling process. The tunnel entry-point also informs 734 the binding between the corresponding tunnel session and the end-to- 735 end session to the exit-point through the BOUND_SESSION_ID QoS NSLP 736 message object. The reservation message dependencies between the 737 tunnel session and end-to-end session is resolved using the MSG_ID 738 and BOUND_MSG_ID objects of the QoS NSLP message binding mechanism. 740 6.1. Sender-initiated Reservation 742 Figure 8 shows the typical messaging sequence of how NSIS operates 743 over IP tunnels when both end-to-end session and tunnel session are 744 sender-initiated. Tunnel signaling messages are distinguished from 745 end-to-end messages by a prime symbol after the message name. The 746 sender first sends an end-to-end RESERVE message (1) which arrives at 747 Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel 748 session and associates the end-to-end session with the tunnel 749 session. Tentry then sends a tunnel RESERVE' message (2) matching 750 the request of the end-to-end session towards Texit to reserve tunnel 751 resources. This RESERVE' message (2) includes a MSG_ID object which 752 contains a randomly generated 128-bit MSG_ID. Meanwhile, Tentry 753 inserts a BOUND_MSG_ID object containing the same MSG_ID as well as a 754 BOUND_SESSION_ID object containing the Session ID of the tunnel 755 session into the original RESERVE message, and sends this RESERVE 756 message (3) towards Texit using normal tunnel encapsulation. The 757 Message_Binding_Type flag of both the MSG_ID and BOUND_MSG_ID objects 758 in the RESERVE' and RESERVE messages (2, 3) is SET, indicating a 759 bidirectional binding. The tunnel RESERVE' message (2) is processed 760 hop-by-hop inside the tunnel for the flow identified by the chosen 761 tunnel Flow ID, while the end-to-end RESERVE message (3) passes 762 through the tunnel intermediate nodes (Tmid) just like other tunneled 763 packets. These two messages could arrive at Texit in different 764 orders, and the reaction of Texit in these different situations 765 should combine the tunnel QoS message processing rules with the QoS 766 NSLP processing principles for message binding 767 [I-D.ietf-nsis-qos-nslp], as illustrated below. 769 Sender Tentry Tmid Texit Receiver 771 | | | | | 772 | RESERVE(1) | | | | 773 +------------->| | | | 774 | | RESERVE'(2) | | | 775 | +=============>| | | 776 | | | RESERVE'(2) | | 777 | | +=============>| | 778 | | RESERVE(3) | | 779 | +---------------------------->| | 780 | | | RESPONSE'(4) | | 781 | | |<=============+ | 782 | | RESPONSE'(4) | | | 783 | |<=============+ | | 784 | | | | RESERVE(5) | 785 | | | +------------->| 786 | | | | RESPONSE(6) | 787 | | | |<-------------+ 788 | | RESPONSE(6) | | 789 | |<----------------------------+ | 790 | RESPONSE(6) | | | | 791 |<-------------+ | | | 792 | | | | | 793 | | | | | 795 (1,5): RESERVE w/o BOUND_MSG_ID and BOUND_SESSION_ID 796 (2): RESERVE' w/ MSG_ID 797 (3): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID 799 Figure 8: Sender-initiated Reservation for Both End-to-end and Tunnel 800 Signaling 802 The first possibility is shown in the example messaging flow of 803 Figure 8, where the tunnel RESERVE' message (2), aka the triggering 804 message in QoS NSLP message binding terms, arrives first. Since the 805 message binding is bidirectional, Texit records the MSG_ID of the 806 RESERVE' message (2), enques it and starts a MsgIDWait timer waiting 807 for the end-to-end RESERVE message (3), aka the bound signaling 808 message in QoS NSLP message binding terms. The timer value is set to 809 the default retransmission timeout period QOSNSLP_REQUEST_RETRY. 810 When the end-to-end RESERVE message (3) arrives, Texit notices that 811 there is an existing stored MSG_ID which matches the MSG_ID in the 812 BOUND_MSG_ID object of the incoming RESERVE message (3). Therefore 813 the message binding condition has been satisfied. Texit resumes 814 processing of the tunnel RESERVE' message (2), creates the 815 reservation state for the tunnel session, and sends a tunnel 816 RESPONSE' message (4) to Tentry. At the same time, Texit checks the 817 BOUND_SESSION_ID object of the end-to-end RESERVE message (3) and 818 records the binding of the corresponding tunnel session with the end- 819 to-end session. Texit also updates the end-to-end RESERVE message 820 based on the result of the tunnel session reservation, removes its 821 tunnel BOUND_SESSION_ID and BOUND_MSG_ID object and forwards the end- 822 to-end RESERVE message (5) along the path towards the receiver. When 823 the receiver receives the end-to-end RESERVE message (5), it sends an 824 end-to-end RESPONSE message (6) back to the sender. 826 The second possibility is that the end-to-end RESERVE message arrives 827 before the tunnel RESERVE' message at Texit. In that case, Texit 828 notices a BOUND_SESSION_ID object and a BOUND_MSG_ID object in the 829 end-to-end RESERVE message, but realizes that the tunnel session does 830 not exist yet. So Texit enques the RESERVE message and starts a 831 MsgIDWait timer. The timer value is set to the default 832 retransmission timeout period QOSNSLP_REQUEST_RETRY. When the 833 corresponding tunnel RESERVE' message arrives with a MSG_ID matching 834 that of the outstanding BOUND_MSG_ID object, the message binding 835 condition is satisfied. Texit sends a tunnel RESPONSE' message back 836 to Tentry and updates the end-to-end RESERVE message by incorporating 837 the result of the tunnel session reservation, as well as removing the 838 tunnel BOUND_SESSION_ID and BOUND_MSG_ID objects. Texit then 839 forwards the end-to-end RESERVE message along the path towards the 840 receiver. When the receiver receives the end-to-end RESERVE message, 841 it sends an end-to-end RESPONSE message back to the sender. 843 Yet another possibility is that the tunnel RESERVE' message arrives 844 at Texit first but the end-to-end RESERVE message never arrives. In 845 that case, the MsgIDWait timer for the queued tunnel RESERVE' message 846 will expire. Texit should send a tunnel RESPONSE' message back to 847 Tentry indicating a reservation error has occurred, and discard the 848 tunnel RESERVE' message. The last possibility is that the end-to-end 849 RESERVE message arrives at Texit first but the tunnel RESERVE' 850 message never arrives. And in that case, the MsgIDWait timer for the 851 queued end-to-end RESERVE message will expire. Texit should treat 852 this situation as a local reservation failure, and according to 853 [I-D.ietf-nsis-qos-nslp], Texit as a stateful QoS NSLP should 854 generate an end-to-end RESPONSE message indicating the RESERVE error 855 to the sender. 857 Once the end-to-end and the tunnel QoS session have both been 858 successfully created and associated, the tunnel end-points Tentry and 859 Texit coordinate the signaling between the two sessions and make sure 860 that adjustment or teardown of either session may trigger similar 861 actions for the other session as necessary, by invoking appropriate 862 signaling messages. 864 6.2. Receiver-initiated Reservation 866 Figure 9 shows the typical messaging sequence of how NSIS signaling 867 operates over IP tunnels when both end-to-end and tunnel sessions are 868 receiver-initiated. Upon receiving an end-to-end QUERY message (1) 869 from the sender, Tentry chooses the tunnel Flow ID and sends a tunnel 870 QUERY' message (2) matching the request of the end-to-end session 871 towards Texit. This tunnel QUERY' message (2) is meant to discover 872 QoS characteristics of the tunnel path, rather than initiating an 873 actual reservation. Therefore, it includes a Request Identification 874 Information (RII) object but does not set the RESERVE-INIT flag. The 875 tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel 876 for the flow identified by the tunnel Flow ID. When Texit receives 877 this tunnel QUERY' message (2), it replies with a corresponding 878 tunnel RESPONSE' message (3) containing the tunnel path 879 characteristics. After receiving the tunnel RESPONSE' message (3), 880 Tentry creates the tunnel session, generates an outgoing end-to-end 881 QUERY message (4) considering the tunnel path characteristics, 882 appends a tunnel BOUND_SESSION_ID object containing the tunnel 883 Session ID, and sends it toward Texit using normal tunnel 884 encapsulation. The end-to-end QUERY message (4) passes along tunnel 885 intermediate nodes like other tunneled packets. Upon receiving this 886 end-to-end QUERY message (4), Texit notices the tunnel session 887 binding and creates the tunnel session state, removes the tunnel 888 BOUND_SESSION_ID object and forwards the end-to-end QUERY message (5) 889 further along the path. 891 The end-to-end QUERY message (5) arrives at the receiver and triggers 892 a RESERVE message (6). When Texit receives the RESERVE message (6), 893 it notices that the session is bound to a receiver-initiated tunnel 894 session. Therefore, Texit triggers a RESERVE' message (7) toward 895 Tentry for the tunnel session reservation. This tunnel RESERVE' 896 message (7) includes a randomly generated 128-bit MSG_ID. Meanwhile, 897 Texit inserts a BOUND_MSG_ID object containing the same MSG_ID and a 898 BOUND_SESSION_ID object containing the tunnel Session ID into the 899 end-to-end RESERVE message (8), and sends it towards Tentry using 900 normal tunnel encapsulation. The Message_Binding_Type flag of the 901 MSG_ID and BOUND_MSG_ID objects in the RESERVE' and RESERVE messages 902 (7,8) is SET, indicating a bidirectional binding. 904 Sender Tentry Tmid Texit Receiver 906 | | | | | 907 | QUERY(1) | | | | 908 +------------->| | | | 909 | | QUERY'(2) | | | 910 | +=============>| | | 911 | | | QUERY'(2) | | 912 | | +=============>| | 913 | | | RESPONSE'(3) | | 914 | | |<=============+ | 915 | | RESPONSE'(3) | | | 916 | |<=============+ | | 917 | | QUERY(4) | | 918 | +---------------------------->| | 919 | | | | QUERY(5) | 920 | | | +------------->| 921 | | | | RESERVE(6) | 922 | | | |<-------------+ 923 | | | RESERVE'(7) | | 924 | | |<=============+ | 925 | | RESERVE'(7) | | | 926 | |<=============+ | | 927 | | RESERVE(8) | | 928 | |<----------------------------+ | 929 | | RESPONSE'(9) | | | 930 | +=============>| | | 931 | | | RESPONSE'(9) | | 932 | | +=============>| | 933 | RESERVE(10) | | | | 934 |<-------------+ | | | 935 | RESPONSE(11) | | | | 936 +------------->| | | | 937 | | RESPONSE(11) | | 938 | +---------------------------->| | 939 | | | | RESPONSE(11) | 940 | | | +------------->| 941 | | | | | 942 | | | | | 944 (1,5): QUERY w/ RESERVE-INIT (2): QUERY' w/ RII 945 (4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID 946 (6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID 947 (8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID 949 Figure 9: Receiver-initiated Reservation for Both End-to-end and 950 Tunnel Signaling 952 At Tentry, the tunnel RESERVE' message (7) and the end-to-end RESERVE 953 message (8) could arrive in different orders. In a typical case 954 shown in Figure 9, the tunnel RESERVE' message (7) arrives first. 955 Tentry records the MSG_ID of the tunnel RESERVE' message (7) and 956 starts a MsgIDWait timer. When the end-to-end RESERVE message (8) 957 with the BOUND_MSG_ID object containing the same MSG_ID arrives, the 958 message binding condition is satisfied. Tentry resumes processing of 959 the tunnel RESERVE' message (7), creates the reservation state for 960 the tunnel session, and sends a tunnel RESPONSE' message (9) to 961 Texit. At the same time, Tentry creates the outgoing end-to-end 962 RESERVE message (10) by incorporating results of the tunnel session 963 reservation and removing the BOUND_SESSION_ID and BOUND_MSG_ID 964 objects, and forwards it along the path towards the sender. When the 965 sender receives the end-to-end RESERVE message (10), it sends an end- 966 to-end RESPONSE message (11) back to the receiver. 968 If the end-to-end RESERVE message arrives before the tunnel RESERVE' 969 message at Tentry, or either of the two messages fails to arrive at 970 Tentry, the processing rules at Tentry is similar to those of Texit 971 in the same situation discussed in Section 6.1. 973 Once the end-to-end and the tunnel QoS session have both been 974 successfully created and associated, the tunnel end-points Tentry and 975 Texit coordinate the signaling between the two sessions and make sure 976 that adjustment or teardown of either session can trigger similar 977 actions for the other session as necessary, by invoking appropriate 978 signaling messages. 980 7. NSIS-Tunnel Signaling Capability Discovery 982 The mechanism of NSIS operating over IP tunnels requires the 983 coordination of both tunnel end-points in tasks such as special 984 encapsulation and decapsulation of data flow packets according to the 985 chosen tunnel Flow ID, as well as the possible creation and 986 adjustment of the end-to-end and tunnel QoS sessions. Therefore, one 987 NSIS-tunnel-aware end-point needs to know that the other tunnel end- 988 point is also NSIS-tunnel-aware before initiating this NSIS operating 989 over IP tunnel mechanism. In some cases, especially for IP tunnels 990 with pre-configured QoS sessions, an NSIS-tunnel-aware end-point can 991 learn about whether the other tunnel end-point is also NSIS-tunnel- 992 aware through pre-configuration. In other cases where such pre- 993 configuration is not available, the initiating NSIS-tunnel-aware end- 994 point may dynamically discover the other tunnel end-point's 995 capability through a QoS NSLP NODE_CAPABILITY object defined in this 996 section. 998 7.1. NODE_CAPABILITY Object Format 999 The NODE_CAPABILITY object contains a standard NSLP object header 1000 followed by the object value, as shown in Figure 10. 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 |A|B|r|r| Type |r|r|r|r| Length | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 |T| Reserved | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 Figure 10: NODE_CAPABILITY Object Format 1012 Type: (TBD by IANA) 1014 Length: 1, measured in units of 32-bit word 1016 Value: a single 'T' bit indicating the node supports the NSIS-tunnel 1017 handling mechanisms defined in this document. The reserved bits in 1018 the value field can be used to signal other node characteristics in 1019 the future. 1021 The bits marked 'A' and 'B' define the desired behavior for objects 1022 whose Type field is not recognized. If a node does not recognize the 1023 NODE_CAPABILITY object, the desired behavior is "Ignore". That is, 1024 the object must be deleted and the rest of the message processed as 1025 usual. This can be satisfied by setting 'AB' to '01'. 1027 7.2. Using NODE_CAPABILITY Object 1029 The NODE_CAPABILITY object is included in a QUERY or RESERVE message 1030 by a tunnel end-point that needs to learn about the other end-point's 1031 NSIS tunnel handling capability. If the receiving tunnel end-point 1032 is indeed NSIS-tunnel-aware, it recognizes this object and knows that 1033 the sending end-point is NSIS-tunnel-aware. The receiving tunnel 1034 end-point places the same object in a RESPONSE message to inform the 1035 sending end-point that it is also NSIS-tunnel-aware. The use of the 1036 NODE_CAPABILITY object in the cases of sender-initiated reservation 1037 and receiver-initiated reservation are further detailed below. 1039 First, assume that the end-to-end session is sender-initiated and an 1040 NSIS-tunnel-aware Tentry wants to discover the NSIS-tunnel capability 1041 of Texit (e.g., in Figure 8). After receiving the first end-to-end 1042 RESERVE message and without initiating a tunnel RESERVE' message, 1043 Tentry inserts an RII object and a NODE_CAPABILITY object with T bit 1044 set into the end-to-end RESERVE message and sends it to Texit. When 1045 Texit receives this RESERVE message, if it is also NSIS-tunnel-aware, 1046 it learns that Tentry is NSIS-tunnel-aware and includes the same 1047 object with T bit set in the following end-to-end RESPONSE message 1048 sent back to Tentry. Otherwise, Texit ignores and deletes the 1049 NODE_CAPABILITY object. When Tentry receives the RESPONSE message, 1050 it knows whether Texit is NSIS-tunnel-aware by checking the T bit in 1051 the NODE_CAPABILITY object. 1053 Second, assume that the end-to-end session is receiver-initiated and 1054 the NSIS-tunnel-aware Tentry wants to discover the NSIS-tunnel 1055 capability of Texit (e.g., in Figure 9). Upon receiving the first 1056 end-to-end QUERY message and without initiating a tunnel QUERY' 1057 message, Tentry includes an RII object and a NODE_CAPABILITY object 1058 with T bit set in the end-to-end QUERY message and sends it toward 1059 Texit. If Texit is NSIS-tunnel-aware, it learns from the 1060 NODE_CAPABILITY object that Tentry is also NSIS-tunnel-aware and 1061 includes the same object with T bit in the later end-to-end RESERVE 1062 message sent to Tentry. Otherwise, Texit ignores and deletes the 1063 NODE_CAPABILITY object. When Tentry receives the end-to-end RESERVE 1064 message, it knows whether Texit is NSIS-tunnel-aware by checking the 1065 T bit in the NODE_CAPABILITY object. 1067 8. IANA Considerations 1069 This document defines a new object type called NODE_CAPABILITY for 1070 QoS NSLP. Its Type value needs to be assigned by IANA. The object 1071 format and the setting of the extensibility bits are defined in 1072 Section 7. 1074 9. Security Considerations 1076 This draft does not raise new security threats. Security 1077 considerations for NSIS NTLP and QoS NSLP are discussed in 1078 [I-D.ietf-nsis-ntlp] and [I-D.ietf-nsis-qos-nslp], respectively. 1079 General threats for NSIS can be found in [RFC4081]. 1081 10. Acknowledgements 1083 The authors would like to thank Roland Bless, Hannes Tschofenig, 1084 Georgios Karagiannis and other members of the NSIS working group for 1085 comments to this work. 1087 11. References 1088 11.1. Normative References 1090 [I-D.ietf-nsis-ntlp] 1091 Schulzrinne, H. and M. Stiemerling, "GIST: General 1092 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1093 (work in progress), June 2009. 1095 [I-D.ietf-nsis-qos-nslp] 1096 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1097 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 1098 (work in progress), January 2010. 1100 11.2. Informative References 1102 [I-D.ietf-nsis-applicability-mobility-signaling] 1103 Sanda, T., Fu, X., Jeong, S., Manner, J., and H. 1104 Tschofenig, "Applicability Statement of NSIS Protocols in 1105 Mobile Environments", 1106 draft-ietf-nsis-applicability-mobility-signaling-14 (work 1107 in progress), January 2010. 1109 [I-D.ietf-nsis-nslp-natfw] 1110 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1111 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1112 draft-ietf-nsis-nslp-natfw-23 (work in progress), 1113 February 2010. 1115 [I-D.ietf-nsis-qspec] 1116 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 1117 Template", draft-ietf-nsis-qspec-24 (work in progress), 1118 January 2010. 1120 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1121 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1123 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1124 Routing Encapsulation over IPv4 networks", RFC 1702, 1125 October 1994. 1127 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 1129 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1130 October 1996. 1132 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1133 October 1996. 1135 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1136 February 1997. 1138 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1139 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1140 Functional Specification", RFC 2205, September 1997. 1142 [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC 1143 Data Flows", RFC 2207, September 1997. 1145 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1146 Internet Protocol", RFC 2401, November 1998. 1148 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1149 IPv6 Specification", RFC 2473, December 1998. 1151 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1152 RFC 2711, October 1999. 1154 [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, 1155 "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. 1157 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1158 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1159 March 2000. 1161 [RFC3220] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, 1162 January 2002. 1164 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 1165 "IPv6 Flow Label Specification", RFC 3697, March 2004. 1167 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1168 Bosch, "Next Steps in Signaling (NSIS): Framework", 1169 RFC 4080, June 2005. 1171 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1172 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1174 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1175 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1177 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1178 Internet Protocol", RFC 4301, December 2005. 1180 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1181 RFC 4303, December 2005. 1183 Authors' Addresses 1185 Charles Shen 1186 Columbia University 1187 Department of Computer Science 1188 1214 Amsterdam Avenue, MC 0401 1189 New York, NY 10027 1190 USA 1192 Phone: +1 212 854 3109 1193 Email: charles@cs.columbia.edu 1195 Henning Schulzrinne 1196 Columbia University 1197 Department of Computer Science 1198 1214 Amsterdam Avenue, MC 0401 1199 New York, NY 10027 1200 USA 1202 Phone: +1 212 939 7004 1203 Email: hgs@cs.columbia.edu 1205 Sung-Hyuck Lee 1206 SAMSUNG Advanced Institute of Technology 1207 San 14-1, Nongseo-ri, Giheung-eup 1208 Yongin-si, Gyeonggi-do 449-712 1209 KOREA 1211 Phone: +82 31 280 9552 1212 Email: starsu.lee@samsung.com 1214 Jong Ho Bang 1215 SAMSUNG Advanced Institute of Technology 1216 San 14-1, Nongseo-ri, Giheung-eup 1217 Yongin-si, Gyeonggi-do 449-712 1218 KOREA 1220 Phone: +82 31 280 9585 1221 Email: jh0278.bang@samsung.com