idnits 2.17.1 draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3471, but the abstract doesn't seem to directly say this. It does mention RFC3471 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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. (Using the creation date from RFC3471, updated by this document, for RFC5378 checks: 2000-10-23) -- 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 (March 23, 2009) is 5507 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'G.694' is mentioned on line 208, but not defined -- Unexpected draft version: The latest known version of draft-otani-ccamp-gmpls-cspf-constraints is -07, but you're referring to -08. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Tomohiro Otani 3 Updates: RFC 3471 KDDI 4 Intended status: standard track (Editor) 5 Expires: September 23, 2009 March 23, 2009 7 Generalized Labels for G.694 Lambda-Switching Capable Label Switching 8 Routers 10 Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 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 September 23, 2009. 36 Abstract 38 Technology in the optical domain is constantly evolving and as a 39 consequence new equipment providing lambda switching capability has 40 been developed and is currently being deployed. However, RFC 3471 has 41 defined that a wavelength label (section 3.2.1.1) "only has 42 significance between two neighbors" and global wavelength continuity 43 is not considered. In order to achieve interoperability in a network 44 composed of next generation lambda switch-capable equipment, this 45 document defines a standard lambda label format, being compliant with 46 ITU-T G.694. Moreover some consideration on how to ensure lambda 47 continuity with RSVP-TE is provided. This document is a companion to 48 the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It 49 defines the label format when Lambda Switching is requested in an all 50 optical network. 52 Table of Contents 54 Abstract........................................................... 1 55 1. Introduction.................................................... 2 56 2. Conventions used in this document............................... 2 57 3. Assumed network model and related problem statement............. 2 58 4. Label Related Formats........................................... 5 59 5. Security Considerations......................................... 8 60 6. IANA Considerations............................................. 9 61 7. Acknowledgement................................................ 10 62 8. References..................................................... 11 63 8.1. Normative References......................................... 11 64 8.2. Informative References....................................... 11 65 Appendix A. DWDM Example.......................................... 11 66 Appendix B. CWDM Example.......................................... 12 67 Authors' address.................................................. 13 68 Intellectual property and Copyright Statement..................... 14 70 1. Introduction 72 As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS from 73 supporting only packet (Packet Switching Capable - PSC) interfaces 74 and switching to also include support for four new classes of 75 interfaces and switching: 76 o Layer-2 Switch Capable (L2SC) 77 o Time-Division Multiplex (TDM) 78 o Lambda Switch Capable (LSC) 79 o Fiber-Switch Capable (FSC). 80 A functional description of the extensions to MPLS signaling needed 81 to support new classes of interfaces and switching is provided in 82 [RFC3471]. 84 This document presents details that are specific to the use of GMPLS 85 with a new generation of Lambda Switch Capable (LSC) equipment. 86 Technologies such as Reconfigurable Optical Add/Drop Multiplex 87 (ROADM) and Wavelength Cross-Connect (WXC) operate at the wavelength 88 switching level. As such, the wavelength is important information 89 that is necessary to set up a wavelength-based LSP appropriately and 90 the wavelength defined in [G.694] is widely utilized. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC-2119 [RFC2119]. 98 3. Assumed network model and related problem statement 99 Figure 1 depicts an all-optically switched network consisting of 100 different vendor's optical network domains. Vendor A's network 101 consists of ROADM or WXC, and vendor B's network consists of PXCs and 102 DWDMs, otherwise both vendors' networks might be based on the same 103 technology. 105 In this case, the use of standardized wavelength label information is 106 quite significant to establish a wavelength-based LSP. It is also an 107 important constraint when conducting CSPF calculation for RSVP-TE 108 signaling. The way the CSPF is performed is outside the scope of this 109 document, but defined in [GMPLS-CSPF]. 111 It is needless to say, a LSP must be appropriately provisioned 112 between a selected pair of ports not only within Domain A but also 113 over multiple domains satisfying wavelength constraints. 115 Figure 2 illustrates in detail the interconnection between Domain A 116 and Domain B. 118 | 119 Domain A (or Vendor A) | Domain B (or Vendor B) 120 | 121 Node-1 Node-2 | Node-6 Node-7 122 +--------+ +--------+ | +-------+ +-+ +-+ +-------+ 123 | ROADM | | ROADM +---|------+ PXC +-+D| |D+-+ PXC | 124 | or WXC +========+ or WXC +---|------+ +-+W+=====+W+-+ | 125 | (LSC) | | (LSC) +---|------+ (LSC) +-+D| |D+-+ (LSC) | 126 +--------+ +--------+ | | +-|M| |M+-+ | 127 || || | +++++++++ +-+ +-+ +++++++++ 128 || Node-3 || | ||||||| ||||||| 129 || +--------+ || | +++++++++ +++++++++ 130 ||===| WXC +===|| | | DWDM | | DWDM | 131 | (LSC) | | +--++---+ +--++---+ 132 ||===+ +===|| | || || 133 || +--------+ || | +--++---+ +--++---+ 134 || || | | DWDM | | DWDM | 135 +--------+ +--------+ | +++++++++ +++++++++ 136 | ROADM | | ROADM | | ||||||| ||||||| 137 | or WXC +========+ or WXC +=+ | +-+ +++++++++ +-+ +-+ +++++++++ 138 | (LSC) | | (LSC) | | | |D|-| PXC +-+D| |D+-+ PXC | 139 +--------+ +--------+ +=|==+W|-| +-+W+=====+W+-+ | 140 Node-4 Node-5 | |D|-| (LSC) +-+D| |D+-+ (LSC) | 141 | |M|-| +-+M| |M+-+ | 142 | +-+ +-------+ +-+ +-+ +-------+ 143 | Node-8 Node-9 145 Figure 1 Wavelength-based network model. 147 +-------------------------------------------------------------+ 148 | Domain A | Domain B | 149 | | | 150 | +---+ lambda 1 | +---+ | 151 | | |---------------|---------| | | 152 | WDM | N | lambda 2 | | N | WDM | 153 | =====| O |---------------|---------| O |===== | 154 | O | D | . | | D | O | 155 | T WDM | E | . | | E | WDM T | 156 | H =====| 2 | lambda n | | 6 |===== H | 157 | E | |---------------|---------| | E | 158 | R +---+ | +---+ R | 159 | | | 160 | N +---+ | +---+ N | 161 | O | | | | | O | 162 | D WDM | N | | | N | WDM D | 163 | E =====| O | WDM | | O |===== E | 164 | S | D |=========================| D | S | 165 | WDM | E | | | E | WDM | 166 | =====| 5 | | | 8 |===== | 167 | | | | | | | 168 | +---+ | +---+ | 169 +-------------------------------------------------------------+ 171 Figure 2 Interconnecting details between two domains. 173 In the scenario of Figure 1, consider the setting up of a 174 bidirectional LSP from ingress switch 1 to egress switch 9. In order 175 to satisfy wavelength continuity constraint, a fixed wavelength 176 (lambda 1) needs to be used in domain A and domain B. A Path message 177 will be used for the signaling, the PATH message must contain the 178 upstream label and a label set object; both containing the same 179 lambda. The label set object is made by only one sub channel that 180 must be same as the upstream label. The path setup will continue 181 downstream to switch 9 by configuring each lambda switch based on the 182 wavelength label. This label allows the correct switching of lambda 183 switches and the label contents needs to be used over the inter- 184 domain. As same above, the path setup will continue downstream to 185 switch 9 by configuring lambda switch based on multiple wavelength 186 labels. If the node has a tunable wavelength transponder, the tuning 187 wavelength is considered as a part of wavelength switching operation. 189 Not using a standardized label would add undue burden on the operator 190 to enforce policy as each manufacturer may decide on a different 191 representation and therefore each domain may have its own label 192 formats. Moreover, manual provisioning may lead to misconfiguration 193 if domain-specific labels are used. 195 Therefore, a wavelength label should be standardized in order to 196 allow interoperability between multiple domains; otherwise 197 appropriate existing labels are identified in support of wavelength 198 availability. As identical wavelength information, the ITU-T 199 frequency grid specified in [G.694.1] for Dense WDM (DWDM) and 200 wavelength information in [G.694.2] for Coarse WDM (CWDM) are used by 201 LSRs and should be followed as a wavelength label. 203 4. Label Related Formats 205 To deal with the widening scope of MPLS into the optical and time 206 domains, several new forms of "label" have been defined in [RFC3471]. 207 This section contains clarifications for the Wavelength label based 208 on [G.694] and Label Set definition specific for LSC LSRs. 210 4.1 Wavelength Labels 212 In section 3.2.1.1 of [RFC3471], a Wavelength label is defined to 213 have significance between two neighbors, and the receiver may need to 214 convert the received value into a value that has local significance. 216 LSC equipment uses multiple wavelengths controlled by a single 217 control channel. In such case, the label indicates the wavelength to 218 be used for the LSP. This document proposes to standardize the 219 wavelength label. As an example of wavelength values, the reader is 220 referred to [G.694.1] which lists the frequencies from the ITU-T DWDM 221 frequency grid. The same can be done for CWDM technology by using 222 the wavelength defined in [G.694.2]. In that sense, we can call G.694 223 wavelength labels. 225 Since the ITU-T DWDM grid is based on nominal central frequencies, we 226 need to indicate the appropriate table, the channel spacing in the 227 grid and a value n that allows the calculation of the frequency. 228 That value can be positive or negative. 230 The frequency is calculated as such in [G.694.1]: 232 Frequency (THz) = 193.1 THz + n * channel spacing (THz) 234 , where n is a two's-complement integer (positive, negative or 0) and 235 channel spacing is defined to be 0.0125, 0.025, 0.05 or 0.1 THz. When 236 wider channel spacing such as 0.2 THz is utilized, the combination of 237 narrower channel spacing and the value n can provide proper frequency 238 with that channel spacing. Channel spacing is not utilized to 239 indicate the LSR capability but only to specify a frequency in 240 signaling. 242 For the other example of the case of the ITU-T CWDM grid, the spacing 243 between different channels was defined to be 20nm, so we need to pass 244 the wavelength value in nm in this case. Examples of CWDM 245 wavelengths are 1471, 1491, etc. nm. 247 The wavelength is calculated as follows 249 Wavelength (nm) = 1471 nm + n * 20 nm 251 , where n is a two's-complement integer (positive, negative or 0).The 252 tables listed in [G.694.1] and [G.694.2] are not numbered and change 253 with the changing frequency spacing as technology advances, so an 254 index is not appropriate in this case. 256 4.2 DWDM Wavelength Label 258 For the case of DWDM, the information carried in a Wavelength label 259 is: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |Grid | C.S | Reserved | n | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 (1) Grid: 3 bits 269 The value for grid is set to 1 for ITU-T DWDM Grid as defined in 270 [G.694.1]. 272 +----------+---------+ 273 | Grid | Value | 274 +----------+---------+ 275 | Reserved | 0 | 276 +----------+---------+ 277 |ITU-T DWDM| 1 | 278 +----------+---------+ 279 |ITU-T CWDM| 2 | 280 +----------+---------+ 281 |Future use| 3 - 7 | 282 +----------+---------+ 284 (2) C.S.(channel spacing): 4 bits 286 DWDM channel spacing is defined as follows. 288 +----------+---------+ 289 | C.S(GHz) | Value | 290 +----------+---------+ 291 | Reserved | 0 | 292 +----------+---------+ 293 | 100 | 1 | 294 +----------+---------+ 295 | 50 | 2 | 296 +----------+---------+ 297 | 25 | 3 | 298 +----------+---------+ 299 | 12.5 | 4 | 300 +----------+---------+ 301 |Future use| 5 - 15 | 302 +----------+---------+ 304 (3) n: 16 bits 306 n is a two's-complement integer to take either a negative, zero or a 307 positive value. The value used to compute the frequency as shown 308 above. 310 4.3 CWDM Wavelength Label 312 For the case of CWDM, the information carried in a Wavelength label 313 is: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |Grid | C.S | Reserved | n | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 The structure of the label in the case of CWDM is the same as that of 322 DWDM case. 324 (1) Grid: 3 bits 326 The value for grid is set to 2 for ITU-T CWDM Grid as defined in 327 [G.694.2]. 329 +----------+---------+ 330 | Grid | Value | 331 +----------+---------+ 332 | Reserved | 0 | 333 +----------+---------+ 334 |ITU-T DWDM| 1 | 335 +----------+---------+ 336 |ITU-T CWDM| 2 | 337 +----------+---------+ 338 |Future use| 3 - 7 | 339 +----------+---------+ 341 (2) C.S.(channel spacing): 4 bits 343 CWDM channel spacing is defined as follows. 345 +----------+---------+ 346 | C.S(nm) | Value | 347 +----------+---------+ 348 | Reserved | 0 | 349 +----------+---------+ 350 | 20 | 1 | 351 +----------+---------+ 352 |Future use| 2 - 15 | 353 +----------+---------+ 355 (3) n: 16 bits 357 n is a two's-complement integer. The value used to compute the 358 wavelength as shown above. 360 We do not need to define a new type as the information stored is 361 either a port label or a wavelength label. Only the wavelength label 362 as above needs to be defined. 364 5. Security Considerations 366 This document introduces no new security considerations to [RFC3473]. 367 GMPLS security is described in section 11 of [RFC3471] and refers to 368 [RFC3209] for RSVP-TE. 370 6. IANA Considerations 372 This document has no actions for IANA. 374 7. Acknowledgement 376 The authors would like to thank Adrian Farrel, Lawrence Mao, Zafar 377 Ali, Dan Li and Daniele Ceccarelli for the discussion and their 378 comments. 380 8. References 382 8.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 388 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 389 3209, December 2001. 391 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 392 (MPLS) Signaling Functional Description", RFC 3471, January 2003. 394 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 395 (MPLS) Signaling - Resource ReserVation Protocol Traffic Engineering 396 (RSVP-TE) Extensions", RFC 3473, January 2003. 398 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching 399 (GMPLS) Architecture", RFC 3945, October 2004. 401 8.2. Informative References 403 [GMPLS-CSPF] Otani, T., et al, "Considering Generalized Multiprotocol 404 Label Switching Traffic Engineering Attributes During Path 405 Computation", draft-otani-ccamp-gmpls-cspf-constraints-08.txt, Feb. 406 2008. 408 [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM 409 applications: DWDM frequency grid", June 2002. 411 [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM 412 applications: CWDM wavelength grid", December 2003. 414 Appendix A. DWDM Example 416 Considering the network displayed in figure 1 it is possible to show 417 an example of LSP set up using the lambda labels. 419 Node 1 receives the request for establishing an LSP from itself to 420 Node 9. The ITU-T grid to be used is the DWDM one, the channel 421 spacing is 50Ghz and the wavelength to be used is 193,35 THz. 423 Node 1 signals the LSP via a Path message including a Wavelength 424 Label structured as defined in section 4.2: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |Grid | C.S | Reserved | n | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Where: 434 Grid = 1 : ITU-T DWDM grid 435 C.S. = 2 : 50 GHz channel spacing 436 n = 5 : 438 Frequency (THz) = 193.1 THz + n * channel spacing (THz) 440 193.35 (THz) = 193.1 (THz) + n* 0.05 (THz) 442 n = (193.35-193.1)/0.05 = 5 444 Appendix B. CWDM Example 446 The network displayed in figure 1 can be used also to display an 447 example of signaling using the Wavelength Label in a CWDM 448 environment. 450 This time the signaling of an LSP from Node 4 to Node 7 is 451 considered. Such LSP exploits the CWDM ITU-T grid with a 20nm 452 channel spacing and is to established using wavelength equal to 1331 453 nm. 455 Node 4 signals the LSP via a Path message including a Wavelength 456 Label structured as defined in section 4.3: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |Grid | C.S | Reserved | n | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Where: 466 Grid = 2 : ITU-T CWDM grid 467 C.S. = 1 : 20 nm channel spacing 468 n = -7 : 470 Wavelength (nm) = 1471 nm + n * 20 nm 472 1331 (nm) = 1471 (nm) + n * 20 nm 474 n = (1331-1471)/20 = -7 476 Authors' address 478 Tomohiro Otani 479 KDDI Corporation 480 2-3-2 Nishishinjuku Shinjuku-ku Tokyo, 163-8003, Japan 481 Phone: +81-3-3347-6006 482 Email: tm-otani@kddi.com 484 Richard Rabbat 485 Google, Inc. 486 1600 Amphitheatre Pkwy 487 Mountain View, CA 94043 488 Email: rabbat@alum.mit.edu 490 Sidney Shiba 491 Email: sidney.shiba@yahoo.com 493 Hongxiang Guo 494 Email: hongxiang.guo@gmail.com 496 Keiji Miyazaki 497 Fujitsu Laboratories Ltd 498 4-1-1 Kotanaka Nakahara-ku, Kawasaki Kanagawa, 211-8588, Japan 499 Phone: +81-44-754-2765 500 Email: miyazaki.keiji@jp.fujitsu.com 502 Diego Caviglia 503 Ericsson 504 16153 Genova Cornigliano, ITALY 505 Phone: +390106003736 506 Email: diego.caviglia@ericsson.com 508 Full Copyright Statement 510 Copyright (c) 2009 IETF Trust and the persons identified as the 511 document authors. All rights reserved. 513 This document is subject to BCP 78 and the IETF Trust's Legal 514 Provisions Relating to IETF Documents in effect on the date of 515 publication of this document 516 (http://trustee.ietf.org/license-info). Please review these documents 517 carefully, as they describe your rights and restrictions with 518 respect to this document. 520 All IETF Documents and the information contained therein are provided 521 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 522 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 523 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 524 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 525 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 526 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 527 FOR A PARTICULAR PURPOSE. 529 Intellectual Property 531 The IETF Trust takes no position regarding the validity or scope of 532 any Intellectual Property Rights or other rights that might be 533 claimed to pertain to the implementation or use of the technology 534 described in any IETF Document or the extent to which any license 535 under such rights might or might not be available; nor does it 536 represent that it has made any independent effort to identify any 537 such rights. 539 Copies of Intellectual Property disclosures made to the IETF 540 Secretariat and any assurances of licenses to be made available, or 541 the result of an attempt made to obtain a general license or 542 permission for the use of such proprietary rights by implementers or 543 users of this specification can be obtained from the IETF on-line IPR 544 repository at http://www.ietf.org/ipr 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 any standard or specification contained in an IETF Document. Please 550 address the information to the IETF at ietf-ipr@ietf.org. 552 The definitive version of an IETF Document is that published by, or 553 under the auspices of, the IETF. Versions of IETF Documents that are 554 published by third parties, including those that are translated into 555 other languages, should not be considered to be definitive versions 556 of IETF Documents. The definitive version of these Legal Provisions 557 is that published by, or under the auspices of, the IETF. Versions of 558 these Legal Provisions that are published by third parties, including 559 those that are translated into other languages, should not be 560 considered to be definitive versions of these Legal Provisions. 562 For the avoidance of doubt, each Contributor to the IETF Standards 563 Process licenses each Contribution that he or she makes as part of 564 the IETF Standards Process to the IETF Trust pursuant to the 565 provisions of RFC 5378. No language to the contrary, or terms, 566 conditions or rights that differ from or are inconsistent with the 567 rights and licenses granted under RFC 5378, shall have any effect and 568 shall be null and void, whether published or posted by such 569 Contributor, or included with or in such Contribution.