qos_rsvp

Configuring RSVP-ATM QoS Interworking

This chapter describes the tasks for configuring the RSVP-ATM QoS Interworking feature, which provides support for Controlled Load Service using RSVP over an ATM core network.

For complete conceptual information, see the "Signalling Overview" module.

For a complete description of the RSVP-ATM QoS Interworking commands in this module, see the  Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

RSVP-ATM QoS Interworking Configuration Task List

To configure RSVP-ATM QoS Interworking, perform the tasks described in the following sections. Each task is identified as either optional or required.

•Enabling RSVP and Limiting Reservable Bandwidth (Required)

•Enabling Creation of SVCs for Reserved Flows (Required)

•Limiting the Peak Rate Applied to the PCR for SVCs (Optional)

•Configuring per-VC DWRED (Required)

•Monitoring RSVP-ATM Configuration for an Interface (Optional)

Before you configure RSVP-ATM QoS Interworking, you must enable and configure the following features:

•Cisco Express Forwarding (CEF) switching (required for RSVP-ATM)

•Distributed CEF (dCEF) (required for per-switched virtual circuit (SVC) DWRED)

•NetFlow services

For information about CEF and dCEF, refer to the "Cisco Express Forwarding Features Roadmap" module and the Cisco IOS Switching Services Command Reference. For information about NetFlow services, see the "Cisco IOS Netfow Features Roadmap" module.

The RSVP-ATM QoS Interworking feature does not support Resource Reservation Protocol (RSVP) with multicast.

See the end of this module for the section "RSVP-ATM QoS Interworking Configuration Examples."

Enabling RSVP and Limiting Reservable Bandwidth

RSVP allows end systems or hosts on either side of a router network to establish a reserved-bandwidth path between them to predetermine and ensure QoS for their data transmission. By default, RSVP is disabled so that it is backward compatible with systems that do not implement RSVP.

To enable RSVP on an interface and restrict the total amount of bandwidth that can be reserved for RSVP and the amount that can be reserved for a single RSVP reservation or flow, use the following command in global configuration mode:

For RSVP over ATM, reservations are needed primarily between routers across the ATM backbone. To limit the number of locations where reservations are made, enable RSVP selectively only at subinterfaces corresponding to router-to-router connections across the backbone network. Preventing reservations being made between the host and the router both limits VC usage and reduces load on the router.

The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, the amount reservable by a flow can be up to the entire reservable bandwidth.

On subinterfaces, the more restrictive of the available bandwidths of the physical interface and the subinterface is applied.

Enabling Creation of SVCs for Reserved Flows

Normally, reservations are serviced when RSVP classifies packets and a queueing mechanism polices the packet. To enable establishment of an SVC to service each new RSVP reservation on the interface, use the following command in interface configuration mode:

To ensure defined QoS, SVCs created in response to RSVP reservation requests are established having QoS profiles consistent with the mapped RSVP flow specifications.

The sustainable cell rate (SCR) of an ATM SVC is equal to the RSVP reservation rate; the maximum burst size (MBS) of an ATM SVC is equal to the RSVP burst size. RSVP attempts to compensate for the cell tax when establishing the reservation so that the requested bandwidth is actually available for IP data traffic.

The sustained cell rate formula is given as follows:

ratm = rrsvp * (53/48) * (MPS + DLE + (MPS + DLE) % 48)/MPS

The formula terms used in the equation (and subsequent equations) are described in Table 14, followed by an explanation of how the formula was derived.

There are two reasons for converting from RSVP rate to the ATM cell rate, as follows:

•To account for the ATM encapsulation header overhead and cell header overhead

•To account for the fact that ATM cell sizes are fixed

Because a portion of the last cell is unused, it is possible that a certain IP packet size requires more ATM cell layer bytes.

MPS + DLE is the length of the data packet that needs to be segmented into a number of fixed-length (48-byte payload) pieces that would then be put into a cell and sent.

Because the CPS needs to be greater than or equal to MPS + DLE, CPS must be larger than MPS.

CPS can be calculated as follows:

CPS = ceil((MPS + DLE)/48) * 48

where ceil(x) is the ceiling operator that returns the smallest integer greater than or equal to the real number x. Upon expanding the implementation of the ceil(x) operator, the expression can be arithmetically transformed into the following equation:

CPS = MPS + DLE + (MPS + DLE) % 48

where (MPS + DLE) % 48 yields the integer remainder when MPS + DLE is divided by 48. Because (MPS + DLE) % 48 is equal to the UCO, the equation for CPS can be rewritten as follows:

CPS = MPS + DLE + UCO

Because the IP bit rate was calculated by considering only the IP data and header (that is, packets of length MPS or larger), the IP bit rate (^rrsvp) needs to be multiplied by COMP. According to Table 14, COMP = CPS/MPS. Thus:

ATM cell payload bit rate = rrsvp * COMP = rrsvp * CPS/MPS

When expanded, the ATM cell payload bit rate is as follows:

ATM cell payload bit rate = rrsvp * (MPS + DLE + UCO)/MPS

Each ATM cell has a 5-byte header and a 48-byte payload, resulting in a 53-byte cell. Because the entire cell needs to be accounted for (not just the payload), we need to multiply the equation by a compensation factor of 53/48, which yields the desired equation:

ratm = rrsvp * (53/48) * (MPS + DLE + UCO)/MPS

Thus, the SCR of the SVC created to carry the RSVP flow is calculated by the following formula:

ratm = rrsvp * (53/48) * (MPS + DLE + (MPS + DLE) % 48)/MPS

The ATM peak cell rate (PCR) is derived using the same formula as the cell rate formula. It is either based on the maximum line rate of the ATM interface or on a configured maximum.

The maximum burst size of the SVC is derived by the following formula:

ratm = rrsvp * (MPS + DLE + UCO)/(MPS * 48)

Note that the actual PCR, SCR, and MBS will be slightly larger than these formulas indicate.

See the task "Limiting the Peak Rate Applied to the PCR for SVCs" for information on setting the PCR of the ATM SVC.

Each new RSVP reservation causes establishment of a new SVC. If an existing reservation is refreshed, no new signalling is needed. If the reservation is not refreshed and it times out, the SVC is torn down. If the reservation is refreshed but the RSVP flowspec has changed, the existing SVC is torn down and a new one with the correct QoS parameters is established.

Limiting the Peak Rate Applied to the PCR for SVCs

To set a limit on the PCR of reservations for all new RSVP SVCs established on the current interface or any of its subinterfaces, use the following command in interface configuration mode:

For Controlled Load Service, the nominal peak rate is not defined and is taken as infinity. Consequently, the PCR is set to the available line rate. However, you can use the ip rsvp atm-peak-rate-limit command to further limit the PCR to a specific value on a per-interface basis.

Configuring per-VC DWRED

To configure Distributed Weighted Random Early Detection (DWRED) with per-VC DWRED enabled as a drop policy at the interface level for a specific DWRED group, use the following command in interface configuration mode:

The per SVC-DWRED drop policy ensures that packets that match reservations and conform to the appropriate token bucket have the highest priority. Attaching DWRED group definitions to the interface to support per-VC DWRED drop policy ensures that if packets must be dropped, then best-effort packets are dropped first and not those that conform to the appropriate QoS determined by the token bucket of the RSVP. This drop policy meets the loss requirements of controlled load called for by the Controlled Load Service class.

To meet the loss goals of controlled load, it is necessary to ensure that if packets must be dropped, best-effort packets are dropped first. Given that packets matching reservations and conforming to the appropriate token bucket will have the highest precedence, per-SVC DWRED is used as the drop policy.

Note In order to use per-SVC DWRED, dCEF must be configured on the router. For information on how to configure dCEF, refer to the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference.

Monitoring RSVP-ATM Configuration for an Interface

To display the peak rate limit for the interface, the IP Precedence and ToS bit values configured for packets that conform to and exceed the flowspec, and other RSVP-related information for the interface, such as whether the interface has been configured to establish SVCs to service reservation request messages and whether RSVP is enabled to attach itself to NetFlow, use the following commands in EXEC mode, as needed:

RSVP-ATM QoS Interworking Configuration Examples

This section provides RSPV-ATM QoS Internetworking configuration examples.

For information about configuring RSVP-ATM QoS Internetworking, see the section "RSVP-ATM QoS Interworking Configuration Task List" in this module.

The following example configures two Cisco 7500 series routers that connect over an ATM core network through a permanent virtual circuit (PVC) and multiple SVCs. As depicted in Figure 24, Router A is connected to the ATM core network downstream; upstream it is connected across an Ethernet connection to the RSVP sender host system. Router B is connected upstream to the ATM core network and downstream across an Ethernet connection to the RSVP receiver host.

The example configuration shows three PVCs, two of which are required by ATM. One of the PVCs is used for RSVP-ATM QoS Interworking. It is used for transmission of best-effort traffic and to control traffic such as routing and RSVP messages. The ATM SVCs are established in response to reservation request messages in order to service those requests.

Figure 24 Example RSVP-ATM QoS Interworking Configuration

Router A Configuration

The following portion of the example configures Router A in global configuration mode. It enables CEF, which must be turned on before the RSVP-ATM QoS Interworking feature can be enabled at the interface configuration level.

RouterA# config terminal

RouterA(config)# ip routing

RouterA(config)# ip cef

The following segment of the configuration for Router A configures ATM interface 2/1/0. The ip route-cache flow command enables NetFlow on the interface. If you do not enter the ip rsvp bandwidth command before the ip rsvp svc-required command, a warning is issued requesting that you change the order of the commands.

The ip rsvp bandwidth command enables RSVP on the interface with default values for bandwidth allocation to RSVP. The ip rsvp svc-required command enables establishment of an SVC to service each new RSVP reservation on the interface. The ip rsvp tos and ip rsvp precedence commands configure conform and exceed values to be used for setting the ToS and IP Precedence bits of packets that either conform to or exceed the RSVP flowspec. (Note that once set, the ToS and IP Precedence bit values remain for the duration of the packet.)

You should configure the ip route-cache flow command only on the input interfaces of a router on whose output interfaces you configured the ip rsvp svc-required command.

RouterA(config)# interface ATM2/1/0

RouterA(config-if)# no shut

RouterA(config-if)# ip address 145.5.5.1 255.255.255.0

RouterA(config-if)# no ip proxy

RouterA(config-if)# no ip redirects

RouterA(config-if)# ip route-cache

RouterA(config-if)# ip mroute-cache

RouterA(config-if)# ip route-cache flow

RouterA(config-if)# no ip mroute-cache

RouterA(config-if)# ip route-cache cef

RouterA(config-if)# atm pvc 1 0 5 qsaal

RouterA(config-if)# atm pvc 2 0 16 ilmi

RouterA(config-if)# atm esi-address 111111111151.00

RouterA(config-if)# pvc pvc12 0/51

RouterA(config-if-atm-vc)# inarp 5

RouterA(config-if-atm-vc)# broadcast

RouterA(config-if-atm-vc)# exit

RouterA(config-if)# ip rsvp bandwidth

RouterA(config-if)# ip rsvp svc-required

RouterA(config-if)# ip rsvp tos conform 4

RouterA(config-if)# ip rsvp precedence conform 3 exceed 2

The following portion of the configuration configures Ethernet interface 0/1 on Router A that is used for the connection between the sender host and Router A. RSVP is enabled on the interface with default bandwidth allocations.

RouterA(config)# interface Ethernet0/1

RouterA(config-if)# ip address 145.1.1.1 255.255.255.0

RouterA(config-if)# no ip proxy

RouterA(config-if)# no ip redirects

RouterA(config-if)# no shut

RouterA(config-if)# ip route-cache

RouterA(config-if)# ip mroute-cache

RouterA(config-if)# ip route-cache flow

RouterA(config-if)# no ip mroute-cache

RouterA(config-if)# ip route-cache cef

RouterA(config-if)# fair

RouterA(config-if)# ip rsvp bandwidth

The following section displays configuration for Router A after the preceding commands were used to configure it:

RouterA# write terminal

 Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname RouterA

boot system tftp rsp-jv-mz 171.69.209.28

enable password 

!

ip subnet-zero

ip cef

interface Ethernet0/1

 ip address 145.1.1.1 255.255.255.0

 no ip redirects

 no ip directed-broadcast

 no ip proxy-arp

 ip rsvp bandwidth 7500 7500

 no ip route-cache cef

 no ip mroute-cache

 fair-queue 64 256 1000

!

interface ATM2/1/0

 ip address 145.5.5.1 255.255.255.0

 no ip redirects

 no ip directed-broadcast

 no ip proxy-arp

 ip rsvp bandwidth 112320 112320

 ip rsvp svc-required

 ip route-cache flow 
 ip rsvp tos conform 4 
 ip rsvp precedence conform 3 exceed 2

 no ip route-cache cef

 no ip route-cache distributed

 no ip mroute-cache

 atm pvc 1 0 5 qsaal

 atm pvc 2 0 16 ilmi

 atm esi-address 111111111151.00

 pvc pvc12 0/51

  inarp 5

  broadcast

!

Router B Configuration

Router B is configured similarly to Router A. In the following global configuration portion of the example, Router B is configured so that CEF is e enabled before the RSVP-ATM QoS Interworking feature can be enabled.

RouterB# config terminal

RouterB(config)# ip routing

RouterB(config)# ip cef

The following segment of the configuration for Router B configures ATM interface 3/0/0. The ip rsvp bandwidth command enables RSVP and the ip route-cache flow command enables NetFlow on the interface. The ip rsvp svc-required command enables the RSVP-ATM QoS Interworking feature, allowing for the establishment of an SVC to service each new RSVP reservation on the interface.

RouterB(config)# interface ATM3/0/0

RouterB(config-if)# atm pvc 1 0 5 qsaal

RouterB(config-if)# atm pvc 2 0 16 ilmi

RouterB(config-if)# atm esi-address 111111111152.00

RouterB(config-if)# pvc pvc12 0/52

RouterB(config-if-atm-vc)# inarp 5

RouterB(config-if-atm-vc)# broadcast

RouterB(config-if-atm-vc)# exit

RouterB(config-if)# ip rsvp bandwidth

RouterB(config-if)# ip route-cache flow

RouterB(config-if)# ip rsvp svc-required 

The following portion of the configuration configures the Ethernet interface on Router B. This interface is used for the connection between the receiver host and Router B. RSVP is enabled on the interface.

RouterB(config)# interface Ethernet0/2

RouterB(config-if)# no shut

RouterB(config-if)# ip address 145.4.4.2 255.255.255.0

RouterB(config-if)# no ip proxy

RouterB(config-if)# no ip redirects

RouterB(config-if)# ip route-cache

RouterB(config-if)# ip mroute-cache

RouterB(config-if)# ip route-cache flow

RouterB(config-if)# no ip mroute-cache

RouterB(config-if)# ip route-cache cef

RouterB(config-if)# fair

RouterB(config-if)# ip rsvp bandwidth

RouterB(config-if)# end

RouterB(config)# ip routing

RouterB(config)# router eigrp 17

RouterB(config-router)# network 145.5.5.0

RouterB(config-router)# network 145.4.4.0

The following section displays configuration for Router B after the preceding commands were used to configure it:

RouterB# write terminal

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname RouterB

!

!

boot system tftp rsp-jv-mz 171.69.209.28

enable password 

!

ip subnet-zero

ip cef distributed

interface Ethernet0/2

 ip address 145.4.4.2 255.255.255.0

 no ip redirects

 no ip directed-broadcast

 no ip proxy-arp

 ip rsvp bandwidth 7500 7500

 ip route-cache flow

 no ip mroute-cache

 fair-queue 64 256 1000

!

interface ATM3/0/0

 ip address 145.5.5.2 255.255.255.0

no ip redirects

 no ip directed-broadcast

 no ip proxy-arp

 ip rsvp bandwidth 112320 112320

 ip rsvp svc-required 
 ip route-cache flow

 no ip route-cache cef

 no ip route-cache distributed

 no ip mroute-cache

 atm pvc 1 0 5 qsaal

 atm pvc 2 0 16 ilmi

 atm esi-address 111111111152.00

 pvc pvc12 0/52

  inarp 5

  broadcast

 !

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2007 Cisco Systems, Inc. All rights reserved.