idnits 2.17.1 draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2009) is 5432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE802.3' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC4204' is defined on line 473, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Imajuku, Ed. 3 Internet-Draft NTT Com 4 Intended status: Informational T. Otani, Ed. 5 Expires: December 14, 2009 KDDI 6 N. Bitar, Ed. 7 Verizon 8 June 12, 2009 10 Service Provider Requirements for Ethernet control with GMPLS 11 draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 14, 2009. 36 Abstract 38 Generalized Multi-Protocol Label Switching (GMPLS) is applicable to 39 Ethernet switches supporting Provider Backbone Bridge Traffic 40 Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label 41 switch network not only automates creation of Ethernet Label Switched 42 Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery 43 Mechanisms such as protection and restoration of an Eth-LSP. This 44 document describes the requirements for the set of solutions of GMPLS 45 controlled Ethernet label switch networks. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions used in this document . . . . . . . . . . . . . . 4 51 3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1. Single Layer . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2. Multi Layer . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4.1. Control plane architecture and functionality . . . . . . . 7 56 4.1.1. In-band control channel . . . . . . . . . . . . . . . 7 57 4.1.2. Neighbor discovery mechanism . . . . . . . . . . . . . 7 58 4.1.3. Addressing . . . . . . . . . . . . . . . . . . . . . . 7 59 4.2. Ethernet LSP control . . . . . . . . . . . . . . . . . . . 7 60 4.2.1. Prevention of Loops . . . . . . . . . . . . . . . . . 7 61 4.2.2. Service control . . . . . . . . . . . . . . . . . . . 7 62 4.2.3. P2MP and MP2MP requirements . . . . . . . . . . . . . 8 63 4.2.4. Asymmetric bandwidth . . . . . . . . . . . . . . . . . 8 64 4.2.5. QoS control . . . . . . . . . . . . . . . . . . . . . 8 65 4.3. OA&M related functionality . . . . . . . . . . . . . . . . 9 66 4.4. Protection and Restoration related functionality . . . . . 9 67 4.5. Link Aggregation Group (LAG) related functionality . . . . 9 68 4.5.1. Failure or deletion of LAG member link . . . . . . . . 9 69 4.5.2. Recovery or addition of LAG member link . . . . . . . 9 70 4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 9 71 4.7. Multi-layer network . . . . . . . . . . . . . . . . . . . 10 72 4.7.1. Dynamic formation of LAG . . . . . . . . . . . . . . . 10 73 4.7.2. Other requirements . . . . . . . . . . . . . . . . . . 10 74 4.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . . . 19 84 1. Introduction 86 Scalability and manageability of Ethernet switch networks has 87 continuously improved, and the deployment of Ethernet switches 88 supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the 89 solutions for service providers to provide enterprise WAN/LAN 90 services. IEEE standardization activities of Provider Backbone 91 Bridge(PBB) [IEEE802.1ah] and PBB for Traffic Engineering (PBB-TE) 92 [IEEE802.1Qay] provide an opportunity not only for enhancing the 93 scalability, manageability, and controllability of the Ethernet 94 service networks, but also for more efficiently deploying access/ 95 metro access networks. 97 Generalized Multi-Protocol Label Switching (GMPLS) provides the 98 framework for handling and controlling various types of connection- 99 oriented switching technologies, namely packet switching with various 100 label formats TDM switching, and wavelength switching [RFC3945]. 101 Therefore, the combined use of GMPLS and PBB-TE is a fairly suitable 102 "use case" that contributes to enhancing the flexibility of Ethernet 103 Label Switched Path (Eth-LSP) over Ethernet switch networks without 104 defining additional connection layers. 106 This document describes requirements for GMPLS protocols to control 107 Ethernet label switch networks and comprises mainly two parts. The 108 first one is the requirements for GMPLS extension for controlling 109 Ethernet layer. The second one includes the requirements for GMPLS 110 extensions to support multi-layer operation. Although a large 111 portion of requirements in the second scope coincides with the 112 description in [RFC5145] and [RFC5146], some of important 113 requirements are also described in this document. 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Reference model 123 3.1. Single Layer 125 This document describes requirements based on the reference model 126 depicted in Fig.1. The first reference model is an intra-domain and 127 single layer GMPLS controlled Ethernet label switching network in 128 which Eth-LSPs traverse over between Backbone Core Bridges (BCBs) or 129 Backbone Edge Bridges (BEBs). 131 -------- ----- -------- 132 P-based IF --| LSR1 |____|LSR2 |_____| LSR3 |-- P-based IF 133 S-tagged IF --|(IB-BEB)| |(BCB)| |(IB-BEB)|-- S-tagged IF 134 I-tagged IF --| | | | | |-- I-tagged IF 135 -------- ----- -------- 137 | GMPLS Eth-LSP | 138 | (BVID/BMAC) | 139 |<-------------->| 141 Figure 1 Single layer GMPLS controlled PBB-TE network 143 The BEBs provide mainly three types of service interfaces, namely 144 Port based service interface (P-based IF), S-tagged service interface 145 (S-tagged IF), and I-tagged service Interface (I-tagged IF) 146 [IEEE802.1ah]. The "P-based IF" and "S-tagged IF" are connected to 147 the I-component of a BEB (I-BEB), while the I-tagged IF is connected 148 to the B-component of a BEB (B-BEB). "S-tagged IF" can perform 149 various types of mapping between Service VLAN ID (S-VID) and Backbone 150 instance Service Identifier (I-SID). Here, S-VID is assigned within 151 customer network domain or Provider Bridge (PB) domain. On the other 152 hand, I-SID is defined between I-components of BEBs. 154 3.2. Multi Layer 156 The second reference model is Ethernet and L1 (such as TDM, OTN, etc) 157 multi-layer network. Each Ethernet switch node behaves as a border 158 node between the Ethernet layer and optical Layers. Each BCB or BEB 159 terminates Optical Label Switched Path (O-LSPs) with Ethernet 160 encoding type and some O-LSPs dynamically form LAG. Thus, some Eth- 161 LSPs traverse over multiple O-LSPs, while other Eth-LSPs traverse 162 over single O-LSPs. 164 Also, it is technically possible to form multiple layer Ethernet 165 switch networks. Namely, the reference model is defined as the case 166 that Ethernet switch network substitutes L1 network in Fig.2, and 167 realizes MAC in MAC Ethernet transport. The routing information of 168 optical layer may be isolated (overlay model), shuffled (peer model), 169 or virtualized with FA-LSPs (augmented model) for Ethernet switch 170 layer. 172 -------- ------ -------- 173 P-based IF --| LSR1 | | LSR2 | | LSR3 |-- P-based IF 174 S-tagged IF --|(IB-BEB)| | (BCB)| |(IB-BEB)|-- S-tagged IF 175 I-tagged IF --| | | | | |-- I-tagged IF 176 -------- ------ -------- 177 | | ||LAG LAG|| 178 ..................|...........|..||..........||................... 179 | | || || 180 ---+---- ------ ------ 181 | LSR A |_____|LSR B |_____|LSR C | 182 | (LSC) | |(LSC) | WDM |(LSC) | 183 -------- ------ ------ 184 | GMPLS Eth-LSP (BVID/BMAC)| 185 |<------------------------>| 186 | O-LSP | | O-LSP | 187 |<--------->| |<-------->| 189 Figure 2 Multi-layer GMPLS controlled Ethernet label switched network 191 4. Requirements 193 Section 4.1 to 4.6 describe requirements for single layer Ethernet 194 label swicth network based on the reference model from Fig.1. In 195 addition, section 4.7 describes requirements for multiple layer 196 network with Ethernet layer and circuit switch layer (such as 197 wavelength switched layer and so on). Finally, section 4.8 describes 198 generic requirements applicable to single and multiple layer 199 networks. 201 4.1. Control plane architecture and functionality 203 4.1.1. In-band control channel 205 The solution should be able to establish in-band control channel, 206 while preserving the solution of out-band control channel. The 207 solution should include negotiation mechanism to specify bandwidth 208 and priority of control-channel between peer Ethernet switches. 210 4.1.2. Neighbor discovery mechanism 212 The solution MUST be able to realize automatic neighbor discovery as 213 realized in current PB or PBB networks. Namely, the solution MUST 214 support an automatic negotiation mechanism to exchange information of 215 Node ID, TE-Link ID, Data-link ID (in the case of link Bundling), and 216 IP address of the control channel for these configuration between 217 neighbors. On the other hand, the extension should be minimized by 218 making use of [RFC4394] and [IEEE802.1AB]. 220 4.1.3. Addressing 222 All service interfaces, TE-Link IDs and Data-link IDs MUST be able to 223 be indicated by standard IEEE MAC address format, but Node ID should 224 be with IP addresses. 226 4.2. Ethernet LSP control 228 4.2.1. Prevention of Loops 230 The solution should have reliability to prevent creating loops of 231 Eth-LSPs. Specifically if the solution supports numbered TE-Link 232 addressing, the solution should define a methodology and protocol 233 extensions if needed to detect or prevent loops. 235 4.2.2. Service control 237 The solution should control various types of service interfaces 238 defined in [IEEE802.1ah]. The service types of Egress port 239 1) Port based service interface 241 2) S-tagged service interface 243 a) one-to-one mapping of S-VIDs to I-SIDs 245 b) bundled mapping of S-VIDs to I-SIDs such as many-to-one, all-to- 246 one, transparent mapping 248 3) I-tagged service interface should be controllable in addition to 249 assignment of Egress port itself. 251 Also, the solution should be flexible to following operational 252 scenarios, 254 1) Any change of mapping of S-VIDs to I-SIDs 256 2) Flexibility to nest or stitch higher layer Eth-LSPs. 258 3) Any change of bandwidth of Eth-LSPs. Here, the solution of 259 bandwidth modification scenario may include bundling of multiple Eth- 260 LSPs. 262 4.2.3. P2MP and MP2MP requirements 264 To provide the service such as a content distribution, the creation 265 of uni-directional P2MP Eth-LSPs should be supported. Also, to 266 provide E-tree type services with multicast traffic, the creation of 267 bi-directional P2MP Eth-LSPs should be supported. The MP2MP 268 requirement is for further study. 270 4.2.4. Asymmetric bandwidth 272 To provide the service which has asymmetric traffic pattern such as a 273 kind of E-tree type services, the creation of asymmetric bandwidth 274 bi-directional Eth-LSPs should be supported. The bandwidth 275 modification of Eth-LSPs in operation should be also supported. 277 4.2.5. QoS control 279 The routing and signaling extensions to control QoS based on Ethernet 280 traffic parameters defined in [MEF10.1] should be supported. Unused 281 bandwidth per CoS should be exhanged by routing extensions like 282 [RFC4124] and the CoS and bandwidth profile such as CIR, CBS, EIR and 283 EBS for a requested LSP should be carried by signaling extensions for 284 bandwidth accounting and traffic control at a local level. 286 4.3. OA&M related functionality 288 OAM mechanisms must be defined for GMPLS controlled E-LSPs. Since 289 the data plane is still Ethernet based, the mechanisms should 290 capitalize on existing [IEEE802.1ag] and [Y.1731] mechanisms. 292 Also, the solution should provide admin status control mechanism to 293 coordinate with Connectivity Fault Management (CFM) functionality 294 [IEEE802.1ag]. 296 4.4. Protection and Restoration related functionality 298 1:1 protection, Shared protection and dynamic restoration should be 299 supported. Protection and Restoration may be triggered by Ethernet 300 OA&M function such as CC, AIS and RDI [IEEE802.1ag] , [Y.1731]. 302 4.5. Link Aggregation Group (LAG) related functionality 304 Link Aggregation is beneficial functionality to realize flexible 305 reconfiguration of logical link bandwidth and reliable Ethernet label 306 switched networks. The availability of link bandwidth between peer 307 Ethernet switches can be enhanced. 309 The solution should support Link Bundling mechanism described in 310 [RFC4201] to explicitly assign the links forming LAG. 312 4.5.1. Failure or deletion of LAG member link 314 The solution should include functionality to prioritize Eth-LSPs, 315 specifically when total bandwidth of Eth-LSPs exceeds total bandwidth 316 of healthy LAG members after the failure of one or more LAG member 317 links. 319 The solution should provide for rerouting an Eth-LSP setup over a 320 failed member link in a LAG to another member link in the LAG. 322 4.5.2. Recovery or addition of LAG member link 324 The solution should include functionality to re-optimize Eth-LSP 325 paths after the addition of a LAG member link, i.e. reversion of 326 failed Eth-LSPs after the failure of the LAG member link, or 327 reallocation of other Eth-LSPs traversing congested Links after the 328 addition of LAG member link. 330 4.6. Inter-domain Ethernet LSP 332 The solution should take into account possible future extension to 333 control inter-domain Eth-LSPs. Here, the possible extensions are 334 Eth-LSPs traverse over 336 1) I-tagged service interfaces 338 2) S-tagged service interfaces, and 340 3) C-tagged service interfaces. 342 4.7. Multi-layer network 344 4.7.1. Dynamic formation of LAG 346 The solution should include dynamic formation of a LAG after the 347 creation or deletion of optical LSPs which interconnect ports of 348 Ethernet switches. It should use the existing Link Bundling 349 mechanism to assign bandwidth to dynamically formulated LAG. 351 4.7.2. Other requirements 353 The architecture and requirements for MPLS-GMPLS inter-working are 354 described in [RFC5145] and [RFC5146]. Some of the requirements 355 described in [RFC5146] are valid even for the case of GMPLS-GMPLS 356 interworking between Ethernet label switched network and L1 network. 357 In other words, 359 1) End-to-End signaling of Eth-LSPs 361 2) Triggered establishment of L1 LSPs 363 3) Avoiding complexity and risks. 365 should be satisfied even for GMPLS control plane for Ethernet. For 366 more details, see [RFC5146] and MPLS-TE client network written in the 367 document should be understood as Ethernet client network. 369 Regarding to routing issue, 371 1) Advertisement of Ethernet label switch network information via L1 372 GMPLS networks 374 2) Selective Advertisement of Ethernet label switched network 375 information via a Border node 377 should be satisfied even in the case of GMPLS-GMPLS inter-working. 378 Note that there is significant difference between MPLS-TE and GMPLS 379 controlled Ethernet from the view point of methodology to create 380 control channel. 382 4.8. Scalability 384 The solution MUST be designed to scale according to following 385 metrics. 387 - Number of nodes 389 - Number of TE-Links 391 - Number of LSPs 393 - Number of service ports 395 - Number of bundled S-VLANs mapped to I-SID and Eth-LSPs 397 - Number of advertised VLANs 399 - Number of MEPs and MIPs. 401 5. Security Considerations 403 The extension for GMPLS controlled Ethernet label switching should be 404 considered under the same security as current work. This extension 405 will not change the underlying security issues. 407 6. IANA Considerations 409 This document has no actions for IANA. 411 7. Acknowledgements 413 The authors would like to thank Mr. Allan McGuire, Mr. Jullien 414 Meuric, Mr. Lou Berger, Mr. Don Fedyk and Mr. Attila Takacs for their 415 valuable comments. 417 8. References 419 8.1. Normative References 421 [IEEE802.1AB] 422 "IEEE Standard for Local and Metropolitan Area Networks, 423 Station and Media Access Control Connectivity Discovery". 425 [IEEE802.1Qay] 426 "IEEE standard for Provider Backbone Bridges Traffic 427 Engineering", work in progress.". 429 [IEEE802.1ad] 430 "IEEE Computer Society, "Virtual Bridged Local Area 431 Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0, 432 Draft, Work in Progress". 434 [IEEE802.1ag] 435 "IEEE Computer Society, "Virtual Bridged Local Area 436 Networks - Amendment 5 : Connectivity Fault Management", 437 P802.1ag/D5.2, Draft, Work in Progress". 439 [IEEE802.1ah] 440 "IEEE standard for Provider Backbone Bridges", work in 441 progress.". 443 [IEEE802.3] 444 "IEEE Computer Society, "Amendment to Carrier Sense 445 Multiple Access with Collision Detection (CAMS/CD) Access 446 Method and Physical Layer Specifications". 448 [MEF10.1] "MEF, "Ethernet Services Attributes Phase2(MEF10.1)," http 449 ://www.metroethernetforum.org/PDF_Documents/MEF10-1.pdf, 450 Nov. 2006.". 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 456 (GMPLS) Signaling Functional Description", RFC 3471, 457 January 2003. 459 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 460 (GMPLS) Architecture", RFC 3945, October 2004. 462 [Y.1731] "ITU-T Y.1731". 464 8.2. Informative References 466 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 467 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 468 June 2005. 470 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 471 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 473 [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, 474 October 2005. 476 [RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., and D. 477 Papadimitriou, "A Transport Network View of the Link 478 Management Protocol (LMP)", RFC 4394, February 2006. 480 [RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS Migration", 481 RFC 5145, March 2008. 483 [RFC5146] Kumaki, K., "Interworking Requirements to Support 484 Operation of MPLS-TE over GMPLS Networks", RFC 5146, 485 March 2008. 487 Authors' Addresses 489 Wataru Imajuku (editor) 490 NTT Communications Corporation 491 1-1-6 Uchisaiwai-cho 492 Chiyoda-ku, Tokyo 493 Japan 495 Phone: +81-(46) 859-4315 496 Email: imajuku.wataru@lab.ntt.co.jp 498 Yoshiaki Sone 499 NTT Network Innovation Labs 500 1-1 Hikari-no-oka 501 Yokosuka, Kanagawa 502 Japan 504 Phone: +81-(46) 859-2456 505 Email: sone.yoshiaki@lab.ntt.co.jp 507 Muneyoshi Suzuki 508 NTT Access Service System Labs 509 1-6 Nakase 510 Mihama-ku, Chiba 511 Japan 513 Phone: (43) 211-8282 514 Email: suzuki.muneyoshi@lab.ntt.co.jp 516 Kazuhiro Matsuda 517 NTT Network Innovation Labs 518 1-1 Hikari-no-oka 519 Yokosuka, Kanagawa 520 Japan 522 Phone: (46) 859-3177 523 Email: matsuda.kazuhiro@lab.ntt.co.jp 524 Tomohiro Otani (editor) 525 KDDI Corporation 526 2-3-2 Nishi-shinjuku 527 Shinjuku-ku, Tokyo 163-8003 528 Japan 530 Phone: +81-(3) 3347-6006 531 Email: tm-otani@kddi.com 533 Kenichi Ogaki 534 KDDI R&D Laboratories, Inc. 535 2-1-15 Ohara 536 Kamifukuoka, Saitama 356-8502 537 Japan 539 Phone: +81-(49) 278-7897 540 Email: ogaki@kddilabs.jp 542 Nabil Bitar (editor) 543 Verizon 544 40 Sylvan Road 545 Waltham, MA 02451 546 USA 548 Email: nabil.n.bitar@verizon.com 550 Full Copyright Statement 552 Copyright (c) 2009 IETF Trust and the persons identified as the 553 document authors. All rights reserved. 555 This document is subject to BCP 78 and the IETF Trust's Legal 556 Provisions Relating to IETF Documents in effect on the date of 557 publication of this document 558 (http://trustee.ietf.org/license-info). Please review these documents 559 carefully, as they describe your rights and restrictions with 560 respect to this document. 562 All IETF Documents and the information contained therein are provided 563 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 564 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 565 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 566 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 567 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 568 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 569 FOR A PARTICULAR PURPOSE. 571 Intellectual Property 573 The IETF Trust takes no position regarding the validity or scope of 574 any Intellectual Property Rights or other rights that might be 575 claimed to pertain to the implementation or use of the technology 576 described in any IETF Document or the extent to which any license 577 under such rights might or might not be available; nor does it 578 represent that it has made any independent effort to identify any 579 such rights. 581 Copies of Intellectual Property disclosures made to the IETF 582 Secretariat and any assurances of licenses to be made available, or 583 the result of an attempt made to obtain a general license or 584 permission for the use of such proprietary rights by implementers or 585 users of this specification can be obtained from the IETF on-line IPR 586 repository at http://www.ietf.org/ipr 588 The IETF invites any interested party to bring to its attention any 589 copyrights, patents or patent applications, or other proprietary 590 rights that may cover technology that may be required to implement 591 any standard or specification contained in an IETF Document. Please 592 address the information to the IETF at ietf-ipr@ietf.org. 594 The definitive version of an IETF Document is that published by, or 595 under the auspices of, the IETF. Versions of IETF Documents that are 596 published by third parties, including those that are translated into 597 other languages, should not be considered to be definitive versions 598 of IETF Documents. The definitive version of these Legal Provisions 599 is that published by, or under the auspices of, the IETF. Versions of 600 these Legal Provisions that are published by third parties, including 601 those that are translated into other languages, should not be 602 considered to be definitive versions of these Legal Provisions. 604 For the avoidance of doubt, each Contributor to the IETF Standards 605 Process licenses each Contribution that he or she makes as part of 606 the IETF Standards Process to the IETF Trust pursuant to the 607 provisions of RFC 5378. No language to the contrary, or terms, 608 conditions or rights that differ from or are inconsistent with the 609 rights and licenses granted under RFC 5378, shall have any effect and 610 shall be null and void, whether published or posted by such 611 Contributor, or included with or in such Contribution.