CCAMP Working Group D. Ceccarelli Internet-Draft D. Caviglia Intended status: Standards Track Ericsson Expires: September 15, 2011 F. Zhang D. Li Huawei Technologies Y. Xu CATR S. Belotti P. Grandi Alcatel-Lucent R. Rao Infinera Corporation J. Drake Juniper March 14, 2011 Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks draft-ceccarelli-ccamp-gmpls-ospf-g709-05 Abstract The recent revision of ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and flexible ODU containers, enabling optimized support for an increasingly abundant service mix. This document describes OSPF routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Ceccarelli, et al. Expires September 15, 2011 [Page 1] Internet-Draft OSPF-TE extensions for OTN support March 2011 This Internet-Draft will expire on September 15, 2011. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Ceccarelli, et al. Expires September 15, 2011 [Page 2] Internet-Draft OSPF-TE extensions for OTN support March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. ISCD extensions . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Unreserved Bandwidth sub-sub-TLV . . . . . . . . . . . 5 2.2. IMCD - Interface Multiplexing Capability Descriptor . . . 6 2.2.1. IMCD Bandwidth sub-sub-TLV . . . . . . . . . . . . . . 7 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. ODUk advertisement . . . . . . . . . . . . . . . . . . . . 10 3.2. ODUj advertisement . . . . . . . . . . . . . . . . . . . . 10 3.3. Link Bundling . . . . . . . . . . . . . . . . . . . . . . 10 4. Optimization considerations . . . . . . . . . . . . . . . . . 11 4.1. Efficient priorities advertisement . . . . . . . . . . . . 11 4.2. Efficient bandwidth encoding . . . . . . . . . . . . . . . 12 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Ceccarelli, et al. Expires September 15, 2011 [Page 3] Internet-Draft OSPF-TE extensions for OTN support March 2011 1. Introduction G.709 OTN [G709-V3] includes new fixed and flexible ODU containers, two types of Tributary Slots (i.e., 1.25Gbps and 2.5Gbps), and supports various multiplexing relationships (e.g., ODUj multiplexed into ODUk (jODUk format is used to indicate the ODUj into ODUk multiplexing capability. The advertisement of available bandwidth, max LSP bandwidth and multiplexing capabilities is performed as follows: - ODUk(S) advertised in the ISCD - ODUk(T) advertised in the IMCD (Interface Multiplexing Capability Descriptor) - ODUk(T,S) advertised both in the ISCD and IMCD - ODUj(*) and related multiplexing hierarchy advertised in the IMCD The IMCD and new sub-sub-TLVs format are illustrated in the following sections. 2.1. ISCD extensions This document defines a new Switching Capability value Value Type ----- ---- 101 OTN-TDM while the values of the Encoding Type field are the ones defined in [RFC4328]. 2.1.1. Unreserved Bandwidth sub-sub-TLV The Unreserved bandwidth sub-sub-TLV is included into the SCSI (Switching Capability Specific Information) of the ISCD. It is used for the advertisement of ODUk(S) unreserved bandwidth. Please note that there is no need to advertise MAX LSP bandwidth within the ISCD because the only container with variable bandwidth (ODUflex) can be Ceccarelli, et al. Expires September 15, 2011 [Page 5] Internet-Draft OSPF-TE extensions for OTN support March 2011 an ODUj only. The format of the Unreserved Bandwidth sub-sub-TLV is shown in the following figure. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Available ODUk priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Unreserved Bandwidth sub-sub-TLV format - Type: Type = 1 indicates Unreserved Bandwidth sub-sub-TLV. i.e. advertising Unreserved Bandwidth for ODUk containers. - Lengths: Expressed in Bytes and aligned to 32bits. - Number of Available ODUk at Priority Px: Indicates the number of Available ODUk al Priority Px that can be Switched in the advertised TE Link. 2.2. IMCD - Interface Multiplexing Capability Descriptor The Interface Multiplexing Capability Descriptor (IMCD) is a new Link type sub-TLV (Type TBA by IANA) and is used for the advertisement of: - ODUk Termination Unreserved Bandwidth - ODUj Switching and Termination Unreserved Bandwidth with related muxing hierarchy Ceccarelli, et al. Expires September 15, 2011 [Page 6] Internet-Draft OSPF-TE extensions for OTN support March 2011 - ODUj Switching and Termination MAX LSP Bandwidth with related muxing hierarchy 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-sub-TLVs | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IMCD sub-TLV format - Type: To be assigned by IANA. - Length: Expressed in Bytes and aligned to 32bits. - Sub-sub-TLVs: The body of the IMCD can include a variable number of sub-sub-TLVs. 2.2.1. IMCD Bandwidth sub-sub-TLV This document defines three types of IMCD Unreserved Bandwidth sub- sub-TLVs: - Type = 1, advertising the Unreserved Bandwidth of fixed bandwidth containers (e.g. ODU2,ODU3) - Type = 2, advertising the Unreserved Bandwidth of variable bandwidth containers (e.g. ODUFlex) - Type = 3, advertising the MAX LSP Bandwdith of variable bandwidth containers (e.g. ODUFlex) The format is shown in figure below: Ceccarelli, et al. Expires September 15, 2011 [Page 7] Internet-Draft OSPF-TE extensions for OTN support March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | G-PID |T|S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwdith at Priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IMCD Bandwidth sub-sub-TLV format The rest of the sub-sub-TLV fields is defined as follows: - Length: Expressed in Bytes and aligned to 32bits. - G-PID: Defines new values in addition to those already defined in RFC3471] and identifies the muxing hierarchy supported by a component link. Ceccarelli, et al. Expires September 15, 2011 [Page 8] Internet-Draft OSPF-TE extensions for OTN support March 2011 Value G-PID ----- ------ 100 ODU1 101 ODU2 102 ODU3 103 ODU4 104 ODU1->ODU0 105 ODU2->ODU0 106 ODU2->ODU1 107 ODU2->ODU1->ODU0 108 ODU2->ODUflex 109 ODU3->ODU0 110 ODU3->ODU1 111 ODU3->ODU1->ODU0 112 ODU3->ODU2 113 ODU3->ODU2->ODU0 114 ODU3->ODU2->ODU1 115 ODU3->ODU2->ODU1->ODU0 116 ODU3->ODU2->ODUflex 117 ODU3->ODUflex 118 ODU3->ODU2e 119 ODU4->ODU0 120 ODU4->ODU1 121 ODU4->ODU1->ODU0 122 ODU4->ODU2 123 ODU4->ODU2->ODU0 124 ODU4->ODU2->ODU1 125 ODU4->ODU2->ODU1->ODU0 126 ODU4->ODU2->ODUflex 127 ODU4->ODU3 128 ODU4->ODU3->ODU0 129 ODU4->ODU3->ODU1 130 ODU4->ODU3->ODU1->ODU0 131 ODU4->ODU3->ODU2 132 ODU4->ODU3->ODU2->ODU0 133 ODU4->ODU3->ODU2->ODU1 134 ODU4->ODU3->ODU2->ODU1->ODU0 135 ODU4->ODU3->ODU2->ODUflex 136 ODU4->ODU3->ODUflex 137 ODU4->ODU3->ODU2e 138 ODU4->ODUflex 139 ODU4->ODU2e - Flags: T,S flags are used to indicate Termination and Switching capabilities of the ODUj containers and MUST be set to 0 and ignored in case of ODUk. Ceccarelli, et al. Expires September 15, 2011 [Page 9] Internet-Draft OSPF-TE extensions for OTN support March 2011 - Unreserved Bandwidth: Indicates the Unreserved bandwidth of the container being advertised. It MUST be expressed in Number of Available containers in case of fixed containers (i.e. Type=1) and in IEEE floating point in case of variable bandwidth containers (i.e. Type=2). 3. Procedures 3.1. ODUk advertisement The advertisement of ODUk is performed via ISCD, IMCD or both, depending on the terminating and switching capabilities of the given ODUk. In case of ODUk(S), its unreserved bandwidth MUST be advertised by means of the Unreserved Bandwidth sub-sub-TLV included into the ISCD. One ISCD for each ODUk(S) is advertised. On the other hand, an ODUk(T) MUST be advertised via the Bandwidth sub-sub-TLV included into the IMCD. Multiple ODUk(T) MAY be advertised withing the same IMCD. In the case of ODUk(T,S), the advertisement of such ODUk MUST be present both in the ISCD and the IMCD. 3.2. ODUj advertisement The advertisement of ODUj MUST be performed via IMCD only and its terminating and switching capabilities are specified by the flags (T and S) of the Bandwidth sub-sub-TLV. Unreserved and MAX LSP bandwidth are advertised by means of different types of the Bandwdith sub-sub-TLV as shown in Section 2.2.1. The advertisement of ODUj(S) is not performed via ISCD because the ISCD does not provide the means for distinguishing between ODUj and ODUk and this would prevent the bundling of interfaces at different line rates. 3.3. Link Bundling It is possible to bundle different interfaces with different line rates, muxing hierarchies and termination/switching capabilities except the case in which the end nodes of a TE link have ODUk at the same line rate but different terminating/switching capabilities or muxing hierarchies. An example of this exemption is shown in figure below: Ceccarelli, et al. Expires September 15, 2011 [Page 10] Internet-Draft OSPF-TE extensions for OTN support March 2011 +------+ link A +------+ | A1+------------------+A2 | | N1 B1+------------------+B2 N2 | | | link B | | +--+---+ +---+--+ Figure 4: Bundling not allowed In case link A has interface A1 supporting ODUk (T) and A2 supporting OUDk(S) and link B with interface B1 supporting the same ODUk(S) and B2 supporting ODUk(T), the bundling of the two links in a single TE link would give the false information of ODUk(S) availability at the ends of the TE link. Hence, link A and link B cannot be bundled into the same TE link. 4. Optimization considerations Optimization considerations are extremely important not only under the scalability point of view but also considering the requirement that an LSA (Link State Advertisement) cannot be fragmented into multiple IP packets. Considering that in a conforming Ethernet environment the Frame_MTU is 1500 bytes, the amount of available bandwidth for the LSA payload is 1432 byte. (1500 byte - (IP header 20bytes + OSPF header 28bytes + LSA header 20 bytes)). IP packets fragmentation is not suggested in IPv4-IPv6 as it has a big impact on computation efficiency and CPU processing time. 4.1. Efficient priorities advertisement Actual GMPLS definition foresees the advertisement of all the eight possible priorities. This is an inefficient approach in terms of bandwidth utilization in those cases where not all the priorities are supported. A possible enhancement consists on inserting an 8 bits bitmask identifying the supported priorities being advertised. The bitmask can be applied to the Unreserved Bandwidth sub-sub-TLV of the ISCD and to the Bandwidth sub-sub-TLV of the IMCD. The following figure shows an example of bitmask application to the Bandwidth sub- sub-TLV in the advertisemnt of the MAX LSP bandwidth of a given service type: Ceccarelli, et al. Expires September 15, 2011 [Page 11] Internet-Draft OSPF-TE extensions for OTN support March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | G-PID |T|S| |1|0|0|1|0|0|0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth at Priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth at Priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth at Priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Efficient priorities advertisement Only priorities 0,3 and 7 are supported and hence advertised. In this simple example the amount of bytes saved is 20, but in a scenario with traffic cards supporting a high number of service types and muxing hierarchies, the amount of saved bandwidth is meaningful. 4.2. Efficient bandwidth encoding When a fixed bandwidth service type is advertised, the number of available service types is used as measurement units. This can be esaily advertised via a 16 bits field instead of 32 bits (needed for IEEE floating point encoding). When the number of supported priorities is odd, padding to multiples of 32 bits is required. The following figure shows an example of Unreserved Bandwidth advertisement via Bandwidth sub-sub-TLV with 3 priorities supported and padding. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | G-PID |T|S| |1|0|0|1|0|0|0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth at Priority 0 | Bandwidth at Priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth at Priority 7 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Efficient bandwidth encoding Ceccarelli, et al. Expires September 15, 2011 [Page 12] Internet-Draft OSPF-TE extensions for OTN support March 2011 5. Example TBD 6. Compatibility Backwards compatibility with implementations based on [RFC4328] can be achieved advertising the [RFC4328] based ISCDs in addition to the ISCD defined in this document. 7. Security Considerations This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an effect on the underlying transport (optical and/or SONET-SDH) network. [RFC3630] suggests mechanisms such as [RFC2154] to protect the transmission of this information, and those or other mechanisms should be used to secure and/or authenticate the information carried in the Opaque LSAs. 8. IANA Considerations TBD 9. Contributors Xiaobing Zi, Huawei Technologies Email: zixiaobing@huawei.com Francesco Fondelli, Ericsson Email: francesco.fondelli@ericsson.com Marco Corsi, Altran Italia EMail: marco.corsi@altran.it Ceccarelli, et al. Expires September 15, 2011 [Page 13] Internet-Draft OSPF-TE extensions for OTN support March 2011 Eve Varma, Alcatel-Lucent EMail: eve.varma@alcatel-lucent.com Jonathan Sadler, Tellabs EMail: jonathan.sadler@tellabs.com Lyndon Ong, Ciena EMail: lyong@ciena.com Ashok Kunjidhapatham akunjidhapatham@infinera.com Snigdho Bardalai sbardalai@infinera.com Khuzema Pithewan kpithewan@infinera.com Steve Balls Steve.Balls@metaswitch.com Xihua Fu fu.xihua@zte.com.cn Ceccarelli, et al. Expires September 15, 2011 [Page 14] Internet-Draft OSPF-TE extensions for OTN support March 2011 10. Acknowledgements The authors would like to thank Eric Gray for his precious comments and advices. 11. References 11.1. Normative References [MLN-EXT] D.Papadimitriou, M.Vigoureux, K.Shiomoto, D.Brungard, J.Le Roux, "Generalized Multi-Protocol Extensions for Multi- Layer and Multi-Region Network (MLN/MRN)", February 2010. [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport networks, work in progress draft-ietf-ccamp-gmpls-g709-framework-02", July 2010. [OTN-INFO] S.Belotti, P.Grandi, D.Ceccarelli, D.Caviglia, F.Zhang, D.Li, "Information model for G.709 Optical Transport Networks (OTN), work in progress draft-bddg-ccamp-otn-g709-info-model-01", October 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. Ceccarelli, et al. Expires September 15, 2011 [Page 15] Internet-Draft OSPF-TE extensions for OTN support March 2011 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 5339, September 2008. 11.2. Informative References [G.709] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation (and Amendment 1), February 2001. [G.709-v3] ITU-T, "Draft revised G.709, version 3", consented by ITU-T on Oct 2009. [Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement)", December 2008. 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 Ceccarelli, et al. Expires September 15, 2011 [Page 16] Internet-Draft OSPF-TE extensions for OTN support March 2011 Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28972912 Email: zhangfatai@huawei.com Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28973237 Email: danli@huawei.com Yunbin Xu CATR 11 Yue Tan Nan Jie Beijing P.R.China Email: xuyunbin@mail.ritt.com.cn Sergio Belotti Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: sergio.belotti@alcatel-lucent.com Pietro Vittorio Grandi Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: pietro_vittorio.grandi@alcatel-lucent.com Ceccarelli, et al. Expires September 15, 2011 [Page 17] Internet-Draft OSPF-TE extensions for OTN support March 2011 Rajan Rao Infinera Corporation 169, Java Drive Sunnyvale, CA-94089 USA Email: rrao@infinera.com John E Drake Juniper Email: jdrake@juniper.net Ceccarelli, et al. Expires September 15, 2011 [Page 18]