idnits 2.17.1 draft-cecczhang-ccamp-gmpls-g709v3-lmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2012) is 4214 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) == Unused Reference: 'RFC3945' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'RFC4328' is defined on line 881, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-08 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-g709-framework (ref. 'OTN-frwk') -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'G709-V3' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G.7714.1' == Outdated reference: A later version (-11) exists of draft-ietf-ccamp-lmp-behavior-negotiation-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Xian Zhang 3 Category: Standards Track Huawei 4 D. Ceccarelli 5 D. Caviglia 6 Ericsson 7 Guoying Zhang 8 CATR 9 D. Beller 10 S.Belotti 11 Alcatel-Lucent 12 Expires: April 11, 2013 October 12, 2012 14 Link Management Protocol (LMP) extensions for G.709 15 Optical Transport Networks 17 draft-cecczhang-ccamp-gmpls-g709v3-lmp-00.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 11, 2013. 42 Abstract 44 Recent progress of the Optical Transport Network (OTN) has introduced 45 new signal types (i.e., ODU0, ODU4, ODU2e and ODUflex) and new 46 Tributary Slot granularity (1.25Gbps). 48 Since equipments deployed prior to recently defined ITU-T 49 recommendations only support 2.5 Gbps Tributary Slot granularity and 50 ODU1, ODU2 and ODU3 containers, the compatibility problem should be 51 considered. In addition, a Higher Order ODU (HO ODU) link may not 52 support all the types of Lower Order ODU (LO ODU) signals defined by 53 the new OTN standard because of the limitation of the devices at the 54 two ends of a link. In these cases, the control plane is required to 55 run the capability discovering functions for the evolutive OTN. 57 This document describes the extensions to the Link Management 58 Protocol (LMP) needed to discover the capability of HO ODU link, 59 including the granularity of Tributary Slot to be used and the LO ODU 60 signal types that the link can support. Moreover, extensions of LMP 61 test messages detailing the OTN technology specific information in 62 order to cover also G.709v3 signal types and containers are also 63 provided. 65 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 Table of Contents 73 1. Introduction ................................................ 3 74 2. Terminology ................................................. 4 75 3. Overview of the Evolutive G.709 .............................. 4 76 4. Link Capability Discovery ................................... 5 77 4.1. Link Capabaplity Discovery Requirements ................. 5 78 4.1.1. Discovering the Granularity of the TS .............. 5 79 4.1.2. Discovering the Supported LO ODU Signal Types....... 6 80 4.2. Extensions: LMP Link Summary Message .................... 7 81 4.2.1. Message Extension .................................. 7 82 4.2.1.1. LinkSummary Message ........................... 7 83 4.2.1.2. LinkSummaryAck Message ........................ 8 84 4.2.1.3. LinkSummaryNack Message ....................... 8 85 4.2.2. Object Definitions ................................. 8 86 4.2.3. Procedures ........................................ 10 87 5. Verifying Link Connectivity ................................. 12 88 5.1. Encoding Type ......................................... 13 89 5.2. Verify Transport Mechanism ............................. 13 90 5.3. Transmission Rate ...................................... 14 91 6. Trace Monitoring ........................................... 15 92 6.1. TRACE Object for evolutive OTN ......................... 15 93 6.2. Discovery Response Message for Layer Adjacency Discovery 17 95 7. LMP Behavior Negotiation Update ............................. 18 96 8. Security Considerations ..................................... 18 97 9. IANA Considerations ........................................ 19 98 10. Acknowledgments ........................................... 19 99 11. References ................................................ 19 100 11.1. Normative References .................................. 19 101 11.2. Informative References ................................ 20 102 12. Authors' Addresses ........................................ 20 103 13. Contributors .............................................. 22 105 1. Introduction 107 The Link Management Protocol (LMP) defined in [RFC4204] is being 108 developed as part of the Generalized MPLS (GMPLS) protocol suite to 109 manage Traffic Engineering (TE) links. 111 Recently, great progress has been made for the Optical Transport 112 Networking (OTN) technologies in ITU-T. New ODU containers (i.e., 113 ODU0, ODU4, ODU2e and ODUflex) and a new Tributary Slot (TS) 114 granularity (1.25Gbps) have been introduced by the [G709-V3], 115 enhancing the flexibility of OTNs. 117 With the evolution and deployment of G.709 technology, the backward 118 compatibility problem requires to be considered. In data plane, the 119 equipment supporting 1.25Gbps TS can combine the specific Tributary 120 Slots together (e.g., combination of TS#i and TS#i+4 on a HO ODU2 121 link) so that it can interwork with other equipments which support 122 2.5Gbps TS. From the control plane point of view, it is necessary to 123 discover which type of TS is supported at both ends of a link, so 124 that it can choose and reserve the TS resources correctly in this 125 link for the connection. 127 Additionally, the requirement of discovering the signal types of 128 Lower Order ODU (LO ODU) that can be supported by a Higher Order ODU 129 (HO ODU) should be taken into account. Equipment at one end of a HO 130 ODU link may not support to transport some types of LO ODU signals 131 (e.g., may not support the ODUflex). In this case, this HO ODU link 132 should not be selected for those types of LO ODU connections. 134 From the perspective of control plane, it is necessary to discover 135 the capability of a HO ODUk or OTUk link including the granularity of 136 TS to be used and the LO ODU signal types that the link can support. 137 Note that this capability information can be, in principle, 138 discovered by routing. Since in certain case, routing is not present 139 (e.g., UNI case) we need to extend link management protocol 140 capabilities to cover this aspect. Obviously, in case of routing 141 presence, the discovering procedure by LMP could also be optional. 143 A further enhancement needed with respect to LMP covers the link 144 verification and link property correlation functionalities and the 145 G.709 test procedures they are based on. Such procedures require the 146 definition of a G.709 specific TRACE object. After data links have 147 been verified, it is possible to group them into the TE links. 149 This document extends the LMP and describes the solution of 150 discovering HO ODU link capability and operating link verification 151 and link property correlation. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 3. Overview of the Evolutive G.709 161 The traditional OTN standard [ITUT-G709] describes the optical 162 transport hierarchy (OTH) and introduces three ODU signal types (i.e., 163 ODU1, ODU2 and ODU3). The ODUj can be mapped into one or more 164 Tributary Slots (with a granularity of 2.5Gbps) of OPUk where j j) signal can be depicted as follows: 191 - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) 193 - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS 194 granularity) 196 - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) 198 - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing 199 (with 1.25Gbps TS granularity) 201 - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) 203 - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 204 multiplexing (with 1.25Gbps TS granularity) 206 Note that If TS auto-negotiation is supported, a node supporting 207 1.25Gbps TS can interwork with the other nodes that supporting 208 2.5Gbps TS by combining specific TSs together in data plane, as 209 descirbied in [OTN-frwk]. 211 4. Link Capability Discovery 213 4.1. Link Capabaplity Discovery Requirements 215 4.1.1. Discovering the Granularity of the TS 217 As described in section 3.1, if the two ends of a link use different 218 granularities of TS, The LO ODU must be mapped into specific combined 219 Tributary Slots in the end of link with TS of 1.25Gbps. 221 From the perspective of control plane, when creating a LO ODU 222 connection, the node MUST select and reserve specific TS for the 223 connection if the two ends of a link use different granularities of 224 TS. For example, for an ODU2 link, we suppose that node A only 225 supports the 2.5Gbps TS while node B supports the 1.25Gbps TS. When 226 node B receives a Path message from node A requesting an ODU1 227 connection, node B MUST reserve the TS#i and TS#i+4 (where i<=4) 228 (with the granularity of 1.25Gbps) and tell node A via the label 229 carried in the Resv message that the TS#i (with the granularity of 230 2.5Gbps) among the 4 slots has been reserved for the ODU1 connection. 231 Otherwise, the reservation procedure will fail. 233 +-----+ Path +-----+ 234 | | ------------> | | 235 | A +-------ODU2 link-------+ B | 236 | | <------------- | | 237 +-----+ Resv +-----+ 238 (Support 2.5G TS) (Support 1.25G TS) 240 Therefore, for an ODU2 or ODU3 link, in order to reserve TS resources 241 correctly for a LO ODU connection, the control plane of the two ends 242 MUST know which granularity the other end can support before creating 243 the LO ODU connection. 245 4.1.2. Discovering the Supported LO ODU Signal Types 247 Many new ODU signal types are introduced by [G709-V3], such as ODU0, 248 ODU4, ODU2e and ODUflex. It is possible that equipment does not 249 always support all the LO ODU signal types introduced by [G709-V3]. 250 If one end of a HO ODU link can not support a certain LO ODU signal 251 type and there is no HO ODU FA LSP able to support this LO ODU signal, 252 the HO ODU link/FA LSP can not be selected to carry such type of LO 253 ODU connection. 255 For example, in the following figure, if the interfaces IF1, IF2, IF8, 256 IF7, IF5 and IF6 can support ODUflex signals, while the interfaces IF 257 3 and IF4 can not support ODUflex signals. In this case, if one 258 ODUflex connection from A to C is requested, and there is no HO ODU 259 FA LSP from node A to C through node B, link #1 and #2 should be 260 excluded, link #3 and link #4 are the candidates (the possible path 261 could be A-D-C through link #3 and link #4). 263 +-----+ 264 link #3 | | link #4 265 +-----------------+ D +-----------------+ 266 | IF8| |IF7 | 267 | +-----+ | 268 | | 269 |IF1 IF6| 270 +--+--+ +-----+ +--+--+ 271 | | link #1 | | link #2 | | 272 | A +--------------+ B +--------------+ C | 273 | |IF2 IF3| |IF4 IF5| | 274 +-----+ +-----+ +-----+ 276 Therefore, it is necessary for the two ends of a HO ODU link to 277 discover which types of LO ODU can be supported by the HO ODU link. 279 After discovering, the capability information can be flooded by IGP, 280 so that the correct path for an ODU connection can be calculated. 282 4.2. Extensions: LMP Link Summary Message 284 [RFC4204] defines the Link Management Protocol (LMP) which consists 285 of four main procedures: control channel management, link property 286 correlation, link connectivity verification, and fault management. As 287 part of LMP, the link property correlation is used to verify the 288 consistency of the TE and data link information on both sides of a 289 link. This document extends the link property correlation procedure 290 to discover the capability of both sides of a HO ODU link. 292 The designated HO ODU overhead bytes (e.g., the GCC1 and GCC2 293 overhead bytes) can be used as the control channel to carry the LMP 294 message after the HO ODU link is created. The out-of-band Data 295 Communication Network (DCN) can also be used. 297 4.2.1. Message Extension 299 Three messages are used for link property correlation: LinkSummary, 300 LinkSummaryAck and LinkSummaryNack Message. This document does not 301 change the basic procedure of LMP but just add a new subobject (HO 302 ODU Link Capability) in the DATA_LINK object to carry the capability 303 of one end of a HO ODU link. 305 The formats of LinkSummary, LinkSummaryAck and LinkSummaryNack 306 messages are defined in [RFC4204]. 308 4.2.1.1. LinkSummary Message 310 The local end of a TE link can send a LinkSummary message to the 311 remote end to start the negotiation about the capability that the TE 312 link can support. 314 One new Subobject named HO ODU Link Capability Subobject in the 315 DATA_LINK object is introduced by this document. This new subobect is 316 used to tell the remote end of the HO ODU link which TS granularity 317 and which LO ODU signal types that the local end can support. When 318 the DATA_LINK object carries the new HO ODU Link Capability Subobject, 319 the N flag SHOULD be set to 1 which means that the subobject is 320 negotiable. 322 4.2.1.2. LinkSummaryAck Message 324 The LinkSummaryAck message is used to tell the remote end that it has 325 the same capability as the remote end after the LinkSummary message 326 is received by the local end. 328 4.2.1.3. LinkSummaryNack Message 330 The LinkSummaryNack message is used to tell the remote end that it 331 has different capability from the remote end after the LinkSummary 332 message is received by the local end. The LinkSummaryNack message 333 also carries the HO ODU Link Capability subobject in the DATA_LINK 334 object to tell the remote end the exact capability of the HO ODU link 335 after negotiation, i.e., the granularity of TS and the types of LO 336 ODU that both side of the HO ODU link can support. 338 4.2.2. Object Definitions 340 A new HO ODU Link Capability subobject type is introduced to the DATA 341 LINK object to carry the HO ODU link capability information. The 342 format of the new subobject is defined as follow: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | Length |OD(T)Uk| T | Reserved | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |A|B|C|D|E|F|G| LO ODU Flags | Reserved | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Type (8 bits): 354 The value of this subobject type is TBD. 356 Length (8 bits): 358 The Length field contains the total length of the subobject in bytes, 359 including the Type and Length fields. As for RFC 4204, the Length 360 MUST be at least 4, and MUST be a multiple of 4. Value of this field 361 is 8. 363 OD(T)Uk (4 bits): 365 This field is used to indicate the HO ODU link type (in case of LO 366 ODUj multiplexing into HO ODUk, wherein j | : received discovery message 771 | 773 | : received discovery message 775 | 777 | IP source address in the IP header 779 | 781 | identical to 782 | 784 | 786 | 788 The received TTI, more specifically the discovery message in the SAPI 789 field contains the and the . 790 These attributes are included in the discovery response message by 791 copying the received TTI into the field of the TraceMonitor 792 message. 794 The IP address of the node sending the discovery response message 795 corresponds to the and is the IP source address in 796 the IP header of the LMP TraceMonitor message. 798 Typically, the Trail Connection Point (TCP-)IDs in transmit and 799 receive direction are identical for OTN equipment, i.e., the is identical to the . The 801 identifies the TCP on which the Discovery Message was received and 802 corresponds to the object in the TraceMonitor 803 message. 805 7. LMP Behavior Negotiation Update 807 This docuemnt also introduces an update to the BehaviorConfig C-Type 808 defined in [LMP-NEG]. A new flag in the BehaviorConfig is needed for 809 the indication of the support for OTN Test Messages: 811 0 1 2 3 813 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |S|D|C|O| Must Be Zero (MBZ) | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 - O: 1 bit 823 This bit indicates support for the TEST behavior of OTN 824 technology-specific defined in this document. 826 8. Security Considerations 828 TBD. 830 9. IANA Considerations 832 TBD. 834 10. Acknowledgments 836 TBD. 838 11. References 840 11.1. Normative References 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, 846 October 2005. 848 [OTN-frwk] Zhang, F. et al, "Framework for GMPLS and PCE Control of 849 G.709 Optical Transport Networks", draft-ietf-ccamp- 850 gmpls-g709-framework-08.txt, June 19, 2012. 852 [ITUT-G709] ITU-T, "Interface for the Optical Transport Network 853 (OTN)", G.709 Recommendation, March 2003. 855 [G709-V3] ITU-T, "Interfaces for the Optical Transport Network 856 (OTN)", G.709 Recommendation, December 2009. 858 [ITUT-G.7714.1] ITU-T, "Protocol for automatic discovery in SDH and 859 OTN networks, G.7714.1 Recommendation", April 2003. 861 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 862 July 1994. 864 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 865 (GMPLS) Signaling Functional Description", RFC 3471, 866 January 2003. 868 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 869 (GMPLS) Architecture", RFC 3945, October 2004. 871 [RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical 872 Network (SONET)/Synchronous Digital Hierarchy (SDH) 873 Encoding for Link Management Protocol (LMP) Test 874 Messages", RFC 4207, October 2005. 876 11.2. Informative References 878 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 879 (GMPLS) Architecture", RFC 3945, October 2004. 881 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 882 Switching (GMPLS) Signaling Extensions for G.709 Optical 883 Transport Networks Control", RFC 4328, Jan 2006. 885 [LMP-NEG] D.Li, D.Ceccarelli, L.Berger, "Link Management Protocol 886 Behavior Negotiation and Configuration Modifications," July 887 2012, draft-ietf-ccamp-lmp-behavior-negotiation-06. 889 12. Authors' Addresses 891 Fatai Zhang 892 Huawei Technologies 893 F3-5-B R&D Center, Huawei Base 894 Bantian, Longgang District 895 Shenzhen 518129 P.R.China 897 Phone: +86-755-28972912 898 Email: zhangfatai@huawei.com 900 Xian Zhang 901 Huawei Technologies Co., Ltd. 902 F3-5-B R&D Center, Huawei Base, 903 Bantian, Longgang District 904 Shenzhen 518129 P.R.China 906 Phone: +86-755-28972913 907 Email: zhang.xian@huawei.com 909 Daniele Ceccarelli 910 Ericsson 911 Via A. Negrone 1/A 912 Genova - Sestri Ponente 913 Italy 915 Email: daniele.ceccarelli@ericsson.com 916 Diego Caviglia 917 Ericsson 918 Via A. Negrone 1/A 919 Genova - Sestri Ponente 920 Italy 922 Email: diego.caviglia@ericsson.com 924 Francesco Fondelli 925 Ericsson 926 Via Moruzzi 1 927 Pisa 928 Italy 930 Email: francesco.fondelli@ericsson.com 932 Guoying Zhang 933 China Academy of Telecommunication Research of MII 934 11 Yue Tan Nan Jie Beijing, P.R.China 936 Phone: +86-10-68094272 937 Email: zhangguoying@mail.ritt.com.cn 939 Pietro Grandi 940 Alcatel-Lucent 941 Optics CTO 942 Via Trento 30 20059 Vimercate (Milano) Italy 943 +39 039 6864930 945 Email: pietro_vittorio.grandi@alcatel-lucent.it 947 Sergio Belotti 948 Alcatel-Lucent 949 Optics CTO 950 Via Trento 30 20059 Vimercate (Milano) Italy 951 +39 039 6863033 953 Email: sergio.belotti@alcatel-lucent.it 955 Dan Li 956 Huawei Technologies 957 F3-5-B R&D Center, Huawei Base 958 Shenzhen 518129 P.R.China Bantian, Longgang District 959 Phone: +86-755-28973237 961 Email: danli@huawei.com 963 Dieter Beller 964 Alcatel-Lucent 965 Lorenzstrasse 10 966 Stuttgart 70435 967 Germany 969 Email: dieter.beller@alcatel-lucent.com 971 13. Contributors 973 Yi Lin 974 Huawei Technologies Co., Ltd. 975 F3-5-B R&D Center, Huawei Base, 976 Bantian, Longgang District 977 Shenzhen 518129 P.R.China 979 Phone: +86-755-28972914 980 Email: yi.lin@huawei.com 982 Intellectual Property 984 The IETF Trust takes no position regarding the validity or scope of 985 any Intellectual Property Rights or other rights that might be 986 claimed to pertain to the implementation or use of the technology 987 described in any IETF Document or the extent to which any license 988 under such rights might or might not be available; nor does it 989 represent that it has made any independent effort to identify any 990 such rights. 992 Copies of Intellectual Property disclosures made to the IETF 993 Secretariat and any assurances of licenses to be made available, or 994 the result of an attempt made to obtain a general license or 995 permission for the use of such proprietary rights by implementers or 996 users of this specification can be obtained from the IETF on-line IPR 997 repository at http://www.ietf.org/ipr 998 The IETF invites any interested party to bring to its attention any 999 copyrights, patents or patent applications, or other proprietary 1000 rights that may cover technology that may be required to implement 1001 any standard or specification contained in an IETF Document. Please 1002 address the information to the IETF at ietf-ipr@ietf.org. 1004 The definitive version of an IETF Document is that published by, or 1005 under the auspices of, the IETF. Versions of IETF Documents that are 1006 published by third parties, including those that are translated into 1007 other languages, should not be considered to be definitive versions 1008 of IETF Documents. The definitive version of these Legal Provisions 1009 is that published by, or under the auspices of, the IETF. Versions of 1010 these Legal Provisions that are published by third parties, including 1011 those that are translated into other languages, should not be 1012 considered to be definitive versions of these Legal Provisions. 1014 For the avoidance of doubt, each Contributor to the IETF Standards 1015 Process licenses each Contribution that he or she makes as part of 1016 the IETF Standards Process to the IETF Trust pursuant to the 1017 provisions of RFC 5378. No language to the contrary, or terms, 1018 conditions or rights that differ from or are inconsistent with the 1019 rights and licenses granted under RFC 5378, shall have any effect and 1020 shall be null and void, whether published or posted by such 1021 Contributor, or included with or in such Contribution. 1023 Disclaimer of Validity 1025 All IETF Documents and the information contained therein are provided 1026 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1027 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1028 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1029 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1030 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1031 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1032 FOR A PARTICULAR PURPOSE. 1034 Full Copyright Statement 1036 Copyright (c) 2012 IETF Trust and the persons identified as the 1037 document authors. All rights reserved. 1039 This document is subject to BCP 78 and the IETF Trust's Legal 1040 Provisions Relating to IETF Documents 1041 (http://trustee.ietf.org/license-info) in effect on the date of 1042 publication of this document. Please review these documents 1043 carefully, as they describe your rights and restrictions with respect 1044 to this document. Code Components extracted from this document must 1045 include Simplified BSD License text as described in Section 4.e of 1046 the Trust Legal Provisions and are provided without warranty as 1047 described in the Simplified BSD License.