idnits 2.17.1 draft-ietf-nsis-tunnel-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (June 23, 2009) is 5421 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 851, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 909, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-16 -- Obsolete informational reference (is this intentional?): RFC 3697 (ref. '6') (Obsoleted by RFC 6437) == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-21 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-20 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-applicability-mobility-signaling-12 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 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: Informational Columbia U. 5 Expires: December 25, 2009 S. Lee 6 J. Bang 7 Samsung AIT 8 June 23, 2009 10 NSIS Operation Over IP Tunnels 11 draft-ietf-nsis-tunnel-06.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 25, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This draft presents an NSIS operation over IP tunnel scheme using QoS 50 NSLP as the NSIS signaling application. Both sender-initiated and 51 receiver-initiated NSIS signaling modes are discussed. The scheme 52 creates individual or aggregate tunnel sessions for end-to-end 53 sessions traversing the tunnel. Packets belonging to qualified end- 54 to-end sessions are mapped to corresponding tunnel sessions and 55 assigned special flow IDs to be distinguished from the rest of the 56 tunnel traffic. Tunnel endpoints keep the association of the end-to- 57 end and tunnel session mapping, so that adjustment in one session can 58 be reflected in the other. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. IP Tunneling Mechanisms and Tunnel Signaling Capability . 4 64 1.2. NSIS Tunnel Operation Overview . . . . . . . . . . . . . . 5 65 2. Protocol Design Decisions . . . . . . . . . . . . . . . . . . 6 66 2.1. Flow Packet Classification over the Tunnel . . . . . . . . 6 67 2.2. Tunnel Signaling and its Association with End-to-end 68 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Protocol Operation with Dynamically Created Tunnel Sessions . 7 70 3.1. Operation Scenarios . . . . . . . . . . . . . . . . . . . 7 71 3.1.1. Sender-initiated Reservation for both End-to-end 72 and Tunnel Signaling . . . . . . . . . . . . . . . . . 8 73 3.1.2. Receiver-initiated Reservation for both End-to-end 74 and Tunnel Signaling . . . . . . . . . . . . . . . . . 10 75 3.2. Implementation Specific Issues . . . . . . . . . . . . . . 11 76 3.2.1. End-to-end and Tunnel Signaling Interaction . . . . . 11 77 3.2.2. Aggregate vs. Individual Tunnel Session Setup . . . . 12 78 4. Protocol Operation with Pre-configured Tunnel Sessions . . . . 13 79 4.1. Tunnel with Exactly One Pre-configured Aggregate 80 Session . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.2. Tunnel with Multiple Pre-configured Aggregate Sessions . . 13 82 4.3. Adjustment of Pre-configured Tunnel Sessions . . . . . . . 14 83 5. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 14 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 8.1. NSIS-tunnel Operation for other Types of NSLP . . . . . . 17 88 8.2. NSIS-tunnel Operation and Mobility . . . . . . . . . . . . 17 89 8.3. Various Design Alternatives . . . . . . . . . . . . . . . 18 90 8.3.1. End-to-end and Tunnel Signaling Integration Model . . 18 91 8.3.2. Packet Classification over the Tunnel . . . . . . . . 18 92 8.3.3. Tunnel Binding Methods . . . . . . . . . . . . . . . . 18 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 When IP tunnel mechanism is used to transfer signaling messages, 102 e.g., NSIS messages, the signaling messages usually become hidden 103 inside the tunnel and are not known to the tunnel intermediate nodes. 104 In other words, the IP tunnel behaves as a logical link that does not 105 support signaling in the end-to-end path. If true end-to-end 106 signaling support is desired, there needs to be a scheme to enable 107 signaling at the tunnel segment of the end-to-end signaling path. 108 This draft describes such a scheme for NSIS operation over IP 109 tunnels. We assume QoS NSLP as the NSIS signaling application. 111 1.1. IP Tunneling Mechanisms and Tunnel Signaling Capability 113 There are a number of common IP tunneling mechanisms, such as Generic 114 Routing Encapsulation (GRE) [4][15], Generic Routing Encapsulation 115 over IPv4 Networks (GREIP4) [5] , IP Encapsulation within IP 116 (IP4INIP4) [7], Minimal Encapsulation within IP (MINENC) [8], Generic 117 Packet Tunneling in IPv6 Specification (IP6GEN) [11], IPv6 over IPv4 118 tunneling (IP6INIP4) [9], IPSEC tunneling mode [19][10]. These 119 mechanisms can be differentiated according to the format of the 120 tunnel encapsulation header. IP4INIP4, IP6INIP4 and IP6GENIP4 can be 121 seen as normal IP in IP tunnel encapsulation because their tunnel 122 encapsulation headers are in the form of a standard IP header. All 123 GRE-related IP tunneling (GRE,GREIP4), MINENC and IPSEC tunneling 124 mode can be seen as modified IP in IP tunnel encapsulation because 125 the tunnel encapsulation header contains additional information 126 fields besides a standard IP header. The additional information 127 fields are the GRE header for GRE and GREIP4, the minimum 128 encapsulation header for MINENC and the Encapsulation Security 129 Payload (ESP) header for IPSEC tunneling mode. 131 By default any end-to-end signaling messages arriving at the tunnel 132 endpoint will be encapsulated the same way as data packets. Tunnel 133 intermediate nodes do not identify them as signaling messages. A 134 signaling-aware IP tunnel can participate in a signaling network in 135 various ways. Prior work on RSVP operation over IP tunnels (RSVP- 136 TUNNEL) [16] identifies two types of QoS-aware tunnels: a tunnel that 137 can promise some overall level of resources but cannot allocate 138 resources specifically to individual data flows, or a tunnel that can 139 make reservations for individual end-to-end data flows. This 140 classification leads to two types of tunnel signaling sessions: 141 individual tunnel signaling sessions that are created and torn down 142 dynamically as end-to-end session come and go, and aggregate tunnel 143 sessions that can either be fixed, or dynamically adjusted as the 144 actually used session resources increase or decrease. Aggregate 145 tunnel sessions are usually pre-configured but can also be 146 dynamically created. A tunnel may contain only individual tunnel 147 sessions or aggregate tunnel sessions or both. 149 1.2. NSIS Tunnel Operation Overview 151 This NSIS operation over IP tunnel scheme is designed to work with 152 most, if not all, existing IP in IP tunneling mechanisms. The scheme 153 requires the tunnel endpoints to support specific tunnel related 154 functionalities. Such tunnel endpoints are called NSIS-tunnel 155 capable endpoints. Tunnel intermediate nodes do not need to have 156 special knowledge about this scheme. When tunnel endpoints are NSIS- 157 tunnel capable, this scheme enables the proper signaling initiation 158 and adjustment inside the tunnel to match the requests of the 159 corresponding end-to-end sessions. In cases where tunnel session 160 signaling status is uncertain or not successful, the end-to-end 161 session will be notified about the existence of possible NSIS-unaware 162 links in the end-to-end path. 164 The overall design of this NSIS operation over IP tunnel scheme is 165 conceptually similar to RSVP-TUNNEL [16]. However, the details of 166 the scheme address all the important differences of NSIS from RSVP. 167 For example, 169 o NSIS is based on a two-layer architecture, namely a signaling 170 transport layer and a signaling application layer. It is designed 171 as a generic framework to accommodate various signaling 172 application needs. The basic RSVP protocol does not have a layer 173 split and is only for QoS signaling. 174 o NSIS QoS NSLP allows both sender-initiated and receiver-initiated 175 reservations; RSVP only supports receiver-initiated reservations. 176 o NSIS deals only with unicast; RSVP also supports multicast. 177 o NSIS integrates new features, such as the Session ID, to 178 facilitate operation in specific environments (e.g. mobility and 179 multi-homing). 181 From a high level point of view, there are two main issues in a 182 signaling operation over IP tunnel scheme. First, how packet 183 classification is performed inside the tunnel. Second, how signaling 184 is carried out inside the tunnel. 186 Packets belonging to qualified data flows need to be recognized by 187 tunnel intermediate nodes to receive special treatment. Packet 188 classification is traditionally based on flow ID. After a typical 189 IP-in-IP tunnel encapsulation, packets from different flows appear as 190 having the same flow ID which usually consists of the Tunnel Entry 191 (Tentry) address and Tunnel Exit (Texit) address. Therefore, the 192 flow ID for a signaled flow needs to contain further demultiplexing 193 information to make it distinguishable from non-signaled flows and 194 from other signaled flows. 196 The special flow ID for signaled flows inside the tunnel needs to be 197 carried in tunnel signaling messages, along with tunnel adjusted QoS 198 parameters, to set up or modify the state information in tunnel 199 intermediate nodes. This process creates separate tunnel signaling 200 sessions between the tunnel endpoints. In most cases, it is 201 necessary to maintain the state association between an end-to-end 202 session and its corresponding tunnel session so that any change to 203 one session may be reflected in the other. 205 2. Protocol Design Decisions 207 2.1. Flow Packet Classification over the Tunnel 209 A flow can be an individual flow, or an aggregate flow consisting of 210 multiple individual flows. 212 For individual flows that need to be distinguished from each other 213 inside the tunnel, by default an additional UDP header is inserted 214 during the tunnel IP encapsulation. The resulting UDP encapsulated 215 flow will then use the Tentry IP address, Texit IP address along with 216 the source port number in the additional UDP header as flow ID inside 217 the tunnel. To ensure this mechanism work, the Tentry doing UDP 218 encapsulation needs to know the Texit has the corresponding UDP 219 decapsulation capability. Tentry knows the capability of the Text 220 either by pre-configuration or through tunnel signaling capability 221 discovery defined in Section 5. 223 Not all individual flows must use the UDP encapsulation to form the 224 tunnel flow ID. In particular, for an IPv6 flow with unique flow 225 label [6], the tunnel signaling can use the Tentry and Texit IP 226 addresses plus the IPv6 flow label as the flow ID; for an IPSEC flow 227 with Security Parameter Index (SPI), the tunnel signaling can use the 228 Tentry and Texit IP addresses plus the SPI as the tunnel flow ID. 230 For aggregate flows, the tunnel signaling can still use UDP 231 encapsulation for flow ID; when the DiffServ Code Point (DSCP) field 232 is in use, the aggregate tunnel flow ID can also be Tentry and Texit 233 IP addresses plus the DSCP value; when additional interfaces are 234 available, the tunnel signaling may also use the IP address of an 235 additional interface at Tentry plus the IP address of the Texit as 236 the aggregate flow ID. 238 The choice of the tunnel flow ID format is made by the tunnel 239 signaling initiator and then conveyed to the other end of the tunnel 240 as part of Message Routing Information (MRI, see [2]) in regular NSIS 241 signaling messages. 243 2.2. Tunnel Signaling and its Association with End-to-end Signaling 245 Tunnel signaling messages contain tunnel specific parameters such as 246 tunnel MRI and tunnel adjusted QoS parameters. But in general, the 247 formats of tunnel signaling messages are the same as end-to-end 248 signaling messages. Tunnel signaling is carried out according to the 249 same signaling rules as for end-to-end signaling. The main challenge 250 is, therefore, the interaction between tunnel signaling and end-to- 251 end signaling. The interaction is achieved by special 252 functionalities supported in the NSIS-tunnel aware tunnel endpoints. 253 These special functionalities include assigning tunnel flow IDs, 254 creating tunnel session association, notifying the other endpoint 255 about tunnel association, adjusting one session based on change of 256 the other session, encapsulating (decapsulating) packets according to 257 the chosen tunnel flow ID at Tentry (Texit), and etc. In most cases, 258 we expect to have bi-directional tunnels, where both tunnel endpoints 259 are NSIS-tunnel aware. 261 When both Tentry and Texit are NSIS-tunnel aware, the endpoint that 262 creates the tunnel session notifies the other endpoint of the 263 association between the end-to-end and tunnel session using the QoS 264 NSLP BOUND_SESSION_ID object with a Binding Code indicating tunnel 265 handling as the reason for binding. In the rest of this document, we 266 refer to a BOUND_SESSION_ID object with its tunnel Binding Code set 267 as a tunnel BOUND_SESSION_ID object or a tunnel binding object. This 268 tunnel binding object is carried in the end-to-end signaling messages 269 and contains the session ID of the corresponding tunnel session. 270 NSIS-tunnel aware endpoints that receive this tunnel BOUND_SESSION_ID 271 object should perform tunnel related procedures and then remove it 272 from any end-to-end signaling messages sent out of the tunnel. 274 3. Protocol Operation with Dynamically Created Tunnel Sessions 276 The tunnel session corresponding to the end-to-end session can be 277 dynamically created or pre-configured, the former case is much more 278 complicated. It is a policy decision over which method should be 279 used. We discuss the dynamically created tunnel session case in this 280 section and then the pre-configured tunnel session case in the next. 282 3.1. Operation Scenarios 284 When tunnel sessions are dynamically created for end-to-end sessions, 285 there could be four scenarios based on the sender-initiated and 286 receiver-initiated reservation modes of NSIS QoS NSLP: 288 o End-to-end session is sender-initiated; tunnel session is sender- 289 initiated. 290 o End-to-end session is receiver-initiated; tunnel session is 291 receiver-initiated. 292 o End-to-end session is sender-initiated; tunnel session is 293 receiver-initiated. 294 o End-to-end session is receiver-initiated; tunnel session is 295 sender-initiated. 297 Whether sender-initiated or receiver-initiated reservation should be 298 used is determined by the signaling initiator. When both the end-to- 299 end session and the tunnel session are concerned, this decision will 300 need to be made twice. In order to reduce complexity, we decide that 301 both the end-to-end session and the tunnel session should use the 302 same initiation mode. Since the end-to-end session is the originator 303 that causes the establishment of the tunnel session, we use the 304 decision made by the end-to-end session as a reference. 305 Specifically, when the end-to-end session is sender-initiated, then 306 the tunnel session should be sender-initiated too. If the end-to-end 307 session is receiver-initiated, then the tunnel session should be 308 receiver-initiated too. 310 In the following we describe the typical NSIS end-to-end and tunnel 311 signaling interaction process during the tunnel setup phase in each 312 of the two recommended scenarios. The end-to-end QoS flow is assumed 313 to be one that qualifies an individual dynamic tunnel session. 315 3.1.1. Sender-initiated Reservation for both End-to-end and Tunnel 316 Signaling 318 This scenario assumes both end-to-end and tunnel sessions are sender- 319 initiated. Figure 1 shows the messaging flow of NSIS operation over 320 IP tunnels in this case. Tunnel signaling messages are distinguished 321 from end-to-end messages by a prime symbol after the message name. 322 Tnode denotes an intermediate tunnel node that participates in tunnel 323 signaling. The sender first sends an end-to-end RESERVE message 324 which arrives at Tentry. If Tentry supports tunnel signaling and 325 determines that an individual tunnel session needs to be established 326 for the end-to-end session, it chooses the tunnel flow ID, creates 327 the tunnel session and associates the end-to-end session with the 328 tunnel session. It then sends a tunnel RESERVE' message matching the 329 requests of the end-to-end session towards the Texit to reserve 330 tunnel resources. Tentry also appends to the original RESERVE 331 message a tunnel BOUND_SESSION_ID object containing the session ID of 332 the tunnel session and sends it towards Texit using normal tunnel 333 encapsulation. 335 The tunnel RESERVE' message is processed hop-by-hop inside the tunnel 336 for the flow identified by the chosen tunnel flow ID. When Texit 337 receives the tunnel RESERVE' message, a reservation state for the 338 tunnel session will be created. Texit may also send a tunnel 339 RESPONSE' message to Tentry. On the other hand, the end-to-end 340 RESERVE message passes through the tunnel intermediate nodes just 341 like any other tunneled packets. When Texit receives the end-to-end 342 RESERVE message, it notices the binding of a tunnel session and 343 updates the end-to-end RESERVE message based on the result of the 344 tunnel session reservation. Then Texit removes the tunnel 345 BOUND_SESSION_ID object and forwards the end-to-end RESERVE message 346 further along the path towards the receiver. When the end-to-end 347 reservation finishes, the receiver may send an end-to-end RESPONSE 348 back to the sender. 350 Sender Tentry Tnode Texit Receiver 352 | | | | | 353 | RESERVE | | | | 354 +--------->| | | | 355 | | RESERVE' | | | 356 | +=========>| | | 357 | | | RESERVE' | | 358 | | +=========>| | 359 | | RESERVE | | 360 | +-------------------->| | 361 | | | RESPONSE'| RESERVE | 362 | | |<=========+--------->| 363 | | RESPONSE'| | | 364 | |<=========+ | | 365 | | | | RESPONSE | 366 | | | |<---------+ 367 | | RESPONSE | | 368 | |<--------------------+ | 369 | RESPONSE | | | | 370 |<---------+ | | | 371 | | | | | 372 | | | | | 374 Figure 1: Sender-initiated Reservation for both End-to-end and Tunnel 375 Signaling 377 3.1.2. Receiver-initiated Reservation for both End-to-end and Tunnel 378 Signaling 380 Sender Tentry Tnode Texit Receiver 382 | | | | | 383 | QUERY | | | | 384 +--------->| | | | 385 | | QUERY' | | | 386 | +=========>| | | 387 | | | QUERY' | | 388 | | +=========>| | 389 | | QUERY | | 390 | +-------------------->| | 391 | | | | QUERY | 392 | | | +--------->| 393 | | | | RESERVE | 394 | | | |<---------+ 395 | | | RESERVE' | | 396 | | |<=========+ | 397 | | RESERVE' | | | 398 | |<=========+ | | 399 | | RESERVE | | 400 | |<--------------------+ | 401 | RESERVE | RESPONSE'| | | 402 |<---------+=========>| | | 403 | | | RESPONSE'| | 404 | | +=========>| | 405 | RESPONSE | | | | 406 +--------->| | | | 407 | | RESPONSE | | 408 | +-------------------->| | 409 | | | | RESPONSE | 410 | | | +--------->| 411 | | | | | 412 | | | | | 414 Figure 2: Receiver-initiated Reservation for both End-to-end and 415 Tunnel Signaling 417 This scenario assumes both end-to-end and tunnel sessions are 418 receiver-initiated. Figure 2 shows the messaging flow of NSIS 419 operation over IP tunnels in this case. When Tentry receives the 420 first end-to-end QUERY message from the sender, it chooses the tunnel 421 flow ID, creates the tunnel session and sends a tunnel QUERY' message 422 matching the request of the end-to-end session toward the Texit. 424 Tentry also appends to the original QUERY message with a tunnel 425 BOUND_SESSION_ID object containing the session ID of the tunnel 426 session and sends it toward the Texit using normal tunnel 427 encapsulation. 429 The tunnel QUERY' message is processed hop-by-hop inside the tunnel 430 for the flow identified by the chosen tunnel flow ID. When Texit 431 receives the tunnel QUERY' message, it creates a reservation state 432 for the tunnel session without sending out a tunnel RESERVE' message 433 immediately. 435 The end-to-end QUERY message passes along tunnel intermediate nodes 436 just like any other tunneled packets. When Texit receives the end- 437 to-end QUERY message, it notices the binding of a tunnel session and 438 checks the state for the tunnel session. When the tunnel session 439 state is available, Texit updates the end-to-end QUERY message using 440 the tunnel session state, removes the tunnel BOUND_SESSION_ID object 441 and forwards the end-to-end QUERY message further along the path. 443 When Texit receives the first end-to-end RESERVE message issued by 444 the receiver, it finds the reservation state of the tunnel session 445 and triggers a tunnel RESERVE' message for that session. Meanwhile 446 the end-to-end RESERVE message will be appended with a tunnel 447 BOUND_SESSION_ID object and forwarded towards Tentry. When Tentry 448 receives the tunnel RESERVE' message, it creates the reservation 449 state for the tunnel session and may send a tunnel RESPONSE' message 450 back to Texit. When Tentry receives the end-to-end RESERVE message, 451 it updates the end-to-end RESERVE message with the result of the 452 corresponding tunnel session reservation. Then it removes the 453 BOUND_SESSION_ID object and forwards the end-to-end RESERVE message 454 upstream toward the sender. When the end-to-end signaling finishes, 455 the sender may send a RESPONSE message to the receiver. 457 3.2. Implementation Specific Issues 459 3.2.1. End-to-end and Tunnel Signaling Interaction 461 There could be many ways through which the end-to-end signaling and 462 tunnel signaling may interact with each other. In general, different 463 interaction approaches can be grouped into sequential mode and 464 parallel mode. In sequential mode, end-to-end signaling pauses when 465 it is waiting for results of tunnel signaling, and resumes upon 466 receipt of the tunnel signaling outcome. In parallel mode, end-to- 467 end signaling continues outside the tunnel while tunnel signaling is 468 still in process and its outcome is unknown. Our design decision in 469 this document is a hybrid model. The rule is that the end-to-end 470 signaling waits for tunnel signaling only if pre-conditions is needed 471 to initiate the end-to-end session reservation. The example of this 472 is the end-to-end QUERY message in Section 3.1.2, which needs to wait 473 for the QUERY' message about the tunnel information and then be 474 forwarded further. This ensures that the first end-to-end RESERVE 475 message originated from the receiver will have the correct view of 476 the whole path. After that, as long as the amount of resources the 477 end-to-end session requests for has been decided, the end-to-end 478 reservation and tunnel reservation go parallel to speed up the whole 479 process, as illustrated in both Section 3.1.1 and Section 3.1.2. 481 When the RESERVE messages of the end-to-end session and the tunnel 482 session are propagated in parallel, if by the time an end-to-end 483 RESERVE message carrying tunnel binding object arrives at the exit 484 endpoint of the tunnel (which could be the Texit in Section 3.1.1 or 485 the Tentry in Section 3.1.2), the results of the corresponding tunnel 486 session reservation is already available, then the tunnel exit 487 endpoint can remove the tunnel BOUND_SESSION_ID object, update the 488 end-to-end RESERVE message accordingly and send it out of the tunnel 489 immediately. However, it is also possible that the tunnel session 490 state is not yet available when the end-to-end RESERVE message with a 491 tunnel binding object is received. In the latter case, the exit 492 tunnel endpoint should still remove the tunnel BOUND_SESSION_ID 493 object, but sets the NON-QoSM Hop field [12] to indicate the possible 494 existence of non-QoS link and then forward the message out 495 immediately. The exit tunnel endpoint should then try to learn the 496 results of the corresponding tunnel session reservation. This could 497 be done by proactive polling after a specific amount of time, or when 498 a refresh message is scheduled to send. In any case, once the state 499 of the tunnel session is available, the exit tunnel endpoint should 500 immediately trigger an end-to-end RESERVE message subject to the 501 results of the tunnel reservation. If the tunnel reservation is 502 successfully confirmed, the message would be a normal RESERVE refresh 503 but with the NON-QoSM Hop field reset. Otherwise, the QSPEC in the 504 RESERVE message should indicate error happened in the reservation. 506 3.2.2. Aggregate vs. Individual Tunnel Session Setup 508 The operation outlined in Section 3.1 applies to a flow that 509 qualifies an individual dynamic tunnel session. For a tunnel that 510 may contain multiple end-to-end sessions, it is more efficient to 511 keep aggregate tunnel sessions rather than individual tunnel sessions 512 whenever possible. This will avoid the new tunnel session setup 513 overhead. Therefore, when the tunnel endpoint creates a reservation 514 for a tunnel session based on the individual end-to-end session, it 515 is up to local policy whether it wants to actually create an 516 aggregate session by requesting more resources than the current end- 517 to-end session requires. If it does, other end-to-end sessions 518 arrived later may make use of this aggregate tunnel session. The 519 tunnel endpoint will also need to determine how long to keep the 520 tunnel session if no active end-to-end session is currently mapped to 521 the aggregate tunnel session. The decision may be based on knowledge 522 of likelihood of traffic in the future. It should be noted that once 523 these kinds of on-demand aggregate tunnel sessions are set up, they 524 are treated the same as pre-configured tunnel sessions to future end- 525 to-end sessions. Therefore, the adjustment of such aggregate 526 sessions should follow Section 4. 528 Note that the session ID of an aggregate tunnel session should be 529 different from that of the end-to-end session because they usually 530 have separate lifetime. If the tunnel endpoint is certain that the 531 tunnel session is for an individual end-to-end session alone, it may 532 in some cases want to reuse the same session ID for both sessions. 533 This will require additional manipulation of the NSLP state at the 534 tunnel endpoints, since the NSLP state is usually keyed based on the 535 session ID. 537 4. Protocol Operation with Pre-configured Tunnel Sessions 539 This section discusses NSIS operation over tunnels that are pre- 540 configured through management interface with one or more tunnel 541 sessions. A pre-configured tunnel session may be mapped to one 542 session as an individual tunnel session but are usually mapped to 543 multiple end-to-end sessions as an aggregate tunnel session. 545 4.1. Tunnel with Exactly One Pre-configured Aggregate Session 547 If only one aggregate session is configured in the tunnel and all 548 traffic will receive the reserved tunnel resources, all packets just 549 need to be IP-in-IP encapsulated as usual. If there is only one 550 aggregate session configured in the tunnel but only some traffic 551 should receive the reserved tunnel resources through the aggregate 552 tunnel session, then the aggregate tunnel session should be assigned 553 an appropriate flow ID. Qualified packets need to be encapsulated 554 with this special flow ID. The rest of the traffic will be IP-in-IP 555 encapsulated as usual. 557 4.2. Tunnel with Multiple Pre-configured Aggregate Sessions 559 If there are multiple pre-configured aggregate sessions over a tunnel 560 setup, these sessions must be distinguished by their different 561 aggregate tunnel flow IDs. In this case it is necessary to 562 explicitly bind the end-to-end sessions with specific tunnel 563 sessions. This binding is conveyed between tunnel endpoints by the 564 tunnel BOUND_SESSION_ID object. Once the binding has been 565 established, Tentry should encapsulate qualified data packets 566 according to the associated aggregate tunnel flow ID. Intermediate 567 nodes in the tunnel will then be able to filter these packets to 568 receive reserved tunnel resources. 570 4.3. Adjustment of Pre-configured Tunnel Sessions 572 Adjustment of pre-configured tunnel sessions upon the change of its 573 mapped end-to-end sessions is up to local policy mechanisms. RSVP- 574 TUNNEL [16] described multiple choices to accomplish this. First, 575 the tunnel reservation is never adjusted, which makes the tunnel a 576 rough equivalent of a fixed-capacity hardware link ("hard pipe"). 577 Second, the tunnel reservation is adjusted whenever a new end-to-end 578 reservation arrives or an old one is torn down ("soft pipe"). Doing 579 this will require the Texit to keep track of the resources allocated 580 to the tunnel and the resources actually in use by end-to-end 581 reservations separately. The third approach adopts some hysteresis 582 in the adjustment of the tunnel reservation parameters. The tunnel 583 reservation is adjusted upwards or downwards occasionally, whenever 584 the end-to-end reservation level has changed enough to warrant the 585 adjustment. This trades off extra resource usage in the tunnel for 586 reduced control traffic and overhead. 588 5. NSIS-Tunnel Signaling Capability Discovery 590 There are several reasons why NSIS-tunnel signaling capability 591 discovery is needed. First, when the Tentry decides to use UDP 592 encapsulation to distinguish the tunnel flows, it needs to make sure 593 the Texit is capable of doing UDP decapsulation when the flows leave 594 the tunnel. Second, full operations of the NSIS tunnel mechanism, 595 such as association of the end-to-end and tunnel session and 596 adjustment of one session based on the state change of the other 597 session, require the involvement of both Tentry and Texit. 598 Therefore, one tunnel endpoint wants to know whether the other 599 endpoint is also NSIS-tunnel signaling capable in deciding whether or 600 not to initiate the related operations. 602 Manual configuration is one possible solution to the NSIS-tunnel 603 signaling capability discovery problem. This section defines a 604 NODE_CHAR object for GIST to automate the NSIS-tunnel capability 605 discovery process. 607 The format of the NODE_CHAR object follows the general object 608 definition in GIST [2]. It contains a fixed header giving the object 609 type and object length, followed by the object value as shown in 610 Figure 3 and Figure 4. 612 The Value field contains a single 'T' bit, indicating the NSIS-tunnel 613 scheme defined in this document. It is also possible to use multiple 614 bits to define NSIS-tunnel capability in finer granularity. We have 615 adopted the simplest approach by using only one bit. The remaining 616 reserved bits can be used to signal other node characteristics in the 617 future. 619 The bits marked 'A' and 'B' define the desired behavior for objects 620 whose Type field is not recognized. If a node does not recognize the 621 NODE_CHAR object, the desired behavior is "Ignore". That is, the 622 object must be deleted and the rest of the message processed as 623 usual. This can be satisfied by setting 'AB' to '01' according to 624 GIST specification . 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 |A|B|r|r| Type |r|r|r|r| Length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 // Value // 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 3: NODE_CHAR Object Format 636 Type: NODE_CHAR 638 Length: Fixed (1 32-bit word) 640 Value: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 |T| Reserved | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Figure 4: NODE_CHAR Object Value 650 This NODE_CHAR object is included in a QUERY or RESERVE message by a 651 tunnel endpoint who wishes to learn about the other endpoint's tunnel 652 handling capability. The other endpoint that receives this object 653 will know that the sending endpoint is NSIS-tunnel capable, and place 654 the same object in a RESPONSE message to inform the sending endpoint 655 of its own tunnel handling capability. The procedures for using 656 NODE_CHAR object in the two dynamically created tunnel session 657 scenarios are further detailed below. 659 When both the end-to-end and the tunnel session are sender-initiated 660 (Section 3.1.1) and Tentry is NSIS-tunnel capable, the Tentry 661 includes a Request Identification Information (RII) object (see [3]) 662 (if it is not present already) and a NODE_CHAR object with T bit set 663 in the first end-to-end RESERVE message sent to Texit. When Texit 664 receives this RESERVE message, if it supports NSIS tunneling, it 665 learns that Tentry is NSIS-tunnel capable and includes the same 666 object with T bit set in the following end-to-end RESPONSE message 667 sent back to Tentry. Otherwise, Texit ignores the NODE_CHAR object. 668 When Tentry receives the RESPONSE message, it learns whether Texit is 669 NSIS-tunnel capable by examining the existence of the NODE_CHAR 670 object and its T-bit. If both tunnel endpoints are NSIS-tunnel 671 capable, the rest of the procedures will follow those defined in 672 Section 3.1.1. Alternatively, Tentry may send out tunnel RESERVE 673 message before the RESPONSE message confirming the NSIS-tunnel 674 capability of Texit is received. If later it deduces that the Texit 675 is not NSIS-tunnel capable, it should send out teardown messages to 676 cancel the tunnel session reservation that has already been made. 677 This way the signaling process is faster when Texit is NSIS-tunnel 678 capable, but it can lead to temporary waste of tunnel resources if 679 Texit is not NSIS-tunnel capable. 681 If both end-to-end and tunnel sessions are receiver-initiated 682 (Section 3.1.2) and Tentry is NSIS-tunnel capable, the Tentry 683 includes an RII object (if it is not present already) and a NODE_CHAR 684 object with T bit set in the first end-to-end QUERY message sent 685 toward Texit. An NSIS-tunnel capable Texit learns from the NODE_CHAR 686 object whether Tentry is NSIS-tunnel capable. In the later end-to- 687 end RESPONSE message to this QUERY message, the NSIS-tunnel capable 688 Texit includes a NODE_CHAR object with T bit set to notify Tentry of 689 its own tunnel capability. If both tunnel endpoints are NSIS-tunnel 690 capable, the rest of the procedures will follow those defined in 691 Section 3.1.2. Otherwise, Texit will not initiate tunnel session 692 reservations. 694 6. IANA Considerations 696 This document defines a new object type called NODE_CHAR for GIST. 697 Its OType value needs to be assigned by IANA. The object format and 698 the setting of the extensibility bits are defined in Section 5. 700 7. Security Considerations 702 This draft does not draw new security threats. Security 703 considerations for NSIS NTLP and QoS NSLP are discussed in [2] and 704 [3], respectively. General threats for NSIS can be found in [18]. 706 8. Appendix 708 8.1. NSIS-tunnel Operation for other Types of NSLP 710 This document discusses tunnel operation using QoS NSLP. It will be 711 desirable to have the scheme work with other NSLPs as well. Since 712 NSIS-tunnel operation involves specific NSLP itself and different 713 NSLPs have different message exchange semantics, the NSIS-tunnel 714 specification would not be the same for all NSLPs. However the basic 715 aspects behind NSIS-tunnel operation could indeed be similar for 716 different types of NSLPs. For example, in the case of NATFW NSLP 717 [13], one of the most important signaling operations is CREATE. 718 Assuming Tentry is a NATFW NSLP, the tunnel handling for the CREATE 719 operation is expected to be very similar to the sender-initiated QoS 720 reservation case. There are also a number of reverse directional 721 operations in NATFW NSLP, such as RESERVE_EXTERNAL_ADDRESS and 722 UCREATE. Detailed discussion of their operations inside the tunnel 723 will be the scope of a separate document. 725 8.2. NSIS-tunnel Operation and Mobility 727 NSIS-tunnel operation needs to interact with IP mobility in an 728 efficient way. In places where pre-configured tunnel sessions are 729 available, the process is relatively straightforward. For dynamic 730 individual signaling tunnel sessions, one way to improve NSIS 731 mobility efficiency in the tunnel is to reuse the session ID of the 732 tunnel session when tunnel flow ID changes during mobility. This 733 works as follows. With a mobile IP tunnel, one tunnel endpoint is 734 the Home Agent (HA), and the other endpoint is the Mobile Node (MN) 735 if collocated Care-of-Address (CoA) is used, or the Foreign Agent 736 (FA) if FA CoA is used. When MN is a receiver, Tentry is the HA and 737 Texit is the MN or FA. In a mobility event, handoff tunnel signaling 738 messages will start from HA, which may use the same session ID for 739 the new tunnel session. When MN is a sender and collocated CoA is 740 used, Tentry is the MN and Texit is the HA. Handoff tunnel signaling 741 is started at the MN. It may also use the session ID of the previous 742 tunnel session for the new tunnel session. When MN is a sender and 743 FA CoA is used, the situation is complicated because Tentry has 744 changed from the old FA to the new FA. In this case the new FA does 745 not have the session ID of the previous tunnel session. 747 When mobile IP is operating on a bi-directional tunneling mode, NSIS- 748 tunnel operation with mobility may be further improved by localizing 749 the handoff tunnel signaling process by bypassing the path between HA 750 and CN. 752 General aspects of NSIS interaction with mobility are discussed in 753 [14]. 755 8.3. Various Design Alternatives 757 8.3.1. End-to-end and Tunnel Signaling Integration Model 759 The contents of the original end-to-end singling messages are not 760 directly examined by tunnel intermediate nodes. To carry out tunnel 761 signaling we choose to maintain a separate tunnel session for the 762 end-to-end session by generating tunnel specific signaling messages. 763 An alternative approach is to stack tunnel specific objects on top of 764 the original end-to-end messages and make these messages visible to 765 tunnel intermediate nodes. Thus, these new messages serve both the 766 end-to-end session and tunnel session. The latter approach turns out 767 to be difficult because the actual tunnel signaling messages differ 768 from the end-to-end signaling message both in GIST layer and NSLP 769 layer information, such as MRI, PACKET CLASSIFIER and QSPEC. 770 Although QSPEC can be stacked in an NSLP message, there doesn't seem 771 to be a handy way to stack MRI and the PACKET CLASSIFIER in the NSLP 772 layer. In addition, the stacking method only applies to individual 773 signaling tunnels. The separate end-to-end and tunnel session 774 signaling model adopted in this document handles both individual and 775 aggregate signaling tunnels in a consistent way. 777 8.3.2. Packet Classification over the Tunnel 779 Packet classification over the tunnel may be done in either of the 780 two ways: first, retaining the end-to-end packet classification 781 rules; second, using tunnel specific classification rules. In the 782 first approach, tunnel packet classification is not tied with the 783 tunnel MRI. This is a useful property especially in handling tunnel 784 mobility. Mobility causes changes in the tunnel MRI. If at the same 785 time the packet classification rule does not change, the common path 786 after a handoff does not need to be updated about the packet 787 classification, which results in a better handoff performance. The 788 main problem with this approach is that most existing routers do not 789 support inspection of inner IP headers in an IP tunnel, where the 790 tunnel independent packet classification fields usually reside. 791 Therefore this document adopts the second approach which does not 792 pose special classification requirements on intermediate tunnel 793 nodes. 795 8.3.3. Tunnel Binding Methods 797 In this document, the end-to-end session and its mapping tunnel 798 session use different session IDs and they are associated with each 799 other using the BOUND_SESSION_ID object. This choice is obvious for 800 aggregate tunnel sessions because in those cases the original end-to- 801 end session and the corresponding aggregate tunnel session require 802 independent control. 804 Sessions in individual signaling tunnels are created and deleted 805 along with the related end-to-end session. So association between 806 the end-to-end session and the corresponding individual tunnel 807 session has another choice: the two sessions may share the same 808 session ID. Instead of sending a BOUND_SESSION_ID object, it may be 809 possible to define a BOUND_FLOW_ID object, to bind the flow ID of the 810 end-to-end session to the flow ID of the tunnel session at the tunnel 811 endpoints. However, since flow ID is usually derived from MRI, if a 812 NAT is present in the tunnel, this BOUND_FLOW_ID object will have to 813 be modified in the middle, which makes the process fairly 814 complicated. Furthermore, it is not desirable to have different 815 session association mechanisms for aggregate signaling tunnels and 816 individual signaling tunnels. Therefore, we decide to use the same 817 tunnel BOUND_SESSION_ID mechanism for both individual and aggregation 818 tunnel sessions. Note that in this case the mobility handling inside 819 the tunnel can still be optimized in certain situations as discussed 820 in Section 8.2. 822 In this document we used the existing BOUND_SESSION_ID object with a 823 tunnel Binding Code to indicate the reason of binding. Two other 824 options were considered. 826 1. Define a designated "tunnel object" to be included when tunnel 827 binding needs to be conveyed. 828 2. Define a "tunnel bit" in corresponding NSLP message headers. 830 These options are not chosen because they either require the creation 831 of an entirely new object, or change of basic message headers. They 832 are also not generic solutions that can cover other binding causes. 834 There are basically three ways to carry the binding object between 835 Tentry and Texit, using (a) end-to-end signaling messages, (b) tunnel 836 signaling messages, (c) both end-to-end and tunnel signaling 837 messages. In option (a) only tunnel endpoints see the tunnel binding 838 information. In option (b) every tunnel intermediate node sees the 839 binding information. Since there will be no state for the end-to-end 840 session in tunnel intermediate nodes, they will all generate a 841 message containing an "INFO_SPEC" object indicating no bound session 842 found according to [3], which is not desirable. Option (c) suffers 843 the same problem as in (b). Therefore the choice in this document 844 for carrying the tunnel binding object is option (a). 846 9. Acknowledgements 848 10. References 849 10.1. Normative References 851 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 852 Levels", BCP 14, RFC 2119, March 1997. 854 [2] Schulzrinne, H. and M. Stiemerling, "GIST: General Internet 855 Signalling Transport", draft-ietf-nsis-ntlp-20 (work in 856 progress), June 2009. 858 [3] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 859 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 860 (work in progress), February 2008. 862 10.2. Informative References 864 [4] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 865 Routing Encapsulation (GRE)", RFC 1701, October 1994. 867 [5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 868 Routing Encapsulation over IPv4 networks", RFC 1702, 869 October 1994. 871 [6] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 872 Flow Label Specification", RFC 3697, March 2004. 874 [7] Perkins, C., "IP Encapsulation within IP", RFC 2003, 875 October 1996. 877 [8] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 878 October 1996. 880 [9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 881 IPv6 Hosts and Routers", RFC 4213, October 2005. 883 [10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 884 December 2005. 886 [11] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 887 Specification", RFC 2473, December 1998. 889 [12] Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", 890 draft-ietf-nsis-qspec-21 (work in progress), November 2008. 892 [13] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ 893 Firewall NSIS Signaling Layer Protocol (NSLP)", 894 draft-ietf-nsis-nslp-natfw-20 (work in progress), 895 November 2008. 897 [14] Sanda, T., Fu, X., Jeong, S., Manner, J., and H. Tschofenig, 898 "Applicability Statement of NSIS Protocols in Mobile 899 Environments", 900 draft-ietf-nsis-applicability-mobility-signaling-12 (work in 901 progress), March 2009. 903 [15] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 904 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 906 [16] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 907 Operation Over IP Tunnels", RFC 2746, January 2000. 909 [17] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data 910 Flows", RFC 2207, September 1997. 912 [18] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 913 Steps in Signaling (NSIS)", RFC 4081, June 2005. 915 [19] Kent, S. and K. Seo, "Security Architecture for the Internet 916 Protocol", RFC 4301, December 2005. 918 Authors' Addresses 920 Charles Shen 921 Columbia University 922 Department of Computer Science 923 1214 Amsterdam Avenue, MC 0401 924 New York, NY 10027 925 USA 927 Phone: +1 212 854 3109 928 Email: charles@cs.columbia.edu 930 Henning Schulzrinne 931 Columbia University 932 Department of Computer Science 933 1214 Amsterdam Avenue, MC 0401 934 New York, NY 10027 935 USA 937 Phone: +1 212 939 7004 938 Email: schulzrinne@cs.columbia.edu 939 Sung-Hyuck Lee 940 SAMSUNG Advanced Institute of Technology 941 San 14-1, Nongseo-ri, Giheung-eup 942 Yongin-si, Gyeonggi-do 449-712 943 KOREA 945 Phone: +82 31 280 9552 946 Email: starsu.lee@samsung.com 948 Jong Ho Bang 949 SAMSUNG Advanced Institute of Technology 950 San 14-1, Nongseo-ri, Giheung-eup 951 Yongin-si, Gyeonggi-do 449-712 952 KOREA 954 Phone: +82 31 280 9585 955 Email: jh0278.bang@samsung.com