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