Network Working Group E. Osborne Internet-Draft Cisco Systems, Inc. Intended status: Experimental P. Psenak Expires: February 5, 2012 Cisco Systems. August 4, 2011 Component and Composite Link Membership in OSPF draft-ospf-cc-stlv-00 Abstract This document provides a TLV and sub-TLV for OSPF to establish a relationship between component and composite links in MPLS-TE opaque LSAs. 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]. 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." This Internet-Draft will expire on February 5, 2012. 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 Osborne & Psenak Expires February 5, 2012 [Page 1] Internet-Draft ospf-cc August 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Component TLV . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Removing link type and link ID sub-TLVs from C-TLV . . . . 3 2.2. Inheritance between Link TLV and C-TLV . . . . . . . . . . 3 2.3. Component/composite ID sub-TLV . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Osborne & Psenak Expires February 5, 2012 [Page 2] Internet-Draft ospf-cc August 2011 1. Introduction Composite links [I-D.ietf-rtgwg-cl-requirement] require the ability to place MPLS-TE LSPs across specific components of a composite link. One way to do this is to advertise both the composite and components as links in the TE database using the mechanisms defined in [RFC3630]. In order to do this, a relationship must be established between a given composite link and its components. This document provides a new top-level TLV to be advertised in the Traffic Engineering LSA. This new TLV is necessary in order to ensure that bandwidth reserved from a given component link is properly accounted for at the component level, and to do so in a backward-compatible manner. Along with this new top-level TLV, we define a sub-TLV to identify the composite link to which a component belongs. 2. Component TLV The component TLV (C-TLV) is very similar to the Link TLV [RFC3630]. The C-TLV defines a component link which belongs to a single composite. A C-TLV MUST carry a CC-sTLV (see Section 2.3). A C-TLV MUST NOT carry a Link Type or Link ID sub-TLV (see Section 2.1 for the rationale). A C-TLV MUST otherwise follow all rules for sub-TLVs that pertain to a Link TLV. In particular, all sub-TLVs which are defined for use in a Link TLV are usable in the C-TLV. 2.1. Removing link type and link ID sub-TLVs from C-TLV RFC3630 requires that a Link TLV carry both a Link Type and Link ID sub-TLV. The Link Type describes the link as either p2p or multiaccess. Composite and component links are p2p by definition, and thus explicating this is unnecessary. For p2p links the Link ID of the component is the Router ID of the neighbor at the other end; as all components of a composite terminate on the same node, the Link ID of the parent composite is inherited by the component link and thus does not need to be specified. 2.2. Inheritance between Link TLV and C-TLV A component may or may not carry all of the sub-TLVs that its parent Link TLV does. For example, a component may share an administrative group with its parent composite and thus can inherit the administrative group from the parent, or might not have an IP address. This section specifies inheritance rules used to determine the value of various sub-TLVs inside the component link based on their status in the parent composite: Link type: per section 3.1, a C-TLV MUST NOT carry a Link Type sub- Osborne & Psenak Expires February 5, 2012 [Page 3] Internet-Draft ospf-cc August 2011 TLV. Link ID: per section 3.1, a C-TLV MUST NOT carry a Link ID sub-TLV. Local and remote interface IP addresses: if these are not specified in the parent composite link then they MAY be omitted from the component. Practically speaking it is not useful to advertise a link without some sort of unique identifier, so it is expected that most implementations will advertise a parent link with some sort of identifier, either local/remote IP addresses or some other unique identifier such as Link Local and Remote Identifiers [RFC4203]. If a parent composite link carries a unique identifier a component link SHOULD also carry a unique identifier. However, there is no requirement that the types match; a composite MAY advertise a Link Local/Remote Identifier while the component advertises local/remote IP addresses, or vice versa. Deciding on the identifier used for a component link is outside the scope of this document and is implementation-specific. Traffic engineering metric: if this is not included in the C-TLV, it is inherited from the parent Maximum bandwidth: if this is specified in the parent composite it MUST be explicitly specified (that is, not inherited) in the component link. If it is not specified in the parent it MAY be specified in the component. Maximum reservable bandwidth: if this is specified in the parent composite it MUST be explicitly specified (that is, not inherited) in the component link. If it is not specified in the parent it MAY be specified in the component. Unreserved bandwidth: if this is specified in the parent composite it MUST be explicitly specified (that is, not inherited) in the component link. If it is not specified in the parent it MAY be specified in the component. Administrative group: if this is not included in the C-TLV, it is inherited from the parent. Other sub-TLV types SHOULD follow a similar approach to the sub-TLVs listed here. In general, the idea is that a component link should advertise any properties which are unique to that component and should inherit from the parent composite any properties which are shared between the parent composite and the component. Osborne & Psenak Expires February 5, 2012 [Page 4] Internet-Draft ospf-cc August 2011 2.3. Component/composite ID sub-TLV The association between a composite link and its components is made using the component/composite ID sub-TLV (CC-ID sTLV). The CC-ID sTLV is a sub-TLV carried in both the Link TLV of the OSPF Opaque TE LSA and the C-TLV. It is a 32-bit field (4 octets) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Composite ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Composite ID is a 32-bit value assigned to a composite on a given system. The Composite ID MUST be unique to the advertising router. The method of assignment of the Composite ID is out of the scope of this document. When carried in a Link TLV, the Composite ID identifies that link as a composite link. When carried in a C-TLV, the Composite ID identifies the composite link of which the given component is a member. This association is necessary so that implementations which are component-aware can decide whether to establish an LSP over a composite or one of its components. All components of a given composite MUST have an CC-ID sTLV, and the Composite ID of the composite and all of its components MUST match. A link (component or composite) MUST contain only one CC-ID sTLV. A node MAY advertise a composite link with no components, but if a node advertises any component links the node MUST also advertise an associated composite link. The CC-ID sTLV needs a number assigned to it by IANA. For now, the sub-TLV number is TBD. 3. IANA Considerations tbd 4. Security Considerations There are no security considerations when using this sub-TLV; it is a link property like any other, and provides no more and no less exposure to security issues than the other sub-TLVs defined in [RFC3630]. Osborne & Psenak Expires February 5, 2012 [Page 5] Internet-Draft ospf-cc August 2011 5. Acknowledgements Les Ginsberg, Padma Pilay-Esnault, Stefano Previdi, Tony Li, Abhay Roy 6. Normative References [I-D.ietf-rtgwg-cl-requirement] Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Yong, "Requirements for MPLS Over a Composite Link", draft-ietf-rtgwg-cl-requirement-04 (work in progress), March 2011. [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. Authors' Addresses Eric Osborne Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 Phone: Fax: Email: eosborne@cisco.com URI: Osborne & Psenak Expires February 5, 2012 [Page 6] Internet-Draft ospf-cc August 2011 Peter Psenak Cisco Systems. Mlynske Nivy 43 Bratislava, 821 09 Slovakia Phone: Fax: Email: eosborne@cisco.com URI: Osborne & Psenak Expires February 5, 2012 [Page 7]