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