idnits 2.17.1 draft-ietf-nsis-tunnel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1461. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 19, 2006) is 6513 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '2') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-10 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '3') -- 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-09 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-11 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-applicability-mobility-signaling-04 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 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 Expires: December 21, 2006 Columbia U. 5 S. Lee 6 J. Bang 7 Samsung AIT 8 June 19, 2006 10 NSIS Operation Over IP Tunnels 11 draft-ietf-nsis-tunnel-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 21, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This draft presents an NSIS operation over IP tunnel scheme using QoS 45 NSLP as the NSIS signaling application. Both sender-initiated and 46 receiver-initiated NSIS signaling modes are discussed. The scheme 47 creates individual or aggregate tunnel sessions for end-to-end 48 sessions traversing the tunnel. Packets belonging to qualified end- 49 to-end sessions are mapped to corresponding tunnel sessions and 50 assigned special flow IDs to be distinguished from the rest of the 51 tunnel traffic. Tunnel endpoints keep the association of the end-to- 52 end and tunnel session mapping, so that adjustment in one session can 53 be reflected in the other. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. IP Tunneling Mechanisms and Tunnel Signaling Capability . 4 60 2.2. NSIS Tunnel Operation Overview . . . . . . . . . . . . . . 5 61 3. Protocol Design Decisions . . . . . . . . . . . . . . . . . . 6 62 3.1. Flow Packet Classification over the Tunnel . . . . . . . . 6 63 3.2. Tunnel Signaling and its Association with End-to-end 64 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Protocol Operation with Dynamically Created Tunnel Sessions . 8 66 4.1. Operation Scenarios . . . . . . . . . . . . . . . . . . . 8 67 4.1.1. Sender-initiated Reservation for both End-to-end 68 and Tunnel Signaling . . . . . . . . . . . . . . . . . 9 69 4.1.2. Receiver-initiated Reservation for both End-to-end 70 and Tunnel Signaling . . . . . . . . . . . . . . . . . 11 71 4.1.3. Sender-initiated Reservation for End-to-end and 72 Receiver-initiated Reservation for Tunnel Signaling . 12 73 4.1.4. Receiver-initiated Reservation for End-to-end and 74 Sender-initiated Reservation for Tunnel Signaling . . 14 75 4.2. Implementation Specific Issues . . . . . . . . . . . . . . 15 76 4.2.1. End-to-end and Tunnel Signaling Interaction . . . . . 15 77 4.2.2. Aggregate vs. Individual Tunnel Session Setup . . . . 17 78 5. Protocol Operation with Pre-configured Tunnel Sessions . . . . 17 79 5.1. Tunnel with Exactly One Pre-configured Aggregate 80 Session . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 5.2. Tunnel with Multiple Pre-configured Aggregate Sessions . . 18 82 5.3. Adjustment of Pre-configured Tunnel Sessions . . . . . . . 18 83 6. Processing Rules for Selected End-to-end QoS NSLP Messages . . 19 84 6.1. End-to-end QUERY Message at Tentry . . . . . . . . . . . . 19 85 6.2. End-to-end QUERY Message at Texit . . . . . . . . . . . . 19 86 6.3. End-to-end RESERVE Message at Tentry . . . . . . . . . . . 19 87 6.3.1. Sender-initiated RESERVE Message . . . . . . . . . . . 19 88 6.3.2. Receiver-initiated RESERVE Message . . . . . . . . . . 20 89 6.4. End-to-end RESERVE Message at Texit . . . . . . . . . . . 21 90 6.4.1. Sender-initiated RESERVE Message . . . . . . . . . . . 21 91 6.4.2. Receiver-initiated RESERVE Message . . . . . . . . . . 22 92 6.5. Special Processing Rules for Tunnels with Aggregate 93 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 7. Tunnel Signaling Capability Discovery . . . . . . . . . . . . 23 95 8. Other Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 8.1. Other Types of NSLP . . . . . . . . . . . . . . . . . . . 25 97 8.2. IPSEC Flows . . . . . . . . . . . . . . . . . . . . . . . 26 98 8.3. NSIS-tunnel Operation and Mobility . . . . . . . . . . . . 26 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 10.1. Various Design Alternatives . . . . . . . . . . . . . . . 27 102 10.1.1. End-to-end and Tunnel Signaling Interaction Model . . 27 103 10.1.2. Packet Classification over the Tunnel . . . . . . . . 28 104 10.1.3. Tunnel Binding Methods . . . . . . . . . . . . . . . . 28 105 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 107 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 108 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 110 Intellectual Property and Copyright Statements . . . . . . . . . . 33 112 1. Requirements notation 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [1]. 118 2. Introduction 120 When IP tunnel mechanism is used to transfer signaling messages, 121 e.g., NSIS messages, the signaling messages usually become hidden 122 inside the tunnel and are not known to the tunnel intermediate nodes. 123 In other words, the IP tunnel behaves as a logical link that does not 124 support signaling in the end-to-end path. If true end-to-end 125 signaling support is desired, there needs to be a scheme to enable 126 signaling at the tunnel segment of the end-to-end signaling path. 127 This draft describes such a scheme for NSIS operation over IP 128 tunnels. We assume QoS NSLP as the NSIS signaling application. 130 2.1. IP Tunneling Mechanisms and Tunnel Signaling Capability 132 There are a number of common IP tunneling mechanisms, such as Generic 133 Routing Encapsulation (GRE) [4][15], Generic Routing Encapsulation 134 over IPv4 Networks (GREIP4) [5] , IP Encapsulation within IP 135 (IP4INIP4) [7], Minimal Encapsulation within IP (MINENC) [8], Generic 136 Packet Tunneling in IPv6 Specification (IP6GEN) [11], IPv6 over IPv4 137 tunneling (IP6INIP4) [9], IPSEC tunneling mode [19][10]. These 138 mechanisms can be differentiated according to the format of the 139 tunnel encapsulation header. IP4INIP4, IP6INIP4 and IP6GENIP4 can be 140 seen as normal IP in IP tunnel encapsulation because their tunnel 141 encapsulation headers are in the form of a standard IP header. All 142 GRE-related IP tunneling (GRE,GREIP4), MINENC and IPSEC tunneling 143 mode can be seen as modified IP in IP tunnel encapsulation because 144 the tunnel encapsulation header contains additional information 145 fields besides a standard IP header. The additional information 146 fields are the GRE header for GRE and GREIP4, the minimum 147 encapsulation header for MINENC and the Encapsulation Security 148 Payload (ESP) header for IPSEC tunneling mode. 150 By default any end-to-end signaling messages arriving at the tunnel 151 endpoint will be encapsulated the same way as data packets. Tunnel 152 intermediate nodes do not identify them as signaling messages. A 153 signaling-aware IP tunnel can participate in a signaling network in 154 various ways. Prior work on RSVP operation over IP tunnles (RSVP- 155 TUNNEL) [16] identifies two types of QoS-aware tunnels: a tunnel that 156 can promise some overall level of resources but cannot allocate 157 resources specifically to individual data flows, or a tunnel that can 158 make reservations for individual end-to-end data flows. This 159 classification leads to two types of tunnel signaling sessions: 160 individual tunnel signaling sessions that are created and torn down 161 dynamically as end-to-end session come and go, and aggregate tunnel 162 sessions that can either be fixed, or dynamically adjusted as the 163 actually used session resources increase or decrease. Aggregate 164 tunnel sessions are usually pre-configured but can also be 165 dynamically created. A tunnel MAY contain only individual tunnel 166 sessions or aggregate tunnel sessions or both. 168 2.2. NSIS Tunnel Operation Overview 170 This NSIP operation over IP tunnel scheme is designed to work with 171 most, if not all, existing IP in IP tunneling mechanisms. The scheme 172 requires the tunnel endpoints to support specific tunnel related 173 functionalities. Such tunnel endpoints are called NSIS-tunnel 174 capable endpoints. Tunnel intermediate nodes do not need to have 175 special knowledge about this scheme. When tunnel endpoints are NSIS- 176 tunnel capable, this scheme enables the proper signaling initiation 177 and adjustment inside the tunnel to match the requests of the 178 corresponding end-to-end session. In cases when tunnel session 179 signaling status is uncertain or not successful, the end-to-end 180 session will be notified about the existence of possible NSIS-unaware 181 links in the end-to-end path. 183 The overall design of this NSIS operation over IP tunnel scheme is 184 conceptually similar to RSVP-TUNNEL [16]. However, the details of 185 the scheme address all the important differences of NSIS from RSVP. 186 For example, 188 o NSIS is based on a two-layer architecture, namely a signaling 189 transport layer and a signaling application layer. It is designed 190 as a generic framework to accommodate various signaling 191 application needs. The basic RSVP protocol does not have a layer 192 split and is only for QoS signaling. 193 o NSIS QoS NSLP allows both sender-initiated and receiver-initiated 194 reservations; RSVP only supports receiver-initiated reservations. 195 o NSIS deals only with unicast; RSVP also supports multicast. 196 o NSIS integrates new features, such as the Session ID, to 197 facilitate operation in specific environments (e.g. mobility and 198 multi-homing). 200 From a high level point of view, there are two main issues in a 201 signaling operation over IP tunnel scheme. First, how packet 202 classification is performed inside the tunnel. Second, how signaling 203 is carried out inside the tunnel. 205 Packets belonging to qualified data flows need to be recognized by 206 tunnel intermediate nodes to receive special treatment. Packet 207 classification is traditionally based on flow ID. After a typical 208 IP-in-IP tunnel encapsulation, packets from different flows appear as 209 having the same flow ID which usually consists of the Tunnel Entry 210 (Tentry) address and Tunnel Exit (Texit) address. Therefore, the 211 flow ID for a signaled flow needs to contain further demultiplexing 212 information to make it distinguishable from non-signaled flows, and 213 also from other different signaled flows. 215 The special flow ID for signaled flows inside the tunnel needs to be 216 carried in tunnel signaling messages, along with tunnel adjusted QoS 217 parameters, to set up or modify the state information in tunnel 218 intermediate nodes. This process creates separate tunnel signaling 219 sessions between the tunnel endpoints. In most cases, it is 220 necessary to maintain the state association between an end-to-end 221 session and its corresponding tunnel session so that any change to 222 one session MAY be reflected in the other. 224 In the next section, we will illustrate details on packet 225 classification over the tunnel, signaling over the tunnel as well as 226 association of end-to-end and tunnel signaling. 228 3. Protocol Design Decisions 230 3.1. Flow Packet Classification over the Tunnel 232 A flow can be an individual flow or an aggregate flow. Flow ID 233 formats that MAY be used to identify packets in individual tunnel 234 flows are listed below. 236 o Selected fields from the base IP header portion of the tunnel 237 encapsulation header. For example, the IP source and destination 238 address fields, which contain the IP addresses of Tentry and 239 Texit, together with another field for tunnel-wide demultiplexing. 240 This could be the IPv6 flow label field [6], or the Traffic Class, 241 also known as DiffServ Code Point (DSCP) field. Note that the 242 DSCP field can also be used to represent an aggregate DiffServ 243 flow. As long as individual flow classification is processed 244 before aggregate flow classification, or a longest match kind of 245 packet classifier is used, this individual tunnel flow 246 demultiplexing with DSCP field can work. In the rare cases where 247 these conditions cannot be satisfied, it is still possible to 248 choose different range of DSCP values so that the values used for 249 individual tunnel flow demultiplexing do not collide with those 250 used for DiffServ aggregate flows. Compared to the IPv6 flow 251 label approach, using DSCP field as part of the tunnel flow ID can 252 be applied to both IPv4 and IPv6 and is probably easier to deploy. 253 The drawback is that the small number of bits in the DSCP field 254 limits the total number of individual flows that can be 255 distinguished in the tunnel. Overall, this group of flow ID 256 formats enable efficient packet classification over the tunnel 257 without introducing additional processing requirements on the 258 existing infrastructure. They are also easy to deploy. 260 o Selected fields from the base IP header portion of the tunnel 261 encapsulation header, combined with fields from the addtional 262 infromation in the tunnel encapsulation header. This applies to 263 modified IP-in-IP encapsulation as we mentioned in Section 2.1. 264 An example of the additional information field is the Security 265 Prameter Index (SPI) field for IPSEC tunnels. Comparing with the 266 flow ID formats in the first group, these flow ID formats might 267 pose more requirements at the NSIS protocol side if the addition 268 information field is unique to the specific tunnel mechanism and 269 not already recognized in basic NSIS specification. 271 o UDP header insertion. Inserting an extra UDP header between the 272 tunnel encapsulation IP header and the tunnel payload provides 273 additional demultiplexing information for a tunnelled flow. The 274 drawback of this flow ID format, as compared to the above two 275 format groups, is the additional UDP header overhead both for 276 bandwidth and processing. Moreover, this approach modifies the 277 basic tunneling mechanism at the Tentry, so Texit MUST also be 278 aware of the special UDP insertion in order to correctly 279 decapsulate and forward original packets further along the path. 281 The above three groups of flow ID formats MAY also be used for 282 aggregate tunnel flows. For example, a common aggregate flow ID 283 contains the addresses of tunnel endpoints and a DSCP value. There 284 are other options for aggregate flows. For example, When additional 285 interfaces at tunnel endpoints are available, the IP address of an 286 additional interface at Tentry plus the IP address of the Texit, MAY 287 constitute an aggregate flow ID. 289 The decision of using a specific flow ID format is left to a policy 290 mechanism outside the scope of this document. Tunnel signaling is 291 performed based on the chosen flow ID. As long as the flow ID format 292 is supported, Tentry SHOULD encapsulate all incoming packets for the 293 specific data flows according to the chosen flow ID format. Texit 294 SHOULD be able to decapsulate the packets if any special tunnel flow 295 encapsulation is performed at the Tentry. 297 3.2. Tunnel Signaling and its Association with End-to-end Signaling 299 Tunnel signaling messages contain tunnel specific parameters such as 300 tunnel Message Routing Information (MRI) and tunnel adjusted QoS 301 parameters. But in general, the formats of tunnel signaling messages 302 are the same as end-to-end signaling messages. Tunnel signaling is 303 carried out according to the same signaling rules as for end-to-end 304 signaling. The main challenge is, therefore, the interaction between 305 tunnel signaling and end-to-end signaling. The interaction is 306 achieved by special functionalities supported in the NSIS-tunnel 307 aware tunnel endpoints. These special functionalities include 308 assigning tunnel flow IDs, creating tunnel session association, 309 notifying the other endpoint about tunnel association, adjusting one 310 session based on change of the other session, encapsulating 311 (decapsulating) packets according to the chosen tunnel flow ID at 312 Tentry (Texit), and etc. In most cases, we expect to have bi- 313 directional tunnels, where both tunnel endpoints are NSIS-tunnel 314 aware. 316 When both Tentry and Texit are NSIS-tunnel aware, the endpoint that 317 creates the tunnel session MAY need to notify the other endpoint of 318 the association between the end-to-end and tunnel session. This is 319 achieved by using the QoS NSLP BOUND_SESSION_ID object with a binding 320 code indicating tunnel handling as the reason for binding. In the 321 rest of this document, we refer to a BOUND_SESSION_ID object with its 322 tunnel binding_code set as a tunnel BOUND_SESSION_ID object or a 323 tunnel binding object. The tunnel binding object is carried in the 324 end-to-end signaling messages and contains the session ID of the 325 corresponding tunnel session. NSIS-tunnel aware endpoints that 326 receive this tunnel BOUND_SESSION_ID object SHOULD perform tunnel 327 related procedures and then remove it from any end-to-end signaling 328 messages sent out of the tunnel. 330 4. Protocol Operation with Dynamically Created Tunnel Sessions 332 The operation details for NSIS signaling over IP tunnels are more 333 complicated if the tunnel session needs to be dynamically created, 334 comparing to the case when tunnel sessions are pre-configured. We 335 discuss these two cases in this and the subsequent section, 336 respectively. If a tunnel contains both dynamic and pre-configured 337 tunnel sessions, it can be handled by the combination of the 338 corresponding mechanism for each type of tunnel sessions. The choice 339 of mapping an end-to-end session to a specific type of tunnel session 340 is up to policy control. 342 4.1. Operation Scenarios 344 To dynamically create a mapping tunnel session upon receiving an end- 345 to-end session, we identify four scenarios based on the sender- 346 initiated and receiver-initiated reservation modes of NSIS QoS NSLP: 348 o End-to-end session is sender-initiated; tunnel session is sender- 349 initiated. 350 o End-to-end session is receiver-initiated; tunnel session is 351 receiver-initiated. 352 o End-to-end session is sender-initiated; tunnel session is 353 receiver-initiated. 354 o End-to-end session is receiver-initiated; tunnel session is 355 sender-initiated. 357 In the following we describe a typical NSIS end-to-end and tunnel 358 signaling interaction process during the tunnel setup phase in each 359 of these four scenarios. The end-to-end QoS flow is assumed to be 360 one that qualifies an individual dynamic tunnel session, whose tunnel 361 reservation MUST be confirmed before the end-to-end reservation can 362 proceed further outside the tunnel. 364 It SHOULD be noted that different flow QoS requirements and policy 365 assumptions MAY cause the timing sequence of the messaging flow to be 366 slightly different. This will be discussed in Section 4.2. 368 Once the tunnel session has been created and associated with the end- 369 to-end session, any subsequent changes (modification or termination) 370 to either session MAY be communicated to the other one by the binding 371 endpoint so the state of the two binding sessions can keep 372 consistent. The exception is when the tunnel session is an aggregate 373 session. In that case, after setup, the adjustment of the tunnel 374 session SHOULD follow the rules for pre-configured aggregate tunnel 375 adjustment in Section 5. 377 4.1.1. Sender-initiated Reservation for both End-to-end and Tunnel 378 Signaling 380 Sender Tentry Tnode Texit Receiver 382 | | | | | 383 | RESERVE | | | | 384 +--------->| | | | 385 | | RESERVE' | | | 386 | +=========>| | | 387 | | | RESERVE' | | 388 | | +=========>| | 389 | | RESERVE | | 390 | +-------------------->| | 391 | | | RESPONSE'| RESERVE | 392 | | |<=========+--------->| 393 | | RESPONSE'| | | 394 | |<=========+ | | 395 | | | | RESPONSE | 396 | | | |<---------+ 397 | | RESPONSE | | 398 | |<--------------------+ | 399 | RESPONSE | | | | 400 |<---------+ | | | 401 | | | | | 402 | | | | | 404 Figure 1: Sender-initiated Reservation for both End-to-end and Tunnel 405 Signaling 407 This scenario assumes both end-to-end and tunnel sessions are sender- 408 initiated. Figure 1 shows the messaging flow of NSIS operation over 409 IP tunnels in this case. Tunnel signaling messages are distinguished 410 from end-to-end messages by a "'" after the message name. Tnode 411 denotes an intermediate tunnel node that participates in tunnel 412 signaling. The sender first sends an end-to-end RESERVE message 413 which arrives at Tentry. If Tentry supports tunnel signaling and 414 determines that an individual tunnel session needs to be established 415 for the end-to-end session, it chooses the tunnel flow ID, creates 416 the tunnel session and associates the end-to-end session with the 417 tunnel session. It then sends a tunnel RESERVE' message matching the 418 requests of the end-to-end session toward the Texit to reserve tunnel 419 resources. Tentry also appends to the original RESERVE message a 420 tunnel BOUND_SESSION_ID object containing the session ID of the 421 tunnel session and sends it toward Texit using normal tunnel 422 encapsulation. 424 The tunnel RESERVE' message is processed hop by hop inside the tunnel 425 for the flow identified by the chosen tunnel flow ID. When Texit 426 receives the tunnel RESERVE' message, a reservation state for the 427 tunnel session will be created. Texit MAY also send a tunnel 428 RESPONSE' message to Tentry. On the other hand, the end-to-end 429 RESERVE message passes through the tunnel intermediate nodes just 430 like any other tunneled packets. When Texit receives the end-to-end 431 RESERVE message, it notices the binding of a tunnel session and 432 checks the state for the tunnel session. When the tunnel session 433 state is available, it updates the end-to-end reservation state using 434 the tunnel session state, removes the tunnel BOUND_SESSION_ID object 435 and forwards the end-to-end RESERVE message further along the path 436 towards the receiver. When the end-to-end reservation finishes, an 437 end-to-end RESPONSE MAY be sent back from the receiver to the sender. 439 4.1.2. Receiver-initiated Reservation for both End-to-end and Tunnel 440 Signaling 442 Sender Tentry Tnode Texit Receiver 444 | | | | | 445 | QUERY | | | | 446 +--------->| | | | 447 | | QUERY' | | | 448 | +=========>| | | 449 | | | QUERY' | | 450 | | +=========>| | 451 | | QUERY | | 452 | +-------------------->| | 453 | | | | QUERY | 454 | | | +--------->| 455 | | | | RESERVE | 456 | | | |<---------+ 457 | | | RESERVE' | | 458 | | |<=========+ | 459 | | RESERVE' | | | 460 | |<=========+ | | 461 | | RESERVE | | 462 | |<--------------------+ | 463 | RESERVE | RESPONSE'| | | 464 |<---------+=========>| | | 465 | | | RESPONSE'| | 466 | | +=========>| | 467 | RESPONSE | | | | 468 +--------->| | | | 469 | | RESPONSE | | 470 | +-------------------->| | 471 | | | | RESPONSE | 472 | | | +--------->| 473 | | | | | 474 | | | | | 476 Figure 2: Receiver-initiated Reservation for both End-to-end and 477 Tunnel Signaling 479 This scenario assumes both end-to-end and tunnel sessions are 480 receiver-initiated. Figure 2 shows the messaging flow of NSIS 481 operation over IP tunnels in this case. When Tentry receives the 482 first end-to-end QUERY message from the sender, it chooses the tunnel 483 flow ID, creates the tunnel session and sends a tunnel QUERY' message 484 matching the request of the end-to-end session toward the Texit. 486 Tentry also appends to the original QUERY message with a tunnel 487 BOUND_SESSION_ID object containing the session ID of the tunnel 488 session and sends it toward the Texit using normal tunnel 489 encapsulation. 491 The tunnel QUERY' message is processed hop by hop inside the tunnel 492 for the flow identified by the chosen tunnel flow ID. When Texit 493 receives the tunnel QUERY' message, it creates a reservation state 494 for the tunnel session without sending out a tunnel RESERVE' message 495 immediately. 497 The end-to-end QUERY message passes along tunnel intermediate nodes 498 just like any other tunneled packets. When Texit receives the end- 499 to-end QUERY message, it notices the binding of a tunnel session and 500 checks the state for the tunnel session. When the tunnel session 501 state is available, Texit updates the end-to-end QUERY message using 502 the tunnel session state, removes the tunnel BOUND_SESSION_ID object 503 and forwards the end-to-end QUERY message further along the path. 505 When Texit receives the first end-to-end RESERVE message issued by 506 the receiver, it finds the reservation state of the tunnel session 507 and triggers a tunnel RESERVE' message for that session. Meanwhile 508 the end-to-end RESERVE message will be appended with a tunnel 509 BOUND_SESSION_ID object and forwarded towards Tentry. When Tentry 510 receives the tunnel RESERVE', it creates the reservation state for 511 the tunnel session and MAY send a tunnel RESPONSE' back to Texit. 512 When Tentry receives the end-to-end RESERVE, it creates the end-to- 513 end reservation state and updates it with information from the 514 associated tunnel session reservation state. Then Tentry further 515 forwards the end-to-end RESERVE upstream toward the sender. 517 4.1.3. Sender-initiated Reservation for End-to-end and Receiver- 518 initiated Reservation for Tunnel Signaling 520 Sender Tentry Tnode Texit Receiver 521 | | | | | 522 | RESERVE | | | | 523 +--------->| | | | 524 | | QUERY' | | | 525 | +=========>| | | 526 | | | QUERY' | | 527 | | +=========>| | 528 | | RESERVE | | 529 | +-------------------->| | 530 | | | RESERVE' | | 531 | | |<=========+ | 532 | | RESERVE' | | | 533 | |<=========+ | | 534 | | RESPONSE'| | | 535 | +=========>| | | 536 | | | RESPONSE'| | 537 | | +=========>| | 538 | | | | RESERVE | 539 | | | +--------->| 540 | | | | RESPONSE | 541 | | | |<---------+ 542 | | RESPONSE | | 543 | |<--------------------+ | 544 | RESPONSE | | | | 545 |<---------+ | | | 546 | | | | | 547 | | | | | 549 Figure 3: Sender-initiated Reservation for End-to-end and Receiver- 550 initiated Reservation for Tunnel Signaling 552 This scenario assumes the end-to-end signaling mode is sender- 553 initiated and the tunnel signaling mode is receiver-initiated. 554 Figure 3 shows the messaging flow of NSIS operation over IP tunnels 555 in this case. When Tentry receives the first end-to-end RESERVE 556 message from the sender, it chooses the tunnel flow ID, creates the 557 tunnel session and sends a tunnel QUERY' message matching the 558 requests of the end-to-end session toward the Texit. This Tunnel 559 QUERY' message SHOULD have the "RESERVE-INIT" bit set. Tentry also 560 appends to the original RESERVE message a tunnel BOUND_SESSION_ID 561 object containing the session ID of the tunnel session and sends it 562 toward Texit using normal tunnel encapsulation. 564 The tunnel QUERY' message is processed hop by hop inside the tunnel 565 for the flow identified by the chosen tunnel flow ID. When Texit 566 receives the tunnel QUERY' message, it creates a reservation state 567 for the tunnel session and immediately sends out a tunnel RESERVE' 568 message back to Tentry. When Tentry receives the tunnel RESERVE' 569 message it learns the outcome of the tunnel reservation and sends a 570 tunnel RESPONSE' message to Texit. 572 When Texit receives the end-to-end RESERVE message, it notices the 573 binding of a tunnel session and checks the state for the tunnel 574 session. It learns the outcome of tunnel session reservation from 575 the tunnel RESPONSE' message. Then it updates the end-to-end 576 reservation state using the tunnel session state, removes the tunnel 577 BOUND_SESSION_ID object and forwards the end-to-end RESERVE message 578 further along the path towards the receiver. When the end-to-end 579 reservation finishes, an end-to-end RESPONSE MAY be sent back from 580 the receiver to the sender. 582 4.1.4. Receiver-initiated Reservation for End-to-end and Sender- 583 initiated Reservation for Tunnel Signaling 585 Sender Tentry Tnode Texit Receiver 586 | | | | | 587 | QUERY | | | | 588 +--------->| | | | 589 | | QUERY' | | | 590 | +=========>| | | 591 | | | QUERY' | | 592 | | +=========>| | 593 | | QUERY | | 594 | +-------------------->| | 595 | | | | QUERY | 596 | | | +--------->| 597 | | | | RESERVE | 598 | | | |<---------+ 599 | | RESERVE | | 600 | |<--------------------+ | 601 | | | RESERVE' | | 602 | | +=========>| | 603 | | RESERVE' | | | 604 | +=========>| | | 605 | | | RESPONSE'| | 606 | | |<=========| | 607 | | RESPONSE'| | | 608 | |<=========| | | 609 | RESERVE | | | | 610 |<---------| | | | 611 | RESPONSE | | | | 612 +--------->| | | | 613 | | RESPONSE | | 614 | +-------------------->| | 615 | | | | RESPONSE | 616 | | | +--------->| 617 | | | | | 618 | | | | | 620 Figure 4: Receiver-initiated Reservation for End-to-end and Sender- 621 initiated Reservation for Tunnel Signaling 623 This scenario assumes the end-to-end signaling mode is receiver- 624 initiated and the tunnel signaling mode is sender-initiated. 625 Figure 4 shows the messaging flow of NSIS operation over IP tunnels 626 in this case. When Tentry receives the first end-to-end QUERY 627 message from the sender, it chooses the tunnel flow ID, creates the 628 tunnel session and sends a tunnel QUERY' message matching the request 629 of the end-to-end session toward the Texit. Tentry also appends to 630 the original QUERY message a tunnel BOUND_SESSION_ID object 631 containing the session ID of the tunnel session and sends it toward 632 the Texit using normal tunnel encapsulation. 634 The tunnel QUERY' message is processed hop by hop inside the tunnel 635 for the flow identified by the chosen tunnel flow ID. When Texit 636 receives the tunnel QUERY' message, it creates a reservation state 637 for the tunnel session without sending out a tunnel RESERVE' message 638 immediately. 640 The end-to-end QUERY message passes along tunnel intermediate nodes 641 just like any other tunneled packets. When Texit receives the end- 642 to-end QUERY message, it notices the binding of a tunnel session and 643 checks the state for the tunnel session. When the tunnel session 644 state is available, Texit updates the end-to-end QUERY message using 645 the tunnel session state, removes the tunnel BOUND_SESSION_ID object 646 and forwards the end-to-end QUERY message further along the path. 648 When Texit receives the first end-to-end RESERVE message issued by 649 the receiver, it finds the reservation state of the tunnel session. 650 Texit appends to the end-to-end RESERVE message a tunnel 651 BOUND_SESSION_ID object containing the matching tunnel session ID and 652 sends it upstream to Tentry. 654 When Tentry receives the end-to-end RESERVE message, it notices the 655 binding and immediately sends out a tunnel RESERVE' message matching 656 the end-to-end RESERVE request over the tunnel. This RESERVE' 657 message SHOULD include the Request Identification Information (RII) 658 to trigger a RESPONSE' from Texit. 660 When Tentry receives the result of tunnel reservation from the tunnel 661 RESPONSE' message, it updates the end-to-end RESERVE message and 662 forwards the end-to-end RESERVE message upstream to the Sender. The 663 Sender MAY send an end-to-end RESPONSE message to the receiver when 664 the whole process completes. 666 4.2. Implementation Specific Issues 668 4.2.1. End-to-end and Tunnel Signaling Interaction 670 Given the two separate end-to-end and tunnel signaling sessions, 671 there are many ways of integrating the signaling of each session. In 672 general, different interaction approaches can be grouped into 673 sequential mode and parallel mode. In sequential mode, end-to-end 674 signaling pauses when it is waiting for results of tunnel signaling, 675 and resumes upon receipt of the tunnel signaling outcome. In 676 parallel mode, end-to-end signaling continues outside the tunnel 677 while tunnel signaling is still in process and its outcome is 678 unknown. The operation outlined in Section 4.1 shows the sequential 679 mode. While this mode is suitable for a flow that requires hard 680 guarantee of tunnel reservation, it MAY not be the best choice for a 681 flow that can tolerate some QoS uncertainty but wants to complete the 682 signaling on the path as fast as possible. The parallel mode is 683 clearly for the latter case. 685 Having two separate signaling sessions also causes a possible race 686 condition. When an end-to-end session message carrying tunnel 687 binding object arrives at one of the tunnel endpoints, if the 688 corresponding tunnel session state has already been created, then the 689 tunnel endpoint can refer to information in the tunnel session state 690 (e.g., about tunnel reservation status, or tunnel resource 691 availability) and construct an end-to-end signaling message to be 692 sent out of the tunnel immediately. On the other hand, if the tunnel 693 endpoint receives an end-to-end signaling message carrying tunnel 694 binding referring to a tunnel session that does not yet exist, it MAY 695 either wait until the tunnel session information is ready, or forward 696 the end-to-end session signaling without waiting for the tunnel 697 session. If the end-to-end signaling indeed proceeds in the absence 698 of the tunnel session, the tunnel session MAY still be established 699 after some delay. Since the tunnel signaling message does not 700 contain its associated end-to-end session's session ID, it cannot 701 immediately change the state of its associated end-to-end session. 702 However, the next refresh of the corresponding end-to-end session 703 will carry the tunnel binding information and thus will update the 704 association of the end-to-end and the tunnel session state. If the 705 period waiting for the end-to-end signaling refresh is considered too 706 long, the tunnel endpoint MAY choose to actively poll the session 707 state table about the existence of tunnel session before the refresh 708 timer expires. In any case, once the end-to-end signaling session 709 learns about the tunnel signaling it can send an immediate refresh 710 out of the tunnel with knowledge of tunnel session. 712 The decision on whether and how long to wait for the corresponding 713 tunnel session information is implementation specific and controlled 714 by the tunnel endpoints. This document only requires that if an 715 NSIS-tunnel aware endpoint decides to go forward with the end-to-end 716 signaling outside the tunnel with an uncertain tunnel session 717 condition, it SHOULD indicate this in the corresponding end-to-end 718 signaling messages. As far as QoS NSLP is concerned, this means the 719 NON-QoSM Hop field [12] SHOULD be set to one. Note that in some 720 cases, the application using NSIS signaling MAY wish to indicate the 721 preferred way of end-to-end and tunnel signaling interaction. For 722 example, an application that can not tolerate any QoS uncertainty 723 will prefer the sequential mode of operation; an application that has 724 a looser QoS requirement MAY prefer the parallel mode of operation 725 for faster signaling speed. Current NSIS specification does not 726 contain fields to convey this preference. New objects or flags will 727 need to be defined if this behavior is considered necessary. 729 4.2.2. Aggregate vs. Individual Tunnel Session Setup 731 The operation outlined in Section 4.1 applies to a flow that 732 qualifies an individual dynamic tunnel session. For a tunnel that 733 MAY contain multiple end-to-end sessions, it is more efficient to 734 keep aggregate tunnel sessions rather than individual tunnel sessions 735 whenever possible. This will save the cost of setting up a new 736 session and avoid the setup latency as well as the session 737 establishment race conditions mentioned above. Therefore, when the 738 tunnel endpoint creates a reservation for a tunnel session based on 739 the individual end-to-end session, it is up to local policy whether 740 it wants to actually create an aggregate session by requesting more 741 resources than the current end-to-end session requires. If it does, 742 other end-to-end sessions arrived later MAY make use of this 743 aggregate tunnel session. The tunnel endpoint will also need to 744 determine how long to keep the tunnel session if no active end-to-end 745 session is currently mapped to the aggregate tunnel session. The 746 decision MAY be based on knowledge of likelihood of traffic in the 747 future. It SHOULD be noted that once these kinds of on-demand 748 aggregate tunnel sessions are set up, they are treated the same as 749 pre-configured tunnel sessions to future end-to-end sessions. 750 Therefore, the adjustment of such aggregate sessions SHOULD follow 751 Section 5. 753 Note that the session ID of an aggregate tunnel session SHOULD be 754 different from that of the end-to-end session because they usually 755 have separate lifetime. If the tunnel endpoint is certain that the 756 tunnel session is for an individual end-to-end session alone, it MAY 757 in some cases want to reuse the same session ID for both sessions. 758 This will require additional manipulation of the NSLP state at the 759 tunnel endpoints, since the NSLP state is usually keyed based on the 760 session ID. 762 5. Protocol Operation with Pre-configured Tunnel Sessions 764 This section discusses NSIS operation over tunnels that are pre- 765 configured through management interface with one or more tunnel 766 sessions. A pre-configured tunnel sessions MAY be mapped to one 767 session as an individual tunnel session but are usually mapped to 768 multiple end-to-end sessions as an aggregate tunnel session. 770 5.1. Tunnel with Exactly One Pre-configured Aggregate Session 772 If only one aggregate session is configured in the tunnel and all 773 traffic will receive the reserved tunnel resources, all packets just 774 need to be IP-in-IP encapsulated as usual. If there is only one 775 aggregate session configured in the tunnel but only some traffic 776 SHOULD receive the reserved tunnel resources through the aggregate 777 tunnel session, then the aggregate tunnel session SHOULD be assigned 778 an appropriate flow ID. Qualified packets need to be encapsulated 779 with this special flow ID. The rest of the traffic will be IP-in-IP 780 encapsulated as usual. 782 5.2. Tunnel with Multiple Pre-configured Aggregate Sessions 784 If there are multiple pre-configured aggregate sessions over a tunnel 785 set up, these sessions MUST be distinguished by their different 786 aggregate tunnel flow IDs. In this case it is necessary to 787 explicitly bind the end-to-end sessions with specific tunnel 788 sessions. This binding is conveyed between tunnel endpoints by the 789 tunnel BOUND_SESSION_ID object. Once the binding has been 790 established, Tentry SHOULD encapsulate qualified data packets 791 according to the associated aggregate tunnel flow ID. Intermediate 792 nodes in the tunnel will then be able to filter these packets to 793 receive reserved tunnel resources. 795 5.3. Adjustment of Pre-configured Tunnel Sessions 797 Adjustment of pre-configured tunnel sessions upon the change of its 798 mapped end-to-end sessions is related is up to local policy 799 mechanisms. RSVP-TUNNEL [16] described multiple choices to 800 accomplish this. First, the tunnel reservation is never adjusted, 801 which makes the tunnel a rough equivalent of a fixed-capacity 802 hardware link ("hard pipe"). Second, the tunnel reservation is 803 adjusted whenever a new end-to-end reservation arrives or an old one 804 is torn down ("soft pipe"). Doing this will require the Texit to 805 keep track of the resources allocated to the tunnel and the resources 806 actually in use by end-to-end reservations separately. The third 807 approach adopts some hysteresis in the adjustment of the tunnel 808 reservation parameters. The tunnel reservation is adjusted upwards 809 or downwards occasionally, whenever the end-to-end reservation level 810 has changed enough to warrant the adjustment. This trades off extra 811 resource usage in the tunnel for reduced control traffic and 812 overhead. 814 6. Processing Rules for Selected End-to-end QoS NSLP Messages 816 The following lists basic tunnel related message processing rules for 817 selected end-to-end QoS NSLP messages working in the sequential 818 interaction mode. They are provided as references for implementors 819 to insure minimal interoperability. 821 6.1. End-to-end QUERY Message at Tentry 823 When an end-to-end QUERY message is received at Tentry, Tentry checks 824 whether the end-to-end session is entitled to tunnel resources. 826 If the end-to-end session SHOULD be bound to a tunnel session yet to 827 be created. Tentry creates a tunnel QUERY' message and sends it to 828 Texit. Tentry also appends a tunnel BOUND_SESSION_ID object to the 829 end-to-end QUERY message. The tunnel BOUND_SESSION_ID object 830 contains the session ID of the tunnel session. The end-to-end QUERY 831 message is then encapsulated and sent out through the tunnel 832 interface. 834 If the end-to-end session SHOULD be bound to an existing tunnel 835 session (whether aggregate or individual), Tentry appends a tunnel 836 BOUND_SESSION_ID object to the end-to-end tunnel QUERY message and 837 sends it toward Texit through the tunnel interface. 839 6.2. End-to-end QUERY Message at Texit 841 When an end-to-end QUERY message containing a tunnel BOUND_SESSION_ID 842 object is received, Texit creates a conditional reservation state for 843 the end-to-end session (i.e., a state is created but the related 844 outgoing signaling message, in this case the QUERY message, is held 845 until further information is available). It also checks to see if a 846 conditional reservation state for the associated tunnel session is 847 available. If yes, it reads information from the tunnel session 848 state and sends the end-to-end QUERY downstream. If the conditional 849 reservation state for tunnel session is not yet available, it will be 850 created upon receiving the tunnel QUERY', and then Texit SHOULD 851 forward the end-to-end QUERY downstream with information from results 852 of the tunnel QUERY'. 854 6.3. End-to-end RESERVE Message at Tentry 856 6.3.1. Sender-initiated RESERVE Message 858 If the RESERVE message is received with its T-bit set (RESERVE tear), 859 Tentry removes the local state, then encapsulates the RESERVE message 860 and tunnels it to Texit. If there is a tunnel session associated 861 with this end-to-end session, Tentry also sends a tunnel RESERVE with 862 T-bit set for that tunnel session. 864 If the end-to-end RESERVE message is a refresh for an existing end- 865 to-end session and this session is associated with a tunnel session, 866 the RESERVE message refreshes both two sessions. If the RESERVE 867 message causes changes in resources reserved for the end-to-end 868 session, depending on whether the tunnel signaling is sender 869 initiated or receiver initiated, Tentry SHOULD create a new tunnel 870 RESERVE' message or tunnel QUERY' message to start changing the 871 tunnel reservation as well. At the same time, Tentry appends a 872 tunnel BOUND_SESSION_ID object to the end-to-end RESERVE message and 873 sends it to Texit through the tunnel interface. 875 If the message is the first RESERVE message for an end-to-end 876 session, Tentry determines whether the end-to-end session is entitled 877 to tunnel resources based on policy control mechanisms outside the 878 scope of this document. If not, no special tunnel related processing 879 is needed. Otherwise, if this session SHOULD be bound to an existing 880 tunnel session (whether aggregate or individual), Tentry creates the 881 association between the end-to-end session and the tunnel session. 882 Then it appends a tunnel BOUND_SESSION_ID object to the end-to-end 883 RESERVE message and sends it through the tunnel interface (i.e. the 884 message is encapsulated and tunneled to Texit as normal). 886 If the end-to-end session SHOULD be bound to a tunnel session yet to 887 be created, Tentry assigns the tunnel flow ID, and constructs a 888 tunnel RESERVE' or QUERY' message, depending on whether the tunnel 889 signaling is sender initiated or receiver initiated. The QSPEC in 890 this tunnel message MAY be different from the original QSPEC, taking 891 into consideration the tunnel overhead of the encapsulation of data 892 packets. Tentry then associates the tunnel session with the end-to- 893 end session in the NSLP state and sends the tunnel message toward 894 Texit to start reserving resources over the tunnel. At the same 895 time, Tentry appends a tunnel BOUND_SESSION_ID object to the end-to- 896 end RESERVE message and sends it through the tunnel interface. 898 6.3.2. Receiver-initiated RESERVE Message 900 If the RESERVE message is received with its T-bit set (RESERVE tear), 901 Tentry removes the local state and forwards the message upstream. If 902 the tunnel signaling is sender initiated, Tentry also sends a tunnel 903 RESERVE' message to tear down the tunnel session. 905 If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID 906 and is the first end-to-end RESERVE message, Tentry checks whether 907 the tunnel session bound to the end-to-end session indicated by the 908 RESERVE message already exists. If yes, Tentry records the 909 association between the end-to-end and the tunnel session, reads 910 information from the tunnel session to create the end-to-end RESERVE 911 message to be forwarded upstream. If the state for the tunnel 912 session is not available yet, Tentry SHOULD create state information 913 for the tunnel session and indicate that a conditional reservation is 914 pending. If tunnel signaling is sender initiated, Tentry also sends 915 a tunnel RESERVE' message toward Texit to reserve tunnel resources. 916 When the actual tunnel session status is known at Tentry (from a 917 tunnel RESERVE' if tunnel signaling is receiver initiated or at 918 tunnel RESPONSE' if tunnel signaling is sender initiated) and if at 919 this time there is a pending reservation, Tentry SHOULD generate an 920 end-to-end RESERVE message and forward it upstream. 922 If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID 923 and is a refresh, Texit refreshes the end-to-end session. If the 924 RESERVE message causes changes in resources reserved for the end-to- 925 end session and if tunnel signaling is sender initiated, Tentry sends 926 a tunnel RESERVE' message to Texit to change the reservation. In any 927 case, Texit checks the state information of the tunnel session. If 928 it finds that the reservation has been updated inside the tunnel, 929 Texit forwards the changed RESERVE message toward the sender. If the 930 tunnel reservation update failed, Texit MUST send a RESPONSE with 931 appropriate Error_Spec to the originator of the end-to-end RESERVE 932 message. 934 6.4. End-to-end RESERVE Message at Texit 936 6.4.1. Sender-initiated RESERVE Message 938 If the end-to-end RESERVE message is received with its T-bit set 939 (RESERVE tear), Texit removes the local state, then forwards the 940 RESERVE message downstream. If tunnel signaling is receiver- 941 initiated, Texit also sends a tunnel RESERVE tear upstream toward 942 Tentry to tear down the tunnel session. 944 If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID 945 and is the first end-to-end RESERVE message, Texit checks whether the 946 state for the tunnel session indicated by the RESERVE message already 947 exists. If yes, Texit records the association between the end-to-end 948 and the tunnel session and reads information from the tunnel session 949 to create the end-to-end RESERVE message to be forwarded downstream. 950 If the state for the tunnel session is not available yet, Texit 951 SHOULD create state information for the tunnel session and indicate 952 that a conditional reservation is pending. When the actual tunnel 953 RESERVE' or RESPONSE' message arrives, the tunnel session state will 954 be updated. If at this time there is a pending reservation, Texit 955 will generate an end-to-end RESERVE message and forwards it 956 downstream. 958 If the end-to-end RESERVE message contains a tunnel BOUND_SESSION_ID 959 and is a refresh, Texit refreshes the end-to-end session. If the 960 RESERVE message causes changes in resources reserved for the end-to- 961 end session, Texit checks the state information of the tunnel 962 session. If the reservation has been updated inside the tunnel, 963 Texit forwards the RESERVE message toward the receiver. If the 964 tunnel reservation update failed, Texit MUST send a RESPONSE with 965 appropriate Error_Spec to the originator of the end-to-end RESERVE 966 message. 968 Note that the processing rules for end-to-end RESERVE at Texit in 969 end-to-end sender-initiated case is similar to those for end-to-end 970 RESERVE at Tentry in end-to-end receiver-initiated case. 972 6.4.2. Receiver-initiated RESERVE Message 974 If the RESERVE message is received with its T-bit set (RESERVE tear), 975 Texit removes the local state, then forwards the RESERVE message 976 upstream. If there is an individual tunnel session associated with 977 this end-to-end session, Texit also sends a tunnel RESERVE' with 978 T-bit set for that tunnel session. 980 Otherwise Texit checks to see if the end-to-end session is associated 981 with a tunnel session. If only conditional reservation state is 982 found and no actual reservation has been made, this RESERVE is the 983 first end-to-end RESERVE message. Texit appends a tunnel 984 BOUND_SESSION_ID object to this end-to-end RESERVE message and sends 985 it toward Tentry through the tunnel interface. Meanwhile if tunnel 986 signaling is receiver initiated Texit sends tunnel RESERVE' message 987 toward Tentry to reserve tunnel resources. 989 If the end-to-end session is bound to a tunnel session and the 990 RESERVE message is a refresh, it refreshes both the end-to-end 991 session and tunnel session. If the RESERVE message causes changes in 992 resources reserved for the end-to-end session and if tunnel signaling 993 is receiver initiated, Texit MAY create a new tunnel RESERVE' message 994 to change the tunnel reservation as well. Meanwhile, the end-to-end 995 RESERVE is appended with the tunnel BOUND_SESSION_ID object and sent 996 to Tentry through the reverse path. 998 6.5. Special Processing Rules for Tunnels with Aggregate Sessions 1000 In situations where the end-to-end session is bound to aggregate 1001 tunnel sessions, the handling is similar to that of RSVP-TUNNEL [16]. 1003 If the associated tunnel session is a "hard pipe" session, arrival of 1004 a new end-to-end reservation or adjustment of an existing end-to-end 1005 session MAY cause the overall resources needed in the tunnel session 1006 to exceed its capacity, this case is treated as admission control 1007 failure same as that of a tunnel reservation failure. Tentry SHOULD 1008 create a RESPONSE message with appropriate INFO_SPEC and send it to 1009 the originator of the RESERVE message. 1011 If the associated tunnel session is a "soft pipe" session, arrival of 1012 a new end-to-end reservation or adjustment of existing sessions MAY 1013 cause the tunnel session to be modified. It is recommended that some 1014 hysteresis is enforced in the adjustment of the tunnel reservation 1015 parameters. This requires tunnel endpoint to keep track of both the 1016 allocated tunnel session resources and the resources actually used by 1017 end-to-end sessions bound to that tunnel session. 1019 7. Tunnel Signaling Capability Discovery 1021 The NSIS-tunnel signaling operations described in this document 1022 assume both Tentry and Texit are NSIS-tunnel capable. If prior 1023 knowledge of the other endpoint's NSIS-tunnel capability is not 1024 available, we need a discovery mechanism to find that out. For this 1025 purpose, we define a new NODE_CHAR object. 1027 The format of the NODE_CHAR object follows the general object 1028 definition in GIST [2]. It contains a fixed header giving the object 1029 Type and object Length, followed by the object Value as shown below. 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 |A|B|r|r| Type |r|r|r|r| Length | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 // Value // 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Type: NODE_CHAR 1041 Length: Fixed (1 32-bit word) 1043 Value: 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |T| Reserved | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 The Value field currently contains a single 'T' bit, indicating the 1052 basic NSIS-tunnel scheme defined in this document. It is also 1053 possible to use multiple bits to define NSIS-tunnel capability in 1054 finer granularity. We have adopted the simplest approach by using 1055 only one bit. The remaining reserved bits can be used to signal 1056 other node characteristics in the future. 1058 The bits marked 'A' and 'B' define the desired behavior for objects 1059 whose Type field is not recognized. If a node does not recognize the 1060 NODE_CHAR object, the desired behavior is "Ignore". That is, the 1061 object MUST be deleted and the rest of the message processed as 1062 usual. This can be satisfied by setting 'AB' to '01' according to 1063 GIST specification . 1065 This NODE_CHAR object is included in a QUERY or RESERVE message by a 1066 tunnel endpoint who wishes to learn about the other endpoint's tunnel 1067 handling capability. The other endpoint that receives this object 1068 will know that the sending endpoint is NSIS-tunnel capable, and place 1069 the same object in a RESPONSE message to inform the sending endpoint 1070 of its own tunnel handling capability. The procedures for using 1071 NODE_CHAR object in the four dynamically created tunnel session 1072 scenarios are further detailed below. 1074 If both end-to-end and tunnel sessions are sender-initiated 1075 (Section 4.1.1) and Tentry is NSIS-tunnel capable, the Tentry 1076 includes an RII object and a NODE_CHAR object with T bit set in the 1077 first end-to-end RESERVE message sent to Texit. When Texit receives 1078 this RESERVE message, if it supports NSIS tunneling, it learns that 1079 Tentry is NSIS-tunnel capable and includes the same object with T bit 1080 set in the RESPONSE message sent back to Tentry. Otherwise, Texit 1081 ignores the NODE_CHAR object. When Tentry receives the RESPONSE 1082 message, it learns whether Texit is NSIS-tunnel capable by examining 1083 the existence of the NODE_CHAR object and its T-bit. If both tunnel 1084 endpoints are NSIS-tunnel capable, the rest of the procedures will 1085 follow those defined in Section 4.1.1. Alternatively, Tentry MAY 1086 send out tunnel RESERVE message before the RESPONSE message 1087 confirming the NSIS-tunnel capability of Texit is received. If later 1088 it learns that the Texit is not NSIS-tunnel capable, it SHOULD send 1089 out teardown messages to cancel the tunnel session reservation that 1090 has already been made. This way the signaling process is faster when 1091 Texit is NSIS-tunnel capable, but it can lead to temporary waste of 1092 tunnel resources if Texit is not NSIS-tunnel capable. 1094 If both end-to-end and tunnel sessions are receiver-initiated 1095 (Section 4.1.2) and Tentry is NSIS-tunnel capable, the Tentry 1096 includes an RII object and a NODE_CHAR object with T bit set in the 1097 first end-to-end QUERY message sent toward Texit. An NSIS-tunnel 1098 capable Texit learns from the NODE_CHAR object whether Tentry is 1099 NSIS-tunnel capable. In reply to this end-to-end QUERY message, the 1100 NSIS-tunnel capable Texit includes a NODE_CHAR object with T bit set 1101 in its RESPONSE message to notify Tentry of its own tunnel 1102 capability. If both tunnel endpoints are NSIS-tunnel capable, the 1103 rest of the procedures will follow those defined in Section 4.1.2. 1104 Otherwise, Texit will not initiate tunnel session reservations. 1106 If the end-to-end session is sender-initiated, the tunnel session is 1107 receiver-initiated (Section 4.1.3), and Tentry is NSIS-tunnel 1108 capable, the Tentry includes an RII object and a NODE_CHAR object 1109 with T bit set in the first end-to-end RESERVE message sent toward 1110 Texit. An NSIS-tunnel capable Texit learns from the NODE_CHAR object 1111 whether Tentry is NSIS-tunnel capable. In reply to this end-to-end 1112 QUERY message, the NSIS-tunnel capable Texit includes a NODE_CHAR 1113 object with T bit set in its RESPONSE message to notify Tentry of its 1114 own tunnel capability. If both tunnel endpoints are NSIS-tunnel 1115 capable, the rest of the procedures will follow those defined in 1116 Section 4.1.3. Otherwise, Texit will not initiate tunnel session 1117 reservations. 1119 If the end-to-end session is receiver-initiated, the tunnel session 1120 is sender-initiated (Section 4.1.4), and Tentry is NSIS-tunnel 1121 capable, the operation is similar to the case where both sessions are 1122 receiver-initiated. The Tentry includes an RII object and a 1123 NODE_CHAR object with T bit set in the first end-to-end QUERY message 1124 sent toward Texit. An NSIS-tunnel capable Texit learns from the 1125 NODE_CHAR object whether Tentry is also NSIS-tunnel capable. In 1126 reply to this end-to-end QUERY message, the NSIS-tunnel capable Texit 1127 includes a NODE_CHAR object with T bit set in its RESPONSE message to 1128 notify Tentry of its own tunnel capability. If both tunnel endpoints 1129 are NSIS tunnel capable, the rest procedures follow those defined in 1130 Section 4.1.4. Otherwise, Tentry will not initiate further NSIS 1131 tunnel session reservations. 1133 8. Other Considerations 1135 8.1. Other Types of NSLP 1137 This document discusses tunnel operation using QoS NSLP. It will be 1138 desirable to have the scheme work with other NSLPs as well. Since 1139 NSIS-tunnel operation involves specific NSLP itself and different 1140 NSLPs have different message exchange semantics, the NSIS-tunnel 1141 specification would not be the same for all NSLPs. However the basic 1142 aspects behind NSIS-tunnel operation could indeed be similar for 1143 different types of NSLPs. For example, in the case of NATFW NSLP 1144 [13], the most important signaling operation is CREATE. Assuming 1145 Tentry is a NATFW NSLP, the tunnel handling for the CREATE operation 1146 is expected to be very similar to the sender-initiated QoS 1147 reservation case. There are also a number of reverse directional 1148 operations in NATFW NSLP, such as RESERVE_EXTERNAL_ADDRESS and 1149 UCREATE. It is not very clear whether IP tunnel will cause problems 1150 with these messages in general. But they are likely easier to deal 1151 with than the receiver-initiated reservation case in QoS NSLP. This 1152 topic will be discussed in future version of this document if 1153 necessary. 1155 8.2. IPSEC Flows 1157 If the tunnel supports IPSEC (especially ESP in Tunnel-Mode with or 1158 without AH), it MAY use the flow label, DSCP field, or IPSEC SPI 1159 along with the tunnel source and destination address, as discussed in 1160 Section 3.1 to form the tunnel Flow ID. All these are standard NSIS 1161 MRI fields that can be matched by the NSIS packet classifier. 1162 Virtual destination ports as in RSVP-IPSEC [17] MAY be defined for 1163 further flow demultiplexing capability at the destination side if 1164 necessary. 1166 8.3. NSIS-tunnel Operation and Mobility 1168 NSIS-tunnel operation needs to interact with IP mobility in an 1169 efficient way. In places where pre-configured tunnel sessions are 1170 available, the process is relatively straightforward. For dynamic 1171 individual signaling tunnel sessions, one way to improve NSIS 1172 mobility efficiency in the tunnel is to reuse the session ID of the 1173 tunnel session when tunnel flow ID changes during mobility. This 1174 works as follows. With a mobile IP tunnel, one tunnel endpoint is 1175 the Home Agent (HA), and the other endpoint is the Mobile Node (MN) 1176 if collocated Care-of-Address (CoA) is used, or the Foreign Agent 1177 (FA) if FA CoA is used. When MN is a receiver, Tentry is the HA and 1178 Texit is the MN or FA. In a mobility event, handoff tunnel signaling 1179 messages will start from HA, which MAY use the same session ID for 1180 the new tunnel session. When MN is a sender and collocated CoA is 1181 used, Tentry is the MN and Texit is the HA. Handoff tunnel signaling 1182 is started at the MN. It MAY also use the session ID of the previous 1183 tunnel session for the new tunnel session. When MN is a sender and 1184 FA CoA is used, the situation is complicated because Tentry has 1185 changed from the old FA to the new FA. In this case the new FA does 1186 not have the session ID of the previous tunnel session. 1188 When mobile IP is operating on a bi-directional tunneling mode, NSIS- 1189 tunnel operation with mobility MAY be further improved by localizing 1190 the handoff tunnel signaling process by bypassing the path between HA 1191 and CN. 1193 General aspects of NSIS interaction with mobility are discussed in 1195 [14]. 1197 9. Security Considerations 1199 This draft does not draw new security threats. Security 1200 considerations for NSIS NTLP and QoS NSLP are discussed in [2] and 1201 [3], respectively. General threats for NSIS can be found in [18]. 1203 10. Appendix 1205 10.1. Various Design Alternatives 1207 10.1.1. End-to-end and Tunnel Signaling Interaction Model 1209 The contents of original end-to-end singling messages are not 1210 directly examined by tunnel intermediate nodes. To carry out tunnel 1211 signaling we choose to maintain a separate tunnel session for the 1212 end-to-end session by generating tunnel specific signaling messages. 1213 An alternative approach is to stack tunnel specific objects on top of 1214 the original end-to-end messages and make these messages visible to 1215 tunnel intermediate nodes. Thus, these new messages serve both the 1216 end-to-end session and tunnel session. This approach turns out to be 1217 difficult because the actual tunnel signaling messages differ from 1218 the end-to-end signaling message both in GIST layer and NSLP layer 1219 information, such as MRI, PACKET CLASSIFIER and QSPEC. Although 1220 QSPEC can be stacked in an NSLP message, there doesn't seem to be a 1221 handy way to stack MRI and the PACKET CLASSIFIER in the NSLP layer. 1222 In addition, the stacking method only applies to individual signaling 1223 tunnels. 1225 The separate end-to-end tunnel session signaling model adopted in 1226 this document handles both individual and aggregate signaling tunnels 1227 in a consistent way. Its major drawback is the race condition we 1228 mentioned in Section 4.2. However, we defined simple rules to solve 1229 this problem while maintaining interoperability. 1231 This document defines the sequential and parallel modes of end-to-end 1232 and tunnel signaling interaction. There are a number of different 1233 aspects that can result in variations in carrying out the actual 1234 interaction. One aspect is the tunnel session initiation location. 1235 For example, it is possible to initiate the tunnel session from 1236 Texit, instead of Tentry as in the proposed scheme. A second aspect 1237 is the tunnel session initiation time point. For example, in cases 1238 when both end-to-end session and tunnel session are receiver- 1239 initiated, it is possible to start the tunnel session when Tentry 1240 receives the first end-to-end RESERVE message, instead of when Tentry 1241 receives the first end-to-end QUERY message, as in the proposed 1242 scheme. The advantage of our adopted approach is that it will allow 1243 the first end-to-end QUERY message to also gather tunnel 1244 characteristics along with the rest of the end-to-end path. A third 1245 aspect is how the tunnel signaling messages are used. For example, 1246 in the case where end-to-end session is receiver initiated and tunnel 1247 session is sender initiated (Section 4.1.4), the first tunnel QUERY' 1248 message sent after receiving the end-to-end QUERY message by Tentry 1249 can be replaced by a tunnel RESERVE' message, if the application 1250 wants to trade temporary oversized or wasted (if the end-to-end 1251 reservation turns out to be unsatisfied) tunnel resource reservations 1252 for faster signaling setup delay. All these aspects are local 1253 optimization issues. We require any implementation to support the 1254 basic scheme defined in the main text of document to allow 1255 interoperability. 1257 10.1.2. Packet Classification over the Tunnel 1259 Packet classification over the tunnel MAY be done in either of the 1260 two ways: first, retaining the end-to-end packet classification 1261 rules; Second, using tunnel specific classification rules. In the 1262 first approach, tunnel packet classification is not tied with tunnel 1263 MRI. This is a useful property especially in handling tunnel 1264 mobility. Mobility changes the tunnel MRI, if at the same time the 1265 packet classification rule does not change, the common path after a 1266 handoff does not need to be updated about the packet classification, 1267 which results in a better handoff performance. The main problem with 1268 this approach is that most existing routers do not support inspection 1269 of inner IP headers in an IP tunnel, where the tunnel independent 1270 packet classification fields usually reside. Therefore this document 1271 adopts the second approach which does not pose special classification 1272 requirements on intermediate tunnel nodes. 1274 10.1.3. Tunnel Binding Methods 1276 In this document, the end-to-end session and its mapping tunnel 1277 session use different session IDs and they are associated with each 1278 other using the BOUND_SESSION_ID object. This choice is obvious for 1279 aggregate tunnels sessions because in that case the original end-to- 1280 end session and the corresponding aggregate tunnel session require 1281 independent control. 1283 Sessions in individual signaling tunnels are created and deleted 1284 along with the related end-to-end session. So association between 1285 the end-to-end session and the corresponding individual tunnel 1286 session has another choice: the two sessions MAY share the same 1287 session ID. Instead of sending a BOUND_SESSION_ID object, it MAY be 1288 possible to define a BOUND_FLOW_ID object, to bind the flow ID of the 1289 end-to-end session to the flow ID of the tunnel session at the tunnel 1290 endpoints. However, since flow ID is usually derived from MRI, if a 1291 NAT is present in the tunnel, this BOUND_FLOW_ID object will have to 1292 be modified in the middle, which makes the process fairly 1293 complicated. Furthermore, it is not desirable to have different 1294 session association mechanisms for aggregate signaling tunnels and 1295 individual signaling tunnels. Therefore, we decide to use the same 1296 tunnel BOUND_SESSION_ID mechanism for both individual and aggregation 1297 tunnel sessions. Note that in this case the mobility handling inside 1298 the tunnel can still be optimized in certain situations as discussed 1299 in Section 8.3. 1301 In this document we used the existing BOUND_SESSION_ID object with a 1302 tunnel Binding_code to indicate the reason of binding. Two other 1303 options were considered. 1305 1. Define a designated "tunnel object" to be included when the 1306 tunnel binding needs to be conveyed. 1307 2. Define a "tunnel bit" in corresponding NSLP message headers. 1309 These options are not chosen because they either requires the 1310 creation of an entirely new object, or the change of basic message 1311 headers. They are also not generic solutions that can cover other 1312 binding causes. 1314 There are basically three ways to carry the binding object between 1315 Tentry and Texit, using (a) end-to-end signaling messages, (b) tunnel 1316 signaling messages, (c) both end-to-end and tunnel signaling 1317 messages. In option (a) only tunnel endpoints see the tunnel binding 1318 information. In option (b), every tunnel intermediate node sees the 1319 binding information. Since there will be no state for the end-to-end 1320 session in tunnel intermediate nodes, they will all generate a 1321 message containing an "INFO_SPEC" object indicating no bound session 1322 found according to [3], which is not desirable. Option (c) has an 1323 advantage that if both end-to-end and tunnel signaling messages have 1324 tunnel binding information, the racing condition will be resolved 1325 faster. However it suffers the same problem as in (b). Therefore 1326 the choice in this document for carrying the tunnel binding object is 1327 option (a). 1329 11. Acknowledgements 1331 12. References 1333 12.1. Normative References 1335 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1336 Levels", BCP 14, RFC 2119, March 1997. 1338 [2] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1339 Signaling Transport", draft-ietf-nsis-ntlp-09 (work in 1340 progress), February 2006. 1342 [3] Manner, J., "NSLP for Quality-of-Service Signaling", 1343 draft-ietf-nsis-qos-nslp-10 (work in progress), March 2006. 1345 12.2. Informative References 1347 [4] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1348 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1350 [5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1351 Routing Encapsulation over IPv4 networks", RFC 1702, 1352 October 1994. 1354 [6] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 1355 Flow Label Specification", RFC 3697, March 2004. 1357 [7] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1358 October 1996. 1360 [8] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1361 October 1996. 1363 [9] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 1364 IPv6 Hosts and Routers", RFC 4213, October 2005. 1366 [10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1367 December 2005. 1369 [11] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 1370 Specification", RFC 2473, December 1998. 1372 [12] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-09 1373 (work in progress), March 2006. 1375 [13] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 1376 (NSLP)", draft-ietf-nsis-nslp-natfw-11 (work in progress), 1377 April 2006. 1379 [14] Lee, S., "Applicability Statement of NSIS Protocols in Mobile 1380 Environments", 1381 draft-ietf-nsis-applicability-mobility-signaling-04 (work in 1382 progress), March 2006. 1384 [15] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 1385 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 1387 [16] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP 1388 Operation Over IP Tunnels", RFC 2746, January 2000. 1390 [17] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data 1391 Flows", RFC 2207, September 1997. 1393 [18] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 1394 Steps in Signaling (NSIS)", RFC 4081, June 2005. 1396 [19] Kent, S. and K. Seo, "Security Architecture for the Internet 1397 Protocol", RFC 4301, December 2005. 1399 Authors' Addresses 1401 Charles Shen 1402 Columbia University 1403 Department of Computer Science 1404 1214 Amsterdam Avenue, MC 0401 1405 New York, NY 10027 1406 USA 1408 Phone: +1 212 854 3109 1409 Email: charles@cs.columbia.edu 1411 Henning Schulzrinne 1412 Columbia University 1413 Department of Computer Science 1414 1214 Amsterdam Avenue, MC 0401 1415 New York, NY 10027 1416 USA 1418 Phone: +1 212 939 7004 1419 Email: schulzrinne@cs.columbia.edu 1421 Sung-Hyuck Lee 1422 SAMSUNG Advanced Institute of Technology 1423 San 14-1, Nongseo-ri, Giheung-eup 1424 Yongin-si, Gyeonggi-do 449-712 1425 KOREA 1427 Phone: +82 31 280 9552 1428 Email: starsu.lee@samsung.com 1430 Jong Ho Bang 1431 SAMSUNG Advanced Institute of Technology 1432 San 14-1, Nongseo-ri, Giheung-eup 1433 Yongin-si, Gyeonggi-do 449-712 1434 KOREA 1436 Phone: +82 31 280 9585 1437 Email: jh0278.bang@samsung.com 1439 Intellectual Property Statement 1441 The IETF takes no position regarding the validity or scope of any 1442 Intellectual Property Rights or other rights that might be claimed to 1443 pertain to the implementation or use of the technology described in 1444 this document or the extent to which any license under such rights 1445 might or might not be available; nor does it represent that it has 1446 made any independent effort to identify any such rights. Information 1447 on the procedures with respect to rights in RFC documents can be 1448 found in BCP 78 and BCP 79. 1450 Copies of IPR disclosures made to the IETF Secretariat and any 1451 assurances of licenses to be made available, or the result of an 1452 attempt made to obtain a general license or permission for the use of 1453 such proprietary rights by implementers or users of this 1454 specification can be obtained from the IETF on-line IPR repository at 1455 http://www.ietf.org/ipr. 1457 The IETF invites any interested party to bring to its attention any 1458 copyrights, patents or patent applications, or other proprietary 1459 rights that may cover technology that may be required to implement 1460 this standard. Please address the information to the IETF at 1461 ietf-ipr@ietf.org. 1463 Disclaimer of Validity 1465 This document and the information contained herein are provided on an 1466 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1467 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1468 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1469 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1470 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1473 Copyright Statement 1475 Copyright (C) The Internet Society (2006). This document is subject 1476 to the rights, licenses and restrictions contained in BCP 78, and 1477 except as set forth therein, the authors retain all their rights. 1479 Acknowledgment 1481 Funding for the RFC Editor function is currently provided by the 1482 Internet Society.