idnits 2.17.00 (12 Aug 2021) /tmp/idnits22208/draft-sanda-nsis-path-type-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 518. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 24, 2005) is 6053 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4080 (ref. '2') == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '3') == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '4') ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-shen-nsis-tunnel-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: draft-ietf-nsis-applicability-mobility-signaling has been published as RFC 5980 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-applicability-mobility-signaling (ref. '7') Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signaling (nsis) T. Sanda 3 Internet-Draft T. Ue 4 Expires: April 27, 2006 H. Cheng 5 Panasonic 6 October 24, 2005 8 Path type support for NSIS signaling 9 draft-sanda-nsis-path-type-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 27, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 NSIS state management needs to track data path changes and update the 43 states along the affected data paths. However, in certain scenarios, 44 there are multiple concurrent paths involved in the communication. 45 In this case, the normal NSIS scheme does not provide sufficient 46 support for the state manipulation. Therefore, extra functionality 47 for data path identification and distinction is necessary. In 48 current Internet, with the increasing use of multi-homing devices and 49 the employment of Mobile IP, the above issue is getting more 50 prominent. This draft discusses in detail the problems and issues 51 involved in the NSIS state management relevant to the data path 52 differentiation. Specific scenarios for multi-homing and Mobile IP 53 route optimization are studied. Potential solution and its impacts 54 on current NSIS protocol design are discussed as well. 56 Table of Contents 58 1. Conventions used in this document . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Problems in multi-interface terminal scenario . . . . . . 7 63 4.2. Problems in Mobile IP RO scenario . . . . . . . . . . . . 8 64 5. Requirement of signaling handling for multiple paths . . . . . 11 65 6. Path Type ID . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. Path Type ID for Multi-link terminal scenario . . . . . . 13 67 6.2. Path Type ID utilization for Mobile IP scenario . . . . . 13 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 71 10. Normative Reference . . . . . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Intellectual Property and Copyright Statements . . . . . . . . . . 19 75 1. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC2119 [1]. 81 2. Introduction 83 In the defined NSIS framework [2], a two-layer architecture is used, 84 wherein the NTLP layer handles the general message routing and 85 transport and NSLP layer carries out the actual signaling 86 application. The GIMPS draft [3] defines the NTLP layer, and the QoS 87 NSLP draft [4] specifies an instance of the NSLP signaling 88 application for the QoS provisioning and control. These drafts 89 specify that each signaling path state is managed with two 90 identifiers, i.e. the flow identifier (Flow ID) and the session 91 identifier (Session ID). 93 In certain scenarios, communication nodes utilize plural data paths 94 for one session. For example, a terminal that has multiple 95 communication interfaces may communicate with the Correspondent Node 96 (CN) using multiple data paths via multiple links for one session. 97 For these multi-homed cases, the network may observe several path 98 reservations even without any terminal movement. Therefore, special 99 techniques have to be employed to distinguish this from an actual 100 mobility event, so that no mobility handling procedure would be 101 triggered. Another example is the Route Optimization (RO) in the 102 Mobile IP environment. When a successful RO is performed, data will 103 flow directly between the CN and the Mobile Node (MN) without going 104 through the Home Agent (HA). Since the RO procedure makes use of the 105 triangular (TR) path (path via the HA), it will always happen after 106 the TR path is set up. Even after RO procedure is completed, TR path 107 will be used when RO path is down. This means that the MN may use 108 multiple paths to communicate with the CN. In the RO procedure, 109 there is always a data path change involved, even though there is no 110 actual address change. 112 The first scenario where Flow ID doesn't work is when the address 113 information cannot be represented by a single Flow ID, e.g., the 114 multihoming case, or multi-thread case. In these cases, Flow ID in 115 its current form is incapable of carrying the full information for 116 the packet classification. Another scenario is when the NSIS 117 signaling needs to be carried out before the actual data traffic flow 118 starts. It is possible that at this point of time, some address 119 information is not yet available, and thus the Flow ID cannot be 120 generated according to the current specified method. This would 121 happen most likely in the case of make-before-break reservation on 122 predictive paths. In yet another scenario, the address information 123 involved in the Flow ID generation may change during the course of 124 the session, e.g. the port number or the DSCP/TOS fields. This does 125 not necessary mean a route change, and should not always trigger the 126 state change along the data path. Therefore, the Flow ID and the 127 traffic classification information are not always synchronized. 129 It is obvious from the above that the Flow ID and Session ID defined 130 [3] [4] are not sufficient to support these more complicated 131 reservation management, when multiple data paths are involved. In 132 this draft, details of the problems and requirements for signaling 133 handling multiple paths are discussed. A possible solution using a 134 Path Type ID is also introduced. 136 3. Terminology 138 The Terminology defined in [2], [3] and [4] applies to this draft. 139 In addition, the following terms are used: 141 TR path: Triangular Path. A route between MN and CN with tunneled 143 RO path: Route Optimized path. A direct route between MN and CN 145 4. Problem Statement 147 This section introduces two scenarios that multiple data paths are 148 used for one session, one is multi-interface terminal case and the 149 other is Mobile IP RO case, and shows examples NSIS state management 150 cannot work properly. 152 4.1. Problems in multi-interface terminal scenario 154 It is common nowadays for a terminal to be equipped with multiple 155 communication technologies. For example, it is nature to have a 156 combination of Ethernet, Wireless LAN, InfraRed, and Bluetooth 157 interfaces installed on a laptop. Those best selling PDAs usually 158 have cellular and Wireless LAN interfaces. In this draft, a multi- 159 interface terminal is defined as one that can utilize more than two 160 interfaces for one communication session. With the advance of the 161 interworking study, e.g. IEEE802.11u and IEEE802.21, this may become 162 a normal practice. In this case, multiple data paths are used for 163 the communication simultaneously. Furthermore, if the interfaces are 164 wireless, such as 802.11 WLAN, UMTS and so on, each interface can 165 switch its attachment point independently. This means data paths are 166 changed separately. 168 The scenario discussed here is shown in Figure 1. MN is 169 communicating with CN using two interfaces, "p" and "s", for one 170 session. Interface "p" has a data path (Path1) via AP1, AR1 and QNE1 171 while interface "s" has a data path (Path2) via AP2, AR2 and QNE1. 172 According to the NSIS draft [3] [4], QoS state would be installed on 173 each data path and the same Session ID and different Flow IDs would 174 be allocated for them. 176 +--------+ +--------+ 177 | CN | | CN | 178 +--------+ +--------+ 179 * * * * * 180 * * * * * 181 +--------+ +--------+ 182 | QNE1 | | QNE1 | 183 +--------+ +--------+ 184 * * * * * 185 * * * * * 186 * * * * * 187 Path1* *Path2 Path1* *Path2 *Path3 188 * * * * * 189 * * * * * 190 * * * * * 191 +---+ +---+ +---+ +---+ +---+ 192 |AR1| |AR2| |AR1| |AR2| |AR3| 193 +---+ +---+ +---+ +---+ +---+ 194 * * * * * 195 +---+ +---+ +---+ +---+ +---+ 196 |AP1| |AP2| |AP1| |AP2| |AP3| 197 +---+ +---+ +---+ +---+ +---+ 198 * * * X * 199 * * * X * 200 * * * X * 201 * * * X* 202 p=> | | <=s p=> | | <=s 203 +------+ +------+ 204 | MN | | MN | 205 +------+ +------+ 207 (a) (b) 209 Figure 1. Multi-interface terminal scenario 211 When the interface "s" performs a handover from AP2 to AP3 as shown 212 in Figure 1(b), QoS state for Path2 is replaced by Path3, while Path1 213 should be maintained. In this case, QNE1 needs to know which path/ 214 state must be replaced by Path3. However, since Flow ID for Path1, 215 Path2 and Path3 are different and Session IDs for all paths are the 216 same, it is impossible for QNE1 to know how to operate each path. 218 4.2. Problems in Mobile IP RO scenario 220 As described in MIPv6 [5], the RO procedures will be performed if 221 both the MN and the CN supports it. With optimization, data traffic 222 will flow directly between MN and CN without going through the HA. 223 This improves the efficiency of network resources utilization, and 224 reduces the communication dependency on the MN's Home network. 226 A nature of data path change in RO procedure is different from that 227 resulted from a MN changing its point of attachment. Even after data 228 path is changed from TR path to RO path, they are still related since 229 they have different characteristics. A TR path will be reused when 230 an RO path is aborted as well as when MN moves to a new location. 232 When NSIS QoS state is installed in RO path, reservation state for 233 the old path, i.e. TR path, may be required to be kept because it 234 will be reused. Simultaneously, reserved resource for TR path may 235 have to be reduced not to waste limited resources. Signaling 236 management for each path would also need to be done separately, 237 depending on control policies. 239 Reservation state handling for TR path and RO path requires more 240 flexibility than state handling for path changes caused by MN's move 241 or re-routing. To realize flexible operation, it is desirable that 242 every NSIS Node could differentiate RO path and TR path reservation 243 state with NSIS protocols. 245 Figure 2 shows one example scenario of a TR path and an RO path. 246 When NSIS QoS state is made on a RO path (path "y"), a crossover node 247 (CRN), e.g. a QNE3 needs to operate a TR path (path "x") properly. 248 However, as it cannot differentiate a TR path and an RO path, 249 operation for a TR path cannot be done. 251 Furthermore, when MN moves to a new location (Figure 3), TR path 252 (path "z") followed by RO path (path "w") will be utilized. This 253 case, a CRN, such as QNE3 does not know which path have to be 254 released because it cannot distinguish a path change caused by 255 handover from the one caused by RO procedures. 257 +----+x x x x +----+x x x x x+----+x x x+----+ 258 | HA | |QNE2| |QNE3| | CN | 259 | | | | | |y y y| | 260 +----+ +----+ y +----+ +----+ 261 x y 262 x y 263 +----+ y 264 |QNE1| y 265 | | y 266 +----+ 267 x y 268 x y 269 +----+ 270 |AR1 | 271 +----+ 272 x y 273 +----+ 274 | MN | xxxxx TR at Location1 275 +----+ yyyyy RO at Location1 277 Figure 2. An example of TR path and RO path 279 +----+x x x x +----+x x x x x+----+x x x+----+ 280 | HA |z z z z |QNE2|z z z z z|QNE3|z z z| CN | 281 | | | | | |y y y| | 282 +----+ z +----+ y +----+w w w+----+ 283 x z y w 284 x z y w 285 +----+ y z +----+ 286 |QNE1| y z |QNE4| 287 | | y z | | 288 +----+ +----+ 289 x y z w 290 x y z w 291 +----+ +----+ 292 |AR1 | |AR2 | 293 +----+ +----+ 294 x y z w xxxxx TR at Location1 295 +----+ +----+ yyyyy RO at Location1 296 | MN | ------> | MN | zzzzz TR at Location2 297 +----+ +----+ wwwww RO at Location2 299 Figure 3. An example of TR path and RO path with MN's movement 301 5. Requirement of signaling handling for multiple paths 303 In order to handle signaling in scenarios described in previous 304 sections, the NSIS signaling scheme must be modified to meet the 305 following requirements: 307 1) The signaling identifiers must be able to distinguish each flows/ 308 paths involved in the same session. For example, in Figure 1, Path 309 1, Path 2, and Path 3 must be clearly separated. 311 2) The signaling identifiers must be able to reflect the dependency 312 and relationship between the flows/paths involved in the same 313 session. For example, in Figure 1, Path 1 and Path 2 are serving the 314 same session simultaneously, and thus should co-exist. Whereas, Path 315 2 and Path 3 are two different paths for the same interface at 316 different time, and thus, Path 3 should replace Path 2. 318 The first requirement is achieved in the current NSIS framework by 319 using different Flow IDs for the different paths. Therefore, for the 320 three paths, three separate Flow IDs would be generated, and those 321 help to distinguish the different paths. 323 However, the current NSIS have problem to meet the second requirement 324 completely. Since the paths are all serving the same session, it is 325 nature to use the same Session ID for all the signaling. This could 326 indicate to the NSIS aware nodes, e.g QNEs, that the paths are 327 belonging to the same session. By unsetting the REPLACE flag of the 328 QoS NSLP [4], the signaling is able to indicate to the QNEs that the 329 paths should co-exist. But, this cannot indicate to the QNEs that 330 the Path 3 should replace Path 2. If the signaling message for Path 331 3 has the REPLACE flag set, it would replace states of both Path 2 332 and Path 1 over the common section. This is an undesired situation. 334 In the NSIS Operation Over IP Tunnel draft [6], an 335 ASSOCIATE_FLOW_SESSION object is proposed to further indicate the 336 relationship between flows within a session, i.e. with the same 337 Session ID. This will help to meet the requirement 2. However, this 338 new object, which is big (of the size of Flow ID), needs to be 339 embedded into the signaling for all the flows that has relationship 340 with each other. It would be a overhead for the signaling, once the 341 relationships between flows are complicated, it would be quite costly 342 to the signaling. 344 Another possible choice is to use different Session IDs in the 345 signaling. For example, in Figure 1, since the Path 2 and Path 3 346 cannot co-exist, they will use the same Session ID. And Path 1 and 347 Path 2 should co-exist, and thus would use different Session IDs. In 348 order to indicate their relationship, the BOUND_SESSION_ID object of 349 QoS NSLP [4] could be used to indicate that the two sessions should 350 be bound so that resources could be shared. This way, the 351 requirement 2 would be met. However, it also creates high overhead 352 for the signaling, since every message needs to carry the 353 BOUND_SESSION_ID object, and every QNE needs to support the session 354 binding. 356 In this draft a simply yet effective method is proposed. Instead of 357 introducing the full-fledged binding/associate object, a simple 358 object Path Type ID is used in conjunction with the use of same 359 Session ID and different Flow IDs for the different flow/paths. This 360 way, the requirement 2 can be met with easy. Following section 361 describe the use of such solution with different scenarios. 363 6. Path Type ID 365 In order to introduce the dependency and relationship between the 366 flows/paths involved in the same session, a new identifier called 367 "Path Type ID" can be utilized. Path Type ID could be a few bit 368 values or code which is carried by signaling messages and stored in 369 QNEs with other identifiers. Since it is small, certain reserved 370 fields of NSIS message header could be used to carry it. Therefore, 371 minimum overhead would be added to the signaling.By comparing Path 372 Type ID as well as Session ID and Flow ID, QNEs can operate multiple 373 co-related paths properly. 375 6.1. Path Type ID for Multi-link terminal scenario 377 In the scenario discussed in section 2.1, it is required that QNE1 378 determines which path/state should be replaced or maintained with 379 minimal signaling exchanges. For this purpose, Path Type ID is 380 utilized. In the scenario in Figure 1(b), Path Type ID for Path2 and 381 Path3 is an identical values or code, which is different from that 382 for Path1. QNE1 in Figure 1 (b) can replace a path2 to a path3 383 because it explicitly knows these two paths have the same Path Type 384 ID value. 386 MN can decide Path Type ID by information of interfaces, i.e. Path 387 Type ID in this case shows the interface where the signaling message 388 comes from or goes to. 390 6.2. Path Type ID utilization for Mobile IP scenario 392 As discussed in Sec. 2.2, current NSIS protocol design cannot 393 indicate the complicated relationship between TR path and RO path in 394 the signaling. Since the RO is common for a MIPv6 enable network, 395 NSIS protocols cannot support mobility properly without a solution to 396 this problem. 398 Path Type ID used in this scenario identifies the TR and RO paths. 399 In the scenario in Figure 3, Path Type ID for paths "x" and "z" is an 400 identical code or number (e.g., "TR") while Path Type ID for paths 401 "y" and "w" is also identical but different from that for paths "x" 402 and "z" (e.g., "RO"). 404 MN can decide Path Type ID by the information from MIP layer, e.g. 405 receiving Binding ACK message, and then set the Path Type ID in 406 RESERVE message. 408 Flexible operation for TR and RO paths is also possible. Even when 409 MN A moves to location 2, QNEs could still distinguish the old path 410 and new path by comparing Path Type ID and Flow ID. However, the 411 method to explicitly associate TR path and RO path at the same 412 location may be required. For supporting this functionality, an 413 object to decide MN's location, such as mobility_event_counter 414 mentioned in Applicability Statement draft [7] could be useful. 416 7. Security Considerations 418 Security should be considered in the NTLP/NSLP specifications as an 419 integrated part. Specific issues in Route Optimization case will be 420 essentially covered by the Route Optimization security in Mobile IPv6 421 [5]. Future version of this draft would discuss the relevant 422 security requirements for the solutions in detail. 424 8. Conclusion 426 This draft discussed potential problems related to NSIS QoS state 427 management for multiple paths caused by multi-interface terminal and 428 Mobile IP RO procedures. As one possible solution, Path Type ID was 429 introduced so that QNEs could perform flexible state management for 430 each path. 432 This draft also includes some other discussions relevant to the 433 problems on usage of Flow ID as a packet classifier. Use cases are 434 analyzed with regarding to the requirements. 436 9. Acknowledgements 438 This section contains the acknowledgements. 440 10. Normative Reference 442 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 443 Levels", BCP 14, RFC 2119, March 1997. 445 [2] Hancock, R., "Next Steps in Signaling (NSIS): Framework", 446 RFC 4080, Informational , June 2005. 448 [3] Schulzrinne, H. and R. Hancock, "GIST: General Internet 449 Signaling Transport", Internet Draft draft-ietf-nsis-ntlp-08, 450 Work in progress , September 2005. 452 [4] Manner, J., "NSLP for Quality-of-Service Signaling", Internet 453 Draft draft-ietf-nsis-qos-nslp-07, Work in progress , July 2005. 455 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility support in 456 IPv6", RFC 3775, June 2004. 458 [6] Shen, C., "NSIS Operation Over IP Tunnels", Internet 459 Darf draft-shen-nsis-tunnel-00, Work in Progress , July 2005. 461 [7] Lee, S., "Applicability Statement of NSIS Protocol in Mobile 462 Environments", Internet 463 Draft draft-ietf-nsis-applicability-mobility-signaling-02, Work 464 in progress , July 2005. 466 Authors' Addresses 468 Takako Sanda 469 Matsushita Electric Industrial Co., Ltd. (Panasonic) 470 5-3, Hikarino-oka, Yokosuka City 471 Kanagawa 239-0847 472 Japan 474 Phone: +81 46 840 5764 475 Email: sanda.takako@jp.panasonic.com 477 Toyoki Ue 478 Matsushita Electric Industrial Co., Ltd. (Panasonic) 479 5-3, Hikarino-oka, Yokosuka City 480 Kanagawa 239-0847 481 Japan 483 Phone: +81 46 840 5816 484 Email: ue.toyoki@jp.panasonic.com 486 Hong Cheng 487 Panasonic Singapore Laboratories 488 Block 1022, Tai Seng Industrial Estate 489 #06-3530, Tai Seng Avenue 490 Singapore 534415 491 Singapore 493 Phone: +65 6550 5477 494 Email: hong.cheng@sg.panasonic.com 496 Intellectual Property Statement 498 The IETF takes no position regarding the validity or scope of any 499 Intellectual Property Rights or other rights that might be claimed to 500 pertain to the implementation or use of the technology described in 501 this document or the extent to which any license under such rights 502 might or might not be available; nor does it represent that it has 503 made any independent effort to identify any such rights. Information 504 on the procedures with respect to rights in RFC documents can be 505 found in BCP 78 and BCP 79. 507 Copies of IPR disclosures made to the IETF Secretariat and any 508 assurances of licenses to be made available, or the result of an 509 attempt made to obtain a general license or permission for the use of 510 such proprietary rights by implementers or users of this 511 specification can be obtained from the IETF on-line IPR repository at 512 http://www.ietf.org/ipr. 514 The IETF invites any interested party to bring to its attention any 515 copyrights, patents or patent applications, or other proprietary 516 rights that may cover technology that may be required to implement 517 this standard. Please address the information to the IETF at 518 ietf-ipr@ietf.org. 520 Disclaimer of Validity 522 This document and the information contained herein are provided on an 523 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 524 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 525 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 526 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 527 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 528 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Copyright Statement 532 Copyright (C) The Internet Society (2005). This document is subject 533 to the rights, licenses and restrictions contained in BCP 78, and 534 except as set forth therein, the authors retain all their rights. 536 Acknowledgment 538 Funding for the RFC Editor function is currently provided by the 539 Internet Society.