This module describes how to implement MPLS
Traffic Engineering on
Cisco ASR 9000 Series Router.
Multiprotocol Label Switching (MPLS) is a standards-based solution
driven by the Internet Engineering Task Force (IETF) that was devised to
convert the Internet and IP backbones from best-effort networks into
business-class transport mediums.
MPLS, with its label switching capabilities, eliminates the need for an
IP route look-up and creates a virtual circuit (VC) switching function,
allowing enterprises the same performance on their IP-based network services as
with those delivered over traditional networks such as Frame Relay or
Asynchronous Transfer Mode (ATM).
MPLS traffic engineering (MPLS-TE) software enables an MPLS backbone to
replicate and expand upon the TE capabilities of Layer 2 ATM and Frame Relay
networks. MPLS is an integration of
Layer 2 and Layer 3 technologies. By making traditional Layer 2 features
available to Layer 3, MPLS enables traffic engineering. Thus, you can offer in
a one-tier network what now can be achieved only by overlaying a Layer 3
network on a Layer 2 network.
Note
The LMP and GMPLS-NNI features are not supported on PRP hardware.
Feature History for Implementing MPLS-TE
Release
Modification
Release 3.7.2
This feature was introduced.
Release 3.9.0
The MPLS Traffic Engineering (TE): Path Protection
feature was added.
Release 3.9.1
The MPLS-TE automatic bandwidth feature is supported.
Prerequisites for Implementing Cisco MPLS Traffic Engineering
These prerequisites are required to implement MPLS TE:
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
Router that runs
Cisco IOS XR software.
Installed composite mini-image and the MPLS package, or a full
composite image.
IGP activated.
Enable LDP globally by using the mpls ldp command to allocate local labels even in RSVP (MPLS TE) only core. You do not have to specify any interface if the core is LDP free.
Restrictions for Implementing GMPLS UNI
The total number of configured GMPLS UNI controllers should not exceed the platform scale limit of 500 GMPLS interfaces.
Each UNI-N (ingress or egress) should be routable from its adjacent UNI-C. The UNI-C nodes need to be routable from the UNI-N nodes too.
GMPLS UNI is supported only over DWDM controllers and so, over POS and GigabitEthernet interfaces.
GMPLS UNI is supported only with these Cisco ASR 9000 Enhanced Ethernet Line Cards:
A9K-MOD80-SE : 80G Modular Line Card, Service Edge Optimized
A9K-MOD80-TR : 80G Modular Line Card, Packet Transport Optimized
Information About Implementing MPLS Traffic Engineering
To implement MPLS-TE, you should understand these concepts:
MPLS-TE software enables an MPLS backbone to replicate and expand upon the traffic engineering capabilities of Layer 2 ATM and Frame Relay networks. MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables traffic engineering. Thus, you can offer in a one-tier network what now can be achieved only by overlaying a Layer 3 network on a Layer 2 network.
MPLS-TE is essential for service provider and Internet service provider (ISP) backbones. Such backbones must support a high use of transmission capacity, and the networks must be very resilient so that they can withstand link or node failures. MPLS-TE provides an integrated approach to traffic engineering. With MPLS, traffic engineering capabilities are integrated into Layer 3, which optimizes the routing of IP traffic, given the constraints imposed by backbone capacity and topology.
MPLS-TE enables ISPs to route network traffic to offer the best service to their users in terms of throughput and delay. By making the service provider more efficient, traffic engineering reduces the cost of the network.
Currently, some ISPs base their services on an overlay model. In the overlay model, transmission facilities are managed by Layer 2 switching. The routers see only a fully meshed virtual topology, making most destinations appear one hop away. If you use the explicit Layer 2 transit layer, you can precisely control how traffic uses available bandwidth. However, the overlay model has numerous disadvantages. MPLS-TE achieves the TE benefits of the overlay model without running a separate network and without a non-scalable, full mesh of router interconnects.
How MPLS-TE Works
MPLS-TE automatically establishes and maintains label switched paths
(LSPs) across the backbone by using RSVP. The
path that an LSP uses is determined by the LSP resource requirements and
network resources, such as bandwidth. Available resources are flooded by means
of extensions to a link-state-based Interior Gateway Protocol (IGP).
MPLS-TE tunnels are calculated at the LSP headend router, based on a fit
between the required and available resources (constraint-based routing). The
IGP automatically routes the traffic to these LSPs.
Typically, a packet crossing the MPLS-TE backbone travels on a single
LSP that connects the ingress point to the egress point. MPLS-TE is built on
these mechanisms:
Tunnel interfaces
From a Layer 2 standpoint, an MPLS tunnel interface represents the
headend of an LSP. It is configured with a set of resource requirements, such
as bandwidth and media requirements, and priority. From a Layer 3 standpoint,
an LSP tunnel interface is the headend of a unidirectional virtual link to the
tunnel destination.
MPLS-TE path calculation module
This calculation module operates at the LSP headend. The module
determines a path to use for an LSP. The path calculation uses a link-state
database containing flooded topology and resource information.
RSVP with TE extensions
RSVP operates at each LSP hop and is used to signal and maintain
LSPs based on the calculated path.
MPLS-TE link management module
This module operates at each LSP hop, performs link call admission
on the RSVP signaling messages, and performs bookkeeping on topology and
resource information to be flooded.
Link-state IGP (Intermediate System-to-Intermediate System [IS-IS]
or Open Shortest Path First [OSPF]—each with traffic engineering extensions)
These IGPs are used to globally flood topology and resource
information from the link management module.
Enhancements to the shortest path first (SPF) calculation used by
the link-state IGP (IS-IS or OSPF)
The IGP automatically routes traffic to the appropriate LSP
tunnel, based on tunnel destination. Static routes can also be used to direct
traffic to LSP tunnels.
Label switching forwarding
This forwarding mechanism provides routers with a Layer 2-like
ability to direct traffic across multiple hops of the LSP established by RSVP
signaling.
One approach to engineering a backbone is to define a mesh of tunnels
from every ingress device to every egress device. The MPLS-TE path calculation
and signaling modules determine the path taken by the LSPs for these tunnels,
subject to resource availability and the dynamic state of the network.
The IGP (operating at an ingress device) determines which traffic should
go to which egress device, and steers that traffic into the tunnel from ingress
to egress. A flow from an ingress device to an egress device might be so large
that it cannot fit over a single link, so it cannot be carried by a single
tunnel. In this case, multiple tunnels between a given ingress and egress can
be configured, and the flow is distributed using load sharing among the
tunnels.
Cisco IOS XR software
provides a protocol-based command line interface. The CLI provides commands
that can be used with the multiple IGP protocols supported by MPLS-TE.
Differentiated Services Traffic Engineering
MPLS Differentiated Services (Diff-Serv) Aware Traffic Engineering
(DS-TE) is an extension of the regular MPLS-TE feature. Regular traffic
engineering does not provide bandwidth guarantees to different traffic classes.
A single bandwidth constraint is used in regular TE that is shared by all
traffic. To support various classes of service (CoS), users can configure
multiple bandwidth constraints. These bandwidth constraints can be treated
differently based on the requirement for the traffic class using that
constraint.
MPLS DS-TE provides the ability to configure multiple bandwidth
constraints on an MPLS-enabled interface. Available bandwidths from all
configured bandwidth constraints are advertised using IGP. TE tunnel is
configured with bandwidth value and class-type requirements. Path calculation
and admission control take the bandwidth and class-type into consideration.
RSVP is used to signal the TE tunnel with bandwidth and class-type
requirements.
MPLS DS-TE is deployed with either Russian Doll Model (RDM) or Maximum
Allocation Model (MAM) for bandwidth calculations.
Cisco IOS XR software
supports two DS-TE modes: Prestandard and IETF.
Prestandard DS-TE uses the Cisco proprietary mechanisms for RSVP signaling and IGP advertisements. This DS-TE mode does not interoperate with third-party vendor equipment. Note that prestandard DS-TE is enabled only after configuring the sub-pool bandwidth values on MPLS-enabled interfaces.
Prestandard Diff-Serve TE mode supports a single bandwidth constraint model a Russian Doll Model (RDM) with two bandwidth pools: global-pool and sub-pool.
TE class map is not used with Prestandard DS-TE mode.
IETF DS-TE mode uses IETF-defined extensions for RSVP and IGP. This mode interoperates with third-party vendor equipment.
IETF mode supports multiple bandwidth constraint models, including RDM and MAM, both with two bandwidth pools. In an IETF DS-TE network, identical bandwidth constraint models must be configured on all nodes.
TE class map is used with IETF DS-TE mode and must be configured the same way on all nodes in the network.
Bandwidth Constraint Models
IETF DS-TE mode provides support for the RDM and MAM bandwidth constraints models. Both models support up to two bandwidth pools.
Cisco IOS XR software provides global configuration for the switching between bandwidth constraint models. Both models can be configured on a single interface to preconfigure the bandwidth constraints before swapping to an alternate bandwidth constraint model.
Note
NSF is not guaranteed when you change the bandwidth constraint model or configuration information.
By default, RDM is the default bandwidth constraint model used in both pre-standard and IETF mode.
The RDM constraint model has these characteristics:
Allows greater sharing of bandwidth among different class types.
Ensures bandwidth efficiency simultaneously and protection against QoS degradation of all class types.
Specifies that it is used in conjunction with preemption to simultaneously achieve isolation across class-types such that each class-type is guaranteed its share of bandwidth, bandwidth efficiency, and protection against QoS degradation of all class types.
Note
We recommend that RDM not be used in DS-TE environments in which the use of preemption is precluded. Although RDM ensures bandwidth efficiency and protection against QoS degradation of class types, it does guarantee isolation across class types.
Each of the eight available bandwidth values advertised in the IGP
corresponds to a TE class. Because the IGP advertises only eight bandwidth
values, there can be a maximum of only eight TE classes supported in an IETF
DS-TE network.
TE class mapping must be exactly the same on all routers in a DS-TE
domain. It is the responsibility of the operator configure these settings
properly as there is no way to automatically check or enforce consistency.
The operator must configure TE tunnel class types and priority levels to
form a valid TE class. When the TE class map configuration is changed, tunnels
already up are brought down. Tunnels in the down state, can be set up if a
valid TE class map is found.
The default TE class and attributes are listed. The default mapping
includes four class types.
Table 1 TE Classes and Priority
TE Class
Class Type
Priority
0
0
7
1
1
7
2
Unused
—
3
Unused
—
4
0
0
5
1
0
6
Unused
—
7
Unused
—
Flooding
Available bandwidth in all configured bandwidth pools is flooded on the network to calculate accurate constraint paths when a new TE tunnel is configured. Flooding uses IGP protocol extensions and mechanisms to determine when to flood the network with bandwidth.
TE Link Management (TE-Link) notifies IGP for both global pool and sub-pool available bandwidth and maximum bandwidth to flood the network in these events:
Periodic timer expires (this does not depend on bandwidth pool type).
Tunnel origination node has out-of-date information for either available global pool or sub-pool bandwidth, causing tunnel admission failure at the midpoint.
Consumed bandwidth crosses user-configured thresholds. The same threshold is used for both global pool and sub-pool. If one bandwidth crosses the threshold, both bandwidths are flooded.
Flooding Thresholds
Flooding frequently can burden a network because all routers must send out and process these updates. Infrequent flooding causes tunnel heads (tunnel-originating nodes) to have out-of-date information, causing tunnel admission to fail at the midpoints.
You can control the frequency of flooding by configuring a set of thresholds. When locked bandwidth (at one or more priority levels) crosses one of these thresholds, flooding is triggered.
Thresholds apply to a percentage of the maximum available bandwidth (the global pool), which is locked, and the percentage of maximum available guaranteed bandwidth (the sub-pool), which is locked. If, for one or more priority levels, either of these percentages crosses a threshold, flooding is triggered.
Note
Setting up a global pool TE tunnel can cause the locked bandwidth allocated to sub-pool tunnels to be reduced (and hence to cross a threshold). A sub-pool TE tunnel setup can similarly cause the locked bandwidth for global pool TE tunnels to cross a threshold. Thus, sub-pool TE and global pool TE tunnels can affect each other when flooding is triggered by thresholds.
Fast Reroute
Fast Reroute (FRR) provides link protection to LSPs enabling the traffic carried by LSPs that encounter a failed link to be rerouted around the failure. The reroute decision is controlled locally by the router connected to the failed link. The headend router on the tunnel is notified of the link failure through IGP or through RSVP. When it is notified of a link failure, the headend router attempts to establish a new LSP that bypasses the failure. This provides a path to reestablish links that fail, providing protection to data transfer.
FRR (link or node) is supported over sub-pool tunnels the same way as for regular TE tunnels. In particular, when link protection is activated for a given link, TE tunnels eligible for FRR are redirected into the protection LSP, regardless of whether they are sub-pool or global pool tunnels.
Note
The ability to configure FRR on a per-LSP basis makes it possible to provide different levels of fast restoration to tunnels from different bandwidth pools.
You should be aware of these requirements for the backup tunnel path:
Backup tunnel must not pass through the element it protects.
Primary tunnel and a backup tunnel should intersect at least at two points (nodes) on the path: point of local repair (PLR) and merge point (MP). PLR is the headend of the backup tunnel, and MP is the tailend of the backup tunnel.
Note
When you configure TE tunnel with multiple protection on its path and merge point is the same node for more than one protection, you must configure record-route for that tunnel.
MPLS Traffic Engineering (TE) and Fast Reroute (FRR) are supported over bundle interfaces and virtual local area network (VLAN) interfaces. Bidirectional forwarding detection (BFD) over VLAN is used as an FRR trigger to obtain less than 50 milliseconds of switchover time.
These link bundle types are supported for MPLS-TE/FRR:
Over Ethernet link bundles.
Over VLANs over Ethernet link bundles.
Number of links are limited to 100 for MPLS-TE and FRR.
VLANs go over any Ethernet interface (for example, GigabitEthernet and TenGigE).
FRR is supported over bundle interfaces in the following ways:
Uses minimum links as a threshold to trigger FRR over a bundle interface.
Uses the minimum total available bandwidth as a threshold to trigger FRR.
Ignore Intermediate System-to-Intermediate System Overload Bit Setting in MPLS-TE
The Ignore Intermediate System-to-Intermediate System (IS-IS) Overload Bit Setting in MPLS-TE feature ensures that the RSVP-TE LSPs are not broken because of routers that enabled the IS-IS overload bit.
Note
The current implementation does not allow nodes that have indicated an overload situation through the IS-IS overload bit.
Therefore, an overloaded node cannot be used. The IS-IS overload bit limitation is an indication of an overload situation in the IP topology. The feature provides a method to prevent an IS-IS overload condition from affecting MPLS-TE.
MPLS-TE Flexible Name-based Tunnel Constraints provides a simplified and more flexible means of configuring link attributes and path affinities to compute paths for MPLS-TE tunnels.
In the traditional TE scheme, links are configured with attribute-flags that are flooded with TE link-state parameters using Interior Gateway Protocols (IGPs), such as Open Shortest Path First (OSPF).
MPLS-TE Flexible Name-based Tunnel Constraints lets you assign, or map, up to 32 color names for affinity and attribute-flag attributes instead of 32-bit hexadecimal numbers. After mappings are defined, the attributes can be referred to by the corresponding color name in the command-line interface (CLI). Furthermore, you can define constraints using include, include-strict, exclude, and exclude-all arguments, where each statement can contain up to 10 colors, and define include constraints in both loose and strict sense.
Note
You can configure affinity constraints using attribute flags or the Flexible Name Based Tunnel Constraints scheme; however, when configurations for both schemes exist, only the configuration pertaining to the new scheme is applied.
The MPLS-TE interarea tunneling feature allows you to establish P2P tunnels spanning multiple Interior Gateway Protocol (IGP) areas and levels,
thereby eliminating the requirement that headend and tailend routers reside in
a single area.
Interarea support allows the configuration of a TE LSP that spans
multiple areas, where its headend and tailend label switched routers (LSRs)
reside in different IGP areas.
Multiarea and Interarea TE are required by the customers running
multiple IGP area backbones (primarily for scalability reasons). This lets you
limit the amount of flooded information, reduces the SPF duration, and lessens
the impact of a link or node failure within an area, particularly with large
WAN backbones split in multiple areas.
Figure 1. Interarea (OSPF) TE Network Diagram. This figure shows a typical interarea TE network.
Multiarea Support
Multiarea support allows an area border router (ABR) LSR to support MPLS-TE in more than one
IGP area. A TE LSP is still confined to a single area.
Multiarea and Interarea TE are required when you run multiple IGP area
backbones. The Multiarea and Interarea TE allows you to:
Limit the volume of flooded information.
Reduce the SPF duration.
Decrease the impact of a link or node failure within an area.
Figure 2. Interlevel (IS-IS) TE Network
As shown in
the figure,
R2, R3, R7, and R4 maintain two databases for routing and TE information. For
example, R3 has TE topology information related to R2, flooded through Level-1
IS-IS LSPs plus the TE topology information related to R4, R9, and R7, flooded
as Level 2 IS-IS Link State PDUs (LSPs) (plus, its own IS-IS LSP).
Note
You can configure multiple areas within an IS-IS Level 1. This is
transparent to TE. TE has topology information about the IS-IS level, but not
the area ID.
Loose Hop Expansion
Loose hop optimization allows the reoptimization of tunnels spanning multiple areas and solves the problem which occurs when an MPLS-TE LSP traverses hops that are not in the LSP's headend's OSPF area and IS-IS level.
Interarea MPLS-TE allows you to configure an interarea traffic engineering (TE) label switched path
(LSP)
by specifying a loose source route of ABRs along the path. It is the then the responsibility of the ABR (having a complete view of both areas) to find a path obeying the TE LSP constraints within the next area to reach the next hop ABR (as specified on the headend). The same operation is performed by the last ABR connected to the tailend area to reach the tailend LSR.
You must be aware of these considerations when using loose hop optimization:
You must specify the router ID of the ABR node (as opposed to a link address on the ABR).
When multiarea is deployed in a network that contains subareas, you must enable MPLS-TE in the subarea for TE to find a path when loose hop is specified.
You must specify the reachable explicit path for the interarea tunnel.
Loose Hop Reoptimization
Loose hop reoptimization allows the reoptimization of the tunnels spanning multiple areas and solves the problem which occurs when an MPLS-TE headend does not have visibility into other IGP areas.
Whenever the headend attempts to reoptimize a tunnel, it tries to find a better path to the ABR in the headend area. If a better path is found then the headend initiates the setup of a new LSP. In case a suitable path is not found in the headend area, the headend initiates a querying message. The purpose of this message is to query the ABRs in the areas other than the headend area to check if there exist any better paths in those areas. The purpose of this message is to query the ABRs in the areas other than the headend area, to check if a better path exists. If a better path does not exist, ABR forwards the query to the next router downstream. Alternatively, if better path is found, ABR responds with a special Path Error to the headend to indicate the existence of a better path outside the headend area. Upon receiving the Path Error that indicates the existence of a better path, the headend router initiates the reoptimization.
ABR Node Protection
Because one IGP area does not have visibility into another IGP area, it is not possible to assign backup to protect ABR node. To overcome this problem, node ID sub-object is added into the record route object of the primary tunnel so that at a PLR node, backup destination address can be checked against primary tunnel record-route object and assign a backup tunnel.
Fast Reroute Node Protection
If a link failure occurs within an area, the upstream router directly connected to the failed link generates an RSVP path error message to the headend. As a response to the message, the headend sends an RSVP path tear message and the corresponding path option is marked as invalid for a specified period and the next path-option (if any) is evaluated.
To retry the ABR immediately, a second path option (identical to the first one) should be configured. Alternatively, the retry period (path-option hold-down, 2 minutes by default) can be tuned to achieve a faster retry.
The MPLS-TE Forwarding Adjacency feature allows a network administrator to handle a traffic engineering, label-switched path (LSP) tunnel as a link in an Interior Gateway Protocol (IGP) network based on the Shortest Path First (SPF) algorithm. A forwarding adjacency can be created between routers regardless of their location in the network.
TE tunnel interfaces are advertised in the IGP network just like any other links. Routers can then use these advertisements in their IGPs to compute the SPF even if they are not the head end of any TE tunnels.
The following restrictions are listed for the MPLS-TE Forwarding Adjacency feature:
Using the MPLS-TE Forwarding Adjacency feature increases the size of the IGP database by advertising a TE tunnel as a link.
The MPLS-TE Forwarding Adjacency feature is supported by Intermediate System-to-Intermediate System (IS-IS).
When the MPLS-TE Forwarding Adjacency feature is enabled on a TE tunnel, the link is advertised in the IGP network as a Type-Length-Value (TLV) 22 without any TE sub-TLV.
MPLS-TE forwarding adjacency tunnels must be configured bidirectionally.
MPLS-TE Forwarding Adjacency Prerequisites
Your network must support the following features before enabling the MPLS -TE Forwarding Adjacency feature:
MPLS
IP Cisco Express Forwarding
Intermediate System-to-Intermediate System (IS-IS)
Path Computation Element
Path Computation Element (PCE) solves the specific issue of inter-domain
path computation for MPLS-TE label switched path (LSPs), when the head-end router does not possess
full network topology information (for example, when the head-end and tail-end
routers of an LSP reside in different IGP areas).
PCE uses area border routers (ABRs) to compute a TE LSP spanning
multiple IGP areas as well as computation of Inter-AS TE LSP.
PCE is usually used to define an overall architecture, which is made of
several components, as follows:
Path Computation Element (PCE)
Represents a software module (which can be a component or
application) that enables the router to compute paths applying a set of
constraints between any pair of nodes within the router’s TE topology database.
PCEs are discovered through IGP.
Path Computation Client (PCC)
Represents a software module running on a router that is capable
of sending and receiving path computation requests and responses to and from
PCEs. The PCC is typically an LSR (Label Switching Router).
PCC-PCE communication protocol (PCEP)
Specifies that PCEP is a TCP-based protocol defined by the IETF
PCE WG, and defines a set of messages and objects used to manage PCEP sessions
and to request and send paths for multi-domain TE LSPs. PCEP is used for
communication between PCC and PCE (as well as between two PCEs) and employs IGP
extensions to dynamically discover PCE.
Figure 3. Path Computation Element Network Diagram. This figure
shows a typical PCE implementation.
Path computation elements provides support for the following message
types and objects:
Message types: Open, PCReq, PCRep, PCErr, Close
Objects: OPEN, CLOSE, RP, END-POINT, LSPA, BANDWIDTH, METRIC, and
NO-PATH
Path protection provides an end-to-end failure recovery mechanism (that is, a full path protection) for MPLS-TE tunnels. A secondary Label Switched Path (LSP) is established, in advance, to provide failure protection for the protected LSP that is carrying a tunnel's TE traffic. When there is a failure on the protected LSP, the source router immediately enables the secondary LSP to temporarily carry the tunnel's traffic. If there is a failure on the secondary LSP, the tunnel no longer has path protection until the failure along the secondary path is cleared. Path protection can be used within a single area (OSPF or IS-IS), external BGP [eBGP], and static routes.
The failure detection mechanisms triggers a switchover to a secondary tunnel by:
Path error or resv-tear from Resource Reservation Protocol (RSVP) signaling
Notification from the Bidirectional Forwarding Detection (BFD) protocol that a neighbor is lost
Notification from the Interior Gateway Protocol (IGP) that the adjacency is down
Local teardown of the protected tunnel's LSP due to preemption in order to signal higher priority LSPs, a Packet over SONET (POS) alarm, online insertion and removal (OIR), and so on
An alternate recovery mechanism is Fast Reroute (FRR), which protects MPLS-TE LSPs only from link and node failures, by locally repairing the LSPs at the point of failure.
Although not as fast as link or node protection, presignaling a secondary LSP is faster than configuring a secondary primary path option, or allowing the tunnel's source router to dynamically recalculate a path. The actual recovery time is topology-dependent, and affected by delay factors such as propagation delay or switch fabric latency.
These are the pre-requisites for enabling path protection:
Ensure that your network supports MPLS-TE, Cisco Express Forwarding,
and Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path
First (OSPF).
Enable MPLS.
Configure TE on the routers.
Configure a TE tunnel with a dynamic path option by using the
path-option command with the
dynamic keyword.
MPLS-TE automatic bandwidth is configured on individual Label Switched
Paths (LSPs) at every head-end. MPLS-TE monitors the traffic rate on a tunnel
interface. Periodically, MPLS-TE resizes the bandwidth on the tunnel interface
to align it closely with the traffic in the tunnel. MPLS-TE automatic bandwidth can
perform these functions:
Monitors periodic polling of the tunnel output rate
Resizes the tunnel bandwidth by adjusting the highest rate observed
during a given period
For every traffic-engineered tunnel that is configured for an automatic
bandwidth, the average output rate is sampled, based on various configurable
parameters. Then, the tunnel bandwidth is readjusted automatically based upon
either the largest average output rate that was noticed during a certain interval, or
a configured maximum bandwidth value.
This table lists the automatic bandwidth functions.
Table 2 Automatic Bandwidth Variables
Function
Command
Description
Default Value
Application frequency
application command
Configures how often the tunnel bandwidths changed for each tunnel. The application period is the period of A minutes between the
bandwidth applications during which the output rate collection is done.
24 hours
Requested bandwidth
bw-limit command
Limits the range of bandwidth within the automatic-bandwidth feature that can
request a bandwidth.
0 Kbps
Collection frequency
auto-bw collect command
Configures how often the tunnel output rate is polled globally
for all tunnels.
5 min
Highest collected bandwidth
—
You cannot configure this value.
—
Delta
—
You cannot configure this value.
—
The output rate on a tunnel is collected at regular intervals that are
configured by using the
application command in MPLS-TE auto bandwidth
interface configuration mode. When the application period timer expires, and
when the difference between the measured and the current bandwidth exceeds the
adjustment threshold, the tunnel is reoptimized. Then, the bandwidth samples
are cleared to record the new largest output rate at the next interval.
When reoptimizing the LSP with the new bandwidth, a new path request is
generated. If the new bandwidth is not available, the last good LSP
continues to be used. This way, the network experiences no traffic
interruptions.
If minimum or maximum bandwidth values are configured for a tunnel, the
bandwidth, which the automatic bandwidth signals, stays within these values.
Note
When more than 100 tunnels are auto-bw enabled, the algorithm will
jitter the first application of every tunnel by a maximum of 20% (max
1hour). The algorithm does this to avoid too many tunnels running auto bandwidth applications at the
same time.
If a tunnel is shut down, and is later brought again, the adjusted
bandwidth is lost and the tunnel is brought back with the initial configured
bandwidth. In addition, the application period is reset when the tunnel is brought
back.
Adjustment Threshold is defined as a percentage of the current tunnel bandwidth and an absolute (minimum) bandwidth. Both thresholds must be fulfilled for the automatic bandwidth to resignal the tunnel. The tunnel bandwidth is resized only if the difference between the largest sample output rate and the current tunnel bandwidth is larger than the adjustment thresholds.
For example, assume that the automatic bandwidth is enabled on a tunnel in which the highest observed bandwidth B is 30 Mbps. Also, assume that the tunnel was initially configured for 45 Mbps. Therefore, the difference is 15 mbit/s. Now, assuming the default adjustment thresholds of 10% and 10kbps, the tunnel is signalled with 30 Mbps when the application timer expires. This is because 10% of 45Mbit/s is 4.5 Mbit/s, which is smaller than 15 Mbit/s. The absolute threshold, which by default is 10kbps, is also crossed.
Overflow Detection
Overflow detection is used if a bandwidth must be resized as soon as an overflow condition is detected, without having to wait for the expiry of an automatic bandwidth application frequency interval.
For overflow detection one configures a limit N, a percentage threshold Y% and optionally, a minimum bandwidth threshold Z. The percentage threshold is defined as the percentage of the actual signalled tunnel bandwidth. When the difference between the measured bandwidth and the actual bandwidth are both larger than Y% and Z threshold, for N consecutive times, then the system triggers an overflow detection.
The bandwidth adjustment by the overflow detection is triggered only by an increase of traffic volume through the tunnel, and not by a decrease in the traffic volume. When you trigger an overflow detection, the automatic bandwidth application interval is reset.
By default, the overflow detection is disabled and needs to be manually configured.
Restrictions for MPLS-TE Automatic Bandwidth
When the automatic bandwidth cannot update the tunnel bandwidth, the
following restrictions are listed:
Tunnel is in a fast reroute (FRR) backup, active, or path protect
active state. This occurs because of the assumption that protection is a
temporary state, and there is no need to reserve the bandwidth on a backup
tunnel. You should prevent taking away the bandwidth from other primary or
backup tunnels.
Reoptimization fails to occur during a lockdown. In this case, the
automatic bandwidth does not update the bandwidth unless the bandwidth
application is manually triggered by using the
mpls traffic-eng auto-bw apply command in
EXEC mode.
How to Implement Traffic Engineering
Traffic engineering requires coordination among several global neighbor
routers, creating traffic engineering tunnels, setting up forwarding across
traffic engineering tunnels, setting up FRR, and creating differential service.
Perform this task to configure MPLS-TE topology (required for traffic
engineering tunnel operations).
Before You Begin
Before you start to build the MPLS-TE topology, you must have enabled:
IGP such as OSPF or IS-IS for MPLS-TE.
MPLS Label Distribution Protocol (LDP).
RSVP on the port interface.
Stable router ID is required at either end of the link to ensure
that the link is successful. If you do not assign a router ID, the system
defaults to the global router ID. Default router IDs are subject to change,
which can result in an unstable link.
If you are going to use nondefault holdtime or intervals, you must
decide the values to which they are set.
Creating an MPLS-TE tunnel is a process of customizing the traffic
engineering to fit your network topology.
Perform this task to create an MPLS-TE tunnel after you have built the
traffic engineering topology.
Before You Begin
The following prerequisites are required to create an MPLS-TE tunnel:
You must have a router ID for the neighboring router.
Stable router ID is required at either end of the link to ensure
that the link is successful. If you do not assign a router ID to the routers,
the system defaults to the global router ID. Default router IDs are subject to
change, which can result in an unstable link.
If you are going to use nondefault holdtime or intervals, you must
decide the values to which they are set.
Sets the CT0 bandwidth required on this interface. Because the
default tunnel priority is 7, tunnels use the default TE class map (namely,
class-type 1, priority 7).
Step 7
Use one of these commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)? [cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file, and remain within the configuration session.
Step 8
show mpls traffic-eng tunnels
Example:
RP/0/RSP0/CPU0:router# show mpls traffic-eng tunnels
(Optional)
Verifies that the tunnel is connected (in
the UP state) and displays all configured TE tunnels.
Step 9
show ipv4 interface brief
Example:
RP/0/RSP0/CPU0:router# show ipv4 interface brief
(Optional)
Displays all TE tunnel interfaces.
Step 10
show mpls traffic-eng link-management
admission-control
Example:
RP/0/RSP0/CPU0:router# show mpls traffic-eng link-management admission-control
Perform this task to configure forwarding over the MPLS-TE tunnel
created in the previous task . This
task allows MPLS packets to be forwarded on the link between network
neighbors.
Before You Begin
The following prerequisites are required to configure forwarding over
the MPLS-TE tunnel:
You must have a router ID for the neighboring router.
Stable router ID is required at either end of the link to ensure
that the link is successful. If you do not assign a router ID to the routers,
the system defaults to the global router ID. Default router IDs are subject to
change, which can result in an unstable link.
SUMMARY STEPS
1.configure
2.interface tunnel-tetunnel-id
3.ipv4 unnumberedtype interface-path-id
4.autoroute announce
5.exit
6.router static address-family ipv4 unicastprefix mask ip-address interface type
Perform this task to protect MPLS-TE tunnels, as created in the
previous task.
Note
Although this task is similar to the previous task, its importance
makes it necessary to present as part of the tasks required for traffic
engineering on
Cisco IOS XR software.
Before You Begin
The following prerequisites are required to protect MPLS-TE tunnels:
You must have a router ID for the neighboring router.
Stable router ID is required at either end of the link to ensure
that the link is successful. If you do not assign a router ID to the routers,
the system defaults to the global router ID. Default router IDs are subject to
change, which can result in an unstable link.
Destination address is the remote node’s MPLS-TE router
ID.
Destination address is the merge point between backup and
protected tunnels.
Note
When you configure TE tunnel with multiple protection on its
path and merge point is the same node for more than one protection, you must
configure record-route for that tunnel.
Step 15
Use one of these commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)? [cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file, and remain within the configuration session.
Step 16
show mpls traffic-eng tunnels backup
Example:
RP/0/RSP0/CPU0:router# show mpls traffic-eng tunnels backup
(Optional)
Displays the backup tunnel information.
Step 17
show mpls traffic-eng tunnels protection frr
Example:
RP/0/RSP0/CPU0:router# show mpls traffic-eng tunnels protection frr
(Optional)
Displays the tunnel protection information for Fast-Reroute (FRR).
Step 18
show mpls traffic-eng fast-reroute database
Example:
RP/0/RSP0/CPU0:router# show mpls traffic-eng fast-reroute database
(Optional)
Displays the protected tunnel state (for
example, the tunnel’s current ready or active state).
Perform this task to configure a Prestandard DS-TE tunnel.
Before You Begin
The following prerequisites are required to configure a Prestandard
DS-TE tunnel:
You must have a router ID for the neighboring router.
Stable router ID is required at either end of the link to ensure
that the link is successful. If you do not assign a router ID to the routers,
the system defaults to the global router ID. Default router IDs are subject to
change, which can result in an unstable link.
Sets the reserved RSVP bandwidth available on this interface by
using the prestandard DS-TE mode. The range for the
total reserve bandwidth argument is 0 to
4294967295.
Physical interface bandwidth is not used by MPLS-TE.
Sets the bandwidth required on this interface. Because the default
tunnel priority is 7, tunnels use the default TE class map (namely, class-type
1, priority 7).
Step 8
Use one of these commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)? [cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file, and remain within the configuration session.
Perform this task to create an IETF mode DS-TE tunnel using RDM.
Before You Begin
The following prerequisites are required to create an IETF mode DS-TE
tunnel using RDM:
You must have a router ID for the neighboring router.
Stable router ID is required at either end of the link to ensure
that the link is successful. If you do not assign a router ID to the routers,
the system defaults to the global router ID. Default router IDs are subject to
change, which can result in an unstable link.
Sets the reserved RSVP bandwidth available on this interface by
using the Russian Doll Model (RDM) bandwidth constraints model. The range for
the
total reserve bandwidth argument is 0 to 4294967295.
Note
Physical interface bandwidth is not used by MPLS-TE.
Configures the bandwidth required for an MPLS TE tunnel. Because
the default tunnel priority is 7, tunnels use the default TE class map (namely,
class-type 1, priority 7).
Step 11
Use one of these commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)? [cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file, and remain within the configuration session.
Perform this task to configure an IETF mode differentiated services
traffic engineering tunnel using the Maximum Allocation Model (MAM) bandwidth
constraint model.
Before You Begin
The following prerequisites are required to configure an IETF mode
differentiated services traffic engineering tunnel using the MAM bandwidth
constraint model:
You must have a router ID for the neighboring router.
Stable router ID is required at either end of the link to ensure
that the link is successful. If you do not assign a router ID to the routers,
the system defaults to the global router ID. Default router IDs are subject to
change, which can result in an unstable link.
Configures the bandwidth required for an MPLS TE tunnel. Because
the default tunnel priority is 7, tunnels use the default TE class map (namely,
class-type 1, priority 7).
Step 12
Use one of the following commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-rsvp-if)# end
or
RP/0/RSP0/CPU0:router(config-rsvp-if)# commit
Saves configuration changes.
When you issue the
end command, the system prompts you to
commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:
Entering
yes saves configuration changes to the running
configuration file, exits the configuration session, and returns the router to
EXEC mode.
Entering
no exits the configuration session and returns the
router to EXEC mode without committing the configuration changes.
Entering
cancel leaves the router in the current
configuration session without exiting or committing the configuration changes.
Use the
commit command to save the
configuration changes to the running configuration file and remain within the
configuration session.
Perform this task to configure MPLS-TE and Fast Reroute (FRR) on OSPF.
Before You Begin
Note
Only point-to-point (P2P) interfaces are supported for OSPF multiple
adjacencies. These may be either native P2P interfaces or broadcast interfaces
on which the OSPF P2P configuration command is applied to force them to behave
as P2P interfaces as far as OSPF is concerned. This restriction does not apply
to IS-IS.
The tunnel-te interface is not supported under IS-IS.
RP/0/RSP0/CPU0:router(config-if)# path-option 1 explicit identifier 6 ospf green area 0
Configures an explicit path option for an MPLS-TE tunnel. OSPF is
limited to a single OSPF instance and area.
Step 4
Repeat Step 3 as many times as needed.
Example:
RP/0/RSP0/CPU0:router(config-if)# path-option 2 explicit name 234 ospf 3 area 7 verbatim
Configures another explicit path option.
Step 5
Use one of these commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)? [cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file, and remain within the configuration session.
Step 6
show mpls traffic-eng tunnels [tunnel-number]
Example:
RP/0/RSP0/CPU0:router# show mpls traffic-eng tunnels 1
Displays information about MPLS-TE tunnels.
Configuring the Ignore Integrated IS-IS Overload Bit Setting in
MPLS-TE
Perform this task to configure an overload node avoidance in MPLS-TE.
When the overload bit is enabled, tunnels are brought down when the overload
node is found in the tunnel path.
affinity-mapaffinity name {affinity
value | bit-positionvalue}
Example:
RP/0/RSP0/CPU0:router(config-mpls-te)# affinity-map red 1
Enters an affinity name and a map value by using a color name
(repeat this command to assign multiple colors up to a maximum of 64 colors).
An affinity color name cannot exceed 64 characters. The value you assign to a
color name must be a single digit.
Step 4
Use one of the following commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-mpls-te)# end
or
RP/0/RSP0/CPU0:router(config-mpls-te)# commit
Saves configuration changes.
When you issue the
end command, the system prompts you to
commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:
Entering
yes saves configuration changes to the running
configuration file, exits the configuration session, and returns the router to
EXEC mode.
Entering
no exits the configuration session and returns the
router to EXEC mode without committing the configuration changes.
Entering
cancel leaves the router in the current
configuration session without exiting or committing the configuration changes.
Use the
commit command to save the
configuration changes to the running configuration file and remain within the
configuration session.
The next step in the configuration of MPLS-TE Flexible Name-based
Tunnel Constraints is to assign affinity names and values to TE links. You can
assign up to a maximum of 32 colors. Before you assign a color to a link, you
must define the name-to-value mapping for each color.
RP/0/RSP0/CPU0:router(config-if)# affinity include red
Configures link attributes for links comprising a tunnel. You can
have up to ten colors.
Multiple include statements can be specified under tunnel
configuration. With this configuration, a link is eligible for CSPF if it has
at least a red color or has at least a green color. Thus, a link with red and
any other colors as well as a link with green and any additional colors meet
the above constraint.
Step 4
Use one of these commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them
before exiting(yes/no/cancel)? [cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file, and remain within the configuration session.
Configuring IS-IS to Flood MPLS-TE Link Information
Perform this task to configure a router running the Intermediate
System-to-Intermediate System (IS-IS) protocol to flood MPLS-TE link
information into multiple IS-IS levels.
This procedure shows how to enable MPLS-TE in both IS-IS Level 1 and
Level 2.
SUMMARY STEPS
1.configure
2.router isisinstance-id
3.netnetwork-entity-title
4.address-family {ipv4 |
ipv6} {unicast}
5.metric-style wide
6.mpls traffic-englevel
7.Use one of the following commands:
end
commit
DETAILED STEPS
Command or Action
Purpose
Step 1
configure
Example:
RP/0/RSP0/CPU0:router# configure
Enters global configuration mode.
Step 2
router isisinstance-id
Example:
RP/0/RSP0/CPU0:router(config)# router isis 1
Enters an IS-IS instance.
Step 3
netnetwork-entity-title
Example:
RP/0/RSP0/CPU0:router(config-isis)# net 47.0001.0000.0000.0002.00
Enters an IS-IS network entity title (NET) for the routing
process.
Configures a PCE deadtimer value. The range is from 0 to 255 seconds.
When the dead interval is 0, the LSR does not timeout a PCEP session to a
remote peer.
Configures a periodic reoptimization timer value. The range is from 60
to 604800 seconds. When the dead interval is 0, the LSR does not timeout a PCEP
session to a remote peer.
Perform this task to assign a secondary path option in case there is a
link or node failure along a path and all interfaces in your network are not
protected.
Configuring the Delay the Tunnel Takes Before Reoptimization
Perform this task to configure the time between when a path-protection
switchover event is effected on a tunnel head to when a reoptimization is
performed on that tunnel. This timer affects only the required reoptimization that is attempted due to a switchover and does not override the global reoptimization timer.
Adjusts the number of seconds that the tunnel takes before triggering reoptimization after switchover has happened.
Note
The restriction is that at least one dynamic path-option must be configured for a standby LSP to come up. The strict (explicit) path option is not supported for the standby LSP.
Step 4
Use one of the following commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-mpls-te)# end
or
RP/0/RSP0/CPU0:router(config-mpls-te)# commit
Saves configuration changes.
When you issue the
end command, the system prompts you to
commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:
Entering
yes saves configuration changes to the running
configuration file, exits the configuration session, and returns the router to
EXEC mode.
Entering
no exits the configuration session and returns the
router to EXEC mode without committing the configuration changes.
Entering
cancel leaves the router in the current
configuration session without exiting or committing the configuration changes.
Use the
commit command to save the
configuration changes to the running configuration file and remain within the
configuration session.
RP/0/RSP0/CPU0:router(config-mpls-te)# auto-bw collect frequency 1
Configures the automatic bandwidth collection frequency, and
controls the manner in which the bandwidth for a tunnel collects output rate
information; but does not adjust the tunnel bandwidth.
minutes
Configures the interval between automatic bandwidth
adjustments in minutes. Range is from 1 to 10080.
Step 4
Use one of the following commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-mpls-te)# end
or
RP/0/RSP0/CPU0:router(config-mpls-te)# commit
Saves configuration changes.
When you issue the
end command, the system prompts you to
commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
[cancel]:
Entering
yes saves configuration changes to the running
configuration file, exits the configuration session, and returns the router to
EXEC mode.
Entering
no exits the configuration session and returns the
router to EXEC mode without committing the configuration changes.
Entering
cancel leaves the router in the current
configuration session without exiting or committing the configuration changes.
Use the
commit command to save the
configuration changes to the running configuration file and remain within the
configuration session.
Step 5
show mpls traffic-eng tunnels [auto-bw]
Example:
RP/0/RSP0/CPU0:router# show mpls traffic tunnels auto-bw
Displays information about MPLS-TE tunnels for the automatic
bandwidth. The globally configured collection frequency is displayed.
Forcing the Current Application Period to Expire Immediately
Perform this task to force the current application period to expire
immediately on the specified tunnel. The highest bandwidth is applied on the
tunnel before waiting for the application period to end on its own.
RP/0/RSP0/CPU0:router(config-if-tunte-autobw)# adjustment-threshold 50 min 800
Configures the tunnel bandwidth change threshold to trigger an
adjustment.
percentage
Bandwidth change percent threshold to trigger an adjustment
if the largest sample percentage is higher or lower than the current tunnel
bandwidth. Range is from 1 to 100 percent. The default value is 5 percent.
min
Configures the bandwidth change value to trigger an
adjustment. The tunnel bandwidth is changed only if the largest sample is
higher or lower than the current tunnel bandwidth. Range is from 10 to
4294967295 kilobits per second (kbps). The default value is 10 kbps.
Bandwidth change percent to trigger an overflow. Range is
from 1 to 100 percent.
limit
Configures the number of consecutive collection intervals
that exceeds the threshold. The bandwidth overflow triggers an early tunnel
bandwidth update. Range is from 1 to 10 collection periods. The default value
is none.
min
Configures the bandwidth change value in kbps to trigger an
overflow. Range is from 10 to 4294967295. The default value is 10.
Step 8
Use one of the following commands:
end
commit
Example:
RP/0/RSP0/CPU0:router(config-if-tunte-autobw)# end
Configure MPLS-TE and Fast-Reroute on OSPF: Example
CSPF areas are configured on a per-path-option basis. The following example shows how to use the traffic-engineering tunnels (tunnel-te) interface and the active path for the MPLS-TE tunnel:
configure
interface tunnel-te 0
path-option 1 explicit id 6 ospf 126 area 0
path-option 2 explicit name 234 ospf 3 area 7 verbatim
path-option 3 dynamic isis mtbf level 1 lockdown
commit
Configure the Ignore IS-IS Overload Bit Setting in MPLS-TE: Example
This example shows how to configure the IS-IS overload bit setting in MPLS-TE:
Maximum Allocation Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering, F. Le Faucheur, W. Lai. June 2005.
(Format: TXT=22585 bytes) (Status: EXPERIMENTAL)
RFC 4127
Russian Dolls Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering,
F. Le Faucheur, Ed. June 2005.
(Format: TXT=23694 bytes) (Status: EXPERIMENTAL)
Technical Assistance
Description
Link
The Cisco Technical Support website contains thousands of
pages of searchable technical content, including links to products,
technologies, solutions, technical tips, and tools. Registered Cisco.com users
can log in from this page to access even more content.