< draft-ietf-tewg-framework-04.txt   draft-ietf-tewg-framework-05.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: October 2001 Movaz Networks Expiration Date: November 2001 Movaz Networks
Angela Chiu Angela Chiu
Celion Networks Celion Networks
Anwar Elwalid Anwar Elwalid
Lucent Technologies Lucent Technologies
Indra Widjaja Indra Widjaja
Fujitsu Network Communications Lucent Technologies
XiPeng Xiao XiPeng Xiao
Photuris Photuris
A Framework for Internet Traffic Engineering A Framework for Internet Traffic Engineering
draft-ietf-tewg-framework-04.txt draft-ietf-tewg-framework-05.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.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
performance of IP traffic while utilizing network resources performance of IP traffic while utilizing network resources
economically and reliably. The framework includes a set of generic economically and reliably. The framework includes a set of generic
recommendations, and options for Internet traffic engineering. The recommendations, and options for Internet traffic engineering. The
framework can serve as a guide to implementors of online and offline framework can serve as a guide to implementors of online and offline
Internet traffic engineering mechanisms, tools, and support systems. Internet traffic engineering mechanisms, tools, and support systems.
The framework can also help service providers devise traffic The framework can also help service providers devise traffic
engineering solutions for their networks. engineering solutions for their networks.
Table of Contents Table of Contents
1.0 Introduction...................................................3 1.0 Introduction...................................................3
1.1 What is Internet Traffic Engineering?.......................4 1.1 What is Internet Traffic Engineering?.......................4
1.2 Scope.......................................................7 1.2 Scope.......................................................7
1.3 Terminology.................................................8 1.3 Terminology.................................................8
2.0 Background....................................................11 2.0 Background....................................................11
2.1 Context of Internet Traffic Engineering....................11 2.1 Context of Internet Traffic Engineering....................11
2.2 Network Context............................................12 2.2 Network Context............................................12
2.3 Problem Context............................................14 2.3 Problem Context............................................14
2.3.1 Congestion and its Ramifications......................15 2.3.1 Congestion and its Ramifications......................15
2.4 Solution Context...........................................15 2.4 Solution Context...........................................15
2.4.1 Combating the Congestion Problem......................17 2.4.1 Combating the Congestion Problem......................17
2.5 Implementation and Operational Context.....................19 2.5 Implementation and Operational Context.....................19
3.0 Traffic Engineering Process Model.............................20 3.0 Traffic Engineering Process Model.............................20
3.1 Components of the Traffic Engineering Process Model........21 3.1 Components of the Traffic Engineering Process Model........21
3.2 Measurement................................................21 3.2 Measurement................................................21
3.3 Modeling, Analysis, and Simulation.........................22 3.3 Modeling, Analysis, and Simulation.........................22
3.4 Optimization...............................................23 3.4 Optimization...............................................23
4.0 Historical Review and Recent Developments.....................24 4.0 Historical Review and Recent Developments.....................24
4.1 Traffic Engineering in Classical Telephone Networks........24 4.1 Traffic Engineering in Classical Telephone Networks........24
4.2 Evolution of Traffic Engineering in the Internet...........26 4.2 Evolution of Traffic Engineering in the Internet...........26
4.2.1 Adaptive Routing in ARPANET...........................26 4.2.1 Adaptive Routing in ARPANET...........................26
4.2.2 Dynamic Routing in the Internet.......................27 4.2.2 Dynamic Routing in the Internet.......................27
4.2.3 ToS Routing...........................................27 4.2.3 ToS Routing...........................................27
4.2.4 Equal Cost MultiPath..................................28 4.2.4 Equal Cost Multi-Path.................................28
4.2.5 Nimrod................................................28 4.2.5 Nimrod................................................28
4.3 Overlay Model..............................................29 4.3 Overlay Model..............................................29
4.4 Constraint-Based Routing...................................29 4.4 Constraint-Based Routing...................................29
4.5 Overview of Other IETF Projects Related to Traffic 4.5 Overview of Other IETF Projects Related to Traffic
Engineering................................................30 Engineering................................................30
4.5.1 Integrated Services...................................30 4.5.1 Integrated Services...................................30
4.5.2 RSVP..................................................31 4.5.2 RSVP..................................................31
4.5.3 Differentiated Services...............................32 4.5.3 Differentiated Services...............................32
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
5.0 Taxonomy of Traffic Engineering Systems.......................36 4.7 Content Distribution.......................................36
5.1 Time-Dependent Versus State-Dependent......................36 5.0 Taxonomy of Traffic Engineering Systems.......................37
5.2 Offline Versus Online......................................38 5.1 Time-Dependent Versus State-Dependent......................37
5.3 Centralized Versus Distributed.............................38 5.2 Offline Versus Online......................................38
5.4 Local Versus Global........................................38 5.3 Centralized Versus Distributed.............................38
5.5 Prescriptive Versus Descriptive............................39 5.4 Local Versus Global........................................39
5.6 Open-Loop Versus Closed-Loop...............................39 5.5 Prescriptive Versus Descriptive............................39
5.7 Tactical vs Strategic......................................39 5.6 Open-Loop Versus Closed-Loop...............................40
6.0 Recommendations for Internet Traffic Engineering..............40 5.7 Tactical vs Strategic......................................40
6.1 Generic Non-functional Recommendations.....................40 6.0 Recommendations for Internet Traffic Engineering..............40
6.2 Routing Recommendations....................................42 6.1 Generic Non-functional Recommendations.....................41
6.3 Traffic Mapping Recommendations............................44 6.2 Routing Recommendations....................................42
6.4 Measurement Recommendations................................45 6.3 Traffic Mapping Recommendations............................45
6.5 Network Survivability......................................46 6.4 Measurement Recommendations................................45
6.5.1 Survivability in MPLS Based Networks..................48 6.5 Network Survivability......................................46
6.5.2 Protection Option.....................................49 6.5.1 Survivability in MPLS Based Networks..................48
6.6 Content Distribution Recommendations.......................49 6.5.2 Protection Option.....................................49
6.7 Traffic Engineering in Diffserv Environments...............50 6.6 Traffic Engineering in Diffserv Environments...............50
6.8 Network Controllability....................................52 6.7 Network Controllability....................................52
7.0 Inter-Domain Considerations...................................53 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...................................................54 IP Networks...................................................53
9.0 Conclusion....................................................56 9.0 Conclusion....................................................55
10.0 Security Considerations......................................56 10.0 Security Considerations......................................55
11.0 Acknowledgments..............................................56 11.0 Acknowledgments..............................................55
12.0 References...................................................56 12.0 References...................................................56
13.0 Authors' Addresses...........................................61 13.0 Authors' Addresses...........................................60
1.0 Introduction 1.0 Introduction
This memo describes a framework for Internet traffic engineering. This memo describes a framework for Internet traffic engineering.
The 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.
skipping to change at page 4, line 47 skipping to change at page 4, line 47
include delay, delay variation, packet loss, and throughput. include delay, delay variation, packet loss, and throughput.
An important objective of Internet traffic engineering is to An important objective of Internet traffic engineering is to
facilitate reliable network operations [RFC-2702]. Reliable network facilitate reliable network operations [RFC-2702]. Reliable network
operations can be facilitated by providing mechanisms that enhance operations can be facilitated by providing mechanisms that enhance
network integrity and by embracing policies emphasizing network network integrity and by embracing policies emphasizing network
survivability. This results in a minimization of the vulnerability of survivability. This results in a minimization of the vulnerability of
the network to service outages arising from errors, faults, and the network to service outages arising from errors, faults, and
failures occurring within the infrastructure. failures occurring within the infrastructure.
An Internet exists in order to transfer information from source nodes The Internet exists in order to transfer information from source
to destination nodes. Accordingly, one of the most significant nodes to destination nodes. Accordingly, one of the most significant
functions performed by an Internet is the routing of traffic from functions performed by the Internet is the routing of traffic from
ingress nodes to egress nodes. Therefore, one of the most distinctive ingress nodes to egress nodes. Therefore, one of the most distinctive
functions performed by Internet traffic engineering is the control functions performed by Internet traffic engineering is the control
and optimization of the routing function, to steer traffic through and optimization of the routing function, to steer traffic through
the network in the most effective way. the network in the most effective way.
Ultimately, it is the performance of the network as seen by end users Ultimately, it is the performance of the network as seen by end users
of network services that is truly paramount. This crucial point of network services that is truly paramount. This crucial point
should be considered throughout the development of traffic should be considered throughout the development of traffic
engineering mechanisms and policies. The characteristics visible to engineering mechanisms and policies. The characteristics visible to
end users are the emergent properties of the network, which are the end users are the emergent properties of the network, which are the
skipping to change at page 6, line 17 skipping to change at page 6, line 17
states. It may also take perfective action to induce a more states. It may also take perfective action to induce a more
desirable state in the future. In the reactive case, the control desirable state in the future. In the reactive case, the control
system responds correctively and perhaps adaptively to events that system responds correctively and perhaps adaptively to events that
have already transpired in the network. have already transpired in the network.
The control dimension of Internet traffic engineering responds at The control dimension of Internet traffic engineering responds at
multiple levels of temporal resolution to network events. Certain multiple levels of temporal resolution to network events. Certain
aspects of capacity management, such as capacity planning, respond at aspects of capacity management, such as capacity planning, respond at
very coarse temporal levels, ranging from days to possibly years. The very coarse temporal levels, ranging from days to possibly years. The
introduction of automatically switched optical transport networks introduction of automatically switched optical transport networks
(e.g. based on the Multiprotocol Lambda Switching concepts) could (e.g. based on the Multi-protocol Lambda Switching concepts) could
significantly reduce the lifecycle for capacity planning by significantly reduce the lifecycle for capacity planning by
expediting provisioning of optical bandwidth. Routing control expediting provisioning of optical bandwidth. Routing control
functions operate at intermediate levels of temporal resolution, functions operate at intermediate levels of temporal resolution,
ranging from milliseconds to days. Finally, the packet level ranging from milliseconds to days. Finally, the packet level
processing functions (e.g. rate shaping, queue management, and processing functions (e.g. rate shaping, queue management, and
scheduling) operate at very fine levels of temporal resolution, scheduling) operate at very fine levels of temporal resolution,
ranging from picoseconds to milliseconds while responding to the ranging from picoseconds to milliseconds while responding to the
real-time statistical behavior of traffic. The subsystems of Internet real-time statistical behavior of traffic. The subsystems of Internet
traffic engineering control include: capacity augmentation, routing traffic engineering control include: capacity augmentation, routing
control, traffic control, and resource control (including control of control, traffic control, and resource control (including control of
service policies at network elements). When capacity is to be service policies at network elements). When capacity is to be
augmented for tactical purposes, it may be desirable to devise a augmented for tactical purposes, it may be desirable to devise a
deployment plan expedites bandwidth provisioning while minimizing deployment plan that expedites bandwidth provisioning while
installation costs. minimizing installation costs.
Inputs into the traffic engineering control system include network Inputs into the traffic engineering control system include network
state variables, policy variables, and decision variables. state variables, policy variables, and decision variables.
One major challenge of Internet traffic engineering is the One major challenge of Internet traffic engineering is the
realization of automated control capabilities that adapt quickly and realization of automated control capabilities that adapt quickly and
cost effectively to significant changes in a network's state, while cost effectively to significant changes in a network's state, while
still maintaining stability. still maintaining stability.
Another critical dimension of Internet traffic engineering is network Another critical dimension of Internet traffic engineering is network
skipping to change at page 7, line 48 skipping to change at page 7, line 48
domain traffic control, including such issues as routing control, domain traffic control, including such issues as routing control,
micro and macro resource allocation, and the control coordination micro and macro resource allocation, and the control coordination
problems that arise consequently. problems that arise consequently.
This document will describe and characterize techniques already in This document will describe and characterize techniques already in
use or in advanced development for Internet traffic engineering. The use or in advanced development for Internet traffic engineering. The
way these techniques fit together will be discussed and scenarios in way these techniques fit together will be discussed and scenarios in
which they are useful will be identified. which they are useful will be identified.
Although the emphasis is on intra-domain traffic engineering, in Although the emphasis is on intra-domain traffic engineering, in
Section 7.0, however, an overview of the high level considerations Section 7.0, an overview of the high level considerations pertaining
pertaining to inter-domain traffic engineering will be provided. to inter-domain traffic engineering will be provided. inter-domain
Inter-domain Internet traffic engineering is crucial to the Internet traffic engineering is crucial to the performance
performance enhancement of the global Internet infrastructure. enhancement of the global Internet infrastructure.
Whenever possible, relevant requirements from existing IETF documents Whenever possible, relevant requirements from existing IETF documents
and other sources will be incorporated by reference. and other sources will be incorporated by reference.
1.3 Terminology 1.3 Terminology
This subsection provides terminology which is useful for Internet This subsection provides terminology which is useful for Internet
traffic engineering. The definitions presented apply to this traffic engineering. The definitions presented apply to this
framework document. These terms may have other meanings elsewhere. framework document. These terms may have other meanings elsewhere.
- Baseline analysis: - Baseline analysis:
A study conducted to serve as a baseline for comparison to the A study conducted to serve as a baseline for comparison to the
actual behavior of the network. actual behavior of the network.
- Busy hour: - Busy hour:
A one hour period within a specified interval of time A one hour period within a specified interval of time
(typically 24 hours) in which the traffic load in a (typically 24 hours) in which the traffic load in a
network or subnetwork is greatest. network or sub-network is greatest.
- Bottleneck - Bottleneck
A network element whose input traffic rate tends to be greater A network element whose input traffic rate tends to be greater
than its output rate. than its output rate.
- Congestion: - Congestion:
A state of a network resource in which the traffic incident A state of a network resource in which the traffic incident
on the resource exceeds its output capacity over an interval on the resource exceeds its output capacity over an interval
of time. of time.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
An approach to congestion management that attempts to obviate An approach to congestion management that attempts to obviate
the occurrence of congestion. the occurrence of congestion.
- Congestion control: - Congestion control:
An approach to congestion management that attempts to remedy An approach to congestion management that attempts to remedy
congestion problems that have already occurred. congestion problems that have already occurred.
- Constraint-based routing: - Constraint-based routing:
A class of routing protocols that take specified traffic A class of routing protocols that take specified traffic
attributes, network constraints, and policy constraints into attributes, network constraints, and policy constraints into
account in making routing decisions. Constraint-based routing account when making routing decisions. Constraint-based
is applicable to traffic aggregates as well as flows. It is a routing is applicable to traffic aggregates as well as flows.
generalization of QoS routing. It is a generalization of QoS routing.
- Demand side congestion management: - Demand side congestion management:
A congestion management scheme that addresses congestion A congestion management scheme that addresses congestion
problems by regulating or conditioning offered load. problems by regulating or conditioning offered load.
- Effective bandwidth: - Effective bandwidth:
The minimum amount of bandwidth that can be assigned to a flow The minimum amount of bandwidth that can be assigned to a flow
or traffic aggregate in order to deliver 'acceptable service or traffic aggregate in order to deliver 'acceptable service
quality' to the flow or traffic aggregate. quality' to the flow or traffic aggregate.
skipping to change at page 11, line 40 skipping to change at page 11, line 40
service models to resolve resource contention issues arising from service models to resolve resource contention issues arising from
mutual interference between packets traversing through the network. mutual interference between packets traversing through the network.
Thus, consideration must be given to resolving competition for Thus, consideration must be given to resolving competition for
network resources between traffic streams belonging to the same network resources between traffic streams belonging to the same
service class (intra-class contention resolution) and traffic streams service class (intra-class contention resolution) and traffic streams
belonging to different classes (inter-class contention resolution). belonging to different classes (inter-class contention resolution).
2.1 Context of Internet Traffic Engineering 2.1 Context of Internet Traffic Engineering
The context of Internet traffic engineering pertains to the scenarios The context of Internet traffic engineering pertains to the scenarios
in which the problems that traffic engineering attempts to solve where traffic engineering is used. A traffic engineering methodology
manifest. A traffic engineering methodology establishes appropriate establishes appropriate rules to resolve traffic performance issues
rules to resolve traffic performance issues occurring in a specific occurring in a specific context. The context of Internet traffic
context. The context of Internet traffic engineering includes: engineering includes:
(1) A network context defining the universe of discourse, (1) A network context defining the universe of discourse,
and in particular the situations in which the traffic and in particular the situations in which the traffic
engineering problems occur. The network context engineering problems occur. The network context
encompasses network structure, network policies, network includes network structure, network policies, network
characteristics, network constraints, network quality characteristics, network constraints, network quality
attributes, network optimization criteria, etc. attributes, and network optimization criteria.
(2) A problem context defining the general and concrete (2) A problem context defining the general and concrete
issues that traffic engineering addresses. The problem issues that traffic engineering addresses. The problem
context encompasses identification, abstraction of relevant context includes identification, abstraction of relevant
features, representation, formulation, specification of features, representation, formulation, specification of
the requirements on the solution space, specification the requirements on the solution space, and specification
of the desirable features of acceptable solutions, etc. of the desirable features of acceptable solutions.
(3) A solution context suggesting how to solve the traffic (3) A solution context suggesting how to address the issues
engineering problems. The solution context encompasses identified by the problem context. The solution context
analysis, evaluation of alternatives, prescription, and includes analysis, evaluation of alternatives,
resolution. prescription, and resolution.
(4) An implementation and operational context in which the (4) An implementation and operational context in which the
solutions are methodologically instantiated. The solutions are methodologically instantiated. The
implementation and operational context encompasses implementation and operational context includes
planning, organization, and execution. planning, organization, and execution.
The context of Internet traffic engineering and the different problem The context of Internet traffic engineering and the different problem
scenarios are discussed in the following subsections. scenarios are discussed in the following subsections.
2.2 Network Context 2.2 Network Context
IP networks range in size from small clusters of routers situated IP networks range in size from small clusters of routers situated
within a given location, to thousands of interconnected routers, within a given location, to thousands of interconnected routers,
switches, and other components distributed all over the world. switches, and other components distributed all over the world.
skipping to change at page 14, line 37 skipping to change at page 14, line 37
A network-wide view of the topology is also a must for offline A network-wide view of the topology is also a must for offline
planning. planning.
Still another class of problems concerns how to characterize the Still another class of problems concerns how to characterize the
state of the network and how to evaluate its performance under a state of the network and how to evaluate its performance under a
variety of scenarios. The performance evaluation problem is two-fold. variety of scenarios. The performance evaluation problem is two-fold.
One aspect of this problem relates to the evaluation of the system One aspect of this problem relates to the evaluation of the system
level performance of the network. The other aspect relates to the level performance of the network. The other aspect relates to the
evaluation of the resource level performance, which restricts evaluation of the resource level performance, which restricts
attention to the performance analysis of individual network attention to the performance analysis of individual network
resources. In this memo, we shall refer to the system level resources. In this memo, we refer to the system level characteristics
characteristics of the network as the "macro-states" and the resource of the network as the "macro-states" and the resource level
level characteristics as the "micro-states." The system level characteristics as the "micro-states." The system level
characteristics are also known as the emergent properties of the characteristics are also known as the emergent properties of the
network as noted earlier. Correspondingly, we shall refer to the network as noted earlier. Correspondingly, we shall refer to the
traffic engineering schemes dealing with network performance traffic engineering schemes dealing with network performance
optimization at the systems level as "macro-TE" and the schemes that optimization at the systems level as "macro-TE" and the schemes that
optimize at the individual resource level as "micro-TE." Under optimize at the individual resource level as "micro-TE." Under
certain circumstances, the system level performance can be derived certain circumstances, the system level performance can be derived
from the resource level performance using appropriate rules of from the resource level performance using appropriate rules of
composition, depending upon the particular performance measures of composition, depending upon the particular performance measures of
interest. interest.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
necessity for routing analysis. A network topology model may be necessity for routing analysis. A network topology model may be
extracted from network architecture documents, from network designs, extracted from network architecture documents, from network designs,
from information contained in router configuration files, from from information contained in router configuration files, from
routing databases, from routing tables, or from automated tools that routing databases, from routing tables, or from automated tools that
discover and depict network topology information. Topology discover and depict network topology information. Topology
information may also be derived from servers that monitor network information may also be derived from servers that monitor network
state, and from servers that perform provisioning functions. state, and from servers that perform provisioning functions.
Routing in operational IP networks can be administratively controlled Routing in operational IP networks can be administratively controlled
at various levels of abstraction including the manipulation of BGP at various levels of abstraction including the manipulation of BGP
attributes; manipulation of IGP metrics. For path oriented attributes and manipulation of IGP metrics. For path oriented
technologies such as MPLS and its derivatives, routing can be further technologies such as MPLS, routing can be further controlled by the
controlled by the manipulation of relevant traffic engineering manipulation of relevant traffic engineering parameters, resource
parameters, resource parameters, and administrative policy parameters, and administrative policy constraints. Within the
constraints. Within the context of MPLS, the path of an explicit context of MPLS, the path of an explicit label switched path (LSP)
label switched path (LSP) can be computed and established in various can be computed and established in various ways including: (1)
ways including: (1) manually, (2) automatically online using manually, (2) automatically online using constraint-based routing
constraint-based routing processes implemented on label switching processes implemented on label switching routers, and (3)
routers, and (3) automatically offline using constraint-based routing automatically offline using constraint-based routing entities
entities implemented on external traffic engineering support systems. implemented on external traffic engineering support systems.
2.4.1 Combating the Congestion Problem 2.4.1 Combating the Congestion Problem
Minimizing congestion is a significant aspect of Internet traffic Minimizing congestion is a significant aspect of Internet traffic
engineering. This subsection gives an overview of the general engineering. This subsection gives an overview of the general
approaches that have been used or proposed to combat congestion approaches that have been used or proposed to combat congestion
problems. problems.
Congestion management policies can be categorized based upon the Congestion management policies can be categorized based upon the
following criteria (see e.g., [YARE95] for a more detailed taxonomy following criteria (see e.g., [YARE95] for a more detailed taxonomy
skipping to change at page 18, line 33 skipping to change at page 18, line 33
buffer management. These mechanisms are used to control congestion buffer management. These mechanisms are used to control congestion
and/or signal congestion to end systems so that they can adaptively and/or signal congestion to end systems so that they can adaptively
regulate the rate at which traffic is injected into the network. One regulate the rate at which traffic is injected into the network. One
of the most popular active queue management schemes, especially for of the most popular active queue management schemes, especially for
TCP traffic, is Random Early Detection (RED) [FLJA93], which supports TCP traffic, is Random Early Detection (RED) [FLJA93], which supports
congestion avoidance by controlling the average queue size. During congestion avoidance by controlling the average queue size. During
congestion (but before the queue is filled), the RED scheme chooses congestion (but before the queue is filled), the RED scheme chooses
arriving packets to "mark" according to a probabilistic algorithm arriving packets to "mark" according to a probabilistic algorithm
which takes into account the average queue size. For a router that which takes into account the average queue size. For a router that
does not utilize explicit congestion notification (ECN) see e.g., does not utilize explicit congestion notification (ECN) see e.g.,
[FLOY94]), the marked packets can simply be dropped to signal the [FLOY94], the marked packets can simply be dropped to signal the
inception of congestion to end systems. On the other hand, if the inception of congestion to end systems. On the other hand, if the
router supports ECN, then it can set the ECN field in the packet router supports ECN, then it can set the ECN field in the packet
header. Several variations of RED have been proposed to support header. Several variations of RED have been proposed to support
different drop precedence levels in multiclass environments [RFC- different drop precedence levels in multi-class environments [RFC-
2597], e.g., RED with In and Out (RIO) and Weighted RED. There is 2597], e.g., RED with In and Out (RIO) and Weighted RED. There is
general consensus that RED provides congestion avoidance performance general consensus that RED provides congestion avoidance performance
which is not worse than traditional Tail-Drop (TD) queue management which is not worse than traditional Tail-Drop (TD) queue management
(drop arriving packets only when the queue is full). Importantly, (drop arriving packets only when the queue is full). Importantly,
however, RED reduces the possibility of global synchronization and however, RED reduces the possibility of global synchronization and
improves fairness among different TCP sessions. However, RED by improves fairness among different TCP sessions. However, RED by
itself can not prevent congestion and unfairness caused by itself can not prevent congestion and unfairness caused by sources
unresponsive sources, e.g., UDP traffic and some misbehaved greedy unresponsive to RED, e.g., UDP traffic and some misbehaved greedy
connections. Other schemes have been proposed to improve the connections. Other schemes have been proposed to improve the
performance and fairness in the presence of unresponsive traffic. performance and fairness in the presence of unresponsive traffic.
Some of these schemes were proposed as theoretical frameworks and are Some of these schemes were proposed as theoretical frameworks and are
typically not available in existing commercial products. Two such typically not available in existing commercial products. Two such
schemes are Longest Queue Drop (LQD) and Dynamic Soft Partitioning schemes are Longest Queue Drop (LQD) and Dynamic Soft Partitioning
with Random Drop (RND) [SLDC98]. with Random Drop (RND) [SLDC98].
(2) Congestion Management: Reactive versus Preventive Schemes (2) Congestion Management: Reactive versus Preventive Schemes
- Reactive: reactive (recovery) congestion management policies react - Reactive: reactive (recovery) congestion management policies react
to existing congestion problems to improve it. All the policies to existing congestion problems to improve it. All the policies
described in the long and medium time scales above can be categorized described in the long and medium time scales above can be categorized
as being reactive especially if the policies are based on monitoring as being reactive especially if the policies are based on monitoring
and identifying existing congestion problems, and on the initiation and identifying existing congestion problems, and on the initiation
of relevant actions to ease the situation. of relevant actions to ease a situation.
- Preventive: preventive (predictive/avoidance) policies take - Preventive: preventive (predictive/avoidance) policies take
proactive action to prevent congestion based on estimates and proactive action to prevent congestion based on estimates and
predictions of future potential congestion problems. Some of the predictions of future potential congestion problems. Some of the
policies described in the long and medium time scales fall into this policies described in the long and medium time scales fall into this
category. They do not necessarily respond immediately to existing category. They do not necessarily respond immediately to existing
congestion problems. Instead forecasts of traffic demand and workload congestion problems. Instead forecasts of traffic demand and workload
distribution are considered and action may be taken to prevent distribution are considered and action may be taken to prevent
potential congestion problems in the future. The schemes described in potential congestion problems in the future. The schemes described in
the short time scale (e.g., RED and its variations, ECN, LQD, and the short time scale (e.g., RED and its variations, ECN, LQD, and
skipping to change at page 22, line 25 skipping to change at page 22, line 25
It should also be noted that there is a distinction between It should also be noted that there is a distinction between
measurement and evaluation. Measurement provides raw data concerning measurement and evaluation. Measurement provides raw data concerning
state parameters and variables of monitored network elements. state parameters and variables of monitored network elements.
Evaluation utilizes the raw data to make inferences regarding the Evaluation utilizes the raw data to make inferences regarding the
monitored system. monitored system.
Measurement in support of the TE function can occur at different Measurement in support of the TE function can occur at different
levels of abstraction. For example, measurement can be used to derive levels of abstraction. For example, measurement can be used to derive
packet level characteristics, flow level characteristics, user or packet level characteristics, flow level characteristics, user or
customer level characteristics, traffic aggregate characteristics, customer level characteristics, traffic aggregate characteristics,
component level characteristics, network wide characteristics, etc. component level characteristics, and network wide characteristics.
3.3 Modeling, Analysis, and Simulation 3.3 Modeling, Analysis, and Simulation
Modeling and analysis are important aspects of Internet traffic Modeling and analysis are important aspects of Internet traffic
engineering. Modeling involves constructing an abstract or physical engineering. Modeling involves constructing an abstract or physical
representation which depicts relevant traffic characteristics and representation which depicts relevant traffic characteristics and
network attributes. network attributes.
A network model is an abstract representation of the network which A network model is an abstract representation of the network which
captures relevant network features, attributes, and characteristics, captures relevant network features, attributes, and characteristics,
skipping to change at page 26, line 43 skipping to change at page 26, line 43
In the following subsections, the evolution of practical traffic In the following subsections, the evolution of practical traffic
engineering mechanisms in IP networks and its predecessors is engineering mechanisms in IP networks and its predecessors is
reviewed. reviewed.
4.2.1 Adaptive Routing in the ARPANET 4.2.1 Adaptive Routing in the ARPANET
The early ARPANET recognized the importance of adaptive routing where The early ARPANET recognized the importance of adaptive routing where
routing decisions were based on the current state of the network routing decisions were based on the current state of the network
[MCQ80]. Early minimum delay routing approaches forwarded each [MCQ80]. Early minimum delay routing approaches forwarded each
packet to its destination along a path for which the total estimated packet to its destination along a path for which the total estimated
transit time is the smallest. Each node maintained a table of transit time was the smallest. Each node maintained a table of
network delays, representing the estimated delay that a packet would network delays, representing the estimated delay that a packet would
experience along a given path toward its destination. The minimum experience along a given path toward its destination. The minimum
delay table was periodically transmitted by a node to its neighbors. delay table was periodically transmitted by a node to its neighbors.
The shortest path, in terms of hop count, was also propagated to give The shortest path, in terms of hop count, was also propagated to give
the connectivity information. the connectivity information.
One drawback to this approach is that dynamic link metrics tend to One drawback to this approach is that dynamic link metrics tend to
create "traffic magnets" causing congestion to be shifted from one create "traffic magnets" causing congestion to be shifted from one
location of a network to another location, resulting in oscillation location of a network to another location, resulting in oscillation
and network instability. and network instability.
skipping to change at page 27, line 40 skipping to change at page 27, line 40
- Resources may not be deployed in the most optimal locations - Resources may not be deployed in the most optimal locations
from a routing perspective. from a routing perspective.
- Forecasting errors in traffic volume and/or traffic distribution. - Forecasting errors in traffic volume and/or traffic distribution.
- Dynamics in traffic matrix due to the temporal nature of traffic - Dynamics in traffic matrix due to the temporal nature of traffic
patterns, BGP policy change from peers, etc. patterns, BGP policy change from peers, etc.
The inadequacy of the legacy Internet interior gateway routing system The inadequacy of the legacy Internet interior gateway routing system
is one of the factors motivating the interest in path oriented is one of the factors motivating the interest in path oriented
technologies with explicit routing and constraint-based routing technology with explicit routing and constraint-based routing
capability, such as MPLS. capability such as MPLS.
4.2.3 ToS Routing 4.2.3 ToS Routing
Type-of-Service (ToS) routing involves different routes going to the Type-of-Service (ToS) routing involves different routes going to the
same destination being selected depending upon the ToS field of an IP same destination being selected depending upon the ToS field of an IP
packet [RFC-1349]. The ToS classes may be classified as low delay packet [RFC-1349]. The ToS classes may be classified as low delay
and high throughput. Each link is associated with multiple link and high throughput. Each link is associated with multiple link
costs and each link cost is used to compute routes for a particular costs and each link cost is used to compute routes for a particular
ToS. A separate shortest path tree is computed for each ToS. The ToS. A separate shortest path tree is computed for each ToS. The
shortest path algorithm must be run for each ToS resulting in very shortest path algorithm must be run for each ToS resulting in very
expensive computation. Classical ToS-based routing is now outdated expensive computation. Classical ToS-based routing is now outdated
as the IP header field has been replaced by a Diffserv field. as the IP header field has been replaced by a Diffserv field.
Effective traffic engineering is difficult to perform in classical Effective traffic engineering is difficult to perform in classical
ToS-based routing because each class still relies exclusively on ToS-based routing because each class still relies exclusively on
shortest path routing which results in localization of traffic shortest path routing which results in localization of traffic
concentration within the network. concentration within the network.
4.2.4 Equal Cost MultiPath 4.2.4 Equal Cost Multi-Path
Equal Cost MultiPath (ECMP) is another technique that attempts to Equal Cost Multi-Path (ECMP) is another technique that attempts to
address the deficiency in Shortest Path First (SPF) interior gateway address the deficiency in Shortest Path First (SPF) interior gateway
routing systems [RFC-2178]. In the classical SPF algorithm, if two or routing systems [RFC-2178]. In the classical SPF algorithm, if two or
more shortest paths exist to a given destination, the algorithm will more shortest paths exist to a given destination, the algorithm will
choose one of them. The algorithm is modified slightly in ECMP so choose one of them. The algorithm is modified slightly in ECMP so
that if two or more equal cost shortest paths exist between two that if two or more equal cost shortest paths exist between two
nodes, the traffic between the nodes is distributed among the nodes, the traffic between the nodes is distributed among the
multiple equal-cost paths. Traffic distribution across the equal- multiple equal-cost paths. Traffic distribution across the equal-
cost paths is usually performed in one of two ways: (1) packet-based cost paths is usually performed in one of two ways: (1) packet-based
in a round-robin fashion, or (2) flow-based using hashing on source in a round-robin fashion, or (2) flow-based using hashing on source
and destination IP addresses and possibly other fields of the IP and destination IP addresses and possibly other fields of the IP
skipping to change at page 29, line 19 skipping to change at page 29, line 19
that are located at the edges of a virtual-circuit cloud. In this that are located at the edges of a virtual-circuit cloud. In this
mode, two routers that are connected through a virtual circuit see a mode, two routers that are connected through a virtual circuit see a
direct adjacency between themselves independent of the physical route direct adjacency between themselves independent of the physical route
taken by the virtual circuit through the ATM, frame relay, or WDM taken by the virtual circuit through the ATM, frame relay, or WDM
network. Thus, the overlay model essentially decouples the logical network. Thus, the overlay model essentially decouples the logical
topology that routers see from the physical topology that the ATM, topology that routers see from the physical topology that the ATM,
frame relay, or WDM network manages. The overlay model based on ATM frame relay, or WDM network manages. The overlay model based on ATM
or frame relay enables a network administrator or an automaton to or frame relay enables a network administrator or an automaton to
employ traffic engineering concepts to perform path optimization by employ traffic engineering concepts to perform path optimization by
re-configuring or rearranging the virtual circuits so that a virtual re-configuring or rearranging the virtual circuits so that a virtual
circuit on a congested or suboptimal physical link can be re-routed circuit on a congested or sub-optimal physical link can be re-routed
to a less congested or more optimal one. In the overlay model, to a less congested or more optimal one. In the overlay model,
traffic engineering is also employed to establish relationships traffic engineering is also employed to establish relationships
between the traffic management parameters (e.g. PCR, SCR, MBS for between the traffic management parameters (e.g. PCR, SCR, and MBS for
ATM; or CIR, Be, and Bc for frame relay) of the virtual-circuit ATM) of the virtual-circuit technology and the actual traffic that
technology and the actual traffic that traverses each circuit. These traverses each circuit. These relationships can be established based
relationships can be established based upon known or projected upon known or projected traffic profiles, and some other factors.
traffic profiles, and some other factors.
The overlay model using IP over ATM requires the management of two The overlay model using IP over ATM requires the management of two
separate networks with different technologies (IP and ATM) resulting separate networks with different technologies (IP and ATM) resulting
in increased operational complexity and cost. In the fully-meshed in increased operational complexity and cost. In the fully-meshed
overlay model, each router would peer to every other router in the overlay model, each router would peer to every other router in the
network, so that the total number of adjacencies is a quadratic network, so that the total number of adjacencies is a quadratic
function of the number of routers. Some of the issues with the function of the number of routers. Some of the issues with the
overlay model are discussed in [AWD2]. overlay model are discussed in [AWD2].
4.4 Constrained-Based Routing 4.4 Constrained-Based Routing
skipping to change at page 31, line 9 skipping to change at page 31, line 9
that can tolerate some delay but are sensitive to traffic overload that can tolerate some delay but are sensitive to traffic overload
conditions. This type of application typically functions conditions. This type of application typically functions
satisfactorily when the network is lightly loaded but its performance satisfactorily when the network is lightly loaded but its performance
degrades significantly when the network is heavily loaded. degrades significantly when the network is heavily loaded.
Controlled-load service therefore has been designed to provide Controlled-load service therefore has been designed to provide
approximately the same service as best-effort service in a lightly approximately the same service as best-effort service in a lightly
loaded network regardless of actual network conditions. Controlled- loaded network regardless of actual network conditions. Controlled-
load service is described qualitatively in that no target values of load service is described qualitatively in that no target values of
delay or loss are specified. delay or loss are specified.
The main issue with the Integrated services model has been The main issue with the Integrated Services model has been
scalability, especially in large public IP networks which may scalability [RFC-2998], especially in large public IP networks which
potentially have millions of active micro-flows in transit may potentially have millions of active micro-flows in transit
concurrently. concurrently.
A notable feature of the Integrated Services model is that it A notable feature of the Integrated Services model is that it
requires explicit signaling of QoS requirements from end systems to requires explicit signaling of QoS requirements from end systems to
routers [RFC-2753]. The Resource Reservation Protocol (RSVP) performs routers [RFC-2753]. The Resource Reservation Protocol (RSVP) performs
this signaling function and is a critical component of the Integrated this signaling function and is a critical component of the Integrated
Services model. The RSVP protocol is described next. Services model. The RSVP protocol is described next.
4.5.2 RSVP 4.5.2 RSVP
skipping to change at page 31, line 51 skipping to change at page 31, line 51
or source node in the opposite direction along the path that the PATH or source node in the opposite direction along the path that the PATH
message traversed. Every intermediate router along the path can message traversed. Every intermediate router along the path can
reject or accept the reservation request of the RESV message. If the reject or accept the reservation request of the RESV message. If the
request is rejected, the rejecting router will send an error message request is rejected, the rejecting router will send an error message
to the receiver and the signaling process will terminate. If the to the receiver and the signaling process will terminate. If the
request is accepted, link bandwidth and buffer space are allocated request is accepted, link bandwidth and buffer space are allocated
for the flow and the related flow state information is installed in for the flow and the related flow state information is installed in
the router. the router.
One of the issues with the original RSVP specification was One of the issues with the original RSVP specification was
scalability. This is because reservations were required for micro- Scalability. This is because reservations were required for micro-
flows, so that the amount of state maintained by network elements flows, so that the amount of state maintained by network elements
tends to increase linearly with the number of micro-flows. tends to increase linearly with the number of micro-flows. These
issues are described in [RFC-2961].
Recently, RSVP has been modified and extended in several ways to Recently, RSVP has been modified and extended in several ways to
overcome the scaling problems. As a result, it is becoming a mitigate the scaling problems. As a result, it is becoming a
versatile signaling protocol for the Internet. For example, RSVP has versatile signaling protocol for the Internet. For example, RSVP has
been extended to reserve resources for aggregation of flows, to set been extended to reserve resources for aggregation of flows, to set
up MPLS explicit label switched paths, and to perform other signaling up MPLS explicit label switched paths, and to perform other signaling
functions within the Internet. There are also a number of proposals functions within the Internet. There are also a number of proposals
to reduce the amount of refresh messages required to maintain to reduce the amount of refresh messages required to maintain
established RSVP sessions [BERGER]. established RSVP sessions [RFC-2961].
A number of IETF working groups have been engaged in activities A number of IETF working groups have been engaged in activities
related to the RSVP protocol. These include the original RSVP working related to the RSVP protocol. These include the original RSVP working
group, the MPLS working group, the Resource Allocation Protocol group, the MPLS working group, the Resource Allocation Protocol
working group, and the Policy Framework working group. working group, and the Policy Framework working group.
4.5.3 Differentiated Services 4.5.3 Differentiated Services
The goal of the Differentiated Services (Diffserv) effort within the The goal of the Differentiated Services (Diffserv) effort within the
IETF is to devise scalable mechanisms for categorization of traffic IETF is to devise scalable mechanisms for categorization of traffic
skipping to change at page 33, line 25 skipping to change at page 33, line 26
MPLS is an advanced forwarding scheme which also includes extensions MPLS is an advanced forwarding scheme which also includes extensions
to conventional IP control plane protocols. MPLS extends the Internet to conventional IP control plane protocols. MPLS extends the Internet
routing model and enhances packet forwarding and path control [RFC- routing model and enhances packet forwarding and path control [RFC-
3031]. 3031].
At the ingress to an MPLS domain, label switching routers (LSRs) At the ingress to an MPLS domain, label switching routers (LSRs)
classify IP packets into forwarding equivalence classes (FECs) based classify IP packets into forwarding equivalence classes (FECs) based
on a variety of factors, including e.g. a combination of the on a variety of factors, including e.g. a combination of the
information carried in the IP header of the packets and the local information carried in the IP header of the packets and the local
routing information maintained by the LSRs. An MPLS label is then routing information maintained by the LSRs. An MPLS label is then
appended to each packet according to their forwarding equivalence prepended to each packet according to their forwarding equivalence
classes. In a non-ATM/FR environment, the label is 32 bits long and classes. In a non-ATM/FR environment, the label is 32 bits long and
contains a 20-bit label field, a 3-bit experimental field (formerly contains a 20-bit label field, a 3-bit experimental field (formerly
known as Class-of-Service or CoS field), a 1-bit label stack known as Class-of-Service or CoS field), a 1-bit label stack
indicator and an 8-bit TTL field. In an ATM (FR) environment, the indicator and an 8-bit TTL field. In an ATM (FR) environment, the
label consists information encoded in the VCI/VPI (DLCI) field. An label consists information encoded in the VCI/VPI (DLCI) field. An
MPLS capable router (an LSR) examines the label and possibly the MPLS capable router (an LSR) examines the label and possibly the
experimental field and uses this information to make packet experimental field and uses this information to make packet
forwarding decisions. forwarding decisions.
An LSR makes forwarding decisions by using the label prepended to An LSR makes forwarding decisions by using the label prepended to
skipping to change at page 34, line 38 skipping to change at page 34, line 38
The IETF Real Time Flow Measurement (RTFM) working group has produced The IETF Real Time Flow Measurement (RTFM) working group has produced
an architecture document defining a method to specify traffic flows an architecture document defining a method to specify traffic flows
as well as a number of components for flow measurement (meters, meter as well as a number of components for flow measurement (meters, meter
readers, manager) [RFC-2722]. A flow measurement system enables readers, manager) [RFC-2722]. A flow measurement system enables
network traffic flows to be measured and analyzed at the flow level network traffic flows to be measured and analyzed at the flow level
for a variety of purposes. As noted in RFC-2722, a flow measurement for a variety of purposes. As noted in RFC-2722, a flow measurement
system can be very useful in the following contexts: (1) system can be very useful in the following contexts: (1)
understanding the behavior of existing networks, (2) planning for understanding the behavior of existing networks, (2) planning for
network development and expansion, (3) quantification of network network development and expansion, (3) quantification of network
performance, (4) verifying the quality of network service, and (5) performance, (4) verifying the quality of network service, and (5)
attribution of network usage to users [RFC-2722]. attribution of network usage to users.
A flow measurement system consists of meters, meter readers, and A flow measurement system consists of meters, meter readers, and
managers. A meter observe packets passing through a measurement managers. A meter observe packets passing through a measurement
point, classifies them into certain groups, accumulates certain usage point, classifies them into certain groups, accumulates certain usage
data (such as the number of packets and bytes for each group), and data (such as the number of packets and bytes for each group), and
stores the usage data in a flow table. A group may represent a user stores the usage data in a flow table. A group may represent a user
application, a host, a network, a group of networks, etc. A meter application, a host, a network, a group of networks, etc. A meter
reader gathers usage data from various meters so it can be made reader gathers usage data from various meters so it can be made
available for analysis. A manager is responsible for configuring and available for analysis. A manager is responsible for configuring and
controlling meters and meter readers. The instructions received by a controlling meters and meter readers. The instructions received by a
skipping to change at page 36, line 26 skipping to change at page 36, line 26
Recommendation E.600 stipulates that a set of GoS parameters must be Recommendation E.600 stipulates that a set of GoS parameters must be
selected and defined on an end-to-end basis for each major service selected and defined on an end-to-end basis for each major service
category provided by a network to assist the network provider improve category provided by a network to assist the network provider improve
efficiency and effectiveness of the network. Based on a selected set efficiency and effectiveness of the network. Based on a selected set
of reference connections, suitable target values are assigned to the of reference connections, suitable target values are assigned to the
selected GoS parameters under normal and high load conditions. These selected GoS parameters under normal and high load conditions. These
end-to-end GoS target values are then apportioned to individual end-to-end GoS target values are then apportioned to individual
resource components of the reference connections for dimensioning resource components of the reference connections for dimensioning
purposes. purposes.
4.7 Content Distribution
The Internet is dominated by client-server interactions, especially
Web traffic (in the future, more sophisticated media servers may
become dominant). The location and performance of major information
servers has a significant impact on the traffic patterns within the
Internet as well as on the perception of service quality by end
users.
A number of dynamic load balancing techniques have been devised to
improve the performance of replicated information servers. These
techniques can cause spatial traffic characteristics to become more
dynamic in the Internet because information servers can be
dynamically picked based upon the location of the clients, the
location of the servers, the relative utilization of the servers, the
relative performance of different networks, and the relative
performance of different parts of a network. This process of
assignment of distributed servers to clients is called Traffic
Directing. It functions at the application layer.
Traffic Directing schemes that allocate servers in multiple
geographically dispersed locations to clients may require empirical
network performance statistics to make more effective decisions. In
the future, network measurement systems may need to provide this type
of information. The exact parameters needed are not yet defined.
When congestion exists in the network, Traffic Directing and Traffic
Engineering systems should act in a coordinated manner. This topic is
for further study.
The issues related to location and replication of information
servers, particularly web servers, are important for Internet traffic
engineering because these servers contribute a substantial proportion
of Internet traffic.
5.0 Taxonomy of Traffic Engineering Systems 5.0 Taxonomy of Traffic Engineering Systems
This section presents a short taxonomy of traffic engineering This section presents a short taxonomy of traffic engineering
systems. A taxonomy of traffic engineering systems can be constructed systems. A taxonomy of traffic engineering systems can be constructed
based on traffic engineering styles and views as listed below: based on traffic engineering styles and views as listed below:
- Time-dependent vs State-dependent vs Event-dependent - Time-dependent vs State-dependent vs Event-dependent
- Offline vs Online - Offline vs Online
- Centralized vs Distributed - Centralized vs Distributed
- Local vs Global Information - Local vs Global Information
- Prescriptive vs Descriptive - Prescriptive vs Descriptive
- Open Loop vs Closed Loop - Open Loop vs Closed Loop
- Tactical vs Strategic - Tactical vs Strategic
These classification systems are described in greater detail in the These classification systems are described in greater detail in the
following subsections of this document. following subsections of this document.
5.1 Time-Dependent Versus State-Dependent Versus Event Dependent 5.1 Time-Dependent Versus State-Dependent Versus Event Dependent
Traffic engineering methodologies can be classified as time-dependent Traffic engineering methodologies can be classified as time-dependent
or state-dependent. All TE schemes are considered to be dynamic in or state-dependent or event-dependent. All TE schemes are considered
this framework. Static TE implies that no traffic engineering to be dynamic in this framework. Static TE implies that no traffic
methodology or algorithm is being applied. engineering methodology or algorithm is being applied.
In the time-dependent TE, historical information based on periodic In the time-dependent TE, historical information based on periodic
variations in traffic (such as time of day) is used to pre-program variations in traffic (such as time of day) is used to pre-program
routing plans and other TE control mechanisms. Additionally, routing plans and other TE control mechanisms. Additionally,
customer subscription or traffic projection may be used. Pre- customer subscription or traffic projection may be used. Pre-
programmed routing plans typically change on a relatively long time programmed routing plans typically change on a relatively long time
scale (e.g., diurnal). Time-dependent algorithms do not attempt to scale (e.g., diurnal). Time-dependent algorithms do not attempt to
adapt to random variations in traffic or changing network conditions. adapt to random variations in traffic or changing network conditions.
An example of a time-dependent algorithm is a global centralized An example of a time-dependent algorithm is a global centralized
optimizer where the input to the system is a traffic matrix and optimizer where the input to the system is a traffic matrix and
multiclass QoS requirements as described [MR99]. multi-class QoS requirements as described [MR99].
State-dependent TE adapts the routing plans for packets based on the State-dependent TE adapts the routing plans for packets based on the
current state of the network. The current state of the network current state of the network. The current state of the network
provides additional information on variations in actual traffic provides additional information on variations in actual traffic
(i.e., perturbations from regular variations) that could not be (i.e., perturbations from regular variations) that could not be
predicted using historical information. Constraint-based routing is predicted using historical information. Constraint-based routing is
an example of state-dependent TE operating in a relatively long time an example of state-dependent TE operating in a relatively long time
scale. An example operating in a relatively short time scale is a scale. An example operating in a relatively short time scale is a
load-balancing algorithm described in [MATE]. load-balancing algorithm described in [MATE].
skipping to change at page 37, line 37 skipping to change at page 38, line 19
Expeditious and accurate gathering and distribution of state Expeditious and accurate gathering and distribution of state
information is critical for adaptive TE due to the dynamic nature of information is critical for adaptive TE due to the dynamic nature of
network conditions. State-dependent algorithms may be applied to network conditions. State-dependent algorithms may be applied to
increase network efficiency and resilience. Time-dependent algorithms increase network efficiency and resilience. Time-dependent algorithms
are more suitable for predictable traffic variations. On the other are more suitable for predictable traffic variations. On the other
hand, state-dependent algorithms are more suitable for adapting to hand, state-dependent algorithms are more suitable for adapting to
the prevailing network state. the prevailing network state.
Event-dependent TE methods can also be used for TE path selection. Event-dependent TE methods can also be used for TE path selection.
Event-dependent TE methods are distinct from time-dependent and Event-dependent TE methods are distinct from time-dependent and
state-dependent TE methods in the manner in which paths are selected. state-dependent TE methods in the manner in which paths are selected.
These algorithms are adaptive and distributed in nature and typically These algorithms are adaptive and distributed in nature and typically
use learning models to find good paths for TE in a network. While use learning models to find good paths for TE in a network. While
state-dependent TE models typically use available-link-bandwidth state-dependent TE models typically use available-link-bandwidth
(ALB) flooding for TE path selection, event-dependent TE methods do (ALB) flooding for TE path selection, event-dependent TE methods do
not require ALB flooding. Rather, event-dependent TE methods not require ALB flooding. Rather, event-dependent TE methods
typically search out capacity by learning models, as in the success- typically search out capacity by learning models, as in the success-
to-the-top (STT) method. ALB flooding can be resource intensive, to-the-top (STT) method. ALB flooding can be resource intensive,
since it requires link bandwidth to carry LSAs, processor capacity to since it requires link bandwidth to carry LSAs, processor capacity to
process LSAs, and the overhead can limit area/autonomous system (AS) process LSAs, and the overhead can limit area/autonomous system (AS)
size. Modeling results suggest that event-dependent TE methods can size. Modeling results suggest that event-dependent TE methods could
lead to a reduction in ALB flooding overhead without loss of network lead to a reduction in ALB flooding overhead without loss of network
throughput performance [ASH3]. throughput performance [ASH3].
As an example of event-dependent methods, consider an MPLS network
that uses a success-to-the-top (STT) event-dependent TE method. In
this case, if the bandwidth between two label switching routers (say
LSR-A to LSR-B) needs to be modified, say increased by delta-BW, the
primary LSP-p is tried first. If delta-BW is not available on one or
more links of LSP-p, then the currently successful LSP-s is tried
next. If delta-BW is not available on one or more links of LSP-s,
then a new LSP is searched by trying additional candidate paths until
a new successful LSP-n is found or the candidate paths are exhausted.
LSP-n is then marked as the currently successful path for the next
time bandwidth needs to be modified.
5.2 Offline Versus Online 5.2 Offline Versus Online
Traffic engineering requires the computation of routing plans. The Traffic engineering requires the computation of routing plans. The
computation may be performed offline or online. The computation can computation may be performed offline or online. The computation can
be done offline for scenarios where routing plans need not be be done offline for scenarios where routing plans need not be
executed in real-time. For example, routing plans computed from executed in real-time. For example, routing plans computed from
forecast information may be computed offline. Typically, offline forecast information may be computed offline. Typically, offline
computation is also used to perform extensive searches on multi- computation is also used to perform extensive searches on multi-
dimensional solution spaces. dimensional solution spaces.
skipping to change at page 38, line 48 skipping to change at page 39, line 22
Distributed control determines route selection by each router Distributed control determines route selection by each router
autonomously based on the routers view of the state of the network. autonomously based on the routers view of the state of the network.
The network state information may be obtained by the router using a The network state information may be obtained by the router using a
probing method or distributed by other routers on a periodic basis probing method or distributed by other routers on a periodic basis
using link state advertisements. Network state information may also using link state advertisements. Network state information may also
be disseminated under exceptional conditions. be disseminated under exceptional conditions.
5.4 Local Versus Global 5.4 Local Versus Global
Traffic engineering algorithms may require local or global network- Traffic engineering algorithms may require local or global network-
state information. Note that the scope of network-state information state information.
does not necessarily refer to the scope of the optimization. In other
words, it is possible for a TE algorithm to perform global
optimization based on local state information. Similarly, a TE
algorithm may arrive at a locally optimum solution even if it relies
on global state information.
Local information pertains to the state of a portion of the domain. Local information pertains to the state of a portion of the domain.
Examples include the bandwidth and packet loss rate of a particular Examples include the bandwidth and packet loss rate of a particular
path. Local state information may be sufficient for certain path. Local state information may be sufficient for certain
instances of distributed-controlled TEs. instances of distributed-controlled TEs.
Global information pertains to the state of the entire domain Global information pertains to the state of the entire domain
undergoing traffic engineering. Examples include a global traffic undergoing traffic engineering. Examples include a global traffic
matrix and loading information on each link throughout the domain of matrix and loading information on each link throughout the domain of
interest. Global state information is typically required with interest. Global state information is typically required with
skipping to change at page 39, line 30 skipping to change at page 39, line 47
TE systems may also be classified as prescriptive or descriptive. TE systems may also be classified as prescriptive or descriptive.
Prescriptive traffic engineering evaluates alternatives and Prescriptive traffic engineering evaluates alternatives and
recommends a course of action. Prescriptive traffic engineering can recommends a course of action. Prescriptive traffic engineering can
be further categorized as either corrective or perfective. Corrective be further categorized as either corrective or perfective. Corrective
TE prescribes a course of action to address an existing or predicted TE prescribes a course of action to address an existing or predicted
anomaly. Perfective TE prescribes a course of action to evolve and anomaly. Perfective TE prescribes a course of action to evolve and
improve network performance even when no anomalies are evident. improve network performance even when no anomalies are evident.
Descriptive traffic engineering characterizes, on the other hand, the Descriptive traffic engineering, on the other hand, characterizes the
state of the network and assesses the impact of various policies state of the network and assesses the impact of various policies
without recommending any particular course of action. without recommending any particular course of action.
5.6 Open-Loop Versus Closed-Loop 5.6 Open-Loop Versus Closed-Loop
Open-loop traffic engineering control is where control action does Open-loop traffic engineering control is where control action does
not use feedback information from the current network state. The not use feedback information from the current network state. The
control action may use its own local information for accounting control action may use its own local information for accounting
purposes, however. purposes, however.
skipping to change at page 40, line 8 skipping to change at page 40, line 27
5.7 Tactical vs Strategic 5.7 Tactical vs Strategic
Tactical traffic engineering aims to address specific performance Tactical traffic engineering aims to address specific performance
problems (such as hot-spots) that occur in the network from a problems (such as hot-spots) that occur in the network from a
tactical perspective, without consideration of overall strategic tactical perspective, without consideration of overall strategic
imperatives. Without proper planning and insights, tactical TE tends imperatives. Without proper planning and insights, tactical TE tends
to be ad hoc in nature. to be ad hoc in nature.
Strategic traffic engineering approaches the TE problem from a more Strategic traffic engineering approaches the TE problem from a more
organized and systematic perspective, taking into consideration the organized and systematic perspective, taking into consideration the
immediate and longer term term consequences of specific policies and immediate and longer term consequences of specific policies and
actions. actions.
6.0 Recommendations for Internet Traffic Engineering 6.0 Recommendations for Internet Traffic Engineering
This section describes high level recommendations for traffic This section describes high level recommendations for traffic
engineering in the Internet. These recommendations are presented in engineering in the Internet. These recommendations are presented in
general terms because this is a framework document. general terms because this is a framework document.
The recommendations describe the capabilities needed to solve a The recommendations describe the capabilities needed to solve a
traffic engineering problem or to achieve a traffic engineering traffic engineering problem or to achieve a traffic engineering
skipping to change at page 46, line 48 skipping to change at page 47, line 19
at the wavelength level as well as traditional protection at the wavelength level as well as traditional protection
functionality. At the SONET/SDH layer survivability capability is functionality. At the SONET/SDH layer survivability capability is
provided with Automatic Protection Switching (APS) as well as self- provided with Automatic Protection Switching (APS) as well as self-
healing ring and mesh architectures. Similar functionality is healing ring and mesh architectures. Similar functionality is
provided by layer 2 technologies such as ATM (generally with slower provided by layer 2 technologies such as ATM (generally with slower
mean restoration times). Rerouting is traditionally used at the IP mean restoration times). Rerouting is traditionally used at the IP
layer to restore service following link and node outages. Rerouting layer to restore service following link and node outages. Rerouting
at the IP layer occurs after a period of routing convergence which at the IP layer occurs after a period of routing convergence which
may require seconds to minutes to complete. Some new developments in may require seconds to minutes to complete. Some new developments in
the MPLS context make it possible to achieve recovery at the IP layer the MPLS context make it possible to achieve recovery at the IP layer
prior to convergence. prior to convergence [SHAR].
To support advanced survivability requirements, path-oriented To support advanced survivability requirements, path-oriented
technologies such a MPLS can be used to enhance the survivability of technologies such a MPLS can be used to enhance the survivability of
IP networks in a potentially cost effective manner. The advantages of IP networks in a potentially cost effective manner. The advantages of
path oriented technologies such as MPLS for IP restoration becomes path oriented technologies such as MPLS for IP restoration becomes
even more evident when class based protection and restoration even more evident when class based protection and restoration
capabilities are required. capabilities are required.
Recently, a common suite of control plane protocols has been proposed Recently, a common suite of control plane protocols has been proposed
for both MPLS and optical transport networks under the acronym for both MPLS and optical transport networks under the acronym
Multiprotocol Lambda Switching [AWD1]. This new paradigm of Multi-protocol Lambda Switching [AWD1]. This new paradigm of Multi-
Multiprotocol Lambda Switching will support even more sophisticated protocol Lambda Switching will support even more sophisticated mesh
mesh restoration capabilities at the optical layer for the emerging restoration capabilities at the optical layer for the emerging IP
IP over WDM network architectures. over WDM network architectures.
Another important aspect regarding multi-layer survivability is that Another important aspect regarding multi-layer survivability is that
technologies at different layers provide protection and restoration technologies at different layers provide protection and restoration
capabilities at different temporal granularities (in terms of time capabilities at different temporal granularities (in terms of time
scales) and at different bandwidth granularity (from packet-level to scales) and at different bandwidth granularity (from packet-level to
wavelength level). Protection and restoration capabilities can also wavelength level). Protection and restoration capabilities can also
be sensitive to different service classes and different network be sensitive to different service classes and different network
utility models. utility models.
The impact of service outages varies significantly for different The impact of service outages varies significantly for different
skipping to change at page 49, line 40 skipping to change at page 50, line 12
- 1+1: traffic is sent concurrently on both the working LSP and the - 1+1: traffic is sent concurrently on both the working LSP and the
protection LSP. In this case, the egress LSR selects one of the two protection LSP. In this case, the egress LSR selects one of the two
LSPs based on a local traffic integrity decision process, which LSPs based on a local traffic integrity decision process, which
compares the traffic received from both the working and the compares the traffic received from both the working and the
protection LSP and identifies discrepancies. It is unlikely that protection LSP and identifies discrepancies. It is unlikely that
this option would be used extensively in IP networks due to its this option would be used extensively in IP networks due to its
resource utilization inefficiency. However, if bandwidth becomes resource utilization inefficiency. However, if bandwidth becomes
plentiful and cheap, then this option might become quite viable and plentiful and cheap, then this option might become quite viable and
attractive in IP networks. attractive in IP networks.
6.6 Content Distribution Recommendations 6.6 Traffic Engineering in Diffserv Environments
The Internet is dominated by client-server interactions, especially
Web traffic (in the future, more sophisticated media servers may
become dominant). The location and performance of major information
servers has a significant impact on the traffic patterns within the
Internet as well as on the perception of service quality by end
users.
A number of dynamic load balancing techniques have been devised to
improve the performance of replicated information servers. These
techniques can cause spatial traffic characteristics to become more
dynamic in the Internet because information servers can be
dynamically picked based upon the location of the clients, the
location of the servers, the relative utilization of the servers, the
relative performance of different networks, and the relative
performance of different parts of a network. This process of
assignment of distributed servers to clients is called Traffic
Directing. It is similar to traffic engineering but operates at the
application layer.
Traffic Directing schemes that allocate servers in multiple
geographically dispersed locations to clients may require empirical
network performance statistics to make more effective decisions. In
the future, network measurement systems may need to provide this type
of information. The exact parameters needed are not yet defined.
When congestion exists in the network, Traffic Directing and Traffic
Engineering systems should act in a coordinated manner. This topic is
for further study.
The issues related to location and replication of information
servers, particularly web servers, are important for Internet traffic
engineering because these servers contribute a substantial proportion
of Internet traffic.
6.7 Traffic Engineering in Diffserv Environments
This section provides an overview of the traffic engineering features This section provides an overview of the traffic engineering features
and recommendations that are specifically pertinent to Differentiated and recommendations that are specifically pertinent to Differentiated
Services (Diffserv) capable IP networks. Services (Diffserv) [RFC-2475] capable IP networks.
Increasing requirements to support multiple classes of traffic, such Increasing requirements to support multiple classes of traffic, such
as best effort and mission critical data, in the Internet calls for as best effort and mission critical data, in the Internet calls for
IP networks to differentiate traffic according to some criteria, and IP networks to differentiate traffic according to some criteria, and
to accord preferential treatment to certain types of traffic. Large to accord preferential treatment to certain types of traffic. Large
numbers of flows can be aggregated into a few behavior aggregates numbers of flows can be aggregated into a few behavior aggregates
based on some criteria in terms of common performance requirements in based on some criteria in terms of common performance requirements in
terms of packet loss ratio, delay, and jitter; or in terms of common terms of packet loss ratio, delay, and jitter; or in terms of common
fields within the IP packet headers. fields within the IP packet headers.
skipping to change at page 51, line 44 skipping to change at page 51, line 31
traffic engineering mechanisms that are insensitive to different traffic engineering mechanisms that are insensitive to different
service classes. Instead, it may be desirable to perform traffic service classes. Instead, it may be desirable to perform traffic
engineering, especially routing control and mapping functions, on a engineering, especially routing control and mapping functions, on a
per service class basis. One way to accomplish this in a domain that per service class basis. One way to accomplish this in a domain that
supports both MPLS and Diffserv is to define class specific LSPs and supports both MPLS and Diffserv is to define class specific LSPs and
to map traffic from each class onto one or more LSPs that correspond to map traffic from each class onto one or more LSPs that correspond
to that service class. An LSP corresponding to a given service class to that service class. An LSP corresponding to a given service class
can then be routed and protected/restored in a class dependent can then be routed and protected/restored in a class dependent
manner, according to specific policies. manner, according to specific policies.
Performing traffic engineering on a per class basis in multi-class IP
networks might be beneficial in terms of both performance and
scalability. It allows traffic trunk in a given class to utilize
available resources on both shortest path(s) and non-shortest paths
that meet constraints and requirements that are specific to the given
class. MPLS is capable of providing different levels of
protection/restoration mechanisms, from link/node protection to path
protection which can be pre-established with or without pre-reserved
resources or established on demand. The faster a mechanism, the more
network resources it costs. By performing per-class
protection/restoration, each class can select some
protection/restoration mechanisms that satisfy its survivability
requirements in a cost effective manner.
Performing traffic engineering on a per class basis requires certain Performing traffic engineering on a per class basis requires certain
per-class parameters to be propagated via IGP link state per-class parameters to be propagated via IGP link state
advertisements (LSAs). Note that it is common to have some classes to advertisements (LSAs). Note that it is common to have some classes to
share some aggregate constraint (e.g. maximum bandwidth requirement) share some aggregate constraint (e.g. maximum bandwidth requirement)
without enforcing the constraint on each individual class. These without enforcing the constraint on each individual class. These
classes then can be grouped into a class-type and per-class-type classes then might be grouped into a class-type and per-class-type
parameters can be propagated instead to improve the scalability of parameters might be propagated instead to improve the scalability of
IGP LSAs. It also allows better bandwidth sharing between classes in IGP LSAs. It also allows better bandwidth sharing between classes in
the same class-type. A class-type is a set of classes that satisfy the same class-type. A class-type is a set of classes that satisfy
the following two conditions: the following two conditions:
1) Classes in the same class-type have common aggregate requirements 1) Classes in the same class-type have common aggregate requirements
to satisfy required performance levels. to satisfy required performance levels.
2) There is no requirement to be enforced at the level of individual 2) There is no requirement to be enforced at the level of individual
class in the class-type. Note that it is still possible, class in the class-type. Note that it is still possible,
nevertheless, to implement some priority policies for classes in the nevertheless, to implement some priority policies for classes in the
skipping to change at page 52, line 34 skipping to change at page 52, line 6
An example of the class-type can be a low-loss class-type that An example of the class-type can be a low-loss class-type that
includes both AF1-based and AF2-based Ordering Aggregates. With such includes both AF1-based and AF2-based Ordering Aggregates. With such
a class-type, one may implement some priority policy which assigns a class-type, one may implement some priority policy which assigns
higher preemption priority to AF1-based traffic trunks over AF2-based higher preemption priority to AF1-based traffic trunks over AF2-based
ones, vice versa, or the same priority. ones, vice versa, or the same priority.
See [DIFF-TE] for detailed requirements on Diffserv-aware traffic See [DIFF-TE] for detailed requirements on Diffserv-aware traffic
engineering. engineering.
6.8 Network Controllability 6.7 Network Controllability
Off-line (and on-line) traffic engineering considerations would be of Off-line (and on-line) traffic engineering considerations would be of
limited utility if the network could not be controlled effectively to limited utility if the network could not be controlled effectively to
implement the results of TE decisions and to achieve desired network implement the results of TE decisions and to achieve desired network
performance objectives. Capacity augmentation is a coarse grained performance objectives. Capacity augmentation is a coarse grained
solution to traffic engineering issues. However, it is simple and may solution to traffic engineering issues. However, it is simple and may
be advantageous if bandwidth is abundant and cheap or if the current be advantageous if bandwidth is abundant and cheap or if the current
or expected network workload demands it. However, bandwidth is not or expected network workload demands it. However, bandwidth is not
always abundant and cheap, and the workload may not always demand always abundant and cheap, and the workload may not always demand
additional capacity. Adjustments of administrative weights and other additional capacity. Adjustments of administrative weights and other
skipping to change at page 53, line 19 skipping to change at page 52, line 44
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-4 [BGP4] is the
standard exterior gateway protocol for the Internet. BGP-4 provides standard exterior gateway protocol for the Internet. BGP-4 provides
a number of capabilities that can be used to define import and export a number of attributes (e.g. local preference, AS path, and MED) and
policies for network reachability information. BGP attributes are capabilities (e.g. route filtering) that can be used for inter-domain
used by the BGP decision process to select exit points for traffic to traffic engineering. These mechanisms are generally effective, but
other peer networks. they are usually applied in a trial-and-error fashion. A systematic
approach for inter-domain traffic engineering is yet to be devised.
Inter-domain traffic engineering is inherently more difficult than Inter-domain traffic engineering is inherently more difficult than
intra-domain TE under the current Internet architecture. The reasons intra-domain TE under the current Internet architecture. The reasons
for this are both technical and administrative. Technically, the for this are both technical and administrative. Technically, while
current version of BGP does not propagate topology and link state topology and link state information are helpful for mapping traffic
information across domain boundaries. There are stability and more effectively, BGP does not propagate such information across
scalability issues involved in propagating such details, which domain boundaries for stability and scalability reasons.
require careful consideration. Administratively, there are Administratively, there are differences in operating costs and
differences in operating costs and network capacities between network capacities between domains. Generally, what may be considered
domains. Generally, what may be considered a good solution in one a good solution in one domain may not necessarily be a good solution
domain may not necessarily be a good solution in another domain. in another domain. Moreover, it would generally be considered
Moreover, it would generally be considered inadvisable for one domain inadvisable for one domain to permit another domain to influence the
to permit another domain to influence the routing and management of routing and management of traffic in its network.
traffic in its network.
If Diffserv becomes widely deployed, inter-domain TE will become more
important, and more challenging to address.
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
metric which is smaller than the IGP cost to all other peering metric which is smaller than the IGP cost to all other peering
points. If a peer accepts and processes MEDs, then a similar MPLS points. If a peer accepts and processes MEDs, then a similar MPLS
TE-tunnel based scheme can be applied to cause certain entrance TE-tunnel based scheme can be applied to cause certain entrance
points to be preferred by setting MED to be an IGP cost, which has points to be preferred by setting MED to be an IGP cost, which has
been modified by the tunnel metric. been modified by the tunnel metric.
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 traffic.
Therefore, it is critical for peering partners to coordinate with Therefore, it is mutually beneficial for peering partners to
each other before attempting any policy changes that may result in coordinate with each other before attempting any policy changes that
significant shifts in inter-domain traffic. In certain contexts, this may result in significant shifts in inter-domain traffic. In certain
coordination can be quite challenging due to technical and non- contexts, this coordination can be quite challenging due to technical
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
skipping to change at page 57, line 4 skipping to change at page 56, line 26
[ASH1] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright, [ASH1] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright,
"Applicability Statement for CR-LDP," Work in Progress, July 2000. "Applicability Statement for CR-LDP," Work in Progress, July 2000.
[ASH2] J. Ash, Dynamic Routing in Telecommunications Networks, McGraw [ASH2] J. Ash, Dynamic Routing in Telecommunications Networks, McGraw
Hill, 1998 Hill, 1998
[ASH3] J. Ash, "TE & QoS Methods for IP-, ATM-, & TDM-Based [ASH3] J. Ash, "TE & QoS Methods for IP-, ATM-, & TDM-Based
Networks," Work in Progress, Mar. 2001. Networks," Work in Progress, Mar. 2001.
[AWD1] D. Awduche and Y. Rekhter, "Multiprocotol Lambda Switching: [AWD1] D. Awduche and Y. Rekhter, "Multiprocotol Lambda Switching:
Combining MPLS Traffic Engineering Control with Optical Combining MPLS Traffic Engineering Control with Optical
Crossconnects", IEEE Communications Magazine, March 2001. Crossconnects", IEEE Communications Magazine, March 2001.
[AWD2] D. Awduche, "MPLS and Traffic Engineering in IP Networks," [AWD2] D. Awduche, "MPLS and Traffic Engineering in IP Networks,"
IEEE Communications Magazine, Dec. 1999. IEEE Communications Magazine, Dec. 1999.
[AWD3] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V. [AWD3] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V.
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," Work in Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," Work in
Progress, Feb. 2001. Progress, Feb. 2001.
[AWD4] D. Awduche, A. Hannan, X. Xiao, " Applicability Statement for [AWD4] D. Awduche, A. Hannan, X. Xiao, " Applicability Statement for
Extensions to RSVP for LSP-Tunnels," Work in Progress, Apr. 2000. Extensions to RSVP for LSP-Tunnels," Work in Progress, Apr. 2000.
[AWD5] D. Awduche et al, "An Approach to Optimal Peering Between [AWD5] D. Awduche et al, "An Approach to Optimal Peering Between
Autonomous Systems in the Internet," International Conference on Autonomous Systems in the Internet," International Conference on
Computer Communications and Networks (ICCCN'98), Oct. 1998. Computer Communications and Networks (ICCCN'98), Oct. 1998.
[BERGER] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, and S.
Molendini "RSVP Refresh Overhead Reduction Extensions," Work in
Progress, Jun. 2000.
[CRUZ] R. L. Cruz, "A Calculus for Network Delay, Part II: Network [CRUZ] R. L. Cruz, "A Calculus for Network Delay, Part II: Network
Analysis," IEEE Transactions on Information Theory, vol. 37, pp. Analysis," IEEE Transactions on Information Theory, vol. 37, pp.
132-141, 1991. 132-141, 1991.
[DIFF-TE] F. Le Faucheur, et al, "Requirements for support of Diff- [DIFF-TE] F. Le Faucheur, et al, "Requirements for support of Diff-
Serv-aware MPLS Traffic Engineering", Work in Progress, May 2001. Serv-aware MPLS Traffic Engineering", Work in Progress, May 2001.
[ELW95] A. Elwalid, D. Mitra and R.H. Wentworth, "A New Approach for [ELW95] A. Elwalid, D. Mitra and R.H. Wentworth, "A New Approach for
Allocating Buffers and Bandwidth to Heterogeneous, Regulated Traffic Allocating Buffers and Bandwidth to Heterogeneous, Regulated Traffic
in an ATM Node," IEEE IEEE Journal on Selected Areas in in an ATM Node," IEEE IEEE Journal on Selected Areas in
skipping to change at page 59, line 51 skipping to change at page 59, line 18
[RFC-2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, [RFC-2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
"Requirements for Traffic Engineering over MPLS," RFC 2702, Sep. "Requirements for Traffic Engineering over MPLS," RFC 2702, Sep.
1999. 1999.
[RFC-2722] N. Brownlee, C. Mills, and G. Ruth, "Traffic Flow [RFC-2722] N. Brownlee, C. Mills, and G. Ruth, "Traffic Flow
Measurement: Architecture," RFC 2722, Oct. 1999. Measurement: Architecture," RFC 2722, Oct. 1999.
[RFC-2753] R. Yavatkar, D. Pendarakis, and R. Guerin, "A Framework [RFC-2753] R. Yavatkar, D. Pendarakis, and R. Guerin, "A Framework
for Policy-based Admission Control," RFC 2753, Jan. 2000. for Policy-based Admission Control," RFC 2753, Jan. 2000.
[RFC-2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961,
Apr. 2000.
[RFC-2998] Y. Bernet, et. al., "A Framework for Integrated Services
Operation over Diffserv Networks", RFC 2998, Nov. 2000.
[RFC-3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label [RFC-3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
Switching Architecture," RFC 3031, Jan. 2001. Switching Architecture," RFC 3031, Jan. 2001.
[SHAR] V. Sharma, et. al., "Framework for MPLS Based Recovery," Work [SHAR] V. Sharma, et. al., "Framework for MPLS Based Recovery," Work
in Progress, Mar. 2001. in Progress, Mar. 2001.
[SLDC98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury, [SLDC98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury,
"Design Considerations for Supporting TCP with Per-flow Queueing," "Design Considerations for Supporting TCP with Per-flow Queueing,"
Proc. INFOCOM'98, p. 299-306, 1998. Proc. INFOCOM'98, p. 299-306, 1998.
[SMIT] H. Smit and T. Li, "IS-IS extensions for Traffic Engineering," [SMIT] H. Smit and T. Li, "IS-IS extensions for Traffic Engineering,"
Work in Progress, Sep. 2000. Work in Progress, Feb. 2001.
[XIAO] X. Xiao, A. Hannan, B. Bailey, L. Ni, "Traffic Engineering [XIAO] X. Xiao, A. Hannan, B. Bailey, L. Ni, "Traffic Engineering
with MPLS in the Internet," IEEE Network magazine, Mar. 2000. with MPLS in the Internet," IEEE Network magazine, Mar. 2000.
[YARE95] C. Yang and A. Reddy, "A Taxonomy for Congestion Control [YARE95] C. Yang and A. Reddy, "A Taxonomy for Congestion Control
Algorithms in Packet Switching Networks", IEEE Network Magazine, p. Algorithms in Packet Switching Networks", IEEE Network Magazine, p.
34-45, 1995. 34-45, 1995.
13.0 Authors' Addresses: 13.0 Authors' Addresses:
skipping to change at page 61, line 23 skipping to change at page 60, line 23
Angela Chiu Angela Chiu
Celion Networks Celion Networks
1 Shiela Dr., Suite 2 1 Shiela Dr., Suite 2
Tinton Falls, NJ 07724 Tinton Falls, NJ 07724
Phone: 732-747-9987 Phone: 732-747-9987
Email: angela.chiu@celion.com Email: angela.chiu@celion.com
Anwar Elwalid Anwar Elwalid
Lucent Technologies Lucent Technologies
Murray Hill, NJ 07974, USA Murray Hill, NJ 07974
Phone: 908 582-7589 Phone: 908 582-7589
Email: anwar@lucent.com Email: anwar@lucent.com
Indra Widjaja Indra Widjaja
Fujitsu Network Communications Bell Labs, Lucent Technologies
Two Blue Hill Plaza 600 Mountain Avenue
Pearl River, NY 10965, USA Murray Hill, NJ 07974
Phone: 845-731-2244 Phone: 908 582-0435
Email: indra.widjaja@fnc.fujitsu.com Email: iwidjaja@research.bell-labs.com
XiPeng Xiao XiPeng Xiao
Photuris Inc. Photuris Inc.
2025 Stierlin Ct., 2025 Stierlin Ct.,
Mountain View, CA 94043 Mountain View, CA 94043
Phone: 650-919-3215 Phone: 650-919-3215
Email: xxiao@photuris.com Email: xxiao@photuris.com
 End of changes. 66 change blocks. 
258 lines changed or deleted 226 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/