Network Working Group D.Ceccarelli Internet Draft D.Caviglia Category: Standards Track Ericsson Fatai Zhang Dan Li Huawei Expires: April 2010 October 16, 2009 Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN Networks draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 24, 2010. Abstract This document describes OSPF routing protocol extensions to support the evolutive Optical Transport Networks (OTN) under the control of Generalized MPLS (GMPLS). zhang Expires April 2010 [Page 1] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Overview of the Evolutive G.709...............................3 4. G.709 Digital Layer TE Information............................5 4.1. Tributary Slot type......................................5 4.2. TE link type.............................................6 4.3. LO ODU signal type.......................................6 4.4. TE link Total Bandwidth..................................7 4.5. TE link Unreserved Bandwidth.............................7 4.6. Maximum LSP Bandwidth....................................7 5. OSPF extensions...............................................8 5.1. Extensions to Interface Switching Capability Descriptor..8 6. Compatibility Considerations.................................11 7. Example......................................................11 8. Security Considerations......................................13 9. IANA Considerations..........................................13 10. Acknowledgments.............................................13 11. References..................................................13 11.1. Normative References...................................13 11.2. Informative References.................................14 12. Authors' Addresses..........................................14 13. Contributors................................................15 1. Introduction Per OSPF, an Opaque LSA (Link State Advertisements) carrying application-specific information can be generated and advertised to other nodes following the flooding mechanism defined in [RFC 2370]. Three types of opaque LSA are defined, i.e. type 9 - link-local flooding scope, type 10 - area-local flooding scope, type 11 - AS flooding scope. Traffic Engineering (TE) LSA using type 10 of opaque LSA is defined in [RFC 3630] for TE purpose. This type of LSA is composed of a standard LSA header and a payload including one top-level TLV (Type/Length/Value triplet) and possible several nested sub-TLVs. Ceccarelli Expires April 2010 [Page 2] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 RFC [3630]defines two top-level TLVs: Router Address TLV and Link TLV; and nine possible sub-TLVs for the Link TLV, used to carry link related TE information. The Link type sub-TLVs are enhanced by [RFC 4203] in order to support GMPLS networks and related specific link information. In GMPLS networks, each node generates TE LSAs to advertise its TE information and capabilities (link-specific, or node-specific), through the network. The TE information carried in the LSAs are collected by the other nodes of the networks and stored into their local Traffic Engineering Databases (TED). In the GMPLS based G.709 Optical Transport Networks (OTNs), in order to automatically establish ODUk connections through GMPLS RSVP-TE signaling, routing is the foundation. OTN networks provide flexible and various multiplexing relationships (e.g., ODUj multiplexed into ODUk (j j) signal can be depicted as follows: - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS granularity) - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with 1.25Gbps TS granularity) - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing (with 1.25Gbps TS granularity) - ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity) - ODU2e into ODU3e2 multiplexing (with 1.25Gbps TS granularity) Ceccarelli Expires April 2010 [Page 4] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 In order to be backward compatible with the 2.5Gbps TS defined in [G709-V3], both the 2.5Gbps TS and the 1.25Gbps TS can be used in the two cases listed below: o ODU1 into ODU2 multiplexing o ODU1 and ODU2 into ODU3 multiplexing From the link perspective, it can only work under one TS type. For example, if the both ends (or interfaces) of the link can support 2.5Gbps TS and 1.25Gbps TS, then it will work under 2.5Gbps TS or 1.25Gbps TS. If one end can support 1.25Gbps TS, and another end can support 2.5Gbps TS, the end with 1.25Gbps TS MUST adopt a 2.5Gbps TS). 4. G.709 Digital Layer TE Information This document only considers the TE information needed for LO ODU path computation. WSON TE information is out of scope. Please refer to [WSON-OSPF] for more information about WSON routing information. From the perspective of [G709-V3], there are two types of LO ODU: (1) A LO ODUk mapped into an OTUk. In this case, the server layer of this LO ODU is an OTUk. For example, if a STM-16 signal is encapsulated into ODU1, and then ODU1 is mapped into OTU1, the ODU1 is LO ODU. (2) A LO ODUj multiplexed into a HO (Higher Order) ODUk (j < k) occupying several TSs. In this case, the server layer of this LO ODU is a HO ODUk. For example, if ODU1 is multiplexed into ODU2, and ODU2 is mapped into OTU2, the ODU1 is LO ODU and ODU2 is HO ODU. In order to compute a suitable path the PCE (centralized or distributed) need a set of data that should be advertised by the routing protocol. In the following sections each type of data is listed and analyzed, while the possible values are shown in section 5. 4.1. Tributary Slot type There are two types of TS defined in the ITU-T recommendations, and from the link perspective, it can only work under one TS type. For example, if the both ends (or interfaces) of a link can support 2.5Gbps TS or 1.25Gbps TS, then it will work under 2.5Gbps TS or 1.25Gbps TS. If one end can support 1.25Gbps TS, and another end can support 2.5Gbps TS, the end with 1.25Gbps TS should adopt the 2.5Gbps TS). Ceccarelli Expires April 2010 [Page 5] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 In addition, the bandwidth accounting depends on the type of TS. Therefore, the type of the TS should be known during LO ODU path computation. 4.2. TE link type The link type indicates the OTUk/HO ODUk type of the TE link. The TS bandwidth of different types of OTUk is different. The TS bandwidth in an OTUk is inreaseing along with the increasing of k (see [G709-V3]). The bandwidth of a TS in a TE link can be deduced from the TS type and link type of the TE link. For example, the bandwidth of a 1.25G TS without NJO (Negative Justification Opportunity) in an OTU2 is about 1.249409620 Gbps, while the bandwidth of a 1.25G TS without NJO in an OTU3 is about 1.254703729 Gbps. The actual TS bandwidth of a TE link is useful to determine the TS number needed by an ODUflex service. And the actual TS bandwidth of a TE link can be deduced by the TE link type and TS type. In the case of link bundling, only the component links with the same TS type and TE link type can be bundled together. 4.3. LO ODU signal type It is possible that some equipment can not always support all the LO ODU signal types. When a path computation procedure for a LO ODU is performed, it needs to check whether a link has the capability to carry a specific type of LO ODU or not. If a link can not carry this type of LO ODU, it should be excluded during the path computation. Only the links with the capability of carrying this type of LO ODU can be the candidates. For example, in the following figure, the interfaces IF1, IF2, IF8, IF7, IF5 and IF6 can support ODUflex signals, while the interfaces IF3 and IF4 can not support ODUflex signals. In this case, if one ODUflex connection from A to C is requested, link #1 and #2 are excluded, link #3 and link #4 are the candidates (the possible path could be A-D-C through link #3 and link #4). Ceccarelli Expires April 2010 [Page 6] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 +-----+ link #3 | | link #4 +-----------------+ D +-----------------+ | IF8| |IF7 | | +-----+ | | | |IF1 IF6| +--+--+ +-----+ +--+--+ | | link #1 | | link #2 | | | A +--------------+ B +--------------+ C | | |IF2 IF3| |IF4 IF5| | +-----+ +-----+ +-----+ Therefore, it is necessary to advertise the LO ODU types that the OTU or HO ODU TE link can support. 4.4. TE link Total Bandwidth For an unbundled link, the Total Bandwidth is dependent on the type of the OTU or HO ODU, while in case of link bundling, the Total Bandwidth is the sum of the total bandwidth of all the physical links composing the TE link. For a specific OTUk or HO ODUk TE link, the Total Bandwidth can be deduced through the total number of the Tributary Slots. For example, an unbundled OTU4 link has 80 Tributary Slots with 1.25Gbps. If two component OTU4 links are bundled, the TE link has 160 Tributary Slots with 1.25Gbps. 4.5. TE link Unreserved Bandwidth In the GMPLS based OTN networks, the Unreserved Bandwidth of a TE link is the sum of the unreserved bandwidths of all the component links associated with the bundled link. The unreserved bandwidth can be accounted through the unallocated Tributary Slots of the TE link. 4.6. Maximum LSP Bandwidth The Maximum Bandwidth that a LSP can occupy in a TE link is determined by the component link with the maximum unreserved bandwidth in this TE link. For example, if two OTU3 component links are bundled to a TE link, the unreserved bandwidth of the first component link is 20*1.25G TSs, and the unreserved bandwidth of the second component link is 24*1.25G Ceccarelli Expires April 2010 [Page 7] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 TSs. Then the unreserved bandwidth of this TE link is 44*1.25G TSs, but the maximum TSs that a LSP can occupy in this TE link is 24, not 44. 5. OSPF extensions In terms of GMPLS based OTN networks, each OTUk/HO ODUk can be viewed as a component link, and each component link can carry one or more types of LO ODU. One or more component links with the same attributes can be bundled as a TE link (see [RFC 4201] for link bundling). Each TE LSA can carry a top-level TLV with several nested sub-TLVs to describe different attributes of a TE link. Two top-level TLVs are defined in [RFC 3630]. (1) The Router Address TLV (referred to as the Node TLV) and (2) the TE link TLV. One or more sub-TLVs can be nested into the two top-level TLVs. The sub-TLV set for the two top-level TLVs are also defined in [RFC 3630] and [RFC 4203]. A general Interface Switching Capability Descriptor (ISCD) sub-TLV is defined In [RFC 4203]. The bandwidth accounting is encoded in a 4 octets field in the IEEE floating point format. Max LSP Bandwidth is accounted at each priority X (0~7). To keep the minor changes on the existing routing protocol, the routing procedures and the TLVs defined in the existing standard documents, such as [RFC 3630] and [RFC 4203] should be reused as possible. Therefore, OTN specific routing information can be simply carried in the "Switching Capability-specific information" of ISCD defined in [RFC 4203]. The routing procedures are the same as [RFC 3630] and [RFC 4203]. 5.1. Extensions to Interface Switching Capability Descriptor The Interface Switching Capability Descriptor is defined as follows. Ceccarelli Expires April 2010 [Page 8] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A new type of Switching Cap is introduced to distinguish the evolutive OTN and the existing TDM networks (e.g., SDH networks). The new Switching Cap type is defined in the following: 110 Evolved OTN (Digital Wrapper layer of G.709) When the Switching Capability field is evolved OTN, the Max LSP Bandwidth at priority x is counted by TS number. When the Switching Capability field is evolved OTN, the Switching Capability specific information field includes OTN Specific Information, which shows in the following: Ceccarelli Expires April 2010 [Page 9] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res| T |OD(T)Uk| Reserved | Signal Flags |G|F|E|D|C|B|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv. | Total TS | Resv. | Unreserved TS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type of this sub-TLV is TBD. The length of this TLV is eight octets. o T bits (2 bits): Indicates the type of the Tributary Slot of this TE link, value 0 means the TS type is 1.25Gbps, value 1 means the TS type is 2.5Gbps. o OD(T)Uk (4 bits): Indicates the type of the TE link, i.e. the server layer signal that the LO ODUs can be mapped or multiplexed into. The following values are defined: 0: Reserved (for future use) 1: OTU1/HO ODU1 2: OTU2/HO ODU2 3: OTU3/HO ODU3 4: OTU4/HO ODU4 5: OTU2e/HO ODU2e 6: HO ODU3e1 7: HO ODU3e2 8-15: Reserved (for future use) Note that an ODU3e1/ODU3e2 must carry several LO ODUs, non-OTN signals can not be mapped into ODU3e1/ODU3e2 directly. So ODU3e1/ODU3e2 can not be a LO ODU, and OTU3e1/OTU3e2 can not be a server layer for LO ODU. The bandwidth of a TS in this TE link can be deduced from T bit and OD(T)Uk field. Ceccarelli Expires April 2010 [Page 10] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 o Signal Flags (16 bits): This field indicates the LO ODU type supported by the TE link. A flag set to 1 indicates that the TE link supports the corresponding LO ODU signal. Currently the following flags are defined: Flag A: indicates whether LO ODU0 is supported. Flag B: indicates whether LO ODU1 is supported. Flag C: indicates whether LO ODU2 is supported. Flag D: indicates whether LO ODU3 is supported. Flag E: indicates whether LO ODU4 is supported. Flag F: indicates whether LO ODU2e is supported. Flag G: indicates whether LO ODUflex is supported. Other bits are reserved and must be set to zero when sent and should be ignored when received. o Total TS (12 bits): Indicates the total TS number of the TE link. o Unreserved TS (12 bits): Indicates the number unreserved TS in the TE link. When a node receives a LSA with Switching Capability type 110, the Maximum Bandwidth sub-TLV and Unreserved Bandwidth sub-TLV in this LSA SHOULD be ignored if they exist, the bandwidth information MUST be deduced from ISCD sub-TLV (i.e., Total TS, Unreserved TS). All the reserved fields must be set to zero and should be ignored when received. 6. Compatibility Considerations The legacy nodes that do not implement the extensions defined in this document are able to ignore the LSA containing an ISCD sub-TLV with the Switching Cap type 110, because it is an unknown value. They will continue to flood the LSA to other neighbors, but will not use the information carried in this LSA. 7. Example Based on the sub-TLVs defined in [RFC 3630], [RFC 4203] and this document, a G.709 digital TE link can be described as follows. Ceccarelli Expires April 2010 [Page 11] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 +------+ component link 1 +------+ | +------------------+ | | N1 +------------------+ N2 | | | component link 2 | | +--+---+ +---+--+ This picture shows a simple example of an OTN network. Both the link type of the two component links are OTU3 and both of the two component links have the capability of carrying ODU0, ODU1, ODU2 and ODUflex client signals. The TS type is 1.25Gbps, the number of the total Tributary Slots is 32. The two component links have the same nature, so the two component links can be bundled as a TE link. It is also feasible that each component link can be regarded as a TE link separately. If the two component links are bundled together, N1 and N2 should assign a link local ID to the TE link. Then N1 can get the link remote ID automatically or manually. N1 can generate an LSA to describe the above attributes of the TE link. Suppose the link IDs are unnumbered, the LSA should carry a link TLV with the following nested minimal sub-TLVs: < G.709 Digital Link > ::= < Link Type > < Link ID > < Link Local/Remote Identifiers > < Interface Switching Capability Descriptor > o Link Type sub-TLV: Defined in [RFC 3630], G.709 digital links are always type 1 - Point-to-point link. o Link ID sub-TLV: Defined in [RFC 3630], for point-to-point link, indicates the remote router ID. o Link Local/Remote Identifiers sub-TLV: Defined in [RFC 4203], indicates the local link ID and the remote link ID. o Interface Switching Capability Descriptor sub-TLV: Defined in this document, carries the characteristic of this G.709 digital TE link. Suppose the unreserved TS number of component link 1 is 20, and the unreserved TS number of component link 2 is 28. Also Suppose the Max LSP Bandwidth at priority 0 of component link 1 is 10 TSs, and the Max LSP Bandwidth at priority 0 of component link 2 is 18 TSs. Ceccarelli Expires April 2010 [Page 12] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 The ISCD sub-TLV in this LSA will carry the above attributes, i.e. the value of T bits is 1, OD(T)Uk bits is 3, total TS field is 64, Unreserved TS field is 48, Max LSP Bandwidth at priority 0 field is 18 TSs, and A/B/C/G bits are set to indicate the types of LO ODU that this TE link can carry. When another node receives this LSA, it can determine that this TE link can carry ODU0, ODU1, ODU2, ODUflex signals. The TS type is 1.25G, and the real bandwidth of TS is about 1.254703729 Gbps. An ODUflex signal at priority 0 can occupy 18 TS at most in this TE link. If an ODU0 (priority 0) path computation is performed, this TE link is a candidate. If a 40G ODUflex (priority 0) path computation is performed, this TE link should be excluded, because this ODUflex signal needs more than 18 TSs. 8. Security Considerations TBD. 9. IANA Considerations TBD. 10. Acknowledgments TBD. 11. References 11.1. Normative References [RFC 2370] R. Coltun, "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC 3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC 4201] K. Kompella, Y. Rekhter, L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC 4203] K. Kompella, Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. Ceccarelli Expires April 2010 [Page 13] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", work in progress: draft-ietf-ccamp-rwa-WSON- Framework-02.txt, March 2009. [WSON-OSPF] Fatai Zhang, Y. Lee, etc., " OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) ", work in progress: draft-zhang-ccamp-rwa-wson-routing-ospf-01.txt, July 2009. 11.2. Informative References [Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement)", December 2008. [G709] ITU-T G.709 Recommendation, Interface for the Optical Transport Network (OTN) ITU-T, March 2003. [G709-v3] ITU-T, "Draft revised G.709, version 3", consented by ITU-T on Oct 2009. 12. Authors' Addresses Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Ceccarelli Expires April 2010 [Page 14] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: zhangfatai@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972910 Email: danli@huawei.com 13. Contributors Xiaobing Zi Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973229 Email: zixiaobing@huawei.com Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Ceccarelli Expires April 2010 [Page 15] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Ceccarelli Expires April 2010 [Page 16]