Internet Draft Network Working Group Derek M. Yeung Internet Draft Cisco Systems Expiration Date: August 1999 Februrary 1999 OSPF Extensions for Traffic Engineering draft-yeung-ospf-traffic-00.txt Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 1. Abstract This document describes extensions to the OSPF protocol to support Traffic Engineering [1]. The OSPF protocol is specified in [2], This extension make use of opaque LSA defined in [3] and provides similar information to what is defined in the ISIS extensions for traffic engineering[4]. This document extends the OSPF protocol by specifying new information that a router can place in a type 10 opaque Link State Advertisement (LSA). This information describes additional information about the state of the network that is useful for traffic engineering. Yeung [Page 1] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 2. Introduction OSPF Opaque LSA provides a generalized mechanism for OSPF to carry additional information. The new information can be used directly by OSPF or indirectly by other applications which use OSPF to distribute information. This document defines how to use opaque LSA to carry additional information for traffic engineering. Opaque LSA consists of a standard LSA header followed by a 32-bit aligned application-specific information field. The link-state type field identifies the flooding scope; type 9 for link-local, type 10 for area-local and type 11 for AS. This document uses type 10 area- local flood scope to distribute the LSA. In order words, the traffic engineering (TE) LSA is flooded only within the same area. Handling the traffic engineering information across multiple areas is outside the scope of this document. The TE LSA opaque data is divided into a number of tuples, each consisting of a Type, a Length and a Value. The general definition of TLV is used, except that the Length field size depends on the Type field. This document call this variant as TVLV (See section 4.0). TVLV is flexible and provide an easy way to extend the information carried in the TE opaque LSA. This document defines a set of TVLVs that carry information about the characteristics of a particular link. It also defines a router address TVLV which is useful for traffic engineering. Moreover, the document defines a padding TVLV. This TVLV fulfills the 32-bit alignment requirement of OSPF LSA. Finally, it also defines a TVLV for future extensions. This document only defines the layout of traffic engineering information in the opaque LSA using TVLV. Unless stated otherwise, procedures for obtaining this information, and the use of this information (either within or outside of OSPF) is outside the scope of this document. Yeung [Page 2] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 3. OSPF Traffic Engineering LSA format Type 10 area-scope opaque LSA is used to carry the traffic engineering information. The opaque type is 168. The content of the LSA is represented in a group of TVLVs (See below). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 168 | TE LSA ID | LSA Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VARIABLE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VARIABLE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The opaque ID of the TE LSA is divided into a 2-octets of TE LSA ID and a 1-octet of LSA number. The TE LSA ID is generated from the advertising router ID and is used to indentify the TE opaque LSAs generated by a particular OSPF instance within an area. For example, it could be the last two bytes of the advertising router ID. If different routers happen to use the same TE LSA ID, their TE LSAs are still distinguishable by the advertising router ID. Other mechanisms can be used to generate a unique TE LSA ID. The LSA number allows us to generate multiple LSAs for traffic engineering without consuming new opaque types. The LSA number must start with 0. Moreover, TE LSAs with LSA number 0 must present in the database before other LSA fragments with the same TE LSA ID but different non-zero LSA number are considered in the route calculation. Yeung [Page 3] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 4. Extended TLV (TVTV) In a normal TLV, the size of the type and length fields is fixed in 1-octet. Although 256 different types seems sufficient, 255 octets as the maximum length is a potential limitation. However, making the length field two octets could be too large in certain cases. To solve this problem this document allows the size of the length field to be variable. The TLVs with the variable size Length field are referred in this document as TVLV (Type- Variable Length - Value). In a TVLV the size of the length field depends on the type. Only two lengths is supported; 1 or 2 octets. Since the OSPF LSA length in the LSA header is only 2 octets, it does not make sense to has a length more than 2 octets for the TVLV. Type Type size Length size Content 0-127 1-octet 1-octet VARIABLE 128-255 1-octet 2-octets VARIABLE TVLV provides more flexibility for OSPF than normal TLV. Using the neighbor TVLV (See section 7.0) as an example, the TVLV allows more sub-TVLVs to be added than the TLV. Moreover, given that the maximum size of an OSPF LSA is 64k bytes, a single neighbor TVLV, instead of multiple TLVs, is sufficient to fill up the LSA. This result in less space being wasted in the TLV header. 5. Padding TVLV The padding TVLV is TVLV type 0. Padding is used to algin OSPF LSA on a 32-bit alignment. The padding TVLV, if it is required, should be used as the last TVLV. The size of the length field is 1-octet. Type Length (Octets) Value (Octets) 0 1 Variable Yeung [Page 4] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 6. Router Address TVLV The router address TVLV is TVLV type 1. The router address TVLV contains the 4-octet IP address of the router originating the LSA. The length field size is 1-octet. Type Length (Octets) Value (Octets) 1 1 4 For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces. 7. Neighbor TVLV The neighbor TVLV is TVLV type 128. It describes a series of neighbors in the traffic engineering topology. The value field has a variable length. Type Length (Octets) Value (Octets) 128 2 11+ For each neighbor, it contains the link type, link ID, metric, size of sub-TVLVs and zero or more sub-TVLVs. The sub-TVLVs can be used to provide addtional information. Link Type 1-octet; 1 for p2p, 2 for multi-access Link ID 4-octets Metric 4-octets Length of Sub-TVLV 2-octets 0-65504 octets of sub-TVLVs The link type specify the characteristics of the link. It also affects the meaning of the link ID field. Currently, point-to-point and multi-access types are defined. For point-to-point links, the link ID is the OSPF router ID of the neighbor. In other words, it is the link state ID of the neighbor's router LSA. For multi-access links, the link ID is the IP address of designated router for the link. In other words, it is the link state ID of the designated router's network LSA. Yeung [Page 5] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 This document does not define any equivalent of the network LSA to describe multi-access links. Instead, it makes use of the network LSA defined for normal OSPF. When the neighbor TVLV is generated, the existence of any network LSA and designated router should be taken into account so the link type and link ID can be set correctly. The metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations. The length of the sub-TVLVs is calculated by the maximum LSA length (65535) minus LSA header size (20) minus neighbor TVLV fixed portion (11). This data structure can be repeated in the same neighbor TVLV to describe more than one neighbor. The following sub-TVLVs are proposed. Sub-TVLV type Length (Octets) Value (Octets) Name 1 1 4 Interface address 2 1 4 Neighbor address 3 1 4 Maximum link bandwidth 4 1 2 Maximum Allocation Multiplier 5 1 32 Current bandwith reservation 6 1 4 Resource class Each of the sub-TVLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by mulitple inclusions of the sub-TLV. 7.1. Sub-TVLV 1: Interface address This sub-TVLV contains a 4-octet IPv4 address for the interface described by the (main) TVLV. This sub-TVLV can occur multiple times. If a router implements traffic engineering, it must include this TVLV. Yeung [Page 6] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 7.2. Sub-TVLV 2: Neighbor address This sub-TVLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times. This TVLV is useful for diagnostic purposes. 7.3. Sub-TVLV 3: Maximum link bandwidth This sub-TVLV contains the maximum bandwidth on this link in this direction (from the router originating the LSA to its neighbors). The bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second. 7.4. Sub-TVLV 4: Maximum Allocation Multiplier This sub-TVLV contains the percentage of the maximum link bandwidth that can be reserved. This percentage is encoded as a 2-octet unsigned integer. Thus, this field can indicate that 0% of the link bandwidth up to 65,535% of the link bandwidth (note that for oversubscription purposes, this can be greater than 100%). 7.5. Sub-TVLV 5: Current bandwidth reservation This sub-TVLV contains the amount of bandwidth currently reserved in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link. This is encoded similarly to the maximum link bandwidth. Because of the need for priority and preemption, each originator of a Label Switched Path needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TVLV contains eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second. The values correspond to the bandwidth reserved with a holding of priority 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TVLV, and priority 7 at the end of the sub-TVLV. For stability reasons, rapid changes in the values in this sub-TVLV should not cause rapid generation of LSAs. Yeung [Page 7] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 7.6. Sub-TVLV 6: Resource class (color, administrative group) The administrative group sub-TVLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. By convention the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'. 8. Extension TVLV Extension TVLV is TVLV type 255. The TVLV is reserved for future extension. For example, if we run out of type, we can use this to create another 255 types. Length field size is 2-octets. Type Length Value (Octets) 255 2 Variable 9. Security Considerations This document raises no new security issues for OSPF. 10. Acknowledgments The author would like to thank Yakov Rekhter, Read Bell, Henk Smit and Jim Gibson for their helpful comments on this work. The author also like to recognize [4] as the inspiration of this work. Yeung [Page 8] Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999 11. References [1] draft-ietf-mpls-traffic-eng-00.txt, "Requirements for Traffic Engineering Over MPLS", D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, work in progress. [2] RFC 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367 bytes) (Obsoletes RFC2178) (Also STD0054) (Status: STANDARD) [3] RFC 2370 The OSPF Opaque LSA Option. R. Coltun. July 1998. (Format: TXT=33789 bytes) (Also RFC2328) (Status: PROPOSED STANDARD) [4] draft-ietf-isis-traffic-00.txt, "ISIS Extensions for Traffic Engineering", H. Smit, T. Li, work in progress. 12. Authors' Addresses Derek M. Yeung Cisco Systems, Inc. 210 West Tasman Drive San Jose, CA 95134 Email: myeung@cisco.com Voice: +1 408 526 8019 Yeung [Page 9]