idnits 2.17.1 draft-ietf-nsis-tunnel-12.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2010) is 5043 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: January 7, 2011 S. Lee 6 J. Bang 7 Samsung AIT 8 July 6, 2010 10 NSIS Operation Over IP Tunnels 11 draft-ietf-nsis-tunnel-12.txt 13 Abstract 15 NSIS Quality of Service (QoS) signaling enables applications to 16 perform QoS reservation along a data flow path. When the data flow 17 path contains IP tunnel segments, NSIS QoS signaling has no effect 18 within those tunnel segments and the resulting tunnel segments could 19 become the weakest QoS link which may invalidate the QoS efforts in 20 the rest of the end-to-end path. The problem with NSIS signaling 21 within the tunnel is caused by the tunnel encapsulation which masks 22 packets' original IP header fields. Those original IP header fields 23 are 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 January 7, 2011. 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 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6 79 3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 8 80 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10 82 4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11 83 4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13 84 5. NSIS Operation over Tunnels with Pre-configured QoS 85 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14 87 5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15 88 6. NSIS Operation over Tunnels with Dynamically Created QoS 89 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 17 91 6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 19 92 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 IP tunneling is a technique that allows a packet to be encapsulated 104 and carried as payload within an IP packet. The resulting 105 encapsulated packet is called an IP tunnel packet, and the packet 106 being tunneled is called the original packet. In typical scenarios, 107 IP tunneling is used to exert explicit forwarding path control (e.g., 108 in Mobile IP [RFC3344]), facilitate the secure IP delivery 109 architecture (e.g., in IPsec [RFC4301]), and help packet routing in 110 IP networks of different characteristics (e.g., between IPv6 and IPv4 111 networks [RFC4213]). 113 This document considers the situation when the packet being tunneled 114 contains a Next Step In Signaling (NSIS) [RFC4080] message. NSIS is 115 an IP network layer signaling architecture consisting of a Generic 116 Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer 117 for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) 118 sub-layer customizable for different applications. We focus on the 119 Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides 120 functionalities that extend those of the earlier RSVP [RFC2205] 121 signaling. In this document the term "NSIS" and "NSIS QoS" are used 122 interchangeably. 124 Without additional efforts, NSIS signaling does not work within IP 125 tunnel segments of a signaling path. The reason is that tunnel 126 encapsulation masks the original packet including its header and 127 payload. However, information from the original packet is required 128 both for NSIS peer node discovery and for QoS data flow packet 129 classification. Without access to information from the original 130 packet, an IP tunnel acts as an NSIS-unaware virtual link in the end- 131 to-end NSIS signaling path. 133 This document defines a mechanism to extend end-to-end NSIS signaling 134 for QoS reservation into IP tunnels. The NSIS-aware IP tunnel end- 135 points that support this mechanism are called NSIS-tunnel-aware end- 136 points. There are two main operation modes. On one hand, if the 137 tunnel already has pre-configured QoS sessions, the NSIS-tunnel-aware 138 end-points map end-to-end QoS signaling requests directly to existing 139 tunnel sessions as long as there are enough tunnel session resources; 140 on the other hand, if no pre-configured tunnel QoS sessions are 141 available, the NSIS-tunnel-aware end-points dynamically initiate and 142 maintain tunnel QoS sessions that are then associated with the 143 corresponding end-to-end QoS sessions. Note that whether the tunnel 144 pre-configures QoS sessions or not, and which pre-configured tunnel 145 QoS sessions a particular end-to-end QoS signaling request should be 146 mapped to are policy issues out of scope of this document. 148 The rest of this document is organized as follows. Section 2 defines 149 terminology. Section 3 presents the problem statement including 150 common IP tunneling protocols and existing behavior of NSIS QoS 151 signaling operating over IP tunnels. Section 4 introduces the design 152 requirements and overall approach of our mechanism. More details 153 about how NSIS QoS signaling operates with tunnels that use pre- 154 configured QoS and dynamic QoS signaling are provided in Section 5 155 and Section 6. Section 7 describes a method to automatically 156 discover whether a tunnel end-point node supports the NSIS-tunnel 157 interoperation mechanism defined in this document. Section 8 158 discusses IANA considerations and Section 9 considers security. 160 2. Terminology 162 This document uses terminology defined in [RFC2473], 163 [I-D.ietf-nsis-ntlp], and [I-D.ietf-nsis-qos-nslp]. In addition, the 164 following terms are used: 166 IP Tunnel: A tunnel configured as a virtual link between two IP 167 nodes, on which the encapsulating protocol is IP. 169 Tunnel IP Header: The IP header prepended to the original packet 170 during encapsulation. It specifies the tunnel end-points as 171 source and destination. 173 Tunnel Specific Header: The header fields inserted by the 174 encapsulation mechanism after the tunnel IP header and before the 175 original packet. These headers may or may not exist depending on 176 the specific tunnel mechanism used. 178 Tunnel Intermediate Node (Tmid): A node which resides in the middle 179 of the forwarding path between the tunnel entry-point node and the 180 tunnel exit-point node. 182 Flow Identifier (Flow ID): The set of header fields which is used to 183 identify a [data] flow. For example, it may include flow sender 184 and receiver addresses, protocol and port numbers. 186 End-to-end QoS Signaling: The signaling process that manipulates the 187 QoS control information in the end-to-end path from the flow 188 sender to the flow receiver. When the end-to-end flow path 189 contains tunnel segments, this document uses end-to-end QoS 190 signaling to refer specially to the QoS signaling outside the 191 tunnel segments. This document uses "end-to-end QoS signaling" 192 and "end-to-end signaling" interchangeably. 194 Tunnel QoS Signaling: The signaling process that manipulates the QoS 195 control information in the path inside a tunnel, between the 196 tunnel entry-point and the tunnel exit-point nodes. This document 197 uses "tunnel QoS signaling" and "tunnel signaling" 198 interchangeably. 200 NSIS-aware Node: A node that supports NSIS signaling. 202 NSIS-aware Tunnel End-point Node: A tunnel end-point node which is 203 also an NSIS node. 205 NSIS-tunnel-aware Tunnel End-point Node: An NSIS-aware Tunnel End- 206 point node which also supports the mechanism for NSIS operating 207 over IP tunnels defined in this document. This document uses 208 "NSIS-tunnel-aware tunnel end-point node" and "NSIS-tunnel-aware 209 end-point node" interchangeably. 211 3. Problem Statement 213 3.1. IP Tunneling Protocols 215 Tunnel from node B to node D 216 <----------------------> 217 Tunnel Tunnel Tunnel 218 Entry-Point Intermediate Exit-Point 219 Node Node Node 220 +-+ +-+ +-+ +-+ +-+ 221 |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| 222 +-+ +-+ +-+ +-+ +-+ 223 Original Original 224 Packet Packet 225 Source Destination 226 Node Node 228 Figure 1: IP Tunnel 230 The following definition of IP tunneling is derived from [RFC2473] 231 and adapted for both IPv4 and IPv6. 233 IP tunneling (Figure 1) is a technique for establishing a "virtual 234 link" between two IP nodes for transmitting data packets as payloads 235 of IP packets. From the point of view of the two nodes, this 236 "virtual link", called an IP tunnel, appears as a point-to-point link 237 on which IP acts like a link-layer protocol. The two IP nodes play 238 specific roles. One node encapsulates original packets received from 239 other nodes or from itself and forwards the resulting tunnel packets 240 through the tunnel. The other node decapsulates the received tunnel 241 packets and forwards the resulting original packets towards their 242 destinations, possibly itself. The encapsulating node is called the 243 tunnel entry-point node (Tentry), and it is the source of the tunnel 244 packets. The decapsulating node is called the tunnel exit-point node 245 (Texit), and it is the destination of the tunnel packets. 247 An IP tunnel is a unidirectional mechanism - tunnel packet flow takes 248 place in one direction between the IP tunnel entry-point and exit- 249 point nodes. Bi-directional tunneling is achieved by combining two 250 unidirectional mechanisms, that is, configuring two tunnels, each in 251 opposite direction to the other - the entry-point node of one tunnel 252 is the exit-point node of the other tunnel. 254 Figure 2 illustrates the original packet and the resulting tunnel 255 packet. In a tunnel packet, the original packet is encapsulated 256 within the tunnel header. The tunnel header contains two components, 257 the tunnel IP header and other tunnel specific headers. The tunnel 258 IP header specifies tunnel entry-point node as IP source address and 259 tunnel exit-point node as IP destination address, causing the tunnel 260 packet to be forwarded in the tunnel. The tunnel specific header 261 between the tunnel IP header and the original packet is optional, 262 depending on the tunneling protocol in use. 264 +----------------------------------//-----+ 265 | Original | | 266 | | Original Packet Payload | 267 | Header | | 268 +----------------------------------//-----+ 269 < Original Packet > 270 | 271 v 272 < Tunnel Headers > < Original Packet > 273 +---------+-----------+-------------------------//--------------+ 274 | Tunnel | Tunnel | | 275 | IP | Specific | Original Packet | 276 | Header | Header | | 277 +---------+-----------+-------------------------//--------------+ 278 < Tunnel IP Packet > 280 Figure 2: IP Tunnel Encapsulation 282 Commonly used IP tunneling protocols include Generic Routing 283 Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation 284 over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP 285 (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP 286 (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], 287 Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] 288 and IPsec tunneling mode (IPsec) [RFC4301][RFC4303]. Among these 289 tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4 and 290 IPv6GEN contain only a tunnel IP header, and no tunnel specific 291 header. All the other tunneling protocols have a tunnel header 292 consisting of both a tunnel IP header and a tunnel specific header. 293 The tunnel specific header is the GRE header for GRE and GREIPv4, the 294 minimum encapsulation header for MINENC and the Encapsulation 295 Security Payload (ESP) header for IPsec tunneling mode. As will be 296 discussed in Section 4.3, some of the tunnel specific headers may be 297 used to identify a flow in the tunnel and facilitate NSIS operating 298 over IP tunnels. 300 3.2. NSIS QoS Signaling in the Presence of IP Tunnels 302 Typically, applications use NSIS QoS signaling to reserve resources 303 for a flow along the flow path. NSIS QoS signaling can be initiated 304 by either the flow sender or flow receiver. Figure 3 shows an 305 example scenario with five NSIS nodes, including flow sender node A, 306 flow receiver node E, and intermediate NSIS nodes B, C and D. Nodes 307 which are not NSIS QoS capable are not shown. 309 NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS 310 Node Node Node Node Node 311 +-+ +-+ +-+ +-+ +-+ 312 |A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E| 313 +-+ +-+ +-+ +-+ +-+ 314 Flow Flow 315 Sender Receiver 316 Node Node 318 Figure 3: Example Scenario of NSIS QoS Signaling 320 Figure 4 illustrates a sender-initiated signaling sequence in the 321 scenario of Figure 3. Sender node A sends a RESERVE message towards 322 receiver node E. The RESERVE message gets forwarded by intermediate 323 NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver 324 node E then sends back a RESPONSE message confirming the QoS 325 reservation, again through the previous intermediate NSIS nodes in 326 the flow path. 328 There are two important aspects in the above signaling process that 329 are worth mentioning. First, the flow sender does not initially know 330 exactly which intermediate nodes are NSIS-aware and should be 331 involved in the signaling process for a flow from node A to node E. 332 Discovery of those nodes, namely nodes B, C and D is accomplished by 333 a separate NSIS peer discovery process (not shown above, see 335 [I-D.ietf-nsis-ntlp]). The NSIS peer discovery messages contain 336 special IP header and payload format or include a Router Alert Option 337 (RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery 338 messages allow nodes B, C and D to intercept them and subsequently 339 insert themselves into the signaling path for the flow in question. 340 After formation of the signaling path, all signaling messages 341 corresponding to this flow will be passed to these nodes for 342 processing. Other nodes which are not NSIS-aware simply forward all 343 signaling messages like any other IP packets without additional 344 handling. 346 Node A Node B Node C Node D Node E 347 | | | | | 348 | RESERVE | | | | 349 +------------->| | | | 350 | | RESERVE | | | 351 | +------------->| | | 352 | | | RESERVE | | 353 | | +------------->| | 354 | | | | RESERVE | 355 | | | +------------->| 356 | | | | RESPONSE | 357 | | | |<-------------+ 358 | | | RESPONSE | | 359 | | |<-------------+ | 360 | | RESPONSE | | | 361 | |<-------------+ | | 362 | RESPONSE | | | | 363 |<-------------+ | | | 364 | | | | | 365 | | | | | 367 Figure 4: Sender-initiated NSIS QoS Signaling 369 Second, the goal of QoS signaling is to install control information 370 to give QoS treatment for the flow being signaled. Basic QoS control 371 information includes the data Flow ID for packet classification and 372 the type of QoS treatment those packets are entitled to. The Flow ID 373 contains a set of header fields such as flow sender and receiver 374 addresses, protocol and port numbers. 376 Now consider Figure 5 where nodes B, C and D are end-points and 377 intermediate nodes of an IP tunnel. During the signaling path 378 discovery process, node B can still intercept and process NSIS peer 379 discovery messages if it recognizes them before performing tunnel 380 encapsulation; node D can identify NSIS peer discovery messages after 381 performing tunnel decapsulation. A tunnel intermediate node such as 382 node C, however, only sees the tunnel header of the packets and will 383 not be able to identify the original NSIS peer discovery message or 384 insert itself in the flow signaling path. Furthermore, the Flow ID 385 of the original flow is based on IP header fields of the original 386 packet. Those fields are also hidden in the payload of the tunnel 387 packet. So there is no way node C can classify packets belonging to 388 that flow in the tunnel. In summary, the problem is that tunnel 389 intermediate nodes are unable to intercept original NSIS signaling 390 messages and unable to classify original data flow packets as a 391 result of tunnel encapsulation. An IP tunnel segment appears just 392 like a QoS-unaware virtual link. Since the best QoS of an end-to-end 393 path is judged based on its weakest segment, leaving the tunnel path 394 without QoS risks voiding other efforts to provide QoS in the rest of 395 the path. 397 Tunnel from node B to node D 398 <----------------------> 399 Tunnel Tunnel Tunnel 400 Entry-Point Intermediate Exit-Point 401 NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS 402 Node Node Node Node Node 403 +-+ +-+ +-+ +-+ +-+ 404 |A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E| 405 +-+ +-+ +-+ +-+ +-+ 406 Flow Flow 407 Sender Receiver 408 Node Node 410 Figure 5: Example Scenario of NSIS QoS Signaling with IP Tunnel 412 4. Design Overview 414 4.1. Design Requirements 416 We identify the following design requirements for NSIS operating over 417 IP tunnels. 419 o The mechanism should work with all common IP tunneling protocols 420 listed in Section 3.1. 421 o Some IP tunnels maintain pre-configured QoS sessions inside the 422 tunnel. The mechanism should work for IP tunnels both with and 423 without pre-configured tunnel QoS sessions. 424 o The mechanism should minimize the required upgrade to existing 425 infrastructure in order to facilitate its deployment. 426 Specifically, we should limit the necessary upgrade to the tunnel 427 end-points. 428 o The mechanism should provide a method for one NSIS-tunnel-aware 429 end-point to discover whether the other end-point is also NSIS- 430 tunnel-aware, when necessary. 431 o The mechanism should learn from design experience of previous work 432 on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746], while also 433 addressing the following major differences of NSIS from RSVP. 434 First, NSIS is designed as a generic framework to accommodate 435 various signaling application needs, and therefore is split into a 436 signaling transport layer and a signaling application layer; RSVP 437 does not have a layer split and is designed only for QoS 438 signaling. Second, NSIS QoS NSLP allows both sender-initiated and 439 receiver-initiated reservations; RSVP only supports receiver- 440 initiated reservations. Third, NSIS deals only with unicast; RSVP 441 also supports multicast. Fourth, NSIS integrates a new Session ID 442 feature which is different from the session identification concept 443 in RSVP. 445 4.2. Overall Design Approach 447 The overall design of this NSIS signaling and IP tunnel interworking 448 mechanism draws similar concepts from RSVP-TUNNEL [RFC2746], but is 449 tailored and extended for NSIS operation. 451 Since a flow is considered unidirectional, to accommodate flows in 452 both directions of a tunnel, we require both tunnel entry-point and 453 tunnel exit-point to be NSIS-tunnel-aware. An NSIS-tunnel-aware end- 454 point knows whether the other tunnel end-point is NSIS-tunnel-aware 455 either through pre-configuration or through an NSIS-tunnel capability 456 discovery mechanism defined in Section 7. 458 Tunnel end-points need to always intercept NSIS peer discovery 459 messages and insert themselves into the NSIS signaling path so they 460 can receive all NSIS signaling messages and coordinate their 461 interaction with tunnel QoS. 463 To facilitate QoS handling in the tunnel, an end-to-end QoS session 464 is mapped to a tunnel QoS session, either pre-configured or 465 dynamically created. The tunnel session uses a tunnel Flow ID based 466 on information available in the tunnel headers, thus allowing tunnel- 467 intermediate nodes to classify flow packets correctly. 469 For tunnels that maintain pre-configured QoS sessions, upon receiving 470 a request to reserve resources for an end-to-end session, the tunnel 471 end-point maps the end-to-end QoS session to an existing tunnel 472 session. To simplify the design, the mapping decision is always made 473 by the tunnel entry-point regardless of whether the end-to-end 474 session uses sender-initiated or receiver-initiated NSIS signaling 475 mode. The details about which end-to-end session can be mapped to 476 which pre-configured tunnel session depend on policy mechanisms 477 outside the scope of this document. 479 For tunnels that do not maintain pre-configured QoS sessions, the 480 NSIS-tunnel-aware end-points dynamically create and manage a 481 corresponding tunnel QoS session for the end-to-end session. Since 482 the initiation mode of both QoS sessions can be sender-initiated or 483 receiver-initiated, to simplify the design, we require that the 484 initiation mode of the tunnel QoS session follows that of the end-to- 485 end QoS session. In other words, the end-to-end QoS session and its 486 corresponding tunnel QoS session are either both sender-initiated or 487 both receiver-initiated. To keep the handling mechanism consistent 488 with the case for tunnels with pre-configured QoS sessions, the 489 tunnel entry-point always initiates the mapping between the tunnel 490 session and the end-to-end session. 492 As the mapping initiator, the tunnel entry-point records the 493 association between the end-to-end session and its corresponding 494 tunnel session, both in tunnels with and without pre-configured QoS 495 sessions. This association serves two purposes, one at the signaling 496 plane and the other at the data plane. At the signaling plane, the 497 association enables the tunnel entry-point to coordinate necessary 498 interaction, such as QoS adjustment in sender-initiated reservations, 499 between the end-to-end and the tunnel QoS sessions. At the data 500 plane, the association allows the tunnel entry-point to correctly 501 encapsulate data flow packets according to the chosen tunnel Flow ID. 502 Since the tunnel Flow ID uses header fields that are visible inside 503 the tunnel, the tunnel intermediate nodes can classify the data flow 504 packets and apply appropriate QoS treatment. 506 In addition to the tunnel entry-point recording the association 507 between the end-to-end session and its corresponding tunnel session, 508 the tunnel exit-point also needs to maintain the same association for 509 similar reasons. At the signaling plane, this association at the 510 tunnel exit-point enables the interaction of the end-to-end and the 511 tunnel QoS session such as QoS adjustment in receiver-initiated 512 reservations. At the data plane, this association tells the tunnel 513 exit-point that the relevant data flow packets need to be 514 decapsulated according to the corresponding tunnel Flow ID. 516 In tunnels with pre-configured QoS sessions, the tunnel exit-point 517 may learn about the mapping information between the corresponding 518 tunnel and end-to-end QoS sessions through pre-configuration as well. 519 In tunnels without pre-configured QoS sessions, the tunnel exit-point 520 knows the mapping between the corresponding tunnel and end-to-end QoS 521 sessions through the NSIS signaling process that creates the tunnel 522 QoS sessions inside the tunnel, with the help of appropriate QoS NSLP 523 session binding and message binding mechanisms. 525 One problem for NSIS operating over IP tunnels which dynamically 526 create QoS sessions is that it involves two signaling sequences. The 527 outcome of the tunnel signaling session directly affects the outcome 528 of the end-to-end signaling session. Since the two signaling 529 sessions overlap in time, there are circumstances when a tunnel end- 530 point has to decide whether it should proceed with the end-to-end 531 signaling session while it is still waiting for results of the tunnel 532 session. Sequential mode and parallel mode are two basic options for 533 this problem. In sequential mode, end-to-end signaling pauses when 534 it is waiting for results of tunnel signaling, and resumes upon 535 receipt of the tunnel signaling outcome. In parallel mode, end-to- 536 end signaling continues outside the tunnel while tunnel signaling is 537 still in process and its outcome is unknown. The parallel mode may 538 lead to reduced signaling delays if the QoS resources in the tunnel 539 path are sufficient compared to the rest of the end-to-end path. If 540 the QoS resources in the tunnel path are more constraint than the 541 rest of the end-to-end path, however, the parallel mode may lead to 542 wasted end-to-end signaling or necessitates re-negotiation after the 543 tunnel signaling outcome becomes available. In those cases, the 544 signaling flow of the parallel mode also tends to be complicated. 545 This document adopts a sequential mode approach for the two signaling 546 sequences. 548 4.3. Tunnel Flow ID for Different IP Tunneling Protocols 550 A tunnel Flow ID identifies the end-to-end flow for packet 551 classification within the tunnel. The tunnel Flow ID is based on a 552 set of tunnel header fields. Different tunnel Flow ID can be chosen 553 for different tunneling mechanisms in order to minimize the 554 classification overhead. This document specifies the following Flow 555 ID formats for the respective tunneling protocols. 557 o For IPv6 tunneling protocols (IPv6GEN), the tunnel Flow ID 558 consists of the tunnel entry-point IPv6 address and the tunnel 559 exit-point IPv6 address plus a unique IPv6 flow label [RFC3697]. 560 o For IPsec tunnel mode (IPsec), the tunnel Flow ID contains the 561 tunnel entry-point IP address and the tunnel exit-point IP address 562 plus the Security Parameter Index (SPI). 563 o For all other tunneling protocols (GRE, GREIPv4, IPv4INIPv4, 564 MINENC, IPv6INIPv4), the tunnel entry-point inserts an additional 565 UDP header between the tunnel header and the original packet. The 566 Flow ID consists of the tunnel entry-point and tunnel exit-point 567 IP addresses and the source port number in the additional UDP 568 header. The source port number is dynamically chosen by the 569 tunnel entry-point and conveyed to the tunnel exit-point. In 570 these cases, it is especially important that the tunnel exit-point 571 understands the additional UDP encapsulation, and therefore can 572 correctly decapsulate both the normal tunnel header and the 573 additional UDP header. In other words, both tunnel end-points 574 need to be NSIS-tunnel-aware. 576 The above recommendations about choosing tunnel Flow ID apply to 577 dynamically created QoS tunnel sessions. For pre-configured QoS 578 tunnel sessions, the corresponding Flow ID is determined by the 579 configuration mechanism itself. For example, if the tunnel QoS is 580 DiffServ based, the DiffServ Code Point (DSCP) field value may be 581 used to identify the corresponding tunnel session. 583 5. NSIS Operation over Tunnels with Pre-configured QoS Sessions 585 When tunnel QoS is managed by pre-configured QoS sessions, both the 586 tunnel entry-point and tunnel exit-point need to be configured with 587 information about the Flow ID of the tunnel QoS session. This is to 588 enable the tunnel end-points to correctly perform matching 589 encapsulating and decapsulating operations. The procedures of NSIS 590 operating over tunnels with pre-configured QoS sessions depend on 591 whether the end-to-end NSIS signaling is sender-initiated or 592 receiver-initiated. But in both cases, it is the tunnel entry-point 593 that first creates the mapping between a tunnel session and an end- 594 to-end session. 596 5.1. Sender-initiated Reservation 598 Sender Tentry Tmid Texit Receiver 600 | | | | | 601 | RESERVE | | | | 602 +------------->| | | | 603 | | RESERVE | | 604 | +---------------------------->| | 605 | | | | RESERVE | 606 | | | +------------->| 607 | | | | RESPONSE | 608 | | | |<-------------+ 609 | | RESPONSE | | 610 | |<----------------------------+ | 611 | RESPONSE | | | | 612 |<-------------+ | | | 613 | | | | | 614 | | | | | 616 Figure 6: Sender-initiated End-to-end Session with Pre-configured 617 Tunnel QoS Sessions 619 Figure 6 illustrates the signaling sequence when end-to-end signaling 620 outside the tunnel is sender-initiated. Upon receiving a RESERVE 621 message from the sender, Tentry checks tunnel QoS configuration, 622 determines whether and how this end-to-end session can be mapped to a 623 pre-configured tunnel session. The mapping criteria are part of the 624 pre-configuration and outside the scope of this document. Tentry 625 then tunnels the RESERVE message to Texit. Texit forwards the 626 RESERVE message to the receiver. The receiver replies with a 627 RESPONSE message which arrives at Texit, Tentry and finally the 628 sender. If the RESPONSE message that Tentry receives confirms that 629 the overall signaling is successful, Tentry starts to encapsulate all 630 incoming packets of the data flow using the tunnel Flow ID 631 corresponding to the mapped tunnel session. Texit knows how to 632 decapsulate the tunnel packets because it recognizes the mapped 633 tunnel Flow ID based on information supplied during tunnel session 634 pre-configuration. 636 5.2. Receiver-initiated Reservation 638 Sender Tentry Tmid Texit Receiver 640 | | | | | 641 | QUERY | | | | 642 +------------->| | | | 643 | | QUERY | | 644 | +---------------------------->| | 645 | | | | QUERY | 646 | | | +------------->| 647 | | | | RESERVE | 648 | | | |<-------------+ 649 | | RESERVE | | 650 | |<----------------------------+ | 651 | RESERVE | | | | 652 |<-------------+ | | | 653 | RESPONSE | | | | 654 +------------->| | | | 655 | | RESPONSE | | 656 | +---------------------------->| | 657 | | | | RESPONSE | 658 | | | +------------->| 659 | | | | | 660 | | | | | 662 Figure 7: Receiver-initiated End-to-end Session with Pre-configured 663 Tunnel QoS Sessions 665 Figure 7 shows the signaling sequence when end-to-end signaling 666 outside the tunnel is receiver-initiated. Upon receiving the first 667 end-to-end Query message, Tentry examines the tunnel QoS 668 configuration, updates and tunnels the Query message to Texit. Texit 669 decapsulates the QUERY message, processes it and forwards it toward 670 the receiver. The receiver sends back a RESERVE message passing 671 through Texit and arriving at Tentry. Tentry decides on whether and 672 how the QoS request for this end-to-end session can be mapped to a 673 pre-configured tunnel session based on criteria outside the scope of 674 this document. Then Tentry forwards the RESERVE message towards the 675 sender. The signaling continues until a RESPONSE message arrives at 676 Tentry, Texit and finally the receiver. If the RESPONSE message that 677 Tentry receives confirms that the overall signaling is successful, 678 Tentry starts to encapsulate all incoming packets of the data flow 679 using the tunnel Flow ID corresponding to the mapped tunnel session. 680 Similarly, Texit knows how to decapsulate the tunnel packets because 681 it recognizes the mapped tunnel Flow ID based on information supplied 682 during tunnel session pre-configuration. 684 Since separate tunnel QoS signaling is not involved in pre-configured 685 QoS tunnels, Figure 6 and Figure 7 look as if the tunnel is a single 686 virtual link. The signaling path simply skips all tunnel 687 intermediate nodes. However, both Tentry and Texit need to deploy 688 NSIS-tunnel related functionalities described above, including acting 689 on the end-to-end NSIS signaling messages based on tunnel QoS status, 690 mapping end-to-end and tunnel QoS sessions, and correctly 691 encapsulating and decapsulating tunnel packets according to the 692 tunnel protocol and the configured tunnel Flow ID. 694 6. NSIS Operation over Tunnels with Dynamically Created QoS Sessions 696 When there are no pre-configured tunnel QoS sessions, a tunnel can 697 apply the same NSIS QoS signaling mechanism used for the end-to-end 698 path to manage the QoS inside the tunnel. The tunnel NSIS signaling 699 involves only those NSIS nodes in the tunnel forwarding path. The 700 Flow IDs for the tunnel signaling are based on tunnel header fields. 701 NSIS peer discovery messages inside the tunnel distinguish themselves 702 using the tunnel header fields, which solves the problem for tunnel 703 intermediate NSIS nodes to intercept signaling messages. 705 When tunnel end-points dynamically create tunnel QoS sessions, the 706 initiation mode of the tunnel session always follows the initiation 707 mode of the end-to-end session. Specifically, when the end-to-end 708 session is sender-initiated, the tunnel session should also be 709 sender-initiated; when the end-to-end session is receiver-initiated, 710 the tunnel session should also be receiver-initiated. 712 The tunnel entry-point conveys the corresponding tunnel Flow ID 713 associated with an end-to-end session to the tunnel exit-point during 714 the tunnel signaling process. The tunnel entry-point also informs 715 the exit-point of the binding between the corresponding tunnel 716 session and end-to-end session through the BOUND_SESSION_ID QoS NSLP 717 message object. The reservation message dependencies between the 718 tunnel session and end-to-end session is resolved using the MSG_ID 719 and BOUND_MSG_ID objects of the QoS NSLP message binding mechanism. 721 6.1. Sender-initiated Reservation 723 Sender Tentry Tmid Texit Receiver 725 | | | | | 726 | RESERVE(1) | | | | 727 +------------->| | | | 728 | | RESERVE'(2) | | | 729 | +=============>| | | 730 | | | RESERVE'(2) | | 731 | | +=============>| | 732 | | RESERVE(3) | | 733 | +---------------------------->| | 734 | | | RESPONSE'(4) | | 735 | | |<=============+ | 736 | | RESPONSE'(4) | | | 737 | |<=============+ | | 738 | | | | RESERVE(5) | 739 | | | +------------->| 740 | | | | RESPONSE(6) | 741 | | | |<-------------+ 742 | | RESPONSE(6) | | 743 | |<----------------------------+ | 744 | RESPONSE(6) | | | | 745 |<-------------+ | | | 746 | | | | | 747 | | | | | 749 (1,5): RESERVE w/o BOUND_MSG_ID and BOUND_SESSION_ID 750 (2): RESERVE' w/ MSG_ID 751 (3): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID 753 Figure 8: Sender-initiated Reservation for Both End-to-end and Tunnel 754 Signaling 756 Figure 8 shows the typical messaging sequence of how NSIS operates 757 over IP tunnels when both end-to-end session and tunnel session are 758 sender-initiated. Tunnel signaling messages are distinguished from 759 end-to-end messages by a prime symbol after the message name. The 760 sender first sends an end-to-end RESERVE message (1) which arrives at 761 Tentry. Tentry chooses the tunnel Flow ID, creates the tunnel 762 session and associates the end-to-end session with the tunnel 763 session. Tentry then sends a tunnel RESERVE' message (2) matching 764 the request of the end-to-end session towards Texit to reserve tunnel 765 resources. This RESERVE' message (2) includes a MSG_ID object which 766 contains a randomly generated 128-bit MSG_ID. Meanwhile, Tentry 767 inserts a BOUND_MSG_ID object containing the same MSG_ID as well as a 768 BOUND_SESSION_ID object containing the Session ID of the tunnel 769 session into the original RESERVE message, and sends this RESERVE 770 message (3) towards Texit using normal tunnel encapsulation. The 771 Message_Binding_Type flags of both the MSG_ID and BOUND_MSG_ID 772 objects in the RESERVE' and RESERVE messages (2, 3) are SET, 773 indicating a bidirectional binding. The tunnel RESERVE' message (2) 774 is processed hop-by-hop inside the tunnel for the flow identified by 775 the chosen tunnel Flow ID, while the end-to-end RESERVE message (3) 776 passes through the tunnel intermediate nodes (Tmid) just like other 777 tunneled packets. These two messages could arrive at Texit in 778 different orders, and the reaction of Texit in these different 779 situations should combine the tunnel QoS message processing rules 780 with the QoS NSLP processing principles for message binding 781 [I-D.ietf-nsis-qos-nslp], as illustrated below. 783 The first possibility is shown in the example messaging flow of 784 Figure 8, where the tunnel RESERVE' message (2), aka the triggering 785 message in QoS NSLP message binding terms, arrives first. Since the 786 message binding is bidirectional, Texit records the MSG_ID of the 787 RESERVE' message (2), enqueues it and starts a MsgIDWait timer 788 waiting for the end-to-end RESERVE message (3), aka the bound 789 signaling message in QoS NSLP message binding terms. The timer value 790 is set to the default retransmission timeout period 791 QOSNSLP_REQUEST_RETRY. When the end-to-end RESERVE message (3) 792 arrives, Texit notices that there is an existing stored MSG_ID which 793 matches the MSG_ID in the BOUND_MSG_ID object of the incoming RESERVE 794 message (3). Therefore the message binding condition has been 795 satisfied. Texit resumes processing of the tunnel RESERVE' message 796 (2), creates the reservation state for the tunnel session, and sends 797 a tunnel RESPONSE' message (4) to Tentry. At the same time, Texit 798 checks the BOUND_SESSION_ID object of the end-to-end RESERVE message 799 (3) and records the binding of the corresponding tunnel session with 800 the end-to-end session. Texit also updates the end-to-end RESERVE 801 message based on the result of the tunnel session reservation, 802 removes its tunnel BOUND_SESSION_ID and BOUND_MSG_ID object and 803 forwards the end-to-end RESERVE message (5) along the path towards 804 the receiver. When the receiver receives the end-to-end RESERVE 805 message (5), it sends an end-to-end RESPONSE message (6) back to the 806 sender. 808 The second possibility is that the end-to-end RESERVE message arrives 809 before the tunnel RESERVE' message at Texit. In that case, Texit 810 notices a BOUND_SESSION_ID object and a BOUND_MSG_ID object in the 811 end-to-end RESERVE message, but realizes that the tunnel session does 812 not exist yet. So Texit enqueues the RESERVE message and starts a 813 MsgIDWait timer. The timer value is set to the default 814 retransmission timeout period QOSNSLP_REQUEST_RETRY. When the 815 corresponding tunnel RESERVE' message arrives with a MSG_ID matching 816 that of the outstanding BOUND_MSG_ID object, the message binding 817 condition is satisfied. Texit sends a tunnel RESPONSE' message back 818 to Tentry and updates the end-to-end RESERVE message by incorporating 819 the result of the tunnel session reservation, as well as removing the 820 tunnel BOUND_SESSION_ID and BOUND_MSG_ID objects. Texit then 821 forwards the end-to-end RESERVE message along the path towards the 822 receiver. When the receiver receives the end-to-end RESERVE message, 823 it sends an end-to-end RESPONSE message back to the sender. 825 Yet another possibility is that the tunnel RESERVE' message arrives 826 at Texit first but the end-to-end RESERVE message never arrives. In 827 that case, the MsgIDWait timer for the queued tunnel RESERVE' message 828 will expire. Texit should then send a tunnel RESPONSE' message back 829 to Tentry indicating a reservation error has occurred, and discard 830 the tunnel RESERVE' message. The last possibility is that the end- 831 to-end RESERVE message arrives at Texit first but the tunnel RESERVE' 832 message never arrives. In that case, the MsgIDWait timer for the 833 queued end-to-end RESERVE message will expire. Texit should then 834 treat this situation as a local reservation failure, and according to 835 [I-D.ietf-nsis-qos-nslp], Texit as a stateful QoS NSLP should 836 generate an end-to-end RESPONSE message indicating RESERVE error to 837 the sender. 839 Once the end-to-end and the tunnel QoS session have both been 840 successfully created and associated, the tunnel end-points Tentry and 841 Texit coordinate the signaling between the two sessions and make sure 842 that adjustment or teardown of either session may trigger similar 843 actions for the other session as necessary, by invoking appropriate 844 signaling messages. 846 6.2. Receiver-initiated Reservation 848 Figure 9 shows the typical messaging sequence of how NSIS signaling 849 operates over IP tunnels when both end-to-end and tunnel sessions are 850 receiver-initiated. Upon receiving an end-to-end QUERY message (1) 851 from the sender, Tentry chooses the tunnel Flow ID and sends a tunnel 852 QUERY' message (2) matching the request of the end-to-end session 853 towards Texit. This tunnel QUERY' message (2) is meant to discover 854 QoS characteristics of the tunnel path, rather than initiating an 855 actual reservation. Therefore, it includes a Request Identification 856 Information (RII) object but does not set the RESERVE-INIT flag. The 857 tunnel QUERY' message (2) is processed hop-by-hop inside the tunnel 858 for the flow identified by the tunnel Flow ID. When Texit receives 859 this tunnel QUERY' message (2), it replies with a corresponding 860 tunnel RESPONSE' message (3) containing the tunnel path 861 characteristics. After receiving the tunnel RESPONSE' message (3), 862 Tentry creates the tunnel session, generates an outgoing end-to-end 864 Sender Tentry Tmid Texit Receiver 866 | | | | | 867 | QUERY(1) | | | | 868 +------------->| | | | 869 | | QUERY'(2) | | | 870 | +=============>| | | 871 | | | QUERY'(2) | | 872 | | +=============>| | 873 | | | RESPONSE'(3) | | 874 | | |<=============+ | 875 | | RESPONSE'(3) | | | 876 | |<=============+ | | 877 | | QUERY(4) | | 878 | +---------------------------->| | 879 | | | | QUERY(5) | 880 | | | +------------->| 881 | | | | RESERVE(6) | 882 | | | |<-------------+ 883 | | | RESERVE'(7) | | 884 | | |<=============+ | 885 | | RESERVE'(7) | | | 886 | |<=============+ | | 887 | | RESERVE(8) | | 888 | |<----------------------------+ | 889 | | RESPONSE'(9) | | | 890 | +=============>| | | 891 | | | RESPONSE'(9) | | 892 | | +=============>| | 893 | RESERVE(10) | | | | 894 |<-------------+ | | | 895 | RESPONSE(11) | | | | 896 +------------->| | | | 897 | | RESPONSE(11) | | 898 | +---------------------------->| | 899 | | | | RESPONSE(11) | 900 | | | +------------->| 901 | | | | | 902 | | | | | 903 (1,5): QUERY w/ RESERVE-INIT (2): QUERY' w/ RII 904 (4): QUERY w/ RESERVE-INIT and BOUND_SESSION_ID 905 (6,10): RESERVE w/o BOUND_SESSION_ID (7): RESERVE' w/ MSG_ID 906 (8): RESERVE w/ BOUND_MSG_ID and BOUND_SESSION_ID 908 Figure 9: Receiver-initiated Reservation for Both End-to-end and 909 Tunnel Signaling 911 QUERY message (4) considering the tunnel path characteristics, 912 appends a tunnel BOUND_SESSION_ID object containing the tunnel 913 Session ID, and sends it toward Texit using normal tunnel 914 encapsulation. The end-to-end QUERY message (4) passes along tunnel 915 intermediate nodes like other tunneled packets. Upon receiving this 916 end-to-end QUERY message (4), Texit notices the tunnel session 917 binding and creates the tunnel session state, removes the tunnel 918 BOUND_SESSION_ID object and forwards the end-to-end QUERY message (5) 919 further along the path. 921 The end-to-end QUERY message (5) arrives at the receiver and triggers 922 a RESERVE message (6). When Texit receives the RESERVE message (6), 923 it notices that the session is bound to a receiver-initiated tunnel 924 session. Therefore, Texit triggers a RESERVE' message (7) toward 925 Tentry for the tunnel session reservation. This tunnel RESERVE' 926 message (7) includes a randomly generated 128-bit MSG_ID. Meanwhile, 927 Texit inserts a BOUND_MSG_ID object containing the same MSG_ID and a 928 BOUND_SESSION_ID object containing the tunnel Session ID into the 929 end-to-end RESERVE message (8), and sends it towards Tentry using 930 normal tunnel encapsulation. The Message_Binding_Type flags of the 931 MSG_ID and BOUND_MSG_ID objects in the RESERVE' and RESERVE messages 932 (7,8) are SET, indicating a bidirectional binding. 934 At Tentry, the tunnel RESERVE' message (7) and the end-to-end RESERVE 935 message (8) could arrive in different orders. In a typical case 936 shown in Figure 9, the tunnel RESERVE' message (7) arrives first. 937 Tentry then records the MSG_ID of the tunnel RESERVE' message (7) and 938 starts a MsgIDWait timer. When the end-to-end RESERVE message (8) 939 with the BOUND_MSG_ID object containing the same MSG_ID arrives, the 940 message binding condition is satisfied. Tentry resumes processing of 941 the tunnel RESERVE' message (7), creates the reservation state for 942 the tunnel session, and sends a tunnel RESPONSE' message (9) to 943 Texit. At the same time, Tentry creates the outgoing end-to-end 944 RESERVE message (10) by incorporating results of the tunnel session 945 reservation and removing the BOUND_SESSION_ID and BOUND_MSG_ID 946 objects, and forwards it along the path towards the sender. When the 947 sender receives the end-to-end RESERVE message (10), it sends an end- 948 to-end RESPONSE message (11) back to the receiver. 950 If the end-to-end RESERVE message arrives before the tunnel RESERVE' 951 message at Tentry, or either of the two messages fails to arrive at 952 Tentry, the processing rules at Tentry is similar to those of Texit 953 in the same situation discussed in Section 6.1. 955 Once the end-to-end and the tunnel QoS session have both been 956 successfully created and associated, the tunnel end-points Tentry and 957 Texit coordinate the signaling between the two sessions and make sure 958 that adjustment or teardown of either session can trigger similar 959 actions for the other session as necessary, by invoking appropriate 960 signaling messages. 962 7. NSIS-Tunnel Signaling Capability Discovery 964 The mechanism of NSIS operating over IP tunnels requires the 965 coordination of both tunnel end-points in tasks such as special 966 encapsulation and decapsulation of data flow packets according to the 967 chosen tunnel Flow ID, as well as the possible creation and 968 adjustment of the end-to-end and tunnel QoS sessions. Therefore, one 969 NSIS-tunnel-aware end-point needs to know that the other tunnel end- 970 point is also NSIS-tunnel-aware before initiating this NSIS operating 971 over IP tunnel mechanism. In some cases, especially for IP tunnels 972 with pre-configured QoS sessions, an NSIS-tunnel-aware end-point can 973 learn about whether the other tunnel end-point is also NSIS-tunnel- 974 aware through pre-configuration. In other cases where such pre- 975 configuration is not available, the initiating NSIS-tunnel-aware end- 976 point may dynamically discover the other tunnel end-point's 977 capability through a QoS NSLP NODE_CAPABILITY_TUNNEL object defined 978 in this section. 980 The NODE_CAPABILITY_TUNNEL object is a zero-length object with a 981 standard NSLP object header as shown in Figure 10. 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |A|B|r|r| Type |r|r|r|r| Length | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Figure 10: NODE_CAPABILITY_TUNNEL Object Format 991 Type: TBD from the shared NSLP object type space 993 Length: 0 994 The bits marked 'A' and 'B' define the desired behavior for objects 995 whose Type field is not recognized. If a node does not recognize the 996 NODE_CAPABILITY_TUNNEL object, the desired behavior is "Forward". 997 That is, the object must be retained unchanged and forwarded as a 998 result of message processing. This is satisfied by setting 'AB' to 999 '10'. 1001 The 'r' bit stands for 'reserved'. 1003 The NODE_CAPABILITY_TUNNEL object is included in a tunnel QUERY' or 1004 RESERVE' message by a tunnel end-point that needs to learn about the 1005 other end-point's NSIS tunnel handling capability. If the receiving 1006 tunnel end-point is indeed NSIS-tunnel-aware, it recognizes this 1007 object and knows that the sending end-point is NSIS-tunnel-aware. 1008 The receiving tunnel end-point places the same object in a tunnel 1009 RESPONSE' message to inform the sending end-point that it is also 1010 NSIS-tunnel-aware. The use of the NODE_CAPABILITY_TUNNEL object in 1011 the cases of sender-initiated reservation and receiver-initiated 1012 reservation are as follows. 1014 First, assume that the end-to-end session is sender-initiated as in 1015 Figure 8, and the NSIS-tunnel-aware Tentry wants to discover the 1016 NSIS-tunnel capability of Texit. After receiving the first end-to- 1017 end RESERVE message (1), Tentry inserts an RII object and a 1018 NODE_CAPABILITY_TUNNEL object into the tunnel RESERVE' message (2) 1019 and sends it to Texit. If Texit is NSIS-tunnel-aware, it learns from 1020 the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel- 1021 aware and includes the same object into the tunnel RESPONSE' message 1022 (4) sent back to Tentry. 1024 Second, assume that the end-to-end session is receiver-initiated as 1025 in Figure 9, and the NSIS-tunnel-aware Tentry wants to discover the 1026 NSIS-tunnel capability of Texit. Upon receiving the first end-to-end 1027 QUERY message (1), Tentry inserts an RII object and a 1028 NODE_CAPABILITY_TUNNEL object in the tunnel QUERY' message (2) and 1029 sends it toward Texit. If Texit is NSIS-tunnel-aware, it learns from 1030 the NODE_CAPABILITY_TUNNEL object that Tentry is also NSIS-tunnel- 1031 aware and includes the same object tunnel RESPONSE' message (3) sent 1032 to Tentry. 1034 8. IANA Considerations 1036 This document defines a new object type called NODE_CAPABILITY_TUNNEL 1037 for QoS NSLP. Its Type value needs to be assigned by IANA. The 1038 object format and the setting of the extensibility bits are defined 1039 in Section 7. 1041 9. Security Considerations 1043 There are two IPsec related security considerations about using this 1044 NSIS and IP tunnel interoperation mechanism. First, NSIS messages 1045 may require per-hop processing within the IPsec tunnel, and that is 1046 potentially incompatible with IPsec. A similar problem exists for 1047 RSVP interacting with IPsec, when the Router Alert option is used 1048 (Section A.1 of RFC4302 [RFC4302]). If this mechanism is indeed used 1049 for NSIS and IPsec tunnels, a so-called covert channel could exist 1050 where someone can create spurious NSIS signaling flows within the 1051 protected network in order to create signaling in the outside 1052 network, which then someone else is monitoring. For highly secure 1053 networks, this would be seen as a way to smuggle information out of 1054 the network, and therefore this channel will need to be rate-limited. 1055 A similar covert channel rate-limit problem exists for using 1056 Differentiated Service (DS) or Explicit Congestion Notification (ECN) 1057 fields with IPsec (Section 5.1.2 of RFC4301 [RFC4301]). 1059 Second, since the NSIS-tunnel-aware end-point is responsible for 1060 adapting changes between the NSIS signaling both inside and outside 1061 the tunnel, there could be additional risks for an IPsec end-point 1062 which is also an NSIS-tunnel-aware end-point. For example, security 1063 vulnerability (e.g., buffer overflow) on the NSIS stack of that IPsec 1064 tunnel end-point may be exposed to the unprotected outside network. 1065 Nevertheless, it should also be noted that if any node along the 1066 signaling path is compromised, the whole end-to-end QoS signaling 1067 could be affected, whether the end-to-end path includes an IPsec 1068 tunnel or not. 1070 Several other documents discussed security issues for NSIS. General 1071 threats for NSIS can be found in [RFC4081]. Security considerations 1072 for NSIS NTLP and QoS NSLP are discussed in [I-D.ietf-nsis-ntlp] and 1073 [I-D.ietf-nsis-qos-nslp], respectively. 1075 10. Acknowledgements 1077 The authors would like to thank Roland Bless, Francis Dupont, Lars 1078 Eggert, Russ Housley, Georgios Karagiannis, Jukka Manner, Martin 1079 Rohricht, Peter Saint-Andre, Martin Stiemerling, Hannes Tschofenig, 1080 and other members of the NSIS working group for comments to this 1081 work. Thanks to Yaron Sheffer for pointing out the IPsec related 1082 security considerations. 1084 11. References 1086 11.1. Normative References 1088 [I-D.ietf-nsis-ntlp] 1089 Schulzrinne, H. and M. Stiemerling, "GIST: General 1090 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1091 (work in progress), June 2009. 1093 [I-D.ietf-nsis-qos-nslp] 1094 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1095 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 1096 (work in progress), January 2010. 1098 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1099 February 1997. 1101 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1102 IPv6 Specification", RFC 2473, December 1998. 1104 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1105 RFC 2711, October 1999. 1107 [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, 1108 "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. 1110 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 1111 "IPv6 Flow Label Specification", RFC 3697, March 2004. 1113 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1114 Bosch, "Next Steps in Signaling (NSIS): Framework", 1115 RFC 4080, June 2005. 1117 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1118 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1120 11.2. Informative References 1122 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1123 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1125 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1126 Routing Encapsulation over IPv4 networks", RFC 1702, 1127 October 1994. 1129 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 1131 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1132 October 1996. 1134 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1135 October 1996. 1137 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1138 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1139 Functional Specification", RFC 2205, September 1997. 1141 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1142 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1143 March 2000. 1145 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1146 August 2002. 1148 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1149 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1151 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1152 Internet Protocol", RFC 4301, December 2005. 1154 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1155 December 2005. 1157 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1158 RFC 4303, December 2005. 1160 Authors' Addresses 1162 Charles Shen 1163 Columbia University 1164 Department of Computer Science 1165 1214 Amsterdam Avenue, MC 0401 1166 New York, NY 10027 1167 USA 1169 Phone: +1 212 854 3109 1170 Email: charles@cs.columbia.edu 1172 Henning Schulzrinne 1173 Columbia University 1174 Department of Computer Science 1175 1214 Amsterdam Avenue, MC 0401 1176 New York, NY 10027 1177 USA 1179 Phone: +1 212 939 7004 1180 Email: hgs@cs.columbia.edu 1181 Sung-Hyuck Lee 1182 SAMSUNG Advanced Institute of Technology 1183 San 14-1, Nongseo-ri, Giheung-eup 1184 Yongin-si, Gyeonggi-do 449-712 1185 South Korea 1187 Phone: +82 31 280 9552 1188 Email: starsu.lee@samsung.com 1190 Jong Ho Bang 1191 SAMSUNG Advanced Institute of Technology 1192 San 14-1, Nongseo-ri, Giheung-eup 1193 Yongin-si, Gyeonggi-do 449-712 1194 South Korea 1196 Phone: +82 31 280 9585 1197 Email: jh0278.bang@samsung.com