Network Working Group L. Ong, Ciena Internet-Draft A. Malis, Verizon Intended status: Standards Track R. Theillaud, Marben Products Expires: October 26, 2010 February 26, 2010 OSPFv2 Extensions for ASON Routing based on Implementation Experience draft-ong-gmpls-ason-routing-exper-01 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 October 26, 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 work has continued in [OSPFASON]. This draft defines a set of proposed updates for a subset of the the ASON routing extensions for OSPFv2 defined in [OSPFASON]. These proposed updates have already benefited from running code tested in multiple interoperability testing events, with at least eight independent implementations. The differences from [OSPFASON] are the result of field and interoperability testing experience. Ong & Theillaud Expires October 26, 2010 [Page 1] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 These formats are proposed to either be folded in to [OSPFASON], or be a separate Standards Track RFC covering a subset of the ASON extensions to OSPFv2, as preferred by the working group. We believe that adopting these formats will help move those parts of [OSPFASON] towards Standards Track, while preserving the functionality defined in [OSPFASON]. 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. Comparison with [OSPFASON]. . . . . . . . . . . . . . . . . . 3 3. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ASON Routing Requirements . . . . . . . . . . . . . . . . 4 3.2. Local TE Router_ID sub-TLV . . . . . . . . . . . . . . . . 5 3.3. IPv4 Reachable Address Prefix sub-TLV . . . . . . . . . . 5 3.4. IPv6 Reachable Address Prefix sub-TLV . . . . . . . . . . 5 4. Routing Information Scope . . . . . . . . . . . . . . . . . . 6 4.1. ASON Routing Requirements . . . . . . . . . . . . . . . . 6 4.2. Local and Remote TE Router_ID sub-TLVs . . . . . . . . . . 6 5. Link Attributes . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. ASON Requirements . . . . . . . . . . . . . . . . . . . . 7 5.2. Link Component Availability Sub-TLV. . . . . . . . . . . . 7 6. Implementation and Testing Results . . . . . . . . . . . . . . 9 6.1. Standardization . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Ong & Theillaud Expires October 26, 2010 [Page 2] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 1. Introduction The ITU-T defines the architecture of the Automatically Switched Optical Network (ASON) in [G.8080]. [RFC4258] details the routing requirements for the GMPLS suite of routing protocols to support the capabilities and functionality of ASON control planes identified in [G.7715] and in [G.7715.1]. [RFC4652] evaluates the IETF Link State Routing Protocols against the requirements identified in [RFC4258]. Section 7.1 of [RFC4652] summarizes the capabilities to be provided by OSPFv2 [RFC2328] in support of ASON routing. This document details a set of OSPFv2 extensions supporting a subset of the capabilities identified in [RFC4652] which have already been implemented and tested for interoperability across at least 8 independent implementations. 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. This draft also compares the implemented extensions to those defined in [OSPFASON], which defines experimental OSPFv2 extensions in support of [RFC4652] capabilities. The changes from [OSPFASON] are the result of field and interoperability testing experience, and are either minor format changes or supplementary information found useful in field testing. We believe that adop- ting the extensions in this draft will further progress [OSPFASON]. 2. Comparison with [OSPFASON] This draft defines formats similar to some defined in [OSPFASON]. This section gives a high level comparison of the two formats. 2.1. Reachable Address Prefix Advertisement Uses a single TLV to carry multiple values of TE Router_ID and associated IPv4 or IPv6 address prefixes, rather than separate TLVs as in [OSPFASON]. In the IPv4 prefix format, uses Prefix Length to indicate the prefix length rather than a Network Mask as in [OSPFASON] (Note [OSPFASON] uses Prefix Length for the IPv6 prefix format). 2.2. Router Information Scoping Uses separate Sub-TLVs to carry Local and Remote TE Router_ID instead of a single Sub-TLV for both, as in [OSPFASON]. Ong & Theillaud Expires October 26, 2010 [Page 3] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 2.3. Link Attributes Advertises Link Component Availability at multiple TDM layers as opposed to or in addition to advertisement of ISCD for an individual TDM layer. 3. Reachability 3.1. ASON Routing Requirements [RFC4652] identifies the need for additional capabilities to advertise blocks of reachable address prefixes using a summarization mechanism either taking the form of a prefix length (which indicates the number of significant bits in the prefix) or a network mask. An OSPF Reachable Address Prefix TLV was implemented and tested to support this capability. This TLV is advertised as the payload of a Type 1 Traffic Engineering LSA [RFC3630]. It has 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local TE_Router_Id sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 or IPv6 Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 or IPv6 Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // . . . // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local TE_Router_Id sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 or IPv6 Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 or IPv6 Reachable Address sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ong & Theillaud Expires October 26, 2010 [Page 4] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 This format allows the Reachable Address Prefix TLV to advertise multiple TE Router_IDs associated with the advertising entity, as well as multiple Reachable Address Prefixes associated with these TE Router_IDs. Each IPv4 or IPv6 Reachable Address Prefix sub-TLV is associated specifically with the TE Router_ID preceding it in the TLV. 3.2. Local TE_Router_ID Sub-TLV The Local TE_Router_ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (tbd) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local TE Router_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Local TE Router_ID field advertises a Local TE Router_IDentifier being advertised associated with the advertising entity. 3.3 IPv4 Reachable Address Prefix Sub-TLV The IPv4 Reachable Address Prefix sub-TLV takes the following form: 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 (tbd) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pref_length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Reachable Address Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined: Pref_length: length in bits of the Prefix IPv4 Reachable Address Prefix: Each prefix is encoded as a 32-bit word with trailing zero bit padding as necessary. Ong & Theillaud Expires October 26, 2010 [Page 5] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 3.4 IPv6 Reachable Address Prefix Sub-TLV IPv6 prefixes were not implemented or tested. 4. Routing Information Scope 4.1. ASON Routing Requirements [RFC4652] identifies the need for an extension to routing protocols to support non-1:1 relationships between the Router_ID and TE Router_ID, and as a result the need for the capability to advertise the remote Lj value where Lj is a logical control plane entity that is associated to a single data plane (abstract) node. 4.2. Local and Remote TE Router_ID Sub-TLVs In order to support this capability, two sub-TLVs of the TE LSA Link TLV [RFC3630] are defined for advertising the Local TE Router_ID and Remote TE Router_ID. These use the following formats: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote TE Router_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These sub-TLVs allow the routing protocol to scope the advertised link attributes advertised in an OSPFv2 TE Link LSA for ASON routing. Ong & Theillaud Expires October 26, 2010 [Page 6] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 5. Link Attributes 5.1 ASON Requirements [RFC4652] notes that in the ASON context, bandwidth accounting representations are possible, taking the form of a set of tuples , and that this representation may also require definition of additional signal types (from those defined in [RFC4606]) to represent support of contiguously concatenated signals, i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. It notes that the ISCD defined in [RFC4202] is the most straightforward without requiring any bandwidth accounting change from an LSR perspective. However, the ISCD defined in [RFC4202} must be advertised once per signal type (identified by the Minimum Reservable Bandwidth value) in order to provide an accurate advertisement of bandwidth for each signal. For SONET/SDH links, it is common to support 4-5 signal types (e.g., STS-1, 3c, 12c, 48c and 192c) at once, and advertisement of 4-5 ISCD sub-TLVs would consume about 200 bytes as compared to 20-30 bytes for a tuple format. Most of the ISCD bytes are required to advertise 8 levels of priority. We believe this overhead can be reduced as (a) ASON specifications do not identify priority as an ASON service; and (b) TDM networks generally to not support preemption priority at all, not to mention 8 levels. 5.2. Link Component Availability Sub-TLV The Link Component Availability Sub-TLV carries an indication of SONET/SDH bandwidth at multiple link component signal types as supplementary information to the ISCD sub-TLV. When multiple priorities are used, the Link Component Availability Sub-TLV can be interpreted as the availability for Priority 7. The following format is defined: Ong & Theillaud Expires October 26, 2010 [Page 7] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 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 (tbd) | 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 STS-48c SPE/VC-4-16c STS-192c SPE/VC-4-64c 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 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). Ong & Theillaud Expires October 26, 2010 [Page 8] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 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 timeslots is occupied either by being allocated for a connection at the same or a larger signal type or by being blocked due to the allocation of part of the timeslot for a connection at a smaller signal type, the number of unallocated timeslots is decreased by the number of timeslots this connection implies. 6. Implementation and Testing Results Initial implementation of ASON routing extensions began in 2003. 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: 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 Ericsson o Huawei Technologies o Nokia Siemens Networks o Sycamore Networks o Tellabs o ZTE Further information about the testing conducted can be found at http://www.oiforum.com/public/OIF_demos.html Ong & Theillaud Expires October 26, 2010 [Page 9] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 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 o connections were successfully set up at different SONET/SDH rates using the TE database 6.1. Standardization The extensions defined in this draft satisfy a subset of the functionality identified in [RFC4258] and [RFC4652] for ASON routing. The results of implementation and interoperability testing show that these functions are useful and implementable, and that ASON routing extensions to OSPF may be made Standards Track rather than Experimental, using the formats implemented and tested. Standardization of these extensions by IETF for ASON routing support would allow fast adoption in the industry due to the presence of several existing implementations, i.e., running code. 7. IANA Considerations Propose IANA allocate codepoints for new TLV/sub-TLVs for ASON Routing from the standard range. 8. Security Considerations This document describes implementation and testing experience with ASON routing extensions similar to those defined in [OSPFASON]. 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) Ong & Theillaud Expires October 26, 2010 [Page 10] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 Hans-Martin Foisel (Deutsche Telekom) Thierry Marcot (France Telecom) Evelyne Roch (Nortel Networks) Jonathan Sadler (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. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328,April 1998. [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,February 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 [OSPFASON] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions for ASON Routing, draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in progress", August 2010. [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,February 2006. Ong & Theillaud Expires October 26, 2010 [Page 11] Internet-Draft draft-ong-gmpls-ason-routing-exper-01 February 2010 Authors' Addresses Lyndon Ong Ciena P.O.Box 308 Cupertino CA 95015 USA Phone: +1 408 962 4929 Email: lyong@ciena.com Andrew Malis Verizon 117 West St. Waltham, MA 02451 USA Email: andrew.g.malis@verizon.com Phone: +1 781 466 2362 Remi Theillaud Marben Products 176 rue Jean Jaures Puteaux 92800 France Email: remi.theillaud@marben-products.com Copyright Notice Copyright (c) 2010 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. Ong & Theillaud Expires October 26, 2010 [Page 12]