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