Internet Draft Network Working Group Dave Katz Internet Draft Juniper Networks, Inc. Expiration Date: October 1999 Derek Yeung Cisco Systems, Inc. Traffic Engineering Extensions to OSPF draft-katz-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. Abstract This document describes extensions to the OSPF protocol to support Traffic Engineering, using opaque LSAs. 1. Introduction This document specifies a method of adding traffic engineering capabilities to OSPF [1]. The architecture of traffic engineering is described in [2]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS [3]. It is expected that the traffic engineering extensions to OSPF will continue to mirror those in IS-IS. D. Katz, M. Yeung Expires October 1999 [Page 1] Internet Draft draft-katz-yeung-ospf-traffic-00.txt April 1999 The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints). This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multiaccess links. 2. LSA Format 2.1 LSA type As the baseline OSPF Router LSA is essentially non-extensible, this extension makes use of the Opaque LSA [4]. h Three types of Opaque LSAs exist, each of which has different flooding scope. This proposal uses only Type 10 LSAs, which have area flooding scope. One new LSA is defined, the Traffic Engineering LSA. This LSA describes routers and point-to-point links (similar to a Router LSA). For traffic engineering purposes, the existing Network LSA suffices for describing multiaccess links, so no additional LSA is defined for this purpose. 2.2 LSA ID The LSA ID of an Opaque LSA is defined as having eight bits of type and 24 bits of type-specific data. The Traffic Engineering LSA uses type (TBD). The remaining 24 bits are broken up into eight bits of reserved space (which must be zero) and sixteen bits of instance: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Reserved | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs. A maximum of 65536 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance. D. Katz, M. Yeung Expires October 1999 [Page 2] Internet Draft draft-katz-yeung-ospf-traffic-00.txt April 1999 2.3 LSA Format Overview 2.3.1 LSA Header The Traffic Engineering LSA starts with the standard LSA header: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Reserved | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.3.2 TLV Header The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length field defines the length of the value portion in bytes (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-byte alignment; padding is not included in the length field (so a three byte value would have a length of three, but the total size of the TLV would be eight bytes). Unrecognized types are ignored. 2.4 LSA payload details An LSA contains one or more top-level TLVs. As it is desirable for LSAs to be small, most LSAs will contain only a single top-level TLV. However, implementations MUST be able to accept an arbitrary number of TLVs in each LSA. D. Katz, M. Yeung Expires October 1999 [Page 3] Internet Draft draft-katz-yeung-ospf-traffic-00.txt April 1999 There are two top-level TLVs defined: 1 - Router Address 2 - Link 2.4.1 Router Address TLV The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface is down. In other protocols this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. This TLV has a length of 4, and the value is the four octet IP address. It must appear in exactly one Traffic Engineering LSA originated by a router. 2.4.2 Link TLV The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology. Only numbered links are described, as traffic engineering is not supported on unnumbered links. The following sub-TLVs are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Resource class/color (4 octets) Each sub-TLV may occur only once. Unrecognized types are ignored. All of the defined sub-TLVs are mandatory (though future sub-TLVs may not necessarily be mandatory.) D. Katz, M. Yeung Expires October 1999 [Page 4] Internet Draft draft-katz-yeung-ospf-traffic-00.txt April 1999 2.5 Sub-TLV Details 2.5.1 Link Type The Link Type sub-TLV defines the type of the link: 1 - Point-to-point 2 - Multiaccess The Link Type sub-TLV is TLV type 1, and is one octet in length. 2.5.2 Link ID The Link ID sub-TLV identifies the other end of the link. For point- to-point links, this is the Router ID of the neighbor. For multiaccess links, this is the interface address of the designated router. The Link ID is identical to the contents of the Link ID field in the Router LSA for these link types. The Link ID sub-TLV is TLV type 2, and is four octets in length. 2.5.3 Local Interface IP Address The Local Interface IP Address sub-TLV specifies the IP address of the interface corresponding to this link. Note that at the moment, only numbered point-to-point links are supported for traffic engineering. The Local Interface IP Address sub-TLV is TLV type 3, and is four octets in length. 2.5.4 Remote Interface IP Address The Remote Interface IP Address sub-TLV specifies the IP address of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. The Remote Interface IP Address sub-TLV is TLV type 4, and is four octets in length. D. Katz, M. Yeung Expires October 1999 [Page 5] Internet Draft draft-katz-yeung-ospf-traffic-00.txt April 1999 2.5.5 Traffic Engineering Metric The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length. 2.5.6 Maximum Bandwidth The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are *bytes* per second. The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in length. 2.5.7 Maximum Reservable Bandwidth The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). The units are bytes per second. The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length. 2.5.8 Unreserved Bandwidth The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels, in IEEE floating point format. Each value will be less than or equal to the reservable bandwidth. The units are bytes per second. The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length. 2.5.9 Resource Class/Color The Resource Class/Color sub-TLV specifies administrative group membership for this link, in terms of a bit mask. A link that is a D. Katz, M. Yeung Expires October 1999 [Page 6] Internet Draft draft-katz-yeung-ospf-traffic-00.txt April 1999 member of multiple groups will have multiple bits set. The Resource Class/Color sub-TLV is TLV type 9, and is four octets in length. 3. Elements of Procedure Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No SPF or other route calculations are necessary. 4. Compatibility Issues There should be no interoperability issues with routers that do not implement these extensions, as the Opaque LSAs will be silently ignored. Note, however, that the DR on a multiaccess network must implement Opaque LSAs if any of the systems on that network do; this is a requirement of Opaque LSAs that is not spelled out in the document. The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces; however, if the topology is connected, TE paths can still be calculated and ought to work. 5. Security Considerations This document raises no new security issues for OSPF. 6. References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [2] Awduche, D., et al, "Requirements for Traffic Engineering Over MPLS," draft-ietf-mpls-traffic-eng-00.txt, work in progress. [3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," draft-ietf-isis-traffic-00.txt, work in progress. D. Katz, M. Yeung Expires October 1999 [Page 7] Internet Draft draft-katz-yeung-ospf-traffic-00.txt April 1999 [4] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. 7. Authors' Addresses Dave Katz Juniper Networks 385 Ravendale Drive Mountain View, CA 94043 USA Phone: +1 650 526 8073 Email: dkatz@juniper.net Derek M. Yeung Cisco Systems, Inc. 210 West Tasman Dr. San Jose, CA 95134 Phone: +1 408 526 8019 Email: myeung@cisco.com D. Katz, M. Yeung Expires October 1999 [Page 8] ------- End of Forwarded Message