Internet Draft Network Working Group Tony Li INTERNET DRAFT Juniper Networks Expiration Date: August 1999 George Swallow Cisco Systems Daniel O. Awduche UUNET February 1999 IGP Requirements for Traffic Engineering with MPLS <draft-li-mpls-igp-te-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.0 Abstract This document describes the functional requirements for an IGP to support Traffic Engineering with MPLS. This document does not specify the protocol changes necessary to realize these requirements. 2.0 Introduction A description of the requirements for Traffic Engineering with MPLS can be found in [1]. This document describes the functional requirements to enable a domain's IGP to provide the information necessary to perform important aspects of the traffic engineering function. An important aspect of traffic engineering concerns the procedures and supporting mechanisms employed to compute a path through a domain's network topology. Once a suitable path is computed, a signaling protocol is used to establish a Label Switched Path (LSP) along that path, and traffic that satisfies a given forwarding equivalence relation is sent down the LSP. In general, path computation for an LSP may seek to satisfy a set of requirements associated with the LSP, taking into account a set of constraints imposed by administrative policies and the prevailing state of the network -- which usually relates to topology data and resource availability. Computation of an engineered path that satisfies an arbitrary set of constraints is referred to as "constraint based routing" [1]. Paths computed for an LSP based on constraint based routing can differ from the shortest path that would normally be determined by a domain's IGP. Traffic engineering manipulates the parameters associated with constraint based routing to achieve specific performance objectives, based on a service provider's policies and preferences. Optimal path computation under constraints is computationally expensive. For this reason, online algorithms that are used for this purpose tend to be heuristics that produce reasonable, but suboptimal results in real time. In certain cases, explicit human intervention might be necessary, in the form of engineered paths that are determined off-line and then instantiated through administrative configuration. Because the human component does not scale well with network size and is not predictably responsive, it is beneficial to automate the path computation as much as possible for common cases. In the event that the common cases are not sufficient in the long run to achieve traffic engineering objectives, the requirements stated in this memo are sufficiently flexible so that additional complexity in the path computation can be incorporated in the future. This is possible because all path computation is performed by the originator of the LSP (the head-end). As such, interoperability is constrained to information distribution in the IGP and the basic signaling protocol mechanisms. 3.0 Architectural Requirements The architectural requirements consist of two basic components (1) a constraint based routing process that is implemented on those label switching routers that can serve as head-ends for LSPs, and (2) a set of mechanisms for dissemination and maintenance of topology state information. We will focus only on those aspects which are required for interoperable implementations, namely the set of mechanisms used for dissemination of topology state information. Topology state information can be disseminated by extending an IGP so that it conveys additional details concerning the state of the network. Because the IGP is used solely for conveyance of information about the network to the head-end, the attributes of the IGP are somewhat constrained. Computation of alternative paths implies that the head-end knows about alternative links that would not be used by a shortest path computation. This requirement implies that distance vector protocols, which only propagate information about paths that have already been selected, are not appropriate for this application. The other relevant category of IGPs is the class of link state protocols. There are two link state protocols commonly in use: OSPF [3] and IS-IS [4,5]. Link state protocols function by distributing complete topology information about an area to all nodes within the area. In particular, link state protocols are the only known class of protocols that are capable of full topology dissemination. Link state protocols are particularly useful for the traffic engineering application because they can be easily extended to distribute additional information concerning the state of the network. Accordingly, this manuscript describes traffic engineering requirements for link state IGPs only. Because the intent is to add new parameters to the IGP so that the IGP can distribute additional information about the network, the IGP must be extensible. Furthermore, for practical reasons, the extension mechanism must be backward compatible, that is, the existing implementations must continue to function following the changes necessary to support traffic engineering. Specifically, it is desireable that a given IGP domain remain operational when populated with a hybrid of devices, only a subset of which support the traffic engineering extensions. Fortunately, both OSPF and IS-IS satisfy this requirement. OSPF provides an Opaque LSA which can be used to carry arbitrary information [6]. Opaque LSAs are ignored by systems that do not recognize their contents. IS-IS encodes all of the information in its link state packets in tuples described by a type, length and value (TLVs). TLVs that are not recognized by a system are ignored This makes it possible to add information to each protocol in a backward compatible manner. Link state protocols have an inherent shortcoming when used for traffic engineering. Because link state protocols distribute large databases of information and attempt to do so in a timely manner, the size of the database distribution area must necessarily be restricted. The scalability limitations of the flooding algorithms used for link state protocols imply that an upper bound must be imposed on the amount of topology state information that can be distributed for traffic engineering. Additional considerations pertain to the trigger events that cause topology state information to be distributed and the relative frequency of such distributions. Solving the problem of control of topology state information distribution inherent in link state protocols is beyond the scope of this document. However, a solution is required to provide domain-wide traffic engineering in conjunction with a hierarchical IGP. We expect these problems to be addressed in documents that explicitly specify the protocol extensions for each IGP. 4.0 Data Distribution Requirements In addition to the requirement for distributing the basic topology of the traffic engineering domain, the IGP is required to transport other information about the network. This section describes the required information. Much of this information provides finer granularity details about the links in the network. To determine if the bandwidth requirements of an LSP will be accommodated on a particular link, it is necessary to know the bandwidth available on that link. Knowledge of bandwidth already consumed on the link is quite useful too. Also, if the domain's administrators impose a constraint on the proportion of a link's bandwidth that can be reserved, pertinent information regarding such reserveable bandwidth must be distributed. Another complication is introduced by the presence of multi-access, full duplex links with non-shared bandwidth. Currently, a common example of such a link is a switched Ethernet. Because each port on the switch has independent bandwidth, the inbound and outbound bandwidth on each interface must be tracked independently. To see the need for this more clearly, suppose that there is a Fast Ethernet (100Mbps) switch with three systems on it, say A, B, and C. Suppose that there is 100Mbps of reserved bandwidth from A to B. Notice that we can now reserve 100Mbps of bandwidth from B to C. However, if we try to reserve any bandwidth from C to B, we find that B's input is already saturated. This is true despite the fact that there is no reserved bandwidth on C's output. This example demonstrates that it is necessary to track and advertise reserved bandwidth on output interfaces, and for some interface types, it is necessary to track and advertise the reserved bandwidth on input interfaces as well. Hybrid links, which are comprised of different components operating at layer 2, are beyond the scope of this document. Such a hybrid link might, for example, be constructed by mixing an Ethernet switch with Ethernet hubs. Two systems that share a common hub only have the common bandwidth of the hub. However, systems that are directly on the switch can have the full-duplex bandwidth of each switch port available. The complexity of modeling such situations is a subject for future research and development. 4.1 Specific Data Element Requirements To be used for traffic engineering, an IGP should be able to transport at least the following data elements: 4.1.1 Maximum Link Bandwidth The maximum bandwidth available on a link. The amount of bandwidth is normally determined by the type of the physical link, or by traffic shaping parameters on NBMA interfaces. 4.1.2 Maximum Reservation Bandwidth The maximum total amount of bandwidth that can be reserved on an interface. Note that this may differ from the maximum bandwidth because administrators may choose to dedicate only part of the link's bandwidth to traffic engineering. Conversely, to exploit statistical multiplexing gain and insure high line utilization, the reservable bandwidth may exceed the actual bandwidth of the link. If the interface is a full-duplex multi-access interface, it is necessary to distribute both the maximum total amount of output bandwidth and the maximum total amount of input bandwidth. 4.1.3 Interface IP Address For point-to-point links, a protocol must be able to distribute the IP address of the system at the other end of the link. For multi- access links, a protocol must advertise the IP address of its interface into the multi-access link. These addresses are necessary for Constraint Based Routing to specify the path in the Explicit Route Object that is used by signaling protocols such as RSVP [2]. 4.1.4 Resource Class Attribute The resource class attributes for the link. The resource class is used by Constraint Based Routing as a means of determining which links are acceptable for a particular LSP, based on configured administrative policy. 4.1.5 Reserved Bandwidth The current amount of reserved bandwidth on the interface. Because traffic engineering supports preemption and multiple levels of priority, remote systems need to know the reserved bandwidth on a per-priority basis. Thus, a protocol must be able to communicate the amount of bandwidth reserved by each priority level. There are eight priority levels. Once again, if the interface is a full-duplex multi-access interface, it is necessary to distribute information on the current amount of reserved bandwidth for both the input and the output sides of the interface. 4.2 Comments Note that among these data elements, only the amount of bandwidth currently reserved and the actual bandwidth utilization are expected to be dynamic. All other data elements are not expected to change frequently. Any system generating the dynamic data elements must be careful to limit the frequency with which it distributes these data elements. The exact specification of such rate limiting is beyond the scope of this document. While these data elements are necessary for traffic engineering, the system may also take into account other data elements supported by a protocol or an implementation when performing path computation. 5.0 Acknowledgments The authors would like to thank Henk Smit and Der-Hwa Gan for their contributions. Also Curtis Villamizar, Dave Katz, and Joe Malcolm have provided valuable comments. 6.0 References [1] "Requirements for Traffic Engineering Over MPLS", D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, work in progress, draft- ietf-mpls-traffic-eng-00.txt, October 1998. [2] "Extensions to RSVP for LSP Tunnels", D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V. Srinivasan, work in progress, draft-ietf- mpls-rsvp-lsp-tunnel-00.txt, November 1998. [3] "OSPF Version 2", J. Moy, RFC 2328, April 1998. [4] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 10589, February 1990. [5] "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", R. Callon, RFC 1195, Dec. 1990. [6] "Opaque LSA", R. Coltun, RFC 2370, July 1998. 7.0 Authors' Addresses Tony Li Juniper Networks, Inc. 385 Ravendale Dr. Mountain View, CA 94043 Email: tli@juniper.net Fax: +1 650 526 8001 Voice: +1 650 526 8006 George Swallow Cisco Systems, Inc. 250 Apollo Dr. Chelmsford, MA 01824 Email: swallow@cisco.com Voice: +1 978 244 8143 Daniel O. Awduche UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031 Email: awduche@uu.net Voice: +1 703 208 5277