improving efficiency and effectiveness of the network. Based on a
selected set of reference connections, suitable target values are
assigned to the selected GoS parameters under normal and high load
conditions. These end-to-end GoS target values are then apportioned
to individual resource components of the reference connections for
dimensioning 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
This section presents a short taxonomy of traffic engineering
systems. A taxonomy of traffic engineering systems can be
constructed based on traffic engineering styles and views as listed
below:
- Time-dependent vs State-dependent vs Event-dependent
- Offline vs Online
- Centralized vs Distributed
- Local vs Global Information
- Prescriptive vs Descriptive
- Open Loop vs Closed Loop
- Tactical vs Strategic
These classification systems are described in greater detail in the
following subsections of this document.
5.1 Time-Dependent Versus State-Dependent Versus Event Dependent
Traffic engineering methodologies can be classified as time-
dependent, or state-dependent, or event-dependent. All TE schemes
are considered to be dynamic in this document. Static TE implies
that no traffic engineering methodology or algorithm is being
applied.
In the time-dependent TE, historical information based on periodic
variations in traffic, (such as time of day), is used to pre-program
routing plans and other TE control mechanisms. Additionally,
customer subscription or traffic projection may be used. Pre-
programmed routing plans typically change on a relatively long time
scale (e.g., diurnal). Time-dependent algorithms do not attempt to
adapt to random variations in traffic or changing network conditions.
An example of a time-dependent algorithm is a global centralized
optimizer where the input to the system is a traffic matrix and
multi-class QoS requirements as described [MR99].
State-dependent TE adapts the routing plans for packets based on the
current state of the network. The current state of the network
provides additional information on variations in actual traffic
(i.e., perturbations from regular variations) that could not be
predicted using historical information. Constraint-based routing is
an example of state-dependent TE operating in a relatively long time
scale. An example operating in a relatively short time scale is a
load-balancing algorithm described in [MATE].
The state of the network can be based on parameters such as
utilization, packet delay, packet loss, etc. These parameters can be
obtained in several ways. For example, each router may flood these
parameters periodically or by means of some kind of trigger to other
routers. Another approach is for a particular router performing
adaptive TE to send probe packets along a path to gather the state of
that path. Still another approach is for a management system to
gather relevant information from network elements.
Expeditious and accurate gathering and distribution of state
information is critical for adaptive TE due to the dynamic nature of
network conditions. State-dependent algorithms may be applied to
increase network efficiency and resilience. Time-dependent
algorithms are more suitable for predictable traffic variations. On
the other hand, state-dependent algorithms are more suitable for
adapting to the prevailing network state.
Event-dependent TE methods can also be used for TE path selection.
Event-dependent TE methods are distinct from time-dependent and
state-dependent TE methods in the manner in which paths are selected.
These algorithms are adaptive and distributed in nature and typically
use learning models to find good paths for TE in a network. While
state-dependent TE models typically use available-link-bandwidth
(ALB) flooding for TE path selection, event-dependent TE methods do
not require ALB flooding. Rather, event-dependent TE methods
typically search out capacity by learning models, as in the success-
to-the-top (STT) method. ALB flooding can be resource intensive,
since it requires link bandwidth to carry LSAs, processor capacity to
process LSAs, and the overhead can limit area/autonomous system (AS)
size. Modeling results suggest that event-dependent TE methods could
lead to a reduction in ALB flooding overhead without loss of network
throughput performance [ASH3].
5.2 Offline Versus Online
Traffic engineering requires the computation of routing plans. The
computation may be performed offline or online. The computation can
be done offline for scenarios where routing plans need not be
executed in real-time. For example, routing plans computed from
forecast information may be computed offline. Typically, offline
computation is also used to perform extensive searches on multi-
dimensional solution spaces.
Online computation is required when the routing plans must adapt to
changing network conditions as in state-dependent algorithms. Unlike
offline computation (which can be computationally demanding), online
computation is geared toward relative simple and fast calculations to
select routes, fine-tune the allocations of resources, and perform
load balancing.
5.3 Centralized Versus Distributed
Centralized control has a central authority which determines routing
plans and perhaps other TE control parameters on behalf of each
router. The central authority collects the network-state information
from all routers periodically and returns the routing information to
the routers. The routing update cycle is a critical parameter
directly impacting the performance of the network being controlled.
Centralized control may need high processing power and high bandwidth
control channels.
Distributed control determines route selection by each router
autonomously based on the routers view of the state of the network.
The network state information may be obtained by the router using a
probing method or distributed by other routers on a periodic basis
using link state advertisements. Network state information may also
be disseminated under exceptional conditions.
5.4 Local Versus Global
Traffic engineering algorithms may require local or global network-
state information.
Local information pertains to the state of a portion of the domain.
Examples include the bandwidth and packet loss rate of a particular
path. Local state information may be sufficient for certain
instances of distributed-controlled TEs.
Global information pertains to the state of the entire domain
undergoing traffic engineering. Examples include a global traffic
matrix and loading information on each link throughout the domain of
interest. Global state information is typically required with
centralized control. Distributed TE systems may also need global
information in some cases.
5.5 Prescriptive Versus Descriptive
TE systems may also be classified as prescriptive or descriptive.
Prescriptive traffic engineering evaluates alternatives and
recommends a course of action. Prescriptive traffic engineering can
be further categorized as either corrective or perfective.
Corrective TE prescribes a course of action to address an existing or
predicted anomaly. Perfective TE prescribes a course of action to
evolve and improve network performance even when no anomalies are
evident.
Descriptive traffic engineering, on the other hand, characterizes the
state of the network and assesses the impact of various policies
without recommending any particular course of action.
5.6 Open-Loop Versus Closed-Loop
Open-loop traffic engineering control is where control action does
not use feedback information from the current network state. The
control action may use its own local information for accounting
purposes, however.
Closed-loop traffic engineering control is where control action
utilizes feedback information from the network state. The feedback
information may be in the form of historical information or current
measurement.
5.7 Tactical vs Strategic
Tactical traffic engineering aims to address specific performance
problems (such as hot-spots) that occur in the network from a
tactical perspective, without consideration of overall strategic
imperatives. Without proper planning and insights, tactical TE tends
to be ad hoc in nature.
Strategic traffic engineering approaches the TE problem from a more
organized and systematic perspective, taking into consideration the
immediate and longer term consequences of specific policies and
actions.
6.0 Recommendations for Internet Traffic Engineering
This section describes high level recommendations for traffic
engineering in the Internet. These recommendations are presented in
general terms.
The recommendations describe the capabilities needed to solve a
traffic engineering problem or to achieve a traffic engineering
objective. Broadly speaking, these recommendations can be
categorized as either functional and non-functional recommendations.
Functional recommendations for Internet traffic engineering describe
the functions that a traffic engineering system should perform.
These functions are needed to realize traffic engineering objectives
by addressing traffic engineering problems.
Non-functional recommendations for Internet traffic engineering
relate to the quality attributes or state characteristics of a
traffic engineering system. These recommendations may contain
conflicting assertions and may sometimes be difficult to quantify
precisely.
6.1 Generic Non-functional Recommendations
The generic non-functional recommendations for Internet traffic
engineering include: usability, automation, scalability, stability,
visibility, simplicity, efficiency, reliability, correctness,
maintainability, extensibility, interoperability, and security. In a
given context, some of these recommendations may be critical while
others may be optional. Therefore, prioritization may be required
during the development phase of a traffic engineering system (or
components thereof) to tailor it to a specific operational context.
In the following paragraphs, some of the aspects of the non-
functional recommendations for Internet traffic engineering are
summarized.
Usability: Usability is a human factor aspect of traffic engineering
systems. Usability refers to the ease with which a traffic
engineering system can be deployed and operated. In general, it is
desirable to have a TE system that can be readily deployed in an
existing network. It is also desirable to have a TE system that is
easy to operate and maintain.
Automation: Whenever feasible, a traffic engineering system should
automate as many traffic engineering functions as possible to
minimize the amount of human effort needed to control and analyze
operational networks. Automation is particularly imperative in large
scale public networks because of the high cost of the human aspects
of network operations and the high risk of network problems caused by
human errors. Automation may entail the incorporation of automatic
feedback and intelligence into some components of the traffic
engineering system.
Scalability: Contemporary public networks are growing very fast with
respect to network size and traffic volume. Therefore, a TE system
should be scalable to remain applicable as the network evolves. In
particular, a TE system should remain functional as the network
expands with regard to the number of routers and links, and with
respect to the traffic volume. A TE system should have a scalable
architecture, should not adversely impair other functions and
processes in a network element, and should not consume too much
network resources when collecting and distributing state information
or when exerting control.
Stability: Stability is a very important consideration in traffic
engineering systems that respond to changes in the state of the
network. State-dependent traffic engineering methodologies typically
mandate a tradeoff between responsiveness and stability. It is
strongly recommended that when tradeoffs are warranted between
responsiveness and stability, that the tradeoff should be made in
favor of stability (especially in public IP backbone networks).
Flexibility: A TE system should be flexible to allow for changes in
optimization policy. In particular, a TE system should provide
sufficient configuration options so that a network administrator can
tailor the TE system to a particular environment. It may also be
desirable to have both online and offline TE subsystems which can be
independently enabled and disabled. TE systems that are used in
multi-class networks should also have options to support class based
performance evaluation and optimization.
Visibility: As part of the TE system, mechanisms should exist to
collect statistics from the network and to analyze these statistics
to determine how well the network is functioning. Derived statistics
such as traffic matrices, link utilization, latency, packet loss, and
other performance measures of interest which are determined from
network measurements can be used as indicators of prevailing network
conditions. Other examples of status information which should be
observed include existing functional routing information
(additionally, in the context of MPLS existing LSP routes), etc.
Simplicity: Generally, a TE system should be as simple as possible.
More importantly, the TE system should be relatively easy to use
(i.e., clean, convenient, and intuitive user interfaces). Simplicity
in user interface does not necessarily imply that the TE system will
use naive algorithms. When complex algorithms and internal
structures are used, such complexities should be hidden as much as
possible from the network administrator through the user interface.
Interoperability: Whenever feasible, traffic engineering systems and
their components should be developed with open standards based
interfaces to allow interoperation with other systems and components.
Security: Security is a critical consideration in traffic engineering
systems. Such traffic engineering systems typically exert control
over certain functional aspects of the network to achieve the desired
performance objectives. Therefore, adequate measures must be taken
to safeguard the integrity of the traffic engineering system.
Adequate measures must also be taken to protect the network from
vulnerabilities that originate from security breaches and other
impairments within the traffic engineering system.
The remainder of this section will focus on some of the high level
functional recommendations for traffic engineering.
6.2 Routing Recommendations
Routing control is a significant aspect of Internet traffic
engineering. Routing impacts many of the key performance measures
associated with networks, such as throughput, delay, and utilization.
Generally, it is very difficult to provide good service quality in a
wide area network without effective routing control. A desirable
routing system is one that takes traffic characteristics and network
constraints into account during route selection while maintaining
stability.
Traditional shortest path first (SPF) interior gateway protocols are
based on shortest path algorithms and have limited control
capabilities for traffic engineering [RFC-2702, AWD2]. These
limitations include :
1. The well known issues with pure SPF protocols, which do not take
network constraints and traffic characteristics into account
during route selection. For example, since IGPs always use the
shortest paths (based on administratively assigned link metrics)
to forward traffic, load sharing cannot be accomplished among
paths of different costs. Using shortest paths to forward traffic
conserves network resources, but may cause the following problems:
1) If traffic from a source to a destination exceeds the capacity
of a link along the shortest path, the link (hence the shortest
path) becomes congested while a longer path between these two
nodes may be under-utilized; 2) the shortest paths from different
sources can overlap at some links. If the total traffic from the
sources exceeds the capacity of any of these links, congestion
will occur. Problems can also occur because traffic demand
changes over time but network topology and routing configuration
cannot be changed as rapidly. This causes the network topology
and routing configuration to become sub-optimal over time, which
may result in persistent congestion problems.
2. The Equal-Cost Multi-Path (ECMP) capability of SPF IGPs supports
sharing of traffic among equal cost paths between two nodes.
However, ECMP attempts to divide the traffic as equally as
possible among the equal cost shortest paths. Generally, ECMP
does not support configurable load sharing ratios among equal cost
paths. The result is that one of the paths may carry
significantly more traffic than other paths because it may also
carry traffic from other sources. This situation can result in
congestion along the path that carries more traffic.
3. Modifying IGP metrics to control traffic routing tends to have
network-wide effect. Consequently, undesirable and unanticipated
traffic shifts can be triggered as a result. Recent work
described in Section 8.0 may be capable of better control [FT00,
FT01].
Because of these limitations, new capabilities are needed to enhance
the routing function in IP networks. Some of these capabilities have
been described elsewhere and are summarized below.
Constraint-based routing is desirable to evolve the routing
architecture of IP networks, especially public IP backbones with
complex topologies [RFC-2702]. Constraint-based routing computes
routes to fulfill requirements subject to constraints. Constraints
may include bandwidth, hop count, delay, and administrative policy
instruments such as resource class attributes [RFC-2702, RFC-2386].
This makes it possible to select routes that satisfy a given set of
requirements subject to network and administrative policy
constraints. Routes computed through constraint-based routing are
not necessarily the shortest paths. Constraint-based routing works
best with path oriented technologies that support explicit routing,
such as MPLS.
Constraint-based routing can also be used as a way to redistribute
traffic onto the infrastructure (even for best effort traffic). For
example, if the bandwidth requirements for path selection and
reservable bandwidth attributes of network links are appropriately
defined and configured, then congestion problems caused by uneven
traffic distribution may be avoided or reduced. In this way, the
performance and efficiency of the network can be improved.
A number of enhancements are needed to conventional link state IGPs,
such as OSPF and IS-IS, to allow them to distribute additional state
information required for constraint-based routing. These extensions
to OSPF were described in [KATZ] and to IS-IS in [SMIT].
Essentially, these enhancements require the propagation of additional
information in link state advertisements. Specifically, in addition
to normal link-state information, an enhanced IGP is required to
propagate topology state information needed for constraint-based
routing. Some of the additional topology state information include
link attributes such as reservable bandwidth and link resource class
attribute (an administratively specified property of the link). The
resource class attribute concept was defined in [RFC-2702]. The
additional topology state information is carried in new TLVs and
sub-TLVs in IS-IS, or in the Opaque LSA in OSPF [SMIT, KATZ].
An enhanced link-state IGP may flood information more frequently than
a normal IGP. This is because even without changes in topology,
changes in reservable bandwidth or link affinity can trigger the
enhanced IGP to initiate flooding. A tradeoff is typically required
between the timeliness of the information flooded and the flooding
frequency to avoid excessive consumption of link bandwidth and
computational resources, and more importantly, to avoid instability.
In a TE system, it is also desirable for the routing subsystem to
make the load splitting ratio among multiple paths (with equal cost
or different cost) configurable. This capability gives network
administrators more flexibility in the control of traffic
distribution across the network. It can be very useful for
avoiding/relieving congestion in certain situations. Examples can be
found in [XIAO].
The routing system should also have the capability to control the
routes of subsets of traffic without affecting the routes of other
traffic if sufficient resources exist for this purpose. This
capability allows a more refined control over the distribution of
traffic across the network. For example, the ability to move traffic
from a source to a destination away from its original path to another
path (without affecting other traffic paths) allows traffic to be
moved from resource-poor network segments to resource-rich segments.
Path oriented technologies such as MPLS inherently support this
capability as discussed in [AWD2].
Additionally, the routing subsystem should be able to select
different paths for different classes of traffic (or for different
traffic behavior aggregates) if the network supports multiple classes
of service (different behavior aggregates).
6.3 Traffic Mapping Recommendations
Traffic mapping pertains to the assignment of traffic workload onto
pre-established paths to meet certain requirements. Thus, while
constraint-based routing deals with path selection, traffic mapping
deals with the assignment of traffic to established paths which may
have been selected by constraint-based routing or by some other
means. Traffic mapping can be performed by time-dependent or state-
dependent mechanisms, as described in Section 5.1.
An important aspect of the traffic mapping function is the ability to
establish multiple paths between an originating node and a
destination node, and the capability to distribute the traffic
between the two nodes across the paths according to some policies. A
pre-condition for this scheme is the existence of flexible mechanisms
to partition traffic and then assign the traffic partitions onto the
parallel paths. This requirement was noted in [RFC-2702]. When
traffic is assigned to multiple parallel paths, it is recommended
that special care should be taken to ensure proper ordering of
packets belonging to the same application (or micro-flow) at the
destination node of the parallel paths.
As a general rule, mechanisms that perform the traffic mapping
functions should aim to map the traffic onto the network
infrastructure to minimize congestion. If the total traffic load
cannot be accommodated, or if the routing and mapping functions
cannot react fast enough to changing traffic conditions, then a
traffic mapping system may rely on short time scale congestion
control mechanisms (such as queue management, scheduling, etc.) to
mitigate congestion. Thus, mechanisms that perform the traffic
mapping functions should complement existing congestion control
mechanisms. In an operational network, it is generally desirable to
map the traffic onto the infrastructure such that intra-class and
inter-class resource contention are minimized.
When traffic mapping techniques that depend on dynamic state feedback
(e.g., MATE and such like) are used, special care must be taken to
guarantee network stability.
6.4 Measurement Recommendations
The importance of measurement in traffic engineering has been
discussed throughout this document. Mechanisms should be provided to
measure and collect statistics from the network to support the
traffic engineering function. Additional capabilities may be needed
to help in the analysis of the statistics. The actions of these
mechanisms should not adversely affect the accuracy and integrity of
the statistics collected. The mechanisms for statistical data
acquisition should also be able to scale as the network evolves.
Traffic statistics may be classified according to long-term or
short-term time scales. Long-term time scale traffic statistics are
very useful for traffic engineering. Long-term time scale traffic
statistics may capture or reflect periodicity in network workload
(such as hourly, daily, and weekly variations in traffic profiles) as
well as traffic trends. Aspects of the monitored traffic statistics
may also depict class of service characteristics for a network
supporting multiple classes of service. Analysis of the long-term
traffic statistics MAY yield secondary statistics such as busy hour
characteristics, traffic growth patterns, persistent congestion
problems, hot-spot, and imbalances in link utilization caused by
routing anomalies.
A mechanism for constructing traffic matrices for both long-term and
short-term traffic statistics should be in place. In multi-service
IP networks, the traffic matrices may be constructed for different
service classes. Each element of a traffic matrix represents a
statistic of traffic flow between a pair of abstract nodes. An
abstract node may represent a router, a collection of routers, or a
site in a VPN.
Measured traffic statistics should provide reasonable and reliable
indicators of the current state of the network on the short-term
scale. Some short term traffic statistics may reflect link
utilization and link congestion status. Examples of congestion
indicators include excessive packet delay, packet loss, and high
resource utilization. Examples of mechanisms for distributing this
kind of information include SNMP, probing techniques, FTP, IGP link
state advertisements, etc.
6.5 Network Survivability
Network survivability refers to the capability of a network to
maintain service continuity in the presence of faults. This can be
accomplished by promptly recovering from network impairments and
maintaining the required QoS for existing services after recovery.
Survivability has become an issue of great concern within the
Internet community due to the increasing demands to carry mission
critical traffic, real-time traffic, and other high priority traffic
over the Internet. Survivability can be addressed at the device
level by developing network elements that are more reliable; and at
the network level by incorporating redundancy into the architecture,
design, and operation of networks. It is recommended that a
philosophy of robustness and survivability should be adopted in the
architecture, design, and operation of traffic engineering that
control IP networks (especially public IP networks). Because
different contexts may demand different levels of survivability, the
mechanisms developed to support network survivability should be
flexible so that they can be tailored to different needs.
Failure protection and restoration capabilities have become available
from multiple layers as network technologies have continued to
improve. At the bottom of the layered stack, optical networks are
now capable of providing dynamic ring and mesh restoration
functionality at the wavelength level as well as traditional
protection functionality. At the SONET/SDH layer survivability
capability is provided with Automatic Protection Switching (APS) as
well as self-healing ring and mesh architectures. Similar
functionality is provided by layer 2 technologies such as ATM
(generally with slower mean restoration times). Rerouting is
traditionally used at the IP layer to restore service following link
and node outages. Rerouting at the IP layer occurs after a period of
routing convergence which may require seconds to minutes to complete.
Some new developments in the MPLS context make it possible to achieve
recovery at the IP layer prior to convergence [SHAR].
To support advanced survivability requirements, path-oriented
technologies such a MPLS can be used to enhance the survivability of
IP networks in a potentially cost effective manner. The advantages
of path oriented technologies such as MPLS for IP restoration becomes
even more evident when class based protection and restoration
capabilities are required.
Recently, a common suite of control plane protocols has been proposed
for both MPLS and optical transport networks under the acronym
Multi-protocol Lambda Switching [AWD1]. This new paradigm of Multi-
protocol Lambda Switching will support even more sophisticated mesh
restoration capabilities at the optical layer for the emerging IP
over WDM network architectures.
Another important aspect regarding multi-layer survivability is that
technologies at different layers provide protection and restoration
capabilities at different temporal granularities (in terms of time
scales) and at different bandwidth granularity (from packet-level to
wavelength level). Protection and restoration capabilities can also
be sensitive to different service classes and different network
utility models.
The impact of service outages varies significantly for different
service classes depending upon the effective duration of the outage.
The duration of an outage can vary from milliseconds (with minor
service impact) to seconds (with possible call drops for IP telephony
and session time-outs for connection oriented transactions) to
minutes and hours (with potentially considerable social and business
impact).
Coordinating different protection and restoration capabilities across
multiple layers in a cohesive manner to ensure network survivability
is maintained at reasonable cost is a challenging task. Protection
and restoration coordination across layers may not always be
feasible, because networks at different layers may belong to
different administrative domains.
The following paragraphs present some of the general recommendations
for protection and restoration coordination.
- Protection and restoration capabilities from different layers
should be coordinated whenever feasible and appropriate to provide
network survivability in a flexible and cost effective manner.
Minimization of function duplication across layers is one way to
achieve the coordination. Escalation of alarms and other fault
indicators from lower to higher layers may also be performed in a
coordinated manner. A temporal order of restoration trigger timing
at different layers is another way to coordinate multi-layer
protection/restoration.
- Spare capacity at higher layers is often regarded as working
traffic at lower layers. Placing protection/restoration functions in
many layers may increase redundancy and robustness, but it should not
result in significant and avoidable inefficiencies in network
resource utilization.
- It is generally desirable to have protection and restoration
schemes that are bandwidth efficient.
- Failure notification throughout the network should be timely and
reliable.
- Alarms and other fault monitoring and reporting capabilities
should be provided at appropriate layers.
6.5.1 Survivability in MPLS Based Networks
MPLS is an important emerging technology that enhances IP networks in
terms of features, capabilities, and services. Because MPLS is
path-oriented, it can potentially provide faster and more predictable
protection and restoration capabilities than conventional hop by hop
routed IP systems. This subsection describes some of the basic
aspects and recommendations for MPLS networks regarding protection
and restoration. See [SHAR] for a more comprehensive discussion on
MPLS based recovery.
Protection types for MPLS networks can be categorized as link
protection, node protection, path protection, and segment protection.
- Link Protection: The objective for link protection is to protect
an LSP from a given link failure. Under link protection, the path
of the protection or backup LSP (the secondary LSP) is disjoint
from the path of the working or operational LSP at the particular
link over which protection is required. When the protected link
fails, traffic on the working LSP is switched over to the
protection LSP at the head-end of the failed link. This is a
local repair method which can be fast. It might be more
appropriate in situations where some network elements along a
given path are less reliable than others.
- Node Protection: The objective of LSP node protection is to
protect an LSP from a given node failure. Under node protection,
the path of the protection LSP is disjoint from the path of the
working LSP at the particular node to be protected. The secondary
path is also disjoint from the primary path at all links
associated with the node to be protected. When the node fails,
traffic on the working LSP is switched over to the protection LSP
at the upstream LSR directly connected to the failed node.
- Path Protection: The goal of LSP path protection is to protect an
LSP from failure at any point along its routed path. Under path
protection, the path of the protection LSP is completely disjoint
from the path of the working LSP. The advantage of path
protection is that the backup LSP protects the working LSP from
all possible link and node failures along the path, except for
failures that might occur at the ingress and egress LSRs, or for
correlated failures that might impact both working and backup
paths simultaneously. Additionally, since the path selection is
end-to-end, path protection might be more efficient in terms of
resource usage than link or node protection. However, path
protection may be slower than link and node protection in general.
- Segment Protection: An MPLS domain may be partitioned into
multiple protection domains whereby a failure in a protection
domain is rectified within that domain. In cases where an LSP
traverses multiple protection domains, a protection mechanism
within a domain only needs to protect the segment of the LSP that
lies within the domain. Segment protection will generally be
faster than path protection because recovery generally occurs
closer to the fault.
6.5.2 Protection Option
Another issue to consider is the concept of protection options. The
protection option uses the notation m:n protection, where m is the
number of protection LSPs used to protect n working LSPs. Feasible
protection options follow.
- 1:1: one working LSP is protected/restored by one protection LSP.
- 1:n: one protection LSP is used to protect/restore n working LSPs.
- n:1: one working LSP is protected/restored by n protection LSPs,
possibly with configurable load splitting ratio. When more than
one protection LSP is used, it may be desirable to share the
traffic across the protection LSPs when the working LSP fails to
satisfy the bandwidth requirement of the traffic trunk associated
with the working LSP. This may be especially useful when it is
not feasible to find one path that can satisfy the bandwidth
requirement of the primary LSP.
- 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 LSPs based on a local traffic integrity decision process,
which compares the traffic received from both the working and the
protection LSP and identifies discrepancies. It is unlikely that
this option would be used extensively in IP networks due to its
resource utilization inefficiency. However, if bandwidth becomes
plentiful and cheap, then this option might become quite viable
and attractive in IP networks.
6.6 Traffic Engineering in Diffserv Environments
This section provides an overview of the traffic engineering features
and recommendations that are specifically pertinent to Differentiated
Services (Diffserv) [RFC-2475] capable IP networks.
Increasing requirements to support multiple classes of traffic, such
as best effort and mission critical data, in the Internet calls for
IP networks to differentiate traffic according to some criteria, and
to accord preferential treatment to certain types of traffic. Large
numbers of flows can be aggregated into a few behavior aggregates
based on some criteria in terms of common performance requirements in
terms of packet loss ratio, delay, and jitter; or in terms of common
fields within the IP packet headers.
As Diffserv evolves and becomes deployed in operational networks,
traffic engineering will be critical to ensuring that SLAs defined
within a given Diffserv service model are met. Classes of service
(CoS) can be supported in a Diffserv environment by concatenating
per-hop behaviors (PHBs) along the routing path, using service
provisioning mechanisms, and by appropriately configuring edge
functionality such as traffic classification, marking, policing, and
shaping. PHB is the forwarding behavior that a packet receives at a
DS node (a Diffserv-compliant node). This is accomplished by means
of buffer management and packet scheduling mechanisms. In this
context, packets belonging to a class are those that are members of a
corresponding ordering aggregate.
Traffic engineering can be used as a compliment to Diffserv
mechanisms to improve utilization of network resources, but not as a
necessary element in general. When traffic engineering is used, it
can be operated on an aggregated basis across all service classes
[RFC-3270] or on a per service class basis. The former is used to
provide better distribution of the aggregate traffic load over the
network resources. (See [RFC-3270] for detailed mechanisms to
support aggregate traffic engineering.) The latter case is discussed
below since it is specific to the Diffserv environment, with so
called Diffserv-aware traffic engineering [DIFF_TE].
For some Diffserv networks, it may be desirable to control the
performance of some service classes by enforcing certain
relationships between the traffic workload contributed by each
service class and the amount of network resources allocated or
provisioned for that service class. Such relationships between
demand and resource allocation can be enforced using a combination
of, for example: (1) traffic engineering mechanisms on a per service
class basis that enforce the desired relationship between the amount
of traffic contributed by a given service class and the resources
allocated to that class, and (2) mechanisms that dynamically adjust
the resources allocated to a given service class to relate to the
amount of traffic contributed by that service class.
It may also be desirable to limit the performance impact of high
priority traffic on relatively low priority traffic. This can be
achieved by, for example, controlling the percentage of high priority
traffic that is routed through a given link. Another way to
accomplish this is to increase link capacities appropriately so that
lower priority traffic can still enjoy adequate service quality.
When the ratio of traffic workload contributed by different service
classes vary significantly from router to router, it may not suffice
to rely exclusively on conventional IGP routing protocols or on
traffic engineering mechanisms that are insensitive to different
service classes. Instead, it may be desirable to perform traffic
engineering, especially routing control and mapping functions, on a
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
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
can then be routed and protected/restored in a class dependent
manner, according to specific policies.
Performing traffic engineering on a per class basis may require
certain per-class parameters to be distributed. Note that it is
common to have some classes share some aggregate constraint (e.g.,
maximum bandwidth requirement) without enforcing the constraint on
each individual class. These classes then can be grouped into a
class-type and per-class-type parameters can be distributed instead
to improve scalability. It also allows better bandwidth sharing
between classes in the same class-type. A class-type is a set of
classes that satisfy the following two conditions:
1) Classes in the same class-type have common aggregate requirements
to satisfy required performance levels.
2) There is no requirement to be enforced at the level of individual
class in the class-type. Note that it is still possible,
nevertheless, to implement some priority policies for classes in the
same class-type to permit preferential access to the class-type
bandwidth through the use of preemption priorities.
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
a class-type, one may implement some priority policy which assigns
higher preemption priority to AF1-based traffic trunks over AF2-based
ones, vice versa, or the same priority.
See [DIFF-TE] for detailed requirements on Diffserv-aware traffic
engineering.
6.7 Network Controllability
Off-line (and on-line) traffic engineering considerations would be of
limited utility if the network could not be controlled effectively to
implement the results of TE decisions and to achieve desired network
performance objectives. Capacity augmentation is a coarse grained
solution to traffic engineering issues. However, it is simple and
may be advantageous if bandwidth is abundant and cheap or if the
current or expected network workload demands it. However, bandwidth
is not always abundant and cheap, and the workload may not always
demand additional capacity. Adjustments of administrative weights
and other parameters associated with routing protocols provide finer
grained control, but is difficult to use and imprecise because of the
routing interactions that occur across the network. In certain
network contexts, more flexible, finer grained approaches which
provide more precise control over the mapping of traffic to routes
and over the selection and placement of routes may be appropriate and
useful.
Control mechanisms can be manual (e.g., administrative
configuration), partially-automated (e.g., scripts) or fully-
automated (e.g., policy based management systems). Automated
mechanisms are particularly required in large scale networks.
Multi-vendor interoperability can be facilitated by developing and
deploying standardized management
systems (e.g., standard MIBs) and policies (PIBs) to support the
control functions required to address traffic engineering objectives
such as load distribution and protection/restoration.
Network control functions should be secure, reliable, and stable as
these are often needed to operate correctly in times of network
impairments (e.g., during network congestion or security attacks).
7.0 Inter-Domain Considerations
Inter-domain traffic engineering is concerned with the performance
optimization for traffic that originates in one administrative domain
and terminates in a different one.
Traffic exchange between autonomous systems in the Internet occurs
through exterior gateway protocols. Currently, BGP [BGP4] is the
standard exterior gateway protocol for the Internet. BGP provides a
number of attributes and capabilities (e.g., route filtering) that
can be used for inter-domain traffic engineering. More specifically,
BGP permits the control of routing information and traffic exchange
between Autonomous Systems (AS's) in the Internet. BGP incorporates
a sequential decision process which calculates the degree of
preference for various routes to a given destination network. There
are two fundamental aspects to inter-domain traffic engineering using
BGP:
- Route Redistribution: controlling the import and export of routes
between AS's, and controlling the redistribution of routes between
BGP and other protocols within an AS.
- Best path selection: selecting the best path when there are
multiple candidate paths to a given destination network. Best
path selection is performed by the BGP decision process based on a
sequential procedure, taking a number of different considerations
into account. Ultimately, best path selection under BGP boils
down to selecting preferred exit points out of an AS towards
specific destination networks. The BGP path selection process can
be influenced by manipulating the attributes associated with the
BGP decision process. These attributes include: NEXT-HOP, WEIGHT
(Cisco proprietary which is also implemented by some other
vendors), LOCAL-PREFERENCE, AS-PATH, ROUTE-ORIGIN, MULTI-EXIT-
DESCRIMINATOR (MED), IGP METRIC, etc.
Route-maps provide the flexibility to implement complex BGP policies
based on pre-configured logical conditions. In particular, Route-
maps can be used to control import and export policies for incoming
and outgoing routes, control the redistribution of routes between BGP
and other protocols, and influence the selection of best paths by
manipulating the attributes associated with the BGP decision process.
Very complex logical expressions that implement various types of
policies can be implemented using a combination of Route-maps, BGP-
attributes, Access-lists, and Community attributes.
When looking at possible strategies for inter-domain TE with BGP, it
must be noted that the outbound traffic exit point is controllable,
whereas the interconnection point where inbound traffic is received
from an EBGP peer typically is not, unless a special arrangement is
made with the peer sending the traffic. Therefore, it is up to each
individual network to implement sound TE strategies that deal with
the efficient delivery of outbound traffic from one's customers to