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