Guest

Cisco IOS Software Releases 12.0 ST

Diff-Serv-aware Traffic Engineering

Table Of Contents

Diff-Serv-aware Traffic Engineering (DS-TE)

Background and Overview

Benefits

Related Features and Technologies

Related Documents

Platforms and Interfaces Supported

Supported Standards

Prerequisites

Configuration Tasks

New Commands

The ip rsvp bandwidth command

The tunnel mpls traffic-eng bandwidth command

The Configuration Procedure

Level 1: Configuring the Device

Level 2: Configuring the Physical Interface

Level 3: Configuring the Tunnel Interface

Verifying the Configurations

Configuration Examples

DS-TE Configuration

Tunnel Head

Midpoint Devices

Tail-End Device

Guaranteed Bandwidth Service Configuration

Guaranteed Bandwidth Service Example

Tunnel Head Configuration (Head-1)

Tunnel Head Configuration (Head-2)

Tunnel Midpoint Configuration [Mid-1]

Tunnel Midpoint Configuration [Mid-2]

Tunnel Tail Configuration

Command Reference

interface

ip cef

ip rsvp bandwidth

mpls traffic-eng administrative-weight

mpls traffic-eng area

mpls traffic-eng attribute-flags

mpls traffic-eng backup-path tunnel

mpls traffic-eng flooding thresholds

mpls traffic-eng link timers bandwidth-hold

mpls traffic-eng link timers periodic-flooding

mpls traffic-eng reoptimize timers frequency

mpls traffic-eng router-id

mpls traffic-eng tunnels

mpls traffic-eng tunnels

router ospf

show interfaces tunnel

show ip ospf

show ip route

show ip rsvp host

show ip rsvp interface

show mpls traffic-eng autoroute

show mpls traffic-eng fast-reroute database

show mpls traffic-eng fast-reroute log reroutes

show mpls traffic-eng link-management admission-control

show mpls traffic-eng link-management advertisements

show mpls traffic-eng link-management bandwidth-allocation

show mpls traffic-eng link-management igp-neighbors

show mpls traffic-eng link-management interfaces

show mpls traffic-eng link-management summary

show mpls traffic-eng topology

show mpls traffic-eng tunnels

tunnel destination

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng affinity

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng autoroute metric

tunnel mpls traffic-eng bandwidth

tunnel mpls traffic-eng fast-reroute

tunnel mpls traffic-eng path-option

tunnel mpls traffic-eng priority

Debug Commands

debug mpls traffic-eng link-management preemption

Glossary


Diff-Serv-aware Traffic Engineering (DS-TE)


This guide presents extensions made recently to Multiprotocol Label Switching Traffic Engineering (MPLS TE) that make it Diff-Serv aware. Specifically, the bandwidth reservable on each link for constraint-based routing (CBR) purposes can now be managed through two bandwidth pools: a global pool and a sub-pool. The sub-pool can be limited to a smaller portion of the link bandwidth. Tunnels using the sub-pool bandwidth can then be used in conjunction with MPLS Quality of Service (QoS) mechanisms to deliver guaranteed bandwidth services end-to-end across the network.

The guide contains the following sections:

Background and Overview, page 1

Platforms and Interfaces Supported, page 3

Prerequisites, page 4

Configuration Tasks, page 4

Configuration Examples, page 12

Command Reference, page 21

Debug Commands, page 102

Glossary, page 104


Note References made to specific page numbers are meant to help readers of the printed (Acrobat™ .PDF) form of this guide. On-line readers may simply click on the page number (or the underlined, colored, or bolded text) to go to the referenced page.


Background and Overview

MPLS traffic engineering allows constraint-based routing of IP traffic. One of the constraints satisfied by CBR is the availability of required bandwidth over a selected path. Diff-Serv-aware Traffic Engineering extends MPLS traffic engineering to enable you to perform constraint-based routing of "guaranteed" traffic, which satisfies a more restrictive bandwidth constraint than that satisfied by CBR for regular traffic. The more restrictive bandwidth is termed a sub-pool, while the regular TE tunnel bandwidth is called the global pool. (The sub-pool is a portion of the global pool.) This ability to satisfy a more restrictive bandwidth constraint translates into an ability to achieve higher Quality of Service performance (in terms of delay, jitter, or loss) for the guaranteed traffic.

For example, DS-TE can be used to ensure that traffic is routed over the network so that, on every link, there is never more than 40 per cent (or any assigned percentage) of the link capacity of guaranteed traffic (for example, voice), while there can be up to 100 per cent of the link capacity of regular traffic. Assuming QoS mechanisms are also used on every link to queue guaranteed traffic separately from regular traffic, it then becomes possible to enforce separate "overbooking" ratios for guaranteed and regular traffic. (In fact, for the guaranteed traffic it becomes possible to enforce no overbooking at all—or even an underbooking—so that very high QoS can be achieved end-to-end for that traffic, even while for the regular traffic a significant overbooking continues to be enforced.)

Also, through the ability to enforce a maximum percentage of guaranteed traffic on any link, the network administrator can directly control the end-to-end QoS performance parameters without having to rely on over-engineering or on expected shortest path routing behavior. This is essential for transport of applications that have very high QoS requirements (such as real-time voice, virtual IP leased line, and bandwidth trading), where over-engineering cannot be assumed everywhere in the network.

DS-TE involves extending OSPF (Open Shortest Path First routing protocol), so that the available sub-pool bandwidth at each preemption level is advertised in addition to the available global pool bandwidth at each preemption level. And DS-TE modifies constraint-based routing to take this more complex advertised information into account during path computation.

Benefits

Diff-Serv-aware Traffic Engineering enables service providers to perform separate admission control and separate route computation for discrete subsets of traffic (for example, voice and data traffic).

Therefore, by combining DS-TE with other IOS features such as QoS, the service provider can:

Develop QoS services for end customers based on signaled rather than provisioned QoS

Build the higher-revenue generating "strict-commitment" QoS services, without over-provisioning

Offer virtual IP leased-line, Layer 2 service emulation, and point-to-point guaranteed bandwidth services including voice-trunking

Enjoy the scalability properties offered by MPLS

Related Features and Technologies

The DS-TE feature is related to OSPF, RSVP (Resource reSerVation Protocol), QoS, and MPLS traffic engineering. Cisco documentation for all of these features is listed in the next section.

Related Documents

For OSPF:

"Configuring OSPF" in Cisco IOS Release 12.1 IP and IP Routing Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1cdospf.htm

"OSPF Commands" in Cisco IOS Release 12.1 IP and IP Routing Command Reference, http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdospf.htm

For RSVP:

"Configuring RSVP" in Cisco IOS Release 12.1 Quality of Service Solutions Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt5/qcdrsvp.htm

IP RSVP commands section in Cisco IOS Release 12.1 Quality of Service Solutions Command Reference, http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/qrdcmd2.htm

For QoS:

Cisco IOS Release 12.1 Quality of Service Solutions Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/index.htm

Cisco IOS Release 12.1 Quality of Service Solutions Command Reference,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/index.htm

For MPLS Traffic Engineering:

Cisco IOS Release 12.1(3)T MPLS Traffic Engineering and Enhancements,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/traffeng.htm

"Multiprotocol Label Switching" in Cisco IOS Release 12.1 Switching Services Configuration Guide,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/switch_c/xcprt4

Section containing MPLS commands in Cisco IOS Release 12.1 Switching Services Command Reference,
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/switch_r/xrdscmd3.htm

Platforms and Interfaces Supported

This release supports DS-TE together with QoS on POS (Packet over Sonet) interfaces on the Cisco 12000 Series Gigabit Switch Router (GSR), with Engine 0 on edge (access) interfaces and Engine 2 on core (backbone) interfaces.

Supported Standards

Standardization of Diff-Serv-aware MPLS Traffic Engineering is still in progress in the IETF (Internet Engineering Task Force). At the time of publication of this feature guide, DS-TE has been documented in the following IETF drafts:

Requirements for Support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki & M. Tatham
http://search.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-reqts-00.txt

Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki & M. Tatham
http://search.ietf.org/internet-drafts/draft-ietf-mpls-diff-te-ext-00.txt

Extensions to OSPF for Support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend & D. Skalecki
http://search.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ospf-00.txt

As the IETF work is still in progress, details are still under definition and subject to change, so DS-TE should be considered as a pre-standard implementation of IETF Diff-Serv-aware MPLS Traffic Engineering. However, it is in line with the requirements described in the first document above. The concept of "Class-Type" defined in that IETF draft corresponds to the concept of bandwidth pool implemented by DS-TE. And because DS-TE supports two bandwidth pools (global pool and sub-pool), DS-TE should be seen as supporting two Class-Types (Class-Type 0 and Class-Type 1).

Prerequisites

Your network must support the following Cisco IOS features in order to support guaranteed bandwidth services based on Diff-Serv-aware Traffic Engineering:

MPLS

IP Cisco Express Forwarding (CEF)

OSPF

RSVP

QoS

Configuration Tasks

This section lists the minimum set of commands you need to implement the Diff-Serv-aware Traffic Engineering feature—in other words, to establish a tunnel that reserves bandwidth from the sub-pool.

The subsequent "Configuration Examples" section (page 10), presents these same commands in context and shows how, by combining them with QoS commands, you can build guaranteed bandwidth services.

New Commands

DS-TE commands were developed from the existing command set that configures MPLS traffic engineering. The only difference introduced to create DS-TE was the expansion of two commands:

ip rsvp bandwidth was expanded to configure the size of the sub-pool on every link.

tunnel mpls traffic-eng bandwidth was expanded to enable a TE tunnel to reserve bandwidth from the sub-pool.

The ip rsvp bandwidth command

The old command was

ip rsvp bandwidth x y

where x = the size of the only possible pool, and y = the size of a single traffic flow (ignored by traffic engineering)

Now the extended command is

ip rsvp bandwidth x y sub-pool z

where x = the size of the global pool, and z = the size of the sub-pool.

(Remember, the sub-pool's bandwidth is less than—because it is part of—the global pool's bandwidth.)

The tunnel mpls traffic-eng bandwidth command

The old command was

tunnel mpls traffic-eng bandwidth b

where b = the amount of bandwidth this tunnel requires.

Now you specify from which pool (global or sub) the tunnel's bandwidth is to come. You can enter

tunnel mpls traffic-eng bandwidth sub-pool b

This indicates that the tunnel should use bandwidth from the sub-pool. Alternatively, you can enter

tunnel mpls traffic-eng bandwidth b

This indicates that the tunnel should use bandwidth from the global pool (the default).

The Configuration Procedure

To establish a sub-pool TE tunnel, you must enter configurations at three levels:

the device (router or switch router)

the physical interface

the tunnel interface

On the first two levels, you activate traffic engineering; on the third level—the tunnel interface—you establish the sub-pool tunnel. Therefore, it is only at the tunnel headend device that you need to configure all three levels. At the tunnel midpoints and tail, it is sufficient to configure the first two levels.

In the tables below, each command is explained in brief. For a more complete explanation of any command, refer to the page given in the right-hand column.

Level 1: Configuring the Device

At this level, you tell the device (switch router) to use accelerated packet-forwarding (known as Cisco Express Forwarding or CEF), MultiProtocol Label Switching (MPLS), traffic-engineering tunneling, and the Open Shortest Path First (OSPF) routing algorithm. This level is often called global configuration mode because the configuration is applied globally, to the entire device, rather than to a specific interface or routing instance. (These commands have not been modified from earlier releases of Cisco IOS.)

You enter the following commands:

 
Command
Purpose

Step 1 

Router(config)# ip cef

Enables CEF—which accelerates the flow of packets through the device. (More on page 30.)

Step 2 

Router(config)# mpls traffic-eng tunnels

Enables MPLS, and specifically its traffic engineering tunnel capability. (More on page 44.)

Step 3 

Router(config)# router ospf

Invokes the OSPF routing process for IP and puts the device into router configuration mode. (More on page 46.)

Step 4 

Router(config-router)# mpls traffic-eng 
area num

Turns on MPLS traffic engineering for a particular OSPF area. (More on page 35.)

Step 5 

Router(config-router)# mpls traffic-eng 
router-id loopback0

Specifies that the traffic engineering router identifier is the IP address associated with the loopback0 interface. (More on page 43.)

Level 2: Configuring the Physical Interface

Having configured the device, you now must configure the interface on that device through which the tunnel will run. To do that, you first put the router into interface-configuration mode.

You then enable Resource Reservation Protocol. RSVP is used to signal (set up) a traffic engineering tunnel, and to tell devices along the tunnel path to reserve a specific amount of bandwidth for the traffic that will flow through that tunnel. It is with this command that you establish the maximum size of the sub-pool.

Finally, you enable the MPLS traffic engineering tunnel feature on this physical interface.

To accomplish these tasks, you enter the following commands:

 
Command
Purpose

Step 1 

Router(config)# interface interface-id

Moves configuration to the interface level, directing subsequent configuration commands to the specific interface identified by the interface-id. (More on page 26.)

Step 2 

Router(config-if)# ip rsvp bandwidth interface-kbps sub-pool kbps

Enables RSVP on this interface and limits the amount of bandwidth RSVP can reserve on this interface. The sum of bandwidth used by all tunnels on this interface cannot exceed interface-kbps, and the sum of bandwidth used by all sub-pool tunnels cannot exceed sub-pool kbps. (More on page 32.)

Step 3 

Router(config-if)# mpls traffic-eng tunnels

Enables the MPLS traffic engineering tunnel feature on this interface. (More on page 45.)

Level 3: Configuring the Tunnel Interface

Now you create a set of attributes for the tunnel itself; those attributes are configured on the "tunnel interface" (not to be confused with the physical interface just configured above).

The only command which was modified at this level for DS-TE is tunnel mpls traffic-eng bandwidth (described in detail on page 96).

You enter the following commands:

 
Command
Purpose

Step 1 

Router(config)# interface tunnel1

Creates a tunnel interface (named in this example tunnel1) and enters interface configuration mode. (More on page 26.)

Step 2 

Router(config-if)# tunnel destination A.B.C.D

Specifies the IP address of the tunnel tail device. (More on page 90.)

Step 3 

Router(config-if)# tunnel mode mpls traffic-eng

Sets the tunnel's encapsulation mode to MPLS traffic engineering. (More on page 92.)

Step 4 

Router(config-if)# tunnel mpls traffic-eng 
bandwidth {sub-pool | [global]} bandwidth

Configures the tunnel's bandwidth and assigns it either to the sub-pool or the global pool. (More on page 96).

Step 5 

Sets the priority to be used when system determines which existing tunnels are eligible to be preempted. (More on page 100).

Step 6 

Configures the paths (hops) a tunnel should use. The user can enter an explicit path (can specify the IP addresses of the hops) or can specify a dynamic path (the router figures out the best set of hops). (More on page 98).

Verifying the Configurations

To view the complete configuration you have entered, use the EXEC command show running-config and check its output display for correctness.

To check just one tunnel's configuration, enter show interfaces tunnel followed by the tunnel interface number. And to see that tunnel's RSVP bandwidth and flow, enter show ip rsvp interface followed by the name or number of the physical interface.

Here is an example of the information displayed by these two commands. To see an explanation of each field used in the following displays turn to page 47 for show interfaces tunnel and page 61 for show ip rsvp interface.

GSR1#show interfaces tunnel 4
Tunnel4 is up, line protocol is down
  Hardware is Routing Tunnel
  MTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255
  Encapsulation TUNNEL, loopback not set, keepalive set (10 sec)
  Tunnel source 0.0.0.0, destination 0.0.0.0
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Output queue 0/0, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 0 bits/sec, 0 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts    

GSR1#show ip rsvp interface pos4/0
interface    allocated  i/f max  flow max sub max 
PO4/0        300K       466500K  466500K  0M 

To view all tunnels at once on the router you have configured, enter show mpls traffic-eng tunnels brief. The information displayed when tunnels are functioning properly looks like this (a table explaining the display fields begins on page 88):

GSR1#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process:           running
RSVP Process:                  running
Forwarding:                    enabled
Periodic reoptimization:       every 3600 seconds, next in 3029 seconds
TUNNEL NAME 	DESTINATION      UP IF     DOWN IF   STATE/PROT
GSR1_t0 	192.168.1.13     -         SR3/0     up/up     
GSR1_t1 	192.168.1.13     -         SR3/0     up/up     
GSR1_t2 	192.168.1.13     -         PO4/0     up/up     
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails

When one or more tunnels is not functioning properly, the display could instead look like this. (In the following example, tunnels t0 and t1 are down, as indicated in the far right column).

GSR1#show mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:           running
    RSVP Process:                  running
    Forwarding:                    enabled
    Periodic reoptimization:       every 3600 seconds, next in 2279 seconds
TUNNEL NAME 	DESTINATION      UP IF     DOWN IF   STATE/PROT
GSR1_t0 	192.168.1.13     -         SR3/0     up/down 
GSR1_t1 	192.168.1.13     -         SR3/0     up/down 
GSR1_t2 	192.168.1.13     -         PO4/0     up/up 
Displayed 3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails

To find out why a tunnel is down, insert its name into this same command, after adding the keyword name and omitting the keyword brief. For example:

GSR1#show mpls traffic-eng tunnels name GSR1_t0 
Name:GSR1_t0                            (Tunnel0) Destination:192.168.1.13
  Status:
    Admin:up         Oper:down 	Path: not valid       Signalling:connected

If, as in this example, the Path is displayed as not valid, use the show mpls traffic-eng topology command to make sure the router has received the needed updates. (That command is described on page 85.)

Additionally, you can use any of the following show commands to inspect particular aspects of the network, router, or interface concerned:

To see information about...
Use this command
this level
and this item...

Network

Advertised bandwidth allocation information

show mpls traffic-eng link-management advertisements (described on page 72)

Preemptions along the tunnel path

debug mpls traffic-eng link-management preemption (described on 103)

Available TE link band- width on all head routers

show mpls traffic-eng topology (described on page 85)

Router

Status of all tunnels cur- rently signalled by this router

show mpls traffic-eng link-management admission-control (described on page 70)

Tunnels configured on midpoint routers

show mpls traffic-eng link-management summary
(described on page 83)

Physical interface

Detailed information on current bandwidth pools

show mpls traffic-eng link-management bandwidth-allocation [interface-name]
(described on page 75)

TE RSVP bookkeeping

show mpls traffic-eng link-management interfaces
(described on page 81)

Entire configuration of one interface

show run interface


Configuration Examples

This section first presents the DS-TE configuration needed to create the sub-pool tunnel. Then it presents the more comprehensive design for building end-to-end guaranteed bandwidth service, which involves configuring Quality of Service as well.

DS-TE Configuration

As shown in Figure 1, the tunnel configuration involves at least three devices—tunnel head, midpoint, and tail. On each of those devices one or two physical interfaces must be configured, for traffic ingress and egress.

Figure 1 Sample Tunnel Topology

Tunnel Head

At the device level:

gsr-68-1# configure terminal
gsr-68-1(config)# ip cef
gsr-68-1(config)# mpls traffic-eng tunnels
gsr-68-1(config)# router ospf 100
gsr-68-1(config-router)# redistribute connected
gsr-68-1(config-router)# network 11.1.1.0 0.0.0.255 area 0
gsr-68-1(config-router)# network 23.1.1.1 0.0.0.0 area 0
gsr-68-1(config-router)# mpls traffic-eng router-id Loopback0
gsr-68-1(config-router)# mpls traffic-eng area 0
gsr-68-1(config-router)# exit

gsr-68-1(config)# interface Loopback0

At the physical interface level (internal):

gsr-68-1(config-if)# ip address 23.1.1.1 255.255.255.255
gsr-68-1(config-if)# no ip directed-broadcast
gsr-68-1(config-if)# exit

At the device level:

gsr-68-1(config)# interface POS3/0

At the physical interface level (egress):

gsr-68-1(config-if)# ip address 11.1.1.1 255.255.255.0
gsr-68-1(config-if)# mpls traffic-eng tunnels
gsr-68-1(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000
gsr-68-1(config-if)# exit

At the device level:

gsr-68-1(config)# interface Tunnel1

At the tunnel interface level:

gsr-68-1(config-if)# ip unnumbered Loopback0
gsr-68-1(config-if)# tunnel destination 24.1.1.1
gsr-68-1(config-if)# tunnel mode mpls traffic-eng
gsr-68-1(config-if)# tunnel mpls traffic-eng priority 0 0
gsr-68-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000
gsr-68-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic
gsr-68-1(config-if)# exit
gsr-68-1(config)# 

Midpoint Devices

At the device level:

gsr-68-2# configure terminal
gsr-68-2(config)# ip cef
gsr-68-2(config)# mpls traffic-eng tunnels

gsr-68-2(config)# router ospf 100
gsr-68-2(config-router)# network 10.1.1.0 0.0.0.255 area 0
gsr-68-2(config-router)# network 11.1.1.0 0.0.0.255 area 0
gsr-68-2(config-router)# network 12.1.1.0 0.0.0.255 area 0
gsr-68-2(config-router)# network 25.1.1.1 0.0.0.0 area 0
gsr-68-2(config-router)# mpls traffic-eng router-id Loopback0
gsr-68-2(config-router)# mpls traffic-eng area 0
gsr-68-2(config-router)# exit

gsr-68-2(config)# interface Loopback0

At the physical interface level (internal):

gsr-68-2(config-if)# ip address 25.1.1.1 255.255.255.255
gsr-68-2(config-if)# no ip directed-broadcast
gsr-68-2(config-if)# exit

At the device level:

gsr-68-2(config)# interface POS4/0

At the physical interface level (ingress):

gsr-68-2(config-if)# ip address 11.1.1.2 255.255.255.0
gsr-68-2(config-if)# mpls traffic-eng tunnels
gsr-68-2(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000
gsr-68-2(config-if)# exit

At the device level:

gsr-68-2(config)# interface POS4/1

At the physical interface level (egress):

gsr-68-2(config-if)# ip address 12.1.1.2 255.255.255.0
gsr-68-2(config-if)# mpls traffic-eng tunnels
gsr-68-2(config-if)# ip rsvp bandwidth 500000 500000 sub-pool 300000
gsr-68-2(config-if)# exit

Note that there is no configuring of tunnel interfaces at the mid-point devices, only physical interfaces and the device globally.

Tail-End Device

At the device level:

gsr-69-1# configure terminal
gsr-69-1(config)# ip cef
gsr-69-1(config)# mpls traffic-eng tunnels
gsr-69-1(config)# router ospf 100
gsr-69-1(config-router)# redistribute connected
gsr-69-1(config-router)# network 12.1.1.0 0.0.0.255 area 0
gsr-69-1(config-router)# network 24.1.1.1 0.0.0.0 area 0
gsr-69-1(config-router)# mpls traffic-eng router-id Loopback0
gsr-69-1(config-router)# mpls traffic-eng area 0
gsr-69-1(config-router)# exit

gsr-69-1(config)# interface Loopback0

At the physical interface level (internal):

gsr-69-1(config-if)# ip address 24.1.1.1 255.255.255.255
gsr-69-1(config-if)# no ip directed-broadcast
gsr-69-1(config-if)# exit

At the device level:

gsr-69-1(config)# interface POS2/0

At the physical interface level (ingress):

gsr-69-1(config-if)# ip address 12.1.1.3 255.255.255.0
gsr-69-1(config-if)# mpls traffic-eng tunnels
gsr-69-1(config-if)# exit

Guaranteed Bandwidth Service Configuration

Having configured two bandwith pools, you now can

Use one pool, the sub-pool, for tunnels that carry traffic requiring strict bandwidth guarantees or delay guarantees

Use the other pool, the global pool, for tunnels that carry traffic requiring only Differentiated Service.

Having a separate pool for traffic requiring strict guarantees allows you to limit the amount of such traffic admitted on any given link. Often, it is possible to achieve strict QoS guarantees only if the amount of guaranteed traffic is limited to a portion of the total link bandwidth.

Having a separate pool for other traffic (best-effort or diffserv traffic) allows you to have a separate limit for the amount of such traffic admitted on any given link. This is useful because it allows you to fill up links with best-effort/diffserv traffic, thereby achieving a greater utilization of those links.

Providing Strict QoS Guarantees Using DS-TE Sub--pool Tunnels

A tunnel using sub-pool bandwidth can satisfy the stricter requirements if you do all of the following:

1. Select a queue—or in diffserv terminology, select a PHB (per-hop behavior)—to be used exclusively by the strict guarantee traffic. This shall be called the "GB queue."

If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue (EF PHB) is used. On the Cisco Series 12000 that is the "low-latency" queue. You must configure the bandwidth of the queue to be at least equal to the bandwidth of the sub-pool.

If only bandwidth guarantees are sought, the diffserv Assured Forwarding PHB (AF PHB) is used. On the Cisco 12000 you use one of the existing Modified Deficit Round Robin (MDRR) queues.

2. Ensure that the guaranteed traffic sent through the sub-pool tunnel is placed in the GB queue at the outbound interface of every tunnel hop, and that no other traffic is placed in this queue.

You do this by marking the traffic that enters the tunnel with a unique value in the mpls exp bits field, and steering only traffic with that marking into the GB queue.

3. Ensure that this GB queue is never oversubscribed; that is, see that no more traffic is sent into the sub-pool tunnel than the GB queue can handle.

You do this by rate-limiting the guaranteed traffic before it enters the sub-pool tunnel. The aggregate rate of all traffic entering the sub-pool tunnel should be less than or equal to the bandwidth capacity of the sub-pool tunnel. Excess traffic can be dropped (in the case of delay/jitter guarantees) or can be marked differently for preferential discard (in the case of bandwidth guarantees).

4. Ensure that the amount of traffic entering the GB queue is limited to an appropriate percentage of the total bandwidth of the corresponding outbound link. The exact percentage to use depends on several factors that can contribute to accumulated delay in your network: your QoS performance objective, the total number of tunnel hops, the amount of link fan-in along the tunnel path, burstiness of the input traffic, and so on.

You do this by setting the sub-pool bandwidth of each outbound link to the appropriate percentage of the total link bandwidth (that is, by adjusting the z parameter of the ip rsvp bandwidth command).

Providing Differentiated Service Using DS-TE Global Pool Tunnels

You can configure a tunnel using global pool bandwidth to carry best-effort as well as several other classes of traffic. Traffic from each class can receive differentiated service if you do all of the following:

1. Select a separate queue (a distinct diffserv PHB) for each traffic class. For example, if there are three classes (gold, silver, and bronze) there must be three queues (diffserv AF2, AF3, and AF4).

2. Mark each class of traffic using a unique value in the MPLS experimental bits field (for example gold = 4, silver = 5, bronze = 6).

3. Ensure that packets marked as Gold are placed in the gold queue, Silver in the silver queue, and so on. The tunnel bandwidth is set based on the expected aggregate traffic across all classes of service.

To control the amount of diffserv tunnel traffic you intend to support on a given link, adjust the size of the global pool on that link.

Providing Strict Guarantees and Differentiated Service in the Same Network

Because DS-TE allows simultaneous constraint-based routing of sub-pool and global pool tunnels, strict guarantees and diffserv can be supported simultaneously in a given network.

Guaranteed Bandwidth Service Example

Figure 2 illustrates a topology for guaranteed bandwidth services whose destination is specified by a single prefix, either Site D (prefix 26.1.1.1) or subnet Province (prefix 26.1.1.0). Three services are offered:

From Site A (defined as all traffic arriving at interface FE4/1/0): to host 26.1.1.1, 8 Mbps of guaranteed bandwidth with low loss, low delay and low jitter

From Site B (defined as all traffic arriving at interface FE4/1/1): towards subnet 26.1.1.0, 32 Mbps of guaranteed bandwidth with low loss

From Site C (defined as all traffic arriving at interface FE2/1/0): 30 Mbps of guaranteed bandwidth with low loss

Figure 2 Sample Guaranteed Bandwidth Services Topology

These three services run through two sub-pool tunnels:

From the router-1 head-1, 23.1.1.1, to the router-4 tail

From the router-2 head-2, 22.1.1.1, to the router-4 tail

Thus both tunnels use the same tail router, though they have different heads. (In this picture the two tunnels also share one of the midpoint routers. In the real world there would of course be many more midpoints than just the two shown here.)

All POS interfaces in this example are OC3, whose capacity is 155 Mgps.

Tunnel Head Configuration (Head-1)

First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier in this Configuration Examples section). Then we present the QoS commands that guarantee end-to-end service on the subpool tunnel.

Configuring the Pools and Tunnel

At the device level:

router-1(config)# ip cef
router-1(config)# mpls traffic-eng tunnels
router-1(config)# router ospf 100
router-1(config-router)# redistribute connected
router-1(config-router)# network 10.1.1.0 0.0.0.255 area 0
router-1(config-router)# network 23.1.1.1 0.0.0.0 area 0
router-1(config-router)# mpls traffic-eng router-id Loopback0
router-1(config-router)# mpls traffic-eng area 0
router-1(config-router)# exit

At the outgoing physical interface:

router-1(config)# interface pos4/0
router-1(config-if)# ip address 10.1.1.1 255.0.0.0
router-1(config-if)# mpls traffic-eng tunnels
router-1(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-1(config-if)# exit

At the (internal) physical interface:

router-1(config)# interface Loopback0
router-1(config-if)# ip address 23.1.1.1 255.255.255.255
router-1(config-if)# no ip directed-broadcast
router-1(config-if)# exit

At the tunnel interface:

router-1(config)# interface Tunnel1
router-1(config-if)# ip unnumbered Loopback0
router-1(config-if)# tunnel destination 27.1.1.1
router-1(config-if)# tunnel mode mpls traffic-eng
router-1(config-if)# tunnel mpls traffic-eng priority 0 0
router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 40000
router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic

To ensure that packets destined to host 26.1.1.1 and subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static route. At the device level:

router-1(config)# ip route 26.1.1.0 255.255.255.0 Tunnel1
router-1(config)# exit

And in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down this tunnel, we disable autoroute announce:

router-1(config)# no tunnel mpls traffic-eng autoroute announce

For Service from Site A to Site D

At the inbound physical interface (FE4/1/0):

1. In global configuration mode, create an ACL 100 to refer to all packets destined to 26.1.1.1:

access-list 100 permit ip any host 26.1.1.1

2. Packets received on the inbound interface FE4/1/0 that match ACL 100 are rate-limited to:

a. a rate of 8 Mgps

b. a normal burst of 1 MB

c. a maximum burst of 2 MB

d. Packets which conform to this rate are marked prec 5 and are forwarded

e. Packets which exceed the rate are dropped

interface FastEthernet4/1/0
rate-limit input access-group 100 8000000 1000000 2000000 conform-action \ 
set-mpls-exp-transmit 5 exceed-action drop

3. Packets which do not match ACL 100 are rate-limited and, regardless of whether they conform or not, their precedence is set to zero and they are forwarded. Note that we do not really care to rate-limit these packets. The intention is simply to ensure that all these packets are marked with precedence zero. The values used for rate-limiting are irrelevant.

rate-limit input 2000000000 512000000 1024000000 conform-action \ 
set-mpls-exp-transmit 0 exceed-action set-mpls-exp-transmit 0

For Service from Site B to Subnet "Province"

At the inbound physical interface (FE4/1/1):

1. In global configuration mode, create an ACL 120 to refer to all packets destined to subnet 26.1.1.0:

access-list 120 permit ip any 26.1.1.0 255.255.255.255

2. Packets received on the inbound interface FE4/1/1 that match ACL 120 are rate-limited to:

a. a rate of 32 Mgps

b. a normal burst of 1 MB

c. a maximum burst of 2 MB

d. Packets which conform to this rate are marked prec 5 and are forwarded

e. Packets which exceed the rate are dropped

interface FastEthernet4/1/1
rate-limit input access-group 120 32000000 1000000 2000000 conform-action \ 
set-mpls-exp-transmit 5 exceed-action drop

3. Packets which do not match ACL 120 are rate-limited and, regardless of whether they conform or not, their precedence is set to zero and they are forwarded. Note that we do not really care to rate-limit these packets. The intention is simply to ensure that all these packets are marked with precedence zero. The values used for rate-limiting are irrelevant.

rate-limit input 2000000000 512000000 1024000000 conform-action \  
set-mpls-exp-transmit 0 exceed-action set-mpls-exp-transmit 0

For Both Services

The outbound interface (POS4/0) is configured as follows. At the device level, you create a profile of QoS queuing:

router-1(config)# cos-queue-group class0+5
router-1(config-cos-queue)# precedence 0 random-detect-label 0
router-1(config-cos-queue)# precedence 5 queue low-latency
router-1(config-cos-queue)# precedence 5 random-detect-label 5
router-1(config-cos-queue)# random-detect-label 0 100 200 1
router-1(config-cos-queue)# random-detect-label 5 2000 3000 1
router-1(config-cos-queue)# queue low-latency strict-priority

At the physical interface level:

router-1(config)# interface pos4/0
router-1(config-if)# tx-cos class0+5

As a result of all the above configuration lines, packets entering the Head-1 router via interface FE4/1/0 and destined for host 26.1.1.1, or entering that router via interface FE4/1/1 and destined for subnet 26.1.1.0, have their IP precedence field set to 5. It is assumed that no other packets entering this router (on any interface) are using this precedence. (If this cannot be assumed, an additional configuration must be added to mark all such packets with another precedence value.) When exiting this router via interface POS4/0, packets marked with IP precedence 5 are placed in the low latency queue.


Note Packets entering the router via FE4/1/0 or FE4/1/1 and exiting POS4/0 enter as IP packets and exit as MPLS packets.



Tunnel Head Configuration (Head-2)

First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented earlier in this Configuration Examples section). Then we present the QoS commands that guarantee end-to-end service.

Configuring the Pools and Tunnel

At the device level:

router-2(config)# ip cef
router-2(config)# mpls traffic-eng tunnels
router-2(config)# router ospf 100
router-2(config-router)# redistribute connected
router-2(config-router)# network 11.1.1.0 0.0.0.255 area 0
router-2(config-router)# network 22.1.1.1 0.0.0.0 area 0
router-2(config-router)# mpls traffic-eng router-id Loopback0
router-2(config-router)# mpls traffic-eng area 0
router-2(config-router)# exit

At the outgoing physical interface:

router-2(config)# interface pos0/0
router-2(config-if)# ip address 11.1.1.1 255.0.0.0
router-2(config-if)# mpls traffic-eng tunnels
router-2(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-2(config-if)# exit

At the (internal) physical interface:

router-2(config)# interface Loopback0
router-2(config-if)# ip address 22.1.1.1 255.255.255.255
router-2(config-if)# no ip directed-broadcast
router-2(config-if)# exit

At the tunnel interface:

router-2(config)# interface Tunnel2
router-2(config-if)# ip unnumbered Loopback0
router-2(config-if)# tunnel destination 27.1.1.1
router-2(config-if)# tunnel mode mpls traffic-eng
router-2(config-if)# tunnel mpls traffic-eng priority 0 0
router-2(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000
router-2(config-if)# tunnel mpls traffic-eng path-option 1 dynamic
router-2(config-if)# exit

And to ensure that packets destined to subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static route, at the device level:

router-2(config)# ip route 26.1.1.0 255.255.255.0 Tunnel2
router-2(config)# exit

Finally, in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down this tunnel, we disable autoroute announce:

router-2(config)# no tunnel mpls traffic-eng autoroute announce

For Service from Site C to Subnet "Province"

At the inbound physical interface (FE2/0):

1. In global configuration mode, create an ACL 130 to refer to all packets destined to 26.1.1.0:

access-list 130 permit ip any 26.1.1.0 255.255.255.255

2. Packets received on the inbound interface FE2/0 that match ACL 130 are rate-limited to:

a. a rate of 30 Mgps

b. a normal burst of 1 MB

c. a maximum burst of 2 MB

d. Packets which conform to this rate are marked prec 5 and are forwarded

e. Packets which exceed the rate are dropped

interface FastEthernet2/0
rate-limit input access-group 130 32000000 1000000 2000000 conform-action \ 
set-mpls-exp-transmit 5 exceed-action drop

3. Packets which do not match ACL 130 are rate-limited and, regardless of whether they conform or not, their precedence is set to zero and they are forwarded. Note that we do not really care to rate-limit these packets. The intention is simply to ensure that all these packets are marked with precedence zero. The values used for rate-limiting are irrelevant.

rate-limit input 2000000000 512000000 1024000000 conform-action \  
set-mpls-exp-transmit 0 exceed-action set-mpls-exp-transmit 0

For the outbound physical interface (POS0/0), you create, at the device level, a profile of QoS queuing:

router-1(config)# cos-queue-group class0+5
router-1(config-cos-queue)# precedence 0 random-detect-label 0
router-1(config-cos-queue)# precedence 5 queue low-latency
router-1(config-cos-queue)# precedence 5 random-detect-label 5
router-1(config-cos-queue)# random-detect-label 0 100 200 1
router-1(config-cos-queue)# random-detect-label 5 2000 3000 1
router-1(config-cos-queue)# queue low-latency strict-priority

And at the physical interface level:

router-1(config)# interface pos0/0
router-1(config-if)# tx-cos class0+5

As a result of all the above configuration lines, packets entering the Head-2 router via interface FE2/1/0 and destined for subnet 26.1.1.0 have their IP precedence field set to 5. It is assumed that no other packets entering this router (on any interface) are using this precedence. (If this cannot be assumed, an additional configuration must be added to mark all such packets with another precedence value.) When exiting this router via interface POS0/0, packets marked with IP precedence 5 are placed in the low latency queue.


Note Packets entering the router via FE2/1/0 and exiting through POS0/0 enter as IP packets and exit as MPLS packets.


Tunnel Midpoint Configuration [Mid-1]

All four interfaces on the midpoint router are configured identically to the outbound interface of the head router (except, of course, for the IDs of the individual interfaces):

Configuring the Pools and Tunnels

At the device level:

router-3(config)# ip cef
router-3(config)# mpls traffic-eng tunnels
router-3(config)# router ospf 100
router-3(config-router)# redistribute connected
router-3(config-router)# network 10.1.1.0 0.0.0.255 area 0
router-3(config-router)# network 11.1.1.0 0.0.0.255 area 0
router-3(config-router)# network 24.1.1.1 0.0.0.0 area 0
router-3(config-router)# network 12.1.1.0 0.0.0.255 area 0
router-3(config-router)# network 13.1.1.0 0.0.0.255 area 0
router-3(config-router)# mpls traffic-eng router-id Loopback0
router-3(config-router)# mpls traffic-eng area 0
router-3(config-router)# exit

At the (internal) physical interface:

router-3(config)# interface Loopback0
router-3(config-if)# ip address 24.1.1.1 255.255.255.255
router-3(config-if)# no ip directed-broadcast
router-3(config-if)# exit

At the physical interface level (ingress):

router-3(config)# interface pos2/1
router-3(config-if)# ip address 10.1.1.2 255.0.0.0
router-3(config-if)# mpls traffic-eng tunnels
router-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-3(config-if)# exit

router-3(config)# interface pos1/1
router-3(config-if)# ip address 11.1.1.2 255.0.0.0
router-3(config-if)# mpls traffic-eng tunnels
router-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-3(config-if)# exit

At the physical interface level (egress):

router-3(config)# interface pos3/1
router-3(config-if)# ip address 12.1.1.1 255.0.0.0
router-3(config-if)# mpls traffic-eng tunnels
router-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-3(config-if)# exit

router-3(config)# interface pos4/1
router-3(config-if)# ip address 13.1.1.1 255.0.0.0
router-3(config-if)# mpls traffic-eng tunnels
router-3(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-3(config-if)# exit

For All GB Services

At the device level, create a profile of QoS queuing:

router-3(config)# cos-queue-group class0+5
router-3(config-cos-queue)# precedence 0 random-detect-label 0
router-3(config-cos-queue)# precedence 5 queue low-latency
router-3(config-cos-queue)# precedence 5 random-detect-label 5
router-3(config-cos-queue)# random-detect-label 0 100 200 1
router-3(config-cos-queue)# random-detect-label 5 2000 3000 1
router-3(config-cos-queue)# queue low-latency strict-priority

For Services from Sites A and B

At the physical interface level:

router-3(config)# interface pos3/1
router-3(config-if)# tx-cos class0+5

For Service from Site C

At the physical interface level:

router-3(config)# interface pos4/1
router-3(config-if)# tx-cos class0+5

Tunnel Midpoint Configuration [Mid-2]

Both interfaces on the midpoint router are configured identically to the outbound interface of the head router (except, of course, for the IDs of the individual interfaces):

Configuring the Pools and Tunnel

At the device level:

router-5(config)# ip cef
router-5(config)# mpls traffic-eng tunnels
router-5(config)# router ospf 100
router-5(config-router)# redistribute connected
router-5(config-router)# network 13.1.1.0 0.0.0.255 area 0
router-5(config-router)# network 14.1.1.0 0.0.0.255 area 0
router-5(config-router)# network 25.1.1.1 0.0.0.0 area 0
router-5(config-router)# mpls traffic-eng router-id Loopback0
router-5(config-router)# mpls traffic-eng area 0
router-5(config-router)# exit

At the (internal) physical interface:

router-5(config)# interface Loopback0
router-5(config-if)# ip address 25.1.1.1 255.255.255.255
router-5(config-if)# no ip directed-broadcast
router-5(config-if)# exit

At the physical interface level (ingress):

router-5(config)# interface pos1/1
router-5(config-if)# ip address 13.1.1.2 255.0.0.0
router-5(config-if)# mpls traffic-eng tunnels
router-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-5(config-if)# exit

At the physical interface level (egress):

router-5(config)# interface pos2/1
router-5(config-if)# ip address 14.1.1.1 255.0.0.0
router-5(config-if)# mpls traffic-eng tunnels
router-5(config-if)# ip rsvp bandwidth 140000 140000 sub-pool 60000
router-5(config-if)# exit

For Service from Site C

At the device level, create a profile of QoS queuing:

router-5(config)# cos-queue-group class0+5
router-5(config-cos-queue)# precedence 0 random-detect-label 0
router-5(config-cos-queue)# precedence 5 queue low-latency
router-5(config-cos-queue)# precedence 5 random-detect-label 5
router-5(config-cos-queue)# random-detect-label 0 100 200 1
router-5(config-cos-queue)# random-detect-label 5 2000 3000 1
router-5(config-cos-queue)# queue low-latency strict-priority

At the physical interface level:

router-5(config)# interface pos2/1
router-5(config-if)# tx-cos class0+5

Tunnel Tail Configuration

The inbound interfaces on the tail router are configured identically to the inbound interfaces of the midpoint router (except, of course, for the ID of each particular interface):

Configuring the Pools and Tunnels

At the device level:

router-4(config)# ip cef
router-4(config)# mpls traffic-eng tunnels
router-4(config)# router ospf 100
router-4(config-router)# redistribute connected
router-4(config-router)# network 12.1.1.0 0.0.0.255 area 0
router-4(config-router)# network 14.1.1.0 0.0.0.255 area 0
</