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