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