Network Working Group L. Ong Internet-Draft Ciena Intended status: Informational R. Theillaud Expires: April 21, 2010 Marben Products October 18, 2009 Implementation Experience with OSPFv2 Extensions for ASON Routing draft-ong-gmpls-ason-routing-exper-00 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 April 21, 2010. Abstract IETF CCAMP WG has defined a set of extensions to OSPFv2 to support ASON routing requirements. These extensions have been given EXP status rather than Standards Track and according to guidelines for OSPFv2 have not been allocated standard codepoints by IANA. This draft describes implementation and interoperability testing experiences with ASON routing extensions to OSPFv2 which provide equivalent routing functionality to the extensions defined in IETF CCAMP with some differences in formatting of the extensions. This summary of implementation and testing is provided to help move Ong & Theillaud Expires April 21, 2010 [Page 1] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 ASON Routing extensions for OSPF to Standards Track. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Review of ASON Routing draft . . . . . . . . . . . . . . . 3 2.2. Tested IPv4 Reachability Advertisement . . . . . . . . . . 4 3. Link Attributes . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Review of ASON Routing draft . . . . . . . . . . . . . . . 4 3.2. Bandwidth Accounting for ITU-T SONET/SDH Layers . . . . . 4 3.2.1. SONET/SDH-specific connection availability . . . . . . 5 4. Routing Information Scope . . . . . . . . . . . . . . . . . . 7 4.1. Review of ASON Routing Draft . . . . . . . . . . . . . . . 7 4.2. Link Advertisement (Local and Remote TE Router ID sub-TLVs) . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Reachability Advertisement (Local TE Router ID sub-TLV) . 8 4.4. New Reachable Address top-level TLV . . . . . . . . . . . 9 5. Routing Information Dissemination . . . . . . . . . . . . . . 10 6. Implementation and Testing Results . . . . . . . . . . . . . . 10 6.1. Standardization . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Ong & Theillaud Expires April 21, 2010 [Page 2] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 1. Introduction This draft presents results of interoperability testing on the part of the authors and others that have been involved in understanding and prototyping routing for ASON as part of the OIF (Optical Internetworking Forum). Some of the authors have contributed to the work in IETF on ASON routing requirements and protocol evaluation. Many of the requirements and protocol functions discussed in [RFC4258] and [RFC4652] have been incorporated into prototyping work at OIF. Experimental protocol extensions to OSPF were implemented to support the functions identified in [RFC4258] and [RFC4652]. Note that these extensions have been tested in a transport-only instance of OSPF, i.e. routing implementations supported only optical routing and did not participate in any IP routing use of OSPF. Since then, the IETF has published a draft ( [OSPF-ASON]) addressing some of the features implemented by those prototypes. However, the latest revision of [OSPF-ASON] (-09) no longer provides IETF- standardized code points for such sub-TLVs, due to its Experimental Status and the existing guidelines for allocation of codepoints for OSPF. This draft summarizes testing of ASON routing extensions done by the authors and others participating in OIF interop testing to assist in the process of moving ASON routing extensions to Standards Track. 2. Reachability 2.1. Review of ASON Routing draft In order to advertise blocks of reachable address prefixes a summarization mechanism was proposed in [OSPF-ASON]. This extension consists of a network mask (a 32-bit number indicating the range of IP addresses residing on a single IP network/subnet). The set of local addresses is carried in an OSPFv2 TE LSA node attribute TLV (a specific sub-TLV is defined per address family, i.e., IPv4 and IPv6, used as network-unique identifiers). Similar functionality was implemented and tested by the authors and others. At the time of initial prototyping, the OSPFv2 TE LSA node attribute TLV had not been defined, so somewhat different formatting was used to carry IP prefixes. The tested solution used a new sub-TLV to carry the same information, called the Reachable IPv4 Prefix sub-TLV. This sub-TLV was carried Ong & Theillaud Expires April 21, 2010 [Page 3] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 in a new OSPFv2 Reachable Address TLV. Details of the TLV are given in section 5. 2.2. Tested IPv4 Reachability Advertisement The Reachable IPv4 Prefix sub-TLV used the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-type (EXP) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Reachable Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr length: specifies the length of the prefix as a number of Bits. IPv4 Reachable Address: For example, the address prefix 192.10.3.0/24 can be advertised with an address of 193.10.3 and an addr_length = 24. 3. Link Attributes 3.1. Review of ASON Routing draft [OSPF-ASON] defined additional terminology and scoping of link attributes advertised in a GMPLS LSA. One attribute which was left open for possible technology-specific enhancements was the the Interface Switching Capability Descriptor (ISCD). For prototyping purposes for control of SONET/SDH networks, the following technology-specific enhancement was implemented. 3.2. Bandwidth Accounting for ITU-T SONET/SDH Layers GMPLS Routing defines an Interface Switching Capability Descriptor (ISCD) that delivers, among other things, information about the (maximum/minimum) bandwidth per priority that an LSP can make use of. Per [RFC4202] and [RFC4203], one or more ISCD sub-TLVs can be associated with an interface. This information, combined with the Unreserved Bandwidth (sub-TLV defined in [RFC3630], Section 2.5.8), provides the basis for bandwidth accounting. [OSPF-ASON] states that in the ASON context, additional information may be included when representation and information in the other Ong & Theillaud Expires April 21, 2010 [Page 4] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 advertised fields are not sufficient for a specific technology (e.g., SDH). The definition of technology-specific information elements was left beyond the scope of [OSPF-ASON], in the draft. 3.2.1. SONET/SDH-specific connection availability For SONET/SDH networks with switches capable of handling multiple layer networks, a single link may be used for a number of TDM layers. For example, an OC192 link may be used for STS-1, STS-3c, STS-12c, STS-48c, STS-192c connections, switched by the same fabric. GMPLS appears to offer a number of possible options for advertising link characteristics where multiple layers are supported by the same physical link. One option is to advertise separate Link TLVs for each layer. A second option is to advertise multiple ISCD sub-TLVs within a single Link TLV for the link. A third option is to advertise a single Link TLV and ISCD sub-TLV and attempt to derive bandwidth availability for multiple TDM layers from this information. All three options were found to have some disadvantages and instead a technology-specific ISCD sub-TLV was defined containing information that applies to multiple TDM layers. This solution was implemented for the following reasons: o If separate TLVs are advertised for each layer, then common information such as LSA header information, link type, link ID, link local and remote identifiers, protection type, administrative group and shared risk are repeated for each layer. o If separate ISCD sub-TLVs are advertised for each layer, then common information such as the Switching Capability (TDM) and Encoding Type (SONET/SDH) are repeated for each layer. o Deriving bandwidth availability from a single ISCD sub-TLV which contains the total available bandwidth and the minimum reservable bandwidth yields potentially inaccurate results, since support of standard concatenation requires sequential timeslots in a particular position, and this can be blocked by a smaller signal in that space. Some available bandwidth may not be usable as a result. A technology-specific ISCD sub-TLV that carried a compact description of the number of unallocated timeslots at each supported SONET/SDH signal type was used instead of separate Link TLVs or ISCD sub-TLVs and carried exact availability information for each signal type. The Ong & Theillaud Expires April 21, 2010 [Page 5] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 indication subfield was also removed as no longer necessary since Arbitrary SONET/SDH is not supported. The following technology-specific ISCD format was tested: 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 (EXP) | Length = 4 + n*4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of Unallocated Timeslots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of Unallocated Timeslots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Number of Unallocated Timeslots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: n defines the number of signal types supported on this link, and thus has a value greater than or equal to 1. Inherited from [RFC4202], the Switching Capability field and the Encoding field MUST take the following values for Sonet/SDH interfaces: Switching Capability (8 bits): value 100 (TDM). Encoding (8 bits): value 5 for Sonet/SDH. Reserved (16 bits): must be set to zero when sent and ignored when received. Signal Type (8 bits): STS-1 SPE / VC-3 [RFC4606] STS-3c SPE / VC-4 [RFC4606] STS-12c SPE/VC-4-4c Exp STS-48c SPE/VC-4-16c Exp STS-192c SPE/VC-4-64c Exp Number of Unallocated Timeslots (24 bits): Specifies the number of identical unallocated timeslots per Signal Type and per TE Link. As such, the initial value(s) of this TLV indicates the total capacity in terms of number of timeslots per TE Ong & Theillaud Expires April 21, 2010 [Page 6] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 link. The signal type included in the BW announcement is specific to the layer link being reported and is not derived from some other signal type (e.g. STS-48c is not announced as 16 x STS-3c). For instance on an OC-192/STM-64 interface either the number of STS-3c SPE/VC-4 unallocated timeslots is initially equal to 64, or the number of STS-48c SPE/VC-4-16c unallocated timeslots is equal to 4 or even a combination of both type of signals depending on the interface capabilities. Once one of these components gets allocated for a given connection, the number of unallocated timeslots is decreased by the number of timeslots this connection implies. 4. Routing Information Scope 4.1. Review of ASON Routing Draft [OSPF-ASON] proposed extensions to allow the scope of routing Information to allow flexibility between the relationship of The advertising router and the TE router. Similar extensions with slightly different format were implemented in testing. 4.2. Link Advertisement (Local and Remote TE Router ID sub-TLVs) Implementations followed the concepts defined in [OSPF-ASON] to Allow flexible relationship between the Router-ID and the TE Router-ID. The following is given in [OSPF-ASON]: A Router-ID (Ri) advertising on behalf multiple TE Router_IDs (Lis) creates a 1:N relationship between the Router-ID and the TE Router-ID. As the link local and link remote (unnumbered) ID association is not unique per node (per Li unicity), the advertisement needs to indicate the remote Lj value and rely on the initial discovery process to retrieve the [Li;Lj] relationship. In brief, as unnumbered links have their ID defined on per Li bases, the remote Lj needs to be identified to scope the link remote ID to the local Li. Therefore, the routing protocol MUST be able to disambiguate the advertised TE links so that they can be associated with the correct TE Router-ID. The tested extensions used two sub-TLVs of the (OSPFv2 TE LSA) top level Link TLV that define the local and the remote TE Router-ID. These are combined into a single sub-TLV in [OSPF-ASON] (the Local and Remote TE Router-ID sub-TLV), however implementation and testing began before [OSPF-ASON] was defined. The formats of the Local and Remote TE Router-ID sub-TLVs were: Ong & Theillaud Expires April 21, 2010 [Page 7] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (exp) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local TE Router-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 (exp) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote TE Router-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These sub-TLVs were always included as part of the top level Link TLV as it was assumed that the Router-ID could always advertise on behalf of multiple TE Router-IDs. 4.3. Reachability Advertisement (Local TE Router ID sub-TLV) When the Router-ID is advertised on behalf of multiple TE Router-IDs (Lis), the routing protocol MUST be able to associate the advertised reachability information with the correct TE Router-ID. For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level Node Attribute TLV was introduced in [OSPF-ASON]. Since this sub-TLV had not yet been defined at the time of initial implementation, a sub-TLV was defined independently for prototype testing. In this case the format is the same. The tested solution used a new sub-TLV of the (OSPFv2 TE LSA) top level Reachable Address TLV (see section 5): the TE Router ID sub- TLV. The TE Router_ID sub-TLV used the following format: Ong & Theillaud Expires April 21, 2010 [Page 8] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (exp) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local TE Router_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4. New Reachable Address top-level TLV When the OSPFv2 extensions for ASON routing were designed for the first OIF interoperability demonstrations, draft-ietf-ospf-te-node-addr draft was at a very early stage, and the Node Attribute top-level TLV was not available to carry reachable prefixes. Instead a new experimental top-level TLV was defined: the Reachable Address top-level TLV. Contrary to [OSPF-ASON] where each Node Attribute top-level TLV carries reachable prefixes for a single TE Router ID (so that if a Router advertises reachable prefixes on behalf of multiple TE Router IDs, it will originate multiple OSPFv2 TE LSAs with a Node Attribute TLV), the Reachable Address top-level TLV may be used to advertise reachable prefixes attached to multiple TE Router IDs: in order to do so, a TE Router ID sub-TLV MUST appear before the Reachable Address sub-TLV(s). Ong & Theillaud Expires April 21, 2010 [Page 9] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (exp) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router_Id sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router_Id sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This tested format is functionally equivalent to the format defined in [OSPF-ASON] but is independent of the function of advertising local addresses of a router for MPLS TE LSPs as defined in [OSPF-NODE]. 5. Routing Information Dissemination Subdivision of ASON Routing Areas as discussed in this section of [OSPF-ASON] has not yet been implemented and tested. 6. Implementation and Testing Results Testing of these protocol extensions was carried out at a number of testing events from 2003-2009, most recently occurring over a period of months during July-September 2007 and April-June 2009. There were 7 independent implementations tested at each event as listed below: 2007 interop test implementations: Ong & Theillaud Expires April 21, 2010 [Page 10] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 o Alcatel-Lucent o Ciena Corporation o Ericsson o Huawei Technologies o Sycamore Networks o Tellabs o ZTE 2009 interop test implementations: o Alcatel-Lucent o Ciena Corporation o Huawei Technologies o Nokia Siemens Networks o Sycamore Networks o Tellabs o ZTE Initial implementation and interop testing of ASON routing extensions began as early as 2003. Further information about the testing conducted can be found at http://www.oiforum.com/public/OIF_demos.html All implementations utilized the ASON routing extensions described in this draft. Results were: o prototype implementations were interoperable o aligned TE database was achieved by participating implementations o path computation was successfully achieved for connections Ong & Theillaud Expires April 21, 2010 [Page 11] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 o connections were successfully set up at different SONET/SDH rates using the TE database 6.1. Standardization These testing results are provided in the interests of achieving standard OSPFv2 protocol extensions to support ASON routing. The extensions tested are very similar in functionality to the extensions defined in [OSPF-ASON], with the exception of the technology-specific ISCD sub-TLV used. The results of this implementation and testing show that these functions are useful and implementable, and that ASON routing extensions to OSPF should be Standards Track rather than Experimental. It is believed by the authors that the tested TLVs and sub-TLVs are equivalent in functionality to the extensions defined in [OSPF-ASON] and could be adopted by IETF as extensions to OSPF used in a transport instance. This would enhance the adoption of standard GMPLS routing extensions for ASON as a set of implementations for these routing extensions will have already been tested and these extensions would as a result be available sooner for use in the industry. 7. IANA Considerations Propose IANA allocate codepoints for new TLV/sub-TLVs for ASON Routing. 8. Security Considerations This document describes implementation and testing experience with ASON routing extensions similar to those defined in [OSPF-ASON]. No additional security issues are identified. 9. Acknowledgements The authors would like to thank the following OIF members for their comments and support for this document: Richard Graveman (Department of Defense) Hans-Martin Foisel (Deutsche Telekom) Ong & Theillaud Expires April 21, 2010 [Page 12] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 Thierry Marcot (France Telecom) Evelyne Roch (Nortel Networks) Jonathan Saddler (Tellabs) Yoshiaki Sone (NTT Corporation) Takehiro Tsuritani (KDDI R&D Laboratories) 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [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. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 10.2. Informative References [OSPF-ASON] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress", August 2009. [OSPF-NODE] Aggarwal, R., "Advertising a Router's Local Addresses in OSPF TE Extensions, draft-ietf-ospf- te-node-addr, work in progress", October 2009. Ong & Theillaud Expires April 21, 2010 [Page 13] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005. [RFC4652] Papadimitriou, D., L.Ong, Sadler, J., Shew, S., and D. Ward, "Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements", RFC 4652, October 2006. Authors' Addresses Lyndon Ong Ciena P.O.Box 308 Cupertino CA 95015 USA Phone: +1 408 962 4929 Email: lyong@ciena.com Remi Theillaud Marben Products 176 rue Jean Jaures Puteaux 92800 France Email: remi.theillaud@marben-products.com Ong & Theillaud Expires April 21, 2010 [Page 14] Internet-Draft draft-ong-gmpls-ason-routing-exper-00 October 2009 Copyright Notice 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. Ong & Theillaud Expires April 21, 2010 [Page 15]