Network Working Group D. Katz Request for Comments: 3630 K. Kompella Updates: 2370 Juniper Networks Category: Standards Track D. Yeung Procket Networks September 2003 Traffic Engineering (TE) Extensions to OSPF Version 2 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. 1]. The architecture of traffic engineering is described in . The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS . It is expected that the traffic engineering extensions to OSPF will continue to mirror those in IS-IS. The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. Furthermore, no changes have been made to the operation of OSPFv2 flooding; in
particular, if non-TE capable nodes exist in the topology, they MUST flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs (see ). 5], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as the proposal is to simply add more attributes to links in OSPF advertisements. The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include: o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering. For example, an OSPF-speaking device can participate in an OSPF area, build a traffic engineering database, and thereby report on the reservation state of links in that area. In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated, is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP-hard, or even unsolvable, depending on the nature of the attributes and constraints, and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here.
Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes. 7] and . RFC 2119 . 3]. Three types of Opaque LSAs exist, each of which has a different flooding scope. This proposal uses only Type 10 LSAs, which have an area flooding scope. One new LSA is defined, the Traffic Engineering LSA. This LSA describes routers, point-to-point links, and connections to multi- access networks (similar to a Router LSA). For traffic engineering purposes, the existing Network LSA is sufficient for describing multi-access links, so no additional LSA is defined for this purpose.
IANA Considerations section for allocation of new Types.
If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPF and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPF TE information. R may then appear as two separate nodes in S's TED. However, if both the IS-IS and OSPF LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single router. The router address TLV is type 1, has a length of 4, and a value that is the four octet IP address. It must appear in exactly one Traffic Engineering LSA originated by a router. IANA Considerations section for allocation of new sub-Types. The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.
Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Exponent | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S is the sign, Exponent is the exponent base 2 in "excess 127" notation, and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus, the above represents the value: (-1)**(S) * 2**(Exponent-127) * (1 + Fraction) For more details, refer to .
5]. The Administrative Group sub-TLV is TLV type 9, and is four octets in length. 1]. 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 Shortest Path First (SPF) or other route calculations are necessary.
1] and  apply to Opaque LSAs. It is suggested that any future mechanisms proposed to secure/authenticate OSPFv2 LSA exchanges be made general enough to be used with Opaque LSAs. 10]) for the assignment of top level Types in TE LSAs: o Types in the range 3-32767 are to be assigned via Standards Action. o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs. o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
The guidelines for the assignment of types for sub-TLVs in a TE LSA are as follows: o Types in the range 10-32767 are to be assigned via Standards Action. o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs. o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
 Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.  IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8).  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.  Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering", work in progress.  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.  Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.  Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.