idnits 2.17.1 draft-zhang-ccamp-gmpls-evolving-g709-00.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.ii 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 81 has weird spacing: '...port or fibe...' -- The document date (July 5, 2009) is 5406 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: 'RFC2119' is mentioned on line 111, but not defined == Missing Reference: 'RFC4606' is mentioned on line 229, but not defined == Missing Reference: 'G.709' is mentioned on line 285, but not defined Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Huawei 3 Category: Standards Track 4 Expires: Jan 2010 July 5, 2009 6 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions 7 for the evolving G.709 Optical Transport Networks Control 9 draft-zhang-ccamp-gmpls-evolving-g709-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 5, 2010. 34 Abstract 36 Recent revisions of ITU-T Recommendation G.709 have introduced new 37 features for Optical Transport Networks (OTN) ODU0, ODU4, ODU2e, 38 ODU3e1, ODU3e2 and ODUflex. Several recent documents have proposed 39 ways to modify GMPLS signaling protocols to support the new OTN 40 features. 42 It is important that a single solution is developed for use in GMPLS 43 signaling and routing protocols. This solution must address all of 44 the new features, must be acceptable to all equipment vendors, and 45 must be extensible for the evolving OTN. 47 This document describes the extensions to the Generalized Multi- 48 Protocol Label Switching (GMPLS) signaling to control the evolving 49 Optical Transport Networks (OTN) with new features including ODU0, 50 ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Table of Contents 60 1. Introduction.................................................2 61 2. Terminology..................................................3 62 3. GMPLS Extensions for the Evolving G.709 - Overview...........3 63 4. Generalized Label............................................6 64 4.1. New definition of ODUk label............................6 65 4.2. Examples................................................8 66 4.3. Label Distribution Procedure............................9 67 5. Security Considerations.....................................10 68 6. IANA Considerations.........................................10 69 7. Acknowledgments.............................................10 70 8. References..................................................10 71 8.1. Normative References...................................10 72 8.2. Informative References.................................11 73 9. Author's Addresses..........................................11 74 10. Contributors...............................................11 76 1. Introduction 78 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 79 MPLS to include Layer-2 Switching (L2SC), Time-Division Multiplex 80 (e.g., SONET/SDH, PDH, and G.709), Wavelength (Lambdas) Switching, 81 and Spatial Switching (e.g., incoming port or fiber to outgoing 82 port or fiber). [RFC3471] presents a functional description of the 83 extensions to Multi-Protocol Label Switching (MPLS) signaling 84 required to support Generalized MPLS. RSVP-TE-specific formats and 85 mechanisms and technology specific details are specified in [RFC3473]. 87 With the maturity and deployment of G.709 technology, it is necessary 88 that there should be a kind of control technology for G.709. [RFC4328] 89 describes the control technology details that are specific to G.709 90 Optical Transport Networks (OTN) as specified in the ITU-T G.709 91 recommendation [ITUT-G709]. 93 However, with the evolution of OTN, there are some new features 94 introduced in ITU-T, for example, ODU0, ODU2e,ODU4 are described in 95 [G709-Amd3] and ODU3e1, ODU3e2 are described in [Gsup43] and ODUflex 96 is under being developed in [G709draft-v3]. 98 Therefore, it is obvious that [RFC4328] can not support these new 99 features of OTN from control plane perspective, and it should be 100 updated or replaced to support the evolving OTN. 102 This document extends the G.709 traffic parameters described in 103 [RFC4328] and also presents a new OTN label format which is very 104 flexible, efficient and understandable. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. GMPLS Extensions for the Evolving G.709 - Overview 114 The new features for the evolving OTN are described in the separate 115 ITU-T documents, for example, ODU0, ODU2e,ODU4 are described in 116 [G709-Amd3] and ODU3e1, ODU3e2 are described in [Gsup43] and ODUflex 117 is under being developed in [G709draft-v3]. 119 The new signal types of digital wrapper layer for the evolving OTN 120 are listed as follows: 122 - Optical Channel Transport Unit (OTUk): 124 . OTU4 125 . OTU2e 126 . OTU3e1 127 . OTU3e2 129 - Optical Channel Data Unit (ODUk): 131 . ODU0 132 . ODU2e 133 . ODU3e1 134 . ODU3e2 135 . ODU4 136 . ODUflex 138 A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) is introduced 139 for ODU0, ODU4, ODU3e2 and ODUflex, so there are two TS granularities 140 for the original ODU1, ODU2, ODU3 because it should keep the 141 compatibility. 143 It also defines the new multiplexing hierarchy for the evolving OTN 144 except that the new signal types are introduced. In addition to the 145 support of ODUk mapping into OTUk (k = 1, 2, 2e, 3, 3e1, 3e2, 4), 146 G.709 supports ODUk multiplexing. For the evolving OTN, the 147 multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k > j) 148 signal is as follows: 150 - ODU0 into ODU1 multiplexing 152 - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS 153 granularity) 155 - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) 157 - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with 158 1.25Gbps TS granularity) 160 - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) 162 - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing 163 (with 1.25Gbps TS granularity) 165 - ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity) 167 - ODU2e into ODU3e2 multiplexing (with 1.25Gbps TS granularity) 169 [RFC4328] describes GMPLS signaling extensions to support the control 170 for G.709 Optical Transport Networks (OTN) [ITUT-G709].However, 171 [RFC4328] can not support these new features of the evolving OTN from 172 control plane perspective, and it should be updated or replaced to 173 support the control for the evolving OTN. 175 This document extends the G.709 traffic parameters described in 176 [RFC4328] and also presents a new OTN label format which is very 177 flexible, efficient and understandable. 179 Extensions for Traffic Parameters for the Evolving G.709 181 The traffic parameters for G.709 are defined in [RFC4328] as follows: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Signal Type | Reserved | NMC | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | NVC | Multiplier (MT) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Reserved | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 It is obvious that the Signal Type should be extended to cover the 194 new Signal Type introduced by the evolving OTN. The new Signal Type 195 is extended as follows: 197 Value Type 198 ----- ---- 199 0 Not significant 200 1 ODU1 (i.e., 2.5 Gbps) 201 2 ODU2 (i.e., 10 Gbps) 202 3 ODU3 (i.e., 40 Gbps) 203 4 ODU4 (i.e., 100 Gbps) 204 5 Reserved (for future use) 205 6 OCh at 2.5 Gbps 206 7 OCh at 10 Gbps 207 8 OCh at 40 Gbps 208 9 OCh at 100 Gbps 209 10~19 Reserved (for future use) 210 20 ODU0 (i.e., 1.25 Gbps) 211 21~30 Reserved (for future use) 212 31 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 213 32 ODU3e1 214 33 ODU3e2 215 34 ODUflex (i.e., 1.25*N Gbps) 216 35~255 Reserved (for future use) 218 4. Generalized Label 220 [RFC3471] has defined the Generalized Label which extends the 221 traditional label by allowing the representation of not only labels 222 which travel in-band with associated data packets, but also labels 223 which identify time-slots, wavelengths, or space division multiplexed 224 positions. The format of the corresponding RSVP-TE Generalized Label 225 object is defined in the Section 2.3 of [RFC3473]. 227 However, for different technologies, we usually need use specific 228 label rather than the Generalized Label. For example, the label 229 format described in [RFC4606] could be used for SDH/SONET, the label 230 format in [RFC4328] for G.709. 232 According to the ODUk label format defined in [RFC4328], it may have 233 some difficulties in extensibility. When ODU3 maps to ODU4, or 234 ODUflex maps to ODU4, lots of labels are requested, which brings 235 complicated signaling process. For example, when ODU3 is mapped into 236 ODU4 with 1.25G tributary slots, it will need thirty-two labels 237 (32*4*8=1024 bits) to be allocated for one ODU3 connection. If 238 ODUflex into ODU4, it may need eighty labels (80*4*8=2560 bits) to be 239 allocated for one ODUflex connection. 241 In this document, a new ODUk label format is defined. The new ODUk 242 label format is very flexible, efficient and understandable. 244 4.1. New definition of ODUk label 246 In order to be compatible with new types of ODU signal and new types 247 of tributary slot, the following new ODUk label format is defined: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | ODUj |OD(T)Uk| T | Reserved | Bit Map | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | ......... | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 ODUj and OD(T)Uk (4 bits respectively): indicate that ODUj is 258 multiplexed into ODUk(k>j), or ODUj is mapped into OTUk (j=k). 260 ODUj field Signal type 261 ---------- ----------- 262 0 ODU0 263 1 ODU1 264 2 ODU2 265 3 ODU3 266 4 ODU4 267 5 ODU2e 268 6 ODU3e1 269 7 ODU3e2 270 8-15 Reserved (for future use) 272 OD(T)Uk field Signal type 273 ---------- ----------- 274 0 Reserved (for future use) 275 1 ODU1/OTU1 276 2 ODU2/OTU2 277 3 ODU3/OTU3 278 4 ODU4/OTU4 279 5 OTU2e 280 6 OTU3e1 281 7 OTU3e2 282 8-15 Reserved (for future use) 284 T (2 bits): indicates the type of tributary slot of OD(T)Uk. 285 Currently, two types of tributary slot are defined in [G.709], the 286 1.25Gbps tributary slot and the 2.5Gbps tributary slot. 288 T field TS type 289 ------- ------- 290 0 1.25Gbps TS granularity 291 1 2.5Gbps TS granularity 292 2-3 Reserved (for future use) 294 Bit Map (variable): indicates which tributary slots in ODUk that the 295 ODUj will be multiplexed into. The sequence of the Bit Map is 296 consistent with the sequence of the tributary slots in ODUk. Each bit 297 in the bit map represents the corresponding tributary slot in ODUk 298 with a value of 1 or 0 indicating whether the tributary slot will be 299 used by ODUj or not. 301 The size of the bit map equals to the total number of the tributary 302 slots of ODUk. 304 Padded bits are added behind the Bit Map to make the whole label a 305 multiple of four bytes if necessary. Padded bit MUST be set to 0 and 306 MUST be ignored. 308 In case of an ODUk mapped into OTUk, it's no need to indicate which 309 tributary slots will be used by ODUk, so the size of Bit Map is 0. 311 4.2. Examples 313 The following examples are given in order to illustrate the label 314 format described in the previous sections of this document. 316 1. ODUk in OTUk mapping: In such conditions, the downstream node 317 along an LSP returns a label indicating that the ODU1 (ODU2 or 318 ODU3 or ODU4) is directly mapped into the corresponding OTU1 (OTU2 319 or OTU3 or ODU4). The following example label indicates an ODU1 320 mapped into OTU1 with 2.5Gbps TS granularity. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |0 0 0 1|0 0 0 1|0 1| Reserved | Padded Bits (0) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 2. ODUj into ODUk multiplexing: In such conditions, this label 329 indicates that an ODUj is multiplexed into several tributary slots 330 of OPUk and then mapped into OTUk. Some instances are shown as 331 follow: 333 - ODU0 into ODU2 Multiplexing: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |0 0 0 0|0 0 1 0|0 0| Reserved |0 1 0 0 0 0 0 0|Padded Bits (0)| 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 This above label indicates an ODU0 multiplexed into the second 342 tributary slot of ODU2, wherein the type of the tributary slot is 343 1.25Gbps. 345 - ODU1 into ODU2 Multiplexing with 1.25Gbps TS granularity: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |0 0 0 1|0 0 1 0|0 0| Reserved |0 1 0 1 0 0 0 0|Padded Bits (0)| 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 This above label indicates an ODU1 multiplexed into the 2nd, 4th 354 tributary slot of ODU2, wherein the type of the tributary slot is 355 1.25Gbps. 357 - ODU2 into ODU3 Multiplexing with 2.5Gbps TS granularity: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |0 0 1 0|0 0 1 1|0 1| Reserved |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th 366 and 7th tributary slot of ODU3, wherein the type of the tributary 367 slot is 2.5Gbps. 369 4.3. Label Distribution Procedure 371 This document does not change the existing label distribution 372 procedures [RFC4328] for GMPLS except that the new ODUk label should 373 be processed as follows. 375 When a node receives a generalized label request for setting up an 376 ODUj LSP from its upstream node, the node should generate an ODU 377 label according to the signal type of the requested LSP and the free 378 resources (i.e., free tributary slots of ODUk) that will be reserved 379 for the LSP, and send the label to its upstream node. Note that these 380 labels can also be specified by the source node of the connection. 382 In case of ODUj to ODUk multiplexing, the node should firstly 383 determine the size of the Bit Map field according to the signal type 384 and the tributary slot type of ODUk, and then set the bits to 1 in 385 the Bit Map field corresponding to the reserved tributary slots. 387 In case of ODUk to OTUk mapping, the node only needs to fill the ODUj 388 and the ODUk fields with corresponding values in the label. Other 389 bits are reserved and MUST be set to 0. 391 When receiving an ODU label from its downstream node, the node should 392 learn which ODU signal type is multiplexed or mapped into which ODU 393 signal type by analyzing the ODUj and the ODUk fields. 395 In case of ODUj to ODUk multiplexing, the node should firstly 396 determine the size of the Bit Map field according to the signal type 397 and the tributary slot type of ODUk, and then obtain which tributary 398 slots in ODUk are reserved by its downstream node according to the 399 position of the bits that are set to 1 in the Bit Map field, so that 400 the node can multiplex the ODUj into the reserved tributary slots of 401 ODUk after the LSP is established. 403 In case of ODUk to OTUk mapping, the size of Bit Map field is 0 and 404 no additional procedure is needed. 406 5. Security Considerations 408 TBD. 410 6. IANA Considerations 412 TBD. 414 7. Acknowledgments 416 TBD. 418 8. References 420 8.1. Normative References 422 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 423 Switching (GMPLS) Signaling Extensions for G.709 Optical 424 Transport Networks Control", RFC 4328, Jan 2006. 426 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 427 Switching (GMPLS) Signaling Functional Description", 428 RFC 3471, January 2003. 430 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 431 Switching (GMPLS) Signaling Resource ReserVation 432 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 433 3473, January 2003. 434 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 435 (GMPLS) Architecture", RFC 3945, October 2004. 437 8.2. Informative References 439 [ITUT-G709] ITU-T, "Interface for the Optical Transport Network 440 (OTN)," G.709 Recommendation (and Amendment 1), February 441 2001 (October 2001). 443 [G709-Amd3] ITU-T, "Interface for the Optical Transport Network 444 (OTN)," G.709 Recommendation Amendment3), December 2008. 446 [Gsup43] ITU-T, " Proposed revision of G.sup43 (for agreement),", 447 December 2008. 449 [G709draft-v3] ITU-T, "Draft revised G.709, version 3,", May 2009. 451 9. Author's Addresses 453 Fatai Zhang 454 Huawei Technologies Co., Ltd. 455 F3-5-B R&D Center, Huawei Base, 456 Bantian, Longgang District 457 Shenzhen 518129 P.R.China 458 Phone: +86-755-28972912 459 Email: zhangfatai@huawei.com 461 10. Contributors 463 Yi Lin 464 Huawei Technologies Co., Ltd. 465 F3-5-B R&D Center, Huawei Base, 466 Bantian, Longgang District 467 Shenzhen 518129 P.R.China 468 Phone: +86-755-28972914 469 Email: linyi_hw@huawei.com 471 Yunbin Xu 472 China Academy of Telecommunication Research of MII 473 11 Yue Tan Nan Jie Beijing, P.R.China 474 Phone: +86-10-68094134 475 Email: xuyunbin@mail.ritt.com.cn 477 Guoying Zhang 478 China Academy of Telecommunication Research of MII 479 11 Yue Tan Nan Jie Beijing, P.R.China 480 Phone: +86-10-68094272 481 Email: zhangguoying@mail.ritt.com.cn 483 Intellectual Property 485 The IETF Trust takes no position regarding the validity or scope of 486 any Intellectual Property Rights or other rights that might be 487 claimed to pertain to the implementation or use of the technology 488 described in any IETF Document or the extent to which any license 489 under such rights might or might not be available; nor does it 490 represent that it has made any independent effort to identify any 491 such rights. 493 Copies of Intellectual Property disclosures made to the IETF 494 Secretariat and any assurances of licenses to be made available, or 495 the result of an attempt made to obtain a general license or 496 permission for the use of such proprietary rights by implementers or 497 users of this specification can be obtained from the IETF on-line IPR 498 repository at http://www.ietf.org/ipr 500 The IETF invites any interested party to bring to its attention any 501 copyrights, patents or patent applications, or other proprietary 502 rights that may cover technology that may be required to implement 503 any standard or specification contained in an IETF Document. Please 504 address the information to the IETF at ietf-ipr@ietf.org. 506 The definitive version of an IETF Document is that published by, or 507 under the auspices of, the IETF. Versions of IETF Documents that are 508 published by third parties, including those that are translated into 509 other languages, should not be considered to be definitive versions 510 of IETF Documents. The definitive version of these Legal Provisions 511 is that published by, or under the auspices of, the IETF. Versions of 512 these Legal Provisions that are published by third parties, including 513 those that are translated into other languages, should not be 514 considered to be definitive versions of these Legal Provisions. 516 For the avoidance of doubt, each Contributor to the IETF Standards 517 Process licenses each Contribution that he or she makes as part of 518 the IETF Standards Process to the IETF Trust pursuant to the 519 provisions of RFC 5378. No language to the contrary, or terms, 520 conditions or rights that differ from or are inconsistent with the 521 rights and licenses granted under RFC 5378, shall have any effect and 522 shall be null and void, whether published or posted by such 523 Contributor, or included with or in such Contribution. 525 Disclaimer of Validity 527 All IETF Documents and the information contained therein are provided 528 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 529 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 530 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 531 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 532 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 533 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 534 FOR A PARTICULAR PURPOSE. 536 Full Copyright Statement 538 Copyright (c) 2009 IETF Trust and the persons identified as the 539 document authors. All rights reserved. 541 This document is subject to BCP 78 and the IETF Trust's Legal 542 Provisions Relating to IETF Documents in effect on the date of 543 publication of this document (http://trustee.ietf.org/license-info). 544 Please review these documents carefully, as they describe your rights 545 and restrictions with respect to this document.