Network Working Group R. Theillaud Internet-Draft Marben Products Intended status: Informational L. Ong Expires: April 29, 2010 Ciena October 26, 2009 Additional functions for OSPFv2 extensions for ASON routing draft-theillaud-gmpls-ason-routing-add-fcts-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Theillaud & Ong Expires April 29, 2010 [Page 1] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 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. Abstract [OSPF-ASON] defines OSPFv2 extensions to fulfill the requirements defined in [RFC4258]. In OIF discussion of ASON routing, OIF members have noted that some additional functionality beyond that defined in [OSPF-ASON] would be useful for deployment of ASON routing by OIF carriers. The purpose of this document is to list such additional functionalities, so that CCAMP experts study whether such functionalities can be fulfilled by existing GMPLS mechanisms, or whether extensions to [OSPF-ASON] are required. Some proposals for potential extensions are provided for review by IETF CCAMP. 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]. Theillaud & Ong Expires April 29, 2010 [Page 2] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Layer-scoped link attributes . . . . . . . . . . . . . . . . . 4 2.1. ITU-T G.7715.1 requirement . . . . . . . . . . . . . . . . 4 2.2. IETF extensions for ASON routing . . . . . . . . . . . . . 6 2.3. Proposed extension . . . . . . . . . . . . . . . . . . . . 6 3. Link associated local connection type . . . . . . . . . . . . . 7 3.1. IETF extensions for ASON routing . . . . . . . . . . . . . 7 3.2. Proposed extension . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Theillaud & Ong Expires April 29, 2010 [Page 3] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 1. Introduction The ITU-T Automatically Switched Optical Network (ASON) control plane architecture is defined in [G.8080]. [G.7715] further defines the architecture and requirements for routing in ASON networks; and [G.7715.1] specifically refines such architecture and requirements for link state protocols. [RFC4258] captured those ITU-T requirements. [RFC4652] evaluated he existing GMPLS routing protocols against the same requirements. The necessary extensions to OSPFv2 to meet such requirements were defined in [OSPF-ASON]. In discussing potential deployment of ASON routing, OIF members have identified additional functions that would be useful for routing in OIF carrier member ASON networks. The purpose of this document is to identify and bring these functions to the IETF CCAMP working group, so that the IETF experts may study how to fulfill such new functions using existing GMPLS routing protocols mechanisms, or if necessary, define extensions to [OSPF-ASON] to support these additional functions. The two additional functions discussed in this document are: 1. Layer-scoped link attributes 2. Link associated local connection type This document also provides proposals for routing extensions that have been discussed within OIF for ASON routing. They are provided for the purposes of clarifying the function they address and serving as proposals for extensions in CCAMP. 2. Layer-scoped link attributes 2.1. ITU-T G.7715.1 requirement [G.7715.1] section 9.5.1 specifies the set of link characteristic that are specific to a particular layer network. o Link capacity: This attribute provides the sum of the available and potential link connections for a particular network transport layer. o Link Weight: This attribute represents a vector of one or more metrics, each of which indicates the relative desirability of a particular link over another during path selection. Theillaud & Ong Expires April 29, 2010 [Page 4] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 o Resource Class: This attribute corresponds to a set of administrative groups assigned by the operator to this link. A link may belong to zero, one or more administrative groups. o Local Connection Type: This attribute identifies whether the local SNP represents a TCP, CP, or can be flexibly configured as either a TCP or a CP. o Link Availability: This attribute represents a vector of one or more availability factors for the link or link end. Availability may be represented in different ways between domains and within domains. Within domains it may be used to represent a survivability capability of the link or link end. In addition, the availability factor may be used to represent a node survivability characteristic. o Diversity Support: This attribute represents diversity information with respect to links, nodes and Shared Risk Groups (SRGs) that may be used during path computation. o Local Client Adaptations Supported: This attribute represents the set of client layer adaptations supported by the TCP associated with the Local SNPP. This is only applicable when the local SNP represents a TCP or can be flexibly configured as either a TCP or CP. Protocol extensions for all of these attributes, except Local Connection Type and Local Client Adaptations Supported, are already defined for TE-Links in [RFC3630] and [RFC4203]. In OIF discussions it has been suggested that most of these attributes would be common across ITU-T layer networks supported by a particular link, however some attributes may take different values for different layer networks. For example, administrative weight associated with the link may have one value for VC-3 connectivity across the link and another value for VC-4 connectivity across the link in order to provide finer control of routing on a per layer basis. On the other hand diversity support is more likely to be based on physical link characteristics such as conduits that may be traversed by multiple physical links and be a common point of failure. Given that some attributes may differ per layer network and others are likely to be common across layer networks, an extension that supports advertisement of common attributes on a per link basis but allows some attributes to be scoped to a layer would be highly useful Theillaud & Ong Expires April 29, 2010 [Page 5] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 2.2. IETF extensions for ASON routing [RFC4258] does not require to scope an attribute to a specific layer, therefore [OSPF-ASON] does not provide a clear way to achieve such scoping. It has been recently suggested that GMPLS routing protocols may be able to meet such a requirement by using a specific TE LSA per layer (and so multiple TE LSAs for the same TE-Link). The LSA itself scopes the attributes, the ISCD being used to identify the layer. If multiple layers share the same attributes, then a single LSA with multiple ISCDs is fine. However, this would lead to the advertisement of multiple TE LSAs for the same TE-Link, and it is not clear whether this is allowed by GMPLS routing protocols, or is an efficient solution. 2.3. Proposed extension [OIF-EXP] details how the link capacity attribute has been scoped to a specific layer in ASON routing prototypes used in past OIF interoperability demonstrations. For all other attributes that must be scoped to a layer per [G.7715.1], this draft proposes a new sub-TLV of the (OSPFv2 TE LSA) top-level link TLV. The proposed Link Attribute Scoping sub-TLV is defined as follows: 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 + x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Signal Type | Connect Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Scoped TE-Link Attribute SubTLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: x is the length of all the SubTLVs (including Type and Length fields) contained within the scoping subTLV. The Connect Type field is discussed in Section 3 below. The following sub-TLVs can be encoded within a Link Attribute Scoping sub-TLV: o Traffic Engineering Metric sub-TLV. Theillaud & Ong Expires April 29, 2010 [Page 6] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 o Administrative Group sub-TLV (Resource Class). A given sub-TLV may appear both as a sub-TLV of the top-level Link TLV, and as a sub-TLV of a Link Attribute Scoping sub-TLV. In such a case, the former is relevant for all layers except the layer identified by the Link Attribute Scoping sub-TLV. 3. Link associated local connection type The Local Connection Type is one of the link attribute required by [G.7715.1]. This uni-directional attribute is used to identify if traffic presented on the associated far-end interface has access to the switching function contained within the network element for the specific layer. If this attribute states that the far-end interface does not have access to this switching function, path computation will check to see if the element on the other side of the link is the intended destination, and if not disregard the link. 3.1. IETF extensions for ASON routing [OSPF-ASON] section 4.1 suggests the local connection type can be inferred from ISCDs. The ISCD provides three fields that can be used to identify a layer: a switching type, an encoding type and for some switching types, a minimun bandwidth. However, these three fields together may not allow distinguishing every layer, and as a consequence relying on ISCDs to infer each link-end local connection type may not work for all layers. One example that was brought up to the authors is about distinguishing: 1. An interface that supports high-order VC-4 and high-order VC-3 layers. 2. An interface that supports high-order VC-4 and low-order VC-3 layers. 3.2. Proposed extension The Connect Type field of the Link Attribute Scoping sub-TLV defined in Section 2.3 can be used to specify the link connection type. The local connection type link attribute is considered layer- Theillaud & Ong Expires April 29, 2010 [Page 7] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 specific. This proposed extension carries the local connection type within the Link Attribute Scoping sub-TLV, and therefore scopes this attribute to a specific layer. The connection type is encoded using a bit vector: o 0bxxxxxxx1 - Transit (i.e. CTP) o 0bxxxxxx1x - Trail Sink (i.e. TTP) Other bits are in this bit-vector are reserved, and must be sent as 0 and ignored on reception. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations This document does not identify any security issues. 6. 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) Thierry Marcot (France Telecom) Evelyne Roch (Nortel Networks) Jonathan Saddler (Tellabs) Yoshiaki Sone (NTT Corporation) Takehiro Tsuritani (KDDI R&D Laboratories) Theillaud & Ong Expires April 29, 2010 [Page 8] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 7. Normative References [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and requirements for routing in the automatically switched optical networks", June 2002. [G.7715.1] ITU-T Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and requirements for Link State Protocols", February 2004. [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)", June 2006. [OIF-EXP] Ong, L., "Implementation Experience with OSPFv2 Extensions for ASON Routing, draft-ong-gmpls-ason-routing-exper-00.txt, work in progress", October 2009. [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. [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. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [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. Theillaud & Ong Expires April 29, 2010 [Page 9] Internet-Draft draft-theillaud-gmpls-ason-rting-add-fcts October 2009 Authors' Addresses Remi Theillaud Marben Products 176 rue Jean Jaures Puteaux 92800 France Email: remi.theillaud@marben-products.com Lyndon Ong Ciena P.O.Box 308 Cupertino CA 95015 USA Phone: +1 408 962 4929 Email: lyong@ciena.com Theillaud & Ong Expires April 29, 2010 [Page 10]