< draft-ietf-tewg-principles-00.txt   draft-ietf-tewg-principles-01.txt >
Internet Engineering Task Force Internet Engineering Task Force
INTERNET-DRAFT INTERNET-DRAFT
TE Working Group TE Working Group
Daniel O. Awduche Daniel O. Awduche
Expiration Date: February 2002 Movaz Networks Expiration Date: April 2002 Movaz Networks
Angela Chiu Angela Chiu
Celion Networks Celion Networks
Anwar Elwalid Anwar Elwalid
Lucent Technologies Lucent Technologies
Indra Widjaja Indra Widjaja
Lucent Technologies Lucent Technologies
XiPeng Xiao XiPeng Xiao
Photuris Photuris Inc.
Overview and Principles of Internet Traffic Engineering Overview and Principles of Internet Traffic Engineering
draft-ietf-tewg-principles-00.txt draft-ietf-tewg-principles-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract Abstract
This memo describes principles for Traffic Engineering (TE) in the This memo describes the principles of Traffic Engineering (TE) in the
Internet. The document is intended to promote better understanding Internet. The document is intended to promote better understanding
of the issues surrounding traffic engineering in IP networks, and to of the issues surrounding traffic engineering in IP networks, and to
provide a common basis for the development of traffic engineering provide a common basis for the development of traffic engineering
capabilities for the Internet. The principles, architectures, and capabilities for the Internet. The principles, architectures, and
methodologies for performance evaluation and performance optimization methodologies for performance evaluation and performance optimization
of operational IP networks are discussed throughout this document. of operational IP networks are discussed throughout this document.
The optimization goals of traffic engineering are to enhance the The optimization goals of traffic engineering are to enhance the
performance of IP traffic while utilizing network resources performance of IP traffic while utilizing network resources
economically and reliably. The document includes a set of generic economically and reliably. The document includes a set of generic
recommendations, and options for Internet traffic engineering. The recommendations, and options for Internet traffic engineering. The
skipping to change at page 3, line 14 skipping to change at page 3, line 14
4.5.4 MPLS..................................................33 4.5.4 MPLS..................................................33
4.5.5 IP Performance Metrics................................34 4.5.5 IP Performance Metrics................................34
4.5.6 Flow Measurement......................................34 4.5.6 Flow Measurement......................................34
4.5.7 Endpoint Congestion Management........................35 4.5.7 Endpoint Congestion Management........................35
4.6 Overview of ITU Activities Related to Traffic 4.6 Overview of ITU Activities Related to Traffic
Engineering................................................35 Engineering................................................35
4.7 Content Distribution.......................................36 4.7 Content Distribution.......................................36
5.0 Taxonomy of Traffic Engineering Systems.......................37 5.0 Taxonomy of Traffic Engineering Systems.......................37
5.1 Time-Dependent Versus State-Dependent......................37 5.1 Time-Dependent Versus State-Dependent......................37
5.2 Offline Versus Online......................................38 5.2 Offline Versus Online......................................38
5.3 Centralized Versus Distributed.............................38 5.3 Centralized Versus Distributed.............................39
5.4 Local Versus Global........................................39 5.4 Local Versus Global........................................39
5.5 Prescriptive Versus Descriptive............................39 5.5 Prescriptive Versus Descriptive............................39
5.6 Open-Loop Versus Closed-Loop...............................40 5.6 Open-Loop Versus Closed-Loop...............................40
5.7 Tactical vs Strategic......................................40 5.7 Tactical vs Strategic......................................40
6.0 Recommendations for Internet Traffic Engineering..............40 6.0 Recommendations for Internet Traffic Engineering..............40
6.1 Generic Non-functional Recommendations.....................41 6.1 Generic Non-functional Recommendations.....................41
6.2 Routing Recommendations....................................42 6.2 Routing Recommendations....................................42
6.3 Traffic Mapping Recommendations............................45 6.3 Traffic Mapping Recommendations............................45
6.4 Measurement Recommendations................................45 6.4 Measurement Recommendations................................45
6.5 Network Survivability......................................46 6.5 Network Survivability......................................46
6.5.1 Survivability in MPLS Based Networks..................48 6.5.1 Survivability in MPLS Based Networks..................48
6.5.2 Protection Option.....................................49 6.5.2 Protection Option.....................................49
6.6 Traffic Engineering in Diffserv Environments...............50 6.6 Traffic Engineering in Diffserv Environments...............50
6.7 Network Controllability....................................52 6.7 Network Controllability....................................52
7.0 Inter-Domain Considerations...................................52 7.0 Inter-Domain Considerations...................................52
8.0 Overview of Contemporary TE Practices in Operational 8.0 Overview of Contemporary TE Practices in Operational
IP Networks...................................................53 IP Networks...................................................54
9.0 Conclusion....................................................55 9.0 Conclusion....................................................58
10.0 Security Considerations......................................55 10.0 Security Considerations......................................58
11.0 Acknowledgments..............................................55 11.0 Acknowledgments..............................................58
12.0 References...................................................56 12.0 References...................................................58
13.0 Authors' Addresses...........................................60 13.0 Authors' Addresses...........................................63
1.0 Introduction 1.0 Introduction
This memo describes principles for Internet traffic engineering. The This memo describes the principles of Internet traffic engineering.
objective of the document is to articulate the general issues and The objective of the document is to articulate the general issues and
principles for Internet traffic engineering; and where appropriate to principles for Internet traffic engineering; and where appropriate to
provide recommendations, guidelines, and options for the development provide recommendations, guidelines, and options for the development
of online and offline Internet traffic engineering capabilities and of online and offline Internet traffic engineering capabilities and
support systems. support systems.
The document can aid service providers in devising and implementing The document can aid service providers in devising and implementing
traffic engineering solutions for their networks. Networking hardware traffic engineering solutions for their networks. Networking hardware
and software vendors will also find the document helpful in the and software vendors will also find the document helpful in the
development of mechanisms and support systems for the Internet development of mechanisms and support systems for the Internet
environment that support the traffic engineering function. environment that support the traffic engineering function.
skipping to change at page 52, line 43 skipping to change at page 52, line 43
these are often needed to operate correctly in times of network these are often needed to operate correctly in times of network
impairments (e.g. during network congestion or security attacks). impairments (e.g. during network congestion or security attacks).
7.0 Inter-Domain Considerations 7.0 Inter-Domain Considerations
Inter-domain traffic engineering is concerned with the performance Inter-domain traffic engineering is concerned with the performance
optimization for traffic that originates in one administrative domain optimization for traffic that originates in one administrative domain
and terminates in a different one. and terminates in a different one.
Traffic exchange between autonomous systems in the Internet occurs Traffic exchange between autonomous systems in the Internet occurs
through exterior gateway protocols. Currently, BGP-4 [BGP4] is the through exterior gateway protocols. Currently, BGP [BGP4] is the
standard exterior gateway protocol for the Internet. BGP-4 provides standard exterior gateway protocol for the Internet. BGP provides a
a number of attributes (e.g. local preference, AS path, and MED) and number of attributes and capabilities (e.g. route filtering) that can
capabilities (e.g. route filtering) that can be used for inter-domain be used for inter-domain traffic engineering. More specifically, BGP
traffic engineering. These mechanisms are generally effective, but permits the control of routing information and traffic exchange
they are usually applied in a trial-and-error fashion. A systematic between Autonomous Systems (AS's) in the Internet. BGP incorporates a
approach for inter-domain traffic engineering is yet to be devised. sequential decision process which calculates the degree of preference
for various routes to a given destination network. There are two
fundamental aspects to inter-domain traffic engineering using BGP:
Inter-domain traffic engineering is inherently more difficult than - Route Redistribution: controlling the import and export of routes
intra-domain TE under the current Internet architecture. The reasons between AS's, and controlling the redistribution of routes between
for this are both technical and administrative. Technically, while BGP and other protocols within an AS.
topology and link state information are helpful for mapping traffic
more effectively, BGP does not propagate such information across - Best path selection: selecting the best path when there are
domain boundaries for stability and scalability reasons. multiple candidate paths to a given destination network. Best path
Administratively, there are differences in operating costs and selection is performed by the BGP decision process based on a
network capacities between domains. Generally, what may be considered sequential procedure, taking a number of different considerations
a good solution in one domain may not necessarily be a good solution into account. Ultimately, best path selection under BGP boils down
in another domain. Moreover, it would generally be considered to selecting preferred exit points out of an AS towards
inadvisable for one domain to permit another domain to influence the specific destination networks. The BGP path selection process can
routing and management of traffic in its network. be influenced by manipulating the attributes associated with
the BGP decision process. These attributes include: NEXT-HOP,
WEIGHT (Cisco proprietary which is also implemented by some other
vendors), LOCAL-PREFERENCE, AS-PATH, ROUTE-ORIGIN,
MULTI-EXIT-DESCRIMINATOR (MED), IGP METRIC, etc.
Route-maps provide the flexibility to implement complex BGP policies
based on pre-configured logical conditions. In particular, Route-
maps can be used to control import and export policies for incoming
and outgoing routes, control the redistribution of routes between BGP
and other protocols, and influence the selection of best paths by
manipulating the attributes associated with the BGP decision process.
Very complex logical expressions that implement various types of
policies can be implemented using a combination of Route-maps, BGP-
attributes, Access-lists, and Community attributes.
When looking at possible strategies for inter-domain TE with BGP, it
must be noted that the outbound traffic exit point is controllable,
whereas the interconnection point where inbound traffic is received
from an EBGP peer typically is not, unless a special arrangement is
made with the peer sending the traffic. Therefore, it is up to each
individual network to implement sound TE strategies that deal with
the efficient delivery of outbound traffic from one's customers to
one's peering points. The vast majority of TE policy is based upon a
"closest exit" strategy, which relies on other networks to deliver
traffic to its final destination in the most efficient manner
possible. Most methods of manipulating the point at which inbound
traffic enters a network from an EBGP peer (inconsistent route
announcements between peering points, AS pre-pending, and sending
MEDs) are either ineffective, or not accepted in the peering
community.
Inter-domain TE with BGP is generally effective, but it is usually
applied in a trial-and-error fashion. A systematic approach for
inter-domain traffic engineering is yet to be devised.
Inter-domain TE is inherently more difficult than intra-domain TE
under the current Internet architecture. The reasons for this are
both technical and administrative. Technically, while topology and
link state information are helpful for mapping traffic more
effectively, BGP does not propagate such information across domain
boundaries for stability and scalability reasons. Administratively,
there are differences in operating costs and network capacities
between domains. Generally, what may be considered a good solution in
one domain may not necessarily be a good solution in another domain.
Moreover, it would generally be considered inadvisable for one domain
to permit another domain to influence the routing and management of
traffic in its network.
MPLS TE-tunnels (explicit LSPs) can potentially add a degree of MPLS TE-tunnels (explicit LSPs) can potentially add a degree of
flexibility in the selection of exit points for inter-domain routing. flexibility in the selection of exit points for inter-domain routing.
The concept of relative and absolute metrics can be applied to this The concept of relative and absolute metrics can be applied to this
purpose. The idea is that if BGP attributes are defined such that the purpose. The idea is that if BGP attributes are defined such that the
BGP decision process depends on IGP metrics to select exit points for BGP decision process depends on IGP metrics to select exit points for
inter-domain traffic, then some inter-domain traffic destined to a inter-domain traffic, then some inter-domain traffic destined to a
given peer network can be made to prefer a specific exit point by given peer network can be made to prefer a specific exit point by
establishing a TE-tunnel between the router making the selection to establishing a TE-tunnel between the router making the selection to
the peering point via a TE-tunnel and assigning the TE-tunnel a the peering point via a TE-tunnel and assigning the TE-tunnel a
skipping to change at page 53, line 36 skipping to change at page 54, line 30
Similar to intra-domain TE, inter-domain TE is best accomplished when Similar to intra-domain TE, inter-domain TE is best accomplished when
a traffic matrix can be derived to depict the volume of traffic from a traffic matrix can be derived to depict the volume of traffic from
one autonomous system to another. one autonomous system to another.
Generally, redistribution of inter-domain traffic requires Generally, redistribution of inter-domain traffic requires
coordination between peering partners. An export policy in one domain coordination between peering partners. An export policy in one domain
that results in load redistribution across peer points with another that results in load redistribution across peer points with another
domain can significantly affect the local traffic matrix inside the domain can significantly affect the local traffic matrix inside the
domain of the peering partner. This, in turn, will affect the intra- domain of the peering partner. This, in turn, will affect the intra-
domain TE due to changes in the spatial distribution traffic. domain TE due to changes in the spatial distribution of traffic.
Therefore, it is mutually beneficial for peering partners to Therefore, it is mutually beneficial for peering partners to
coordinate with each other before attempting any policy changes that coordinate with each other before attempting any policy changes that
may result in significant shifts in inter-domain traffic. In certain may result in significant shifts in inter-domain traffic. In certain
contexts, this coordination can be quite challenging due to technical contexts, this coordination can be quite challenging due to technical
and non- technical reasons. and non- technical reasons.
It is a matter of speculation as to whether MPLS, or similar It is a matter of speculation as to whether MPLS, or similar
technologies, can be extended to allow selection of constrained paths technologies, can be extended to allow selection of constrained paths
across domain boundaries. across domain boundaries.
8.0 Overview of Contemporary TE Practices in Operational IP Networks 8.0 Overview of Contemporary TE Practices in Operational IP Networks
This section provides an overview of some contemporary traffic This section provides an overview of some contemporary traffic
engineering practices in IP networks. The focus is primarily on the engineering practices in IP networks. The focus is primarily on the
aspects that pertain to the control of the routing function in aspects that pertain to the control of the routing function in
operational contexts. The intent here is to provide an overview of operational contexts. The intent here is to provide an overview of
the commonly used practices. The discussion is not intended to be the commonly used practices. The discussion is not intended to be
exhaustive. exhaustive.
Currently, service providers apply many of the traffic engineering Currently, service providers apply many of the traffic engineering
mechanisms discussed in this document to optimize the performance of mechanisms discussed in this document to optimize the performance of
skipping to change at page 55, line 27 skipping to change at page 56, line 20
In an MPLS domain, a traffic matrix can also be estimated by In an MPLS domain, a traffic matrix can also be estimated by
monitoring the traffic on LSPs. Such traffic statistics can be used monitoring the traffic on LSPs. Such traffic statistics can be used
for a variety of purposes including network planning and network for a variety of purposes including network planning and network
optimization. Current practice suggests that deploying an MPLS optimization. Current practice suggests that deploying an MPLS
network consisting of hundreds of routers and thousands of LSPs is network consisting of hundreds of routers and thousands of LSPs is
feasible. In summary, recent deployment experience suggests that MPLS feasible. In summary, recent deployment experience suggests that MPLS
approach is very effective for traffic engineering in IP networks approach is very effective for traffic engineering in IP networks
[XIAO]. [XIAO].
As mentioned previously in Section 7.0, one usually has no direct
control over the distribution of inbound traffic. Therefore, the
main goal of contemporary inter-domain TE is to optimize the
distribution of outbound traffic between multiple inter-domain links.
When operating a global network, maintaining the ability to operate
the network in a regional fashion where desired, while continuing to
take advantage of the benefits of a global network, also becomes an
important objective.
Inter-domain TE with BGP usually begins with the placement of
multiple peering interconnection points in locations that have high
peer density, are in close proximity to originating/terminating
traffic locations on one's own network, and are lowest in cost.
There are generally several locations in each region of the world
where the vast majority of major networks congregate and
interconnect. Some location-decision problems that arise in
association with inter-domain routing are discussed in [AWD5].
Once the locations of the interconnects are determined, and circuits
are implemented, one decides how best to handle the routes heard from
the peer, as well as how to propagate the peers' routes within one's
own network. One way to engineer outbound traffic flows on a network
with many EBGP peers is to create a hierarchy of peers. Generally,
the Local Preferences of all peers are set to the same value so that
the shortest AS paths will be chosen to forward traffic. Then, by
over-writing the inbound MED metric (Multi-exit-discriminator metric,
also referred to as "BGP metric". Both terms are used interchangeably
in this document) with BGP metrics to routes received at different
peers, the hierarchy can be formed. For example, all Local
Preferences can be set to 200, preferred private peers can be
assigned a BGP metric of 50, the rest of the private peers can be
assigned a BGP metric of 100, and public peers can be assigned a BGP
metric of 600. "Preferred" peers might be defined as those peers
with whom the most available capacity exists, whose customer base is
larger in comparison to other peers, whose interconnection costs are
the lowest, and with whom upgrading existing capacity is the easiest.
In a network with low utilization at the edge, this works well. The
same concept could be applied to a network with higher edge
utilization by creating more levels of BGP metrics between peers,
allowing for more granularity in selecting the exit points for
traffic bound for a dual homed customer on a peer's network.
By only replacing inbound MED metrics with BGP metrics, only equal
AS-Path length routes' exit points are being changed. (The BGP
decision considers Local Preference first, then AS-Path length, and
then BGP metric). For example, assume a network has two possible
egress points, peer A and peer B. Each peer has 40% of the
Internet's routes exclusively on its network, while the remaining 20%
of the Internet's routes are from customers who dual home between A
and B. Assume that both peers have a Local Preference of 200 and a
BGP metric of 100. If the link to peer A is congested, increasing
its BGP metric while leaving the Local Preference at 200 will ensure
that the 20% of total routes belonging to dual homed customers will
prefer peer B as the exit point. The previous example would be used
in a situation where all exit points to a given peer were close to
congestion levels, and traffic needed to be shifted away from that
peer entirely.
When there are multiple exit points to a given peer, and only one of
them is congested, it is not necessary to shift traffic away from the
peer entirely, but only from the one congested circuit. This can be
achieved by using passive IGP-metrics, AS-path filtering, or prefix
filtering.
Occasionally, more drastic changes are needed, for example, in
dealing with a "problem peer" who is difficult to work with on
upgrades or is charging high prices for connectivity to their
network. In that case, the Local Preference to that peer can be
reduced below the level of other peers. This effectively reduces the
amount of traffic sent to that peer to only originating traffic
(assuming no transit providers are involved). This type of change
can affect a large amount of traffic, and is only used after other
methods have failed to provide the desired results.
Although it is not much of an issue in regional networks, the
propagation of a peer's routes back through the network must be
considered when a network is peering on a global scale. Sometimes,
business considerations can influence the choice of BGP policies in a
given context. For example, it may be imprudent, from a business
perspective, to operate a global network and provide full access to
the global customer base to a small network in a particular country.
However, for the purpose of providing one's own customers with
quality service in a particular region, good connectivity to that
in-country network may still be necessary. This can be achieved by
assigning a set of communities at the edge of the network, which have
a known behavior when routes tagged with those communities are
propagating back through the core. Routes heard from local peers
will be prevented from propagating back to the global network,
whereas routes learned from larger peers may be allowed to propagate
freely throughout the entire global network. By implementing a
flexible community strategy, the benefits of using a single global AS
Number (ASN) can be realized, while the benefits of operating
regional networks can also be taken advantage of. An alternative to
doing this is to use different ASNs in different regions, with the
consequence that the AS path length for routes announced by that
service provider will increase.
9.0 Conclusion 9.0 Conclusion
This document described principles for traffic engineering in the This document described principles for traffic engineering in the
Internet. It presented an overview of some of the basic issues Internet. It presented an overview of some of the basic issues
surrounding traffic engineering in IP networks. The context of TE was surrounding traffic engineering in IP networks. The context of TE was
described, a TE process models and a taxonomy of TE styles were described, a TE process models and a taxonomy of TE styles were
presented. A brief historical review of pertinent developments presented. A brief historical review of pertinent developments
related to traffic engineering was provided. A survey of contemporary related to traffic engineering was provided. A survey of contemporary
TE techniques in operational networks was presented. Additionally, TE techniques in operational networks was presented. Additionally,
the document specified a set of generic requirements, the document specified a set of generic requirements,
skipping to change at page 55, line 49 skipping to change at page 58, line 31
10.0 Security Considerations 10.0 Security Considerations
This document does not introduce new security issues. This document does not introduce new security issues.
11.0 Acknowledgments 11.0 Acknowledgments
The authors would like to thank Jim Boyle for inputs on the The authors would like to thank Jim Boyle for inputs on the
recommendations section, Francois Le Faucheur for inputs on Diffserv recommendations section, Francois Le Faucheur for inputs on Diffserv
aspects, Blaine Christian for inputs on measurement, Gerald Ash for aspects, Blaine Christian for inputs on measurement, Gerald Ash for
inputs on routing in telephone networks and for text on event- inputs on routing in telephone networks and for text on event-
dependent TE methods , and Steven Wright for inputs on network dependent TE methods ,Steven Wright for inputs on network
controllability. Special thanks to Randy Bush for proposing the TE controllability, and Jonathan Aufderheide for inputs on inter-domain
TE with BGP. Special thanks to Randy Bush for proposing the TE
taxonomy based on "tactical vs strategic" methods. The subsection taxonomy based on "tactical vs strategic" methods. The subsection
describing an "Overview of ITU Activities Related to Traffic describing an "Overview of ITU Activities Related to Traffic
Engineering" was adapted from a contribution by Waisum Lai. Useful Engineering" was adapted from a contribution by Waisum Lai. Useful
feedback and pointers to relevant materials were provided by J. Noel feedback and pointers to relevant materials were provided by J. Noel
Chiappa. Additional comments were provided by Glenn Grotefeld during Chiappa. Additional comments were provided by Glenn Grotefeld during
the working last call process. Finally, the authors would like to the working last call process. Finally, the authors would like to
thank Ed Kern, the TEWG co-chair, for his comments and support. thank Ed Kern, the TEWG co-chair, for his comments and support.
12.0 References 12.0 References
 End of changes. 14 change blocks. 
38 lines changed or deleted 188 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/