|
|
The RSVP-ATM Quality of Service (QoS) Interworking feature provides support for Controlled Load Service using RSVP over an ATM core network. This feature requires the ability to signal for establishment of switched virtual circuits (SVCs) across the ATM cloud in response to RSVP reservation messages. To meet this requirement, RSVP over ATM supports mapping of RSVP sessions to ATM SVCs.
RSVP-ATM QoS Interworking allows you to
FIB---Forwarding Information Base, more commonly known as Cisco Express Forwarding (CEF). A FIB is a data structure used for forwarding packets. CEF includes a full routing table with recursion resolved, not a cache. FIB switching is the preferred method of switching on the Versatile Interface Processor (VIP).
maximum burst size---Also referred to as maximum burst, specifies the maximum number of cells in a burst that can be transmitted on an ATM PVC without being policed.
PA-A3 ATM PA---An ATM port adapter (PA) that provides hardware-implemented shaping and substantial onboard buffering.
RED---Random Early Detection, which is an algorithm that allows for a small percentage of packets to be dropped when congestion is detected before the queue overflows.
RSVP---Resource Reservation Protocol, which is a protocol used for requesting per-flow QoS in IP networks.
VIP-Distributed WRED---An implementation of Weighted Random Early Detection for the VIP. It provides the complete set of functions for the VIP that WRED provides on standard Cisco IOS platforms.
The following restrictions apply to RSVP-ATM QoS Interworking:
This feature is supported on the Cisco 7500 series routers with a VIP2-50 and PA-A3 ATM PA. The hardware provides the traffic shaping required by the feature and satisfies the OC-3 rate performance requirement.
For information on how to configure these features, see the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference.
This feature supports the following MIB:
For descriptions of supported MIBs and how to use MIBs, see Cisco's MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
This section gives background on RSVP, then it describes how the RSVP-ATM QoS Interworking feature works and gives a sample scenario.
RSVP does not perform its own routing; instead it uses the underlying routing protocols to determine where it should carry reservation requests.
RSVP uses a mean data rate---the largest amount of data the router will keep in the queue---and the requested QoS---that is, guarantee of the requested bandwidth specified when you made the reservation using RSVP---to determine bandwidth reservation. A host uses RSVP to request a specific QoS service from the network on behalf of an application data stream. RSVP requests the particular QoS, but it is up to the interface queueing mechanism to implement the reservation. Note that for RSVP, an application could send traffic at rate higher than the requested QoS, but the application is guaranteed only the minimum requested rate. If bandwidth is available, traffic surpassing the requested rate will go through if sent; if bandwidth is not available, the exceeding traffic will be dropped.
If the required resources are available and the user is granted administrative access, the RSVP daemon sets arguments in the packet classifier and packet scheduler to obtain the desired QoS. The classifier determines the QoS class for each packet and the scheduler orders packet transmission to achieve the promised QoS for each stream. Weighted fair queueing (WFQ) or WRED sets up the packet classification and the scheduling required for the reserved flows.
The RSVP-ATM QoS Interworking feature allows you to decouple RSVP from WFQ, and instead associate it with ATM SVCs to handle reservation requests (and provide bandwidth guarantees) and Netflow to make packets visible to RSVP.
To configure an interface or subinterface to use RSVP-ATM QoS Interworking, use the ip rsvp svc-required command. Then, whenever a new RSVP reservation is requested, the router software establishes a new ATM SVC to service the reservation.
To ensure correspondence between RSVP and ATM SVC values, the software algorithmically maps the rate and burst size parameters in the RSVP flowspec to the ATM sustained cell rate (SCR) and maximum burst size. For the peak cell rate (PCR), it uses the value you configure or it defaults to the line rate. RSVP-ATM requires a PA-A3 ATM PA with OC-3 speed.
When a packet belonging to a reserved flow arrives on the interface or subinterface, the RSVP-ATM QoS Interworking software uses a token bucket to manage bandwidth guarantees. It measures actual traffic rates against the reservation flowspec to determine if the packet conforms to or exceeds the flowspec. Using values you configure for conformant or exceeding traffic, it sets the IP Precedence and ToS bits in the ToS byte of the packet's header and delivers the packet to the appropriate virtual circuit (VC) for transmission. For RSVP-ATM QoS Interworking, packets are shaped before they are transmitted on the ATM SVC. Shaping creates back pressure to the VIP when the offered load exceeds the rate.
The RSVP-ATM QoS Interworking software uses the per-SVC DWRED to drop packets when shaping causes a queue to build up on the VIP. Use of per-SVC Distributed WRED (DWRED) allows RSVP to deliver Controlled Load Service class, which requires that reserved packets experience performance equivalent to that of an unloaded network (which is one with very low loss and moderate delay). For a more detailed account of how RSVP-ATM QoS Interworking works, see the following example scenario.
To understand the behavior of RSVP-ATM QoS Interworking, consider the following example, which uses a Cisco 7500 router with VIP ingress and egress interfaces and RSVP ingress functionality implemented on the RSP. Figure 1 illustrates this example; it shows a pair of routers that communicate over the ATM cloud. In this example, a single PVC is used for RSVP requests and an ATM SVC is established to handle each new reservation request.
Host X, which is upstream from Router A, is directly connected to Router A using FDDI. Host Y, which is downstream from Router B, is directly connected to Router B using FDDI. (In an alternative configuration, these host-router connections could use ATM VCs.)
For RSVP-ATM QoS Interworking, reservations are needed primarily between routers across the ATM backbone network. To limit the number of locations where reservations are made, you can enable RSVP selectively only at subinterfaces corresponding to router-to-router connections across the ATM backbone network. Preventing reservations from being made between the host and the router both limits virtual circuit (VC) usage and reduces load on the router.
RSVP RESV (reservation) messages flow from receiving host to sending host. In this example, Host Y is the sending host and Host X is the receiving host. (Host Y sends a RESV message to Host X.) Router B, which is at the edge of the ATM cloud, receives the RESV message and forwards it upstream to Router A across the PVC used for control messages. The example configuration shown in Figure 1 uses one PVC; as shown, it carries the RSVP request.
The ingress interface on Router A is configured for RSVP-ATM, which enables it to establish for each request an SVC to service any new RSVP (RESV) reservations made on the interface. When it receives a reservation request, the interface on Router A creates a new non-real-time variable bit rate (nRTVBR) SVC with the appropriate QoS characteristics. The QoS characteristics used to establish the SVC result from algorithmic mapping of the flowspec in the RSVP RESV message to the appropriate set of ATM signalling parameters.
In this example, Controlled Load Service is used as the QoS class. The ATM PCR parameter is set to the line rate. If the ip rsvp atm-peak-rate-limit command is used on the interface to configure a rate limiter, the PCR is set to the peak rate limiter. The ATM SCR parameter is set to the RSVP flowspec rate and the ATM maximum burst size is set to the RSVP flowspec burst size. Packets are shaped before they are transmitted on the ATM SVC. Shaping creates back pressure to the VIP when the offered load exceeds the rate.
When a new SVC is set up to handle a reservation request, other state is also set up including classifier state that uses a packet's source and destination addresses and port numbers to determine which, if any, reservation the packet belongs to. Also, a token bucket is set up to ensure that if a source sends more data than its flowspec's data rate and MBS parameters specify, the excess traffic does not interfere with other reservations.
If the packet does not match a reservation, it is sent out the best-effort PVC to Router B. If a packet matches a reservation, it is further processed by RSVP. The packet is checked against the reservation's token bucket to determine whether it conforms to or exceeds the token bucket parameters. (All packets matching a reservation are sent out on the reservation's SVC to prevent misordering of packets.)
To introduce differentiation between flowspec-conformant and flowspec-exceeding packets, you can specify values for RSVP-ATM to use in setting the IP Precedence and ToS bits of the packets. To specify these values, you use the ip rsvp precedence and ip rsvp tos commands. By setting different precedence values for conformant and exceeding packets and by using a preferential drop policy such as DWRED, RSVP-ATM ensures that flowspec-exceeding packets are dropped prior to flowspec-conformant packets when the VC is congested.
To configure RSVP ATM with QoS Internetworking, perform the following tasks:
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 as well as the amount that can be reserved for a single RSVP reservation or flow, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Enable RSVP for IP on an interface. |
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.
| Command | Purpose |
|---|---|
Enables creation of an SVC for each new reservation made on the interface or subinterface. |
To ensure defined QoS, SVCs created in response to RSVP reservation requests are established having QoS profiles consistent with the mapped RSVP flowspecs.
The ATM SVC's sustained cell rate (SCR) is equal to the RSVP reservation rate; the ATM SVC's maximum burst size (MBS) 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 by the following equation:
ratm = rrsvp * (53/48) * (MPS + DLE + (MPS + DLE) % 48)/MPS
The formula terms used in the equation (and subsequent equations) are described in Table 1, followed by an explanation of how the formula was derived.
| Term | Definition |
ratm | ATM rate (SCR). |
rrsvp | RSVP rate. |
MPS | Minimum IP packet size, including the IP headers (300 bytes minimum). |
DLE | Data-link encapsulation overhead. For RSVP ATM SVCs, AAL5 SNAP encapsulation is used, which imposes a 5-byte encapsulation header on each PDU. |
% | Modulus operator. It yields the integer remainder from an integer division operation. For example, 57 % 53 results in 4. |
CPS | Cell payload size. The total number of bytes in all the payloads of all the cells required to send a single packet with encapsulation. |
UCO | Unused cell overhead (0 to 47). |
COMP | Compensation factor. CPS divided by MPS. |
There are two reasons for converting from RSVP rate to the ATM cell rate:
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 cell payload size (CPS) needs to be greater than or equal to MPS + DLE, CPS must be larger than MPS.
CPS can be calculated by the following expression:
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 above 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 unused cell overhead (UCO), the equation for CPS can be rewritten as
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 a compensation factor (COMP). From Table 1 we see that COMP = CPS/MPS. Thus:
ATM cell payload bit rate = rrsvp * COMP = rrsvp * CPS/MPS
When expanded, the ATM cell payload bit rate is given by the equation:
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 above equation by a compensation factor of 53/48. This 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 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 maximum burst size will be slightly larger than these formulas indicate.
See the task "Limit the Peak Rate Applied to the PCR for SVCs" for information on setting the ATM SVC's PCR.
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.
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:
| Command | Purpose |
|---|---|
Configure the peak rate limit for new RSVP SVCs on an interface or subinterface. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| ip rsvp precedence {conform precedence-value | exceed precedence-value} | Set the IP Precedence conform and exceed values. | ||
| ip rsvp tos {conform tos-value | exceed tos-value} | Set the ToS conform and exceed values. |
The ToS byte in the IP header defines the three high-order bits as IP Precedence bits and the five low-order bits as ToS bits.
The router software checks a packet's source and destination addresses and port numbers to determine if the packet matches an RSVP reservation. If a match exists, as part of its input processing, RSVP checks the packet for conformance to the reservation's flowspec. During this process, RSVP determines if the packet conforms to or exceeds the flowspec, and it sets the packet's IP header IP Precedence and ToS bits accordingly. These IP Precedence and ToS bit settings are used by per-VC DWRED on the output interface, and they can be used by interfaces on downstream routers.
The combination of scheduling performed by the PA-A3 ATM PA and the per-SVC DWRED drop policy ensures that any packet that matches a reservation but exceeds the flowspec, that is, that does not conform to the token bucket for the reservation, is treated as if it were a best-effort packet. It is sent on the SVC for the reservation, but its IP Precedence is marked to ensure that it does not interfere with conforming traffic.
To configure 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:
| Command | Purpose |
|---|---|
random-detect attach [group-name] | Configure interface-level per-VC DWRED for a specific DWRED group. |
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 RSVP's token bucket. 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.
To enable RSVP to attach itself to Netflow so that it can receive information about packets in order to update its token bucket and set IP Precedence as required, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
Enable RSVP to attach itself to Netflow. |
This task is optional for the following reason: When the interface is configured with the ip rsvp svc-required command to use ATM SVCs, RSVP automatically attaches itself to Netflow to perform packet-flow identification (in which case you need not perform this task). However, if you want to perform IP Precedence-ToS bit setting without using ATM SVCs and without using fair queueing, then you must use the ip rsvp flow-assist command to instruct RSVP to attach itself to Netflow.
| Command | Purpose |
|---|---|
show ip rsvp atm-peak-rate-limit [interface] | Display the current peak rate limit set for an interface, if any. |
show ip rsvp {precedence | tos} [interface] |
The following example configures two Cisco 7500 series routers that connect over an ATM core network through a PVC and multiple SVCs. As depicted in Figure 2, 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 Internetworking. It is used for transmission of best effort traffic and control traffic such as routing and RSVP messages. The ATM SVCs are established in response to reservation requests in order to service those requests.
The following portion of the example configures Router A in global configuration mode. It enables Cisco Express Forwarding (CEF) and the Netflow feature accelerate feature, both of 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 RouterA(config)# ip flow-cache feature-accelerate
The following segment of the configuration for Router A configures the ATM2/1/0 interface. The ip route-cache flow command enables Netflow on the interface. The interface must be configured with this command before RSVP-ATM QoS Interworking can be enabled. If you do not enter the ip route-cache flow command before the ip rsvp-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. Finally, 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.)
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 vbns-pvc 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 the Ethernet interface named Ethernet0/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 Router A's configuration 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 flow-cache feature-accelerate 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 vbns-pvc 0/51 inarp 5 broadcast !
Router B is configured similarly to Router A. In the following global configuration portion of the example, Router B is configured so that Cisco Express Forwarding (CEF) and the Netflow feature accelerate feature are enabled, both of which must be turned on before the RSVP-ATM QoS Interworking feature can be enabled.
RouterB# config terminal RouterB(config)# ip routing RouterB(config)# ip cef RouterB(config)# ip flow-cache feature-accelerate
The following segment of the configuration for Router B configures the interface named ATM3/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 vbns-pvc 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 Router B's configuration after the preceding commands were used to configure it:
RouterB# write term 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 flow-cache feature-accelerate 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 vbns-pvc 0/52 inarp 5 broadcast ! !
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references or the Cisco Express Forwarding feature documentation.
limit | The peak rate limit of the reservation specified in kilobytes. The minimum value allowed is 1 KB; the maximum value allowed is 2 GB. |
A reservation's peak rate defaults to the line rate.
Interface configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
Each RSVP reservation corresponds to an ATM SVC with a certain PCR, SCR, and maximum burst size. The PCR, also referred to as the peak rate, can be configured by the user or allowed to default to the line rate.
RSVP controlled-load reservations do not define any peak rate for the data. By convention, the allowable peak rate in such reservations is taken to be infinity, which is usually represented by a very large number. Under these circumstances, when a controlled-load reservation is converted to an ATM SVC, the PCR for the SVC becomes correspondingly large and may be out of range for the switch. You can use the ip rsvp atm-peak-rate-limit command to limit the peak rate.
The following conditions determine the limit on an RSVP SVC's peak rate:
You cannot enter this command nor is it available on interfaces and subinterfaces other than those of the PA-A3 ATM PA.
The peak rate limit is local to the router; it does not affect the normal messaging of RSVP. Only the SVC setup is affected. Large peak rates are transmitted to the next host without modification.
For RSVP SVCs established on subinterfaces, the peak rate limit applied to the subinterface takes effect on all SVCs created on that subinterface. If a peak rate limit is applied to the main interface, it has no effect on SVCs created on a subinterface of the main interface even if the limit value on the main interface is lower than the limiter applied to the subinterface.
For a given interface or subinterface, a peak rate limit applied to that interface affects only new SVCs created on the interface, not existing SVCs.
Use the show ip rsvp atm-peak-rate-limit command to determine the peak rate limit set for an interface or subinterface, if one is configured.
The following example sets the peak rate limit for interface atm2/0/0.1 to 100 KB:
RouterA# config terminal RouterA(config)# interface atm2/0/0.1 RouterA(config-if)# ip rsvp atm-peak-rate-limit 100
ip flow-cache feature accelerate
ip route-cache flow
ip rsvp svc-required
show ip rsvp atm-peak-rate-limit
show ip rsvp interface
This command has no arguments or keywords.
None. (RSVP does not use Netflow as a packet filtering mechanism.)
Interface configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
For RSVP to maintain token buckets and set IP Precedence on packets traversing the flow, it must interact with the underlying packet forwarding mechanism in order to obtain the information it needs. RSVP uses Netflow for this purpose.
If RSVP is used on non-ATM links and RSVP must set IP Precedence without relying on traffic policing, WFQ cannot be used. In this case, a method of attaching RSVP to the underlying forwarding mechanism is required. The ip rsvp flow-assist command satisfies this requirement. It allows RSVP to attach itself to Netflow so that it can use Netflow to obtain information about packets, which it can then use to update its token bucket and set IP Precedence. Netflow does not police packets or flows. For this reason, when RSVP is configured in this mode, it can only set IP Precedence and not otherwise police traffic.
In summary, you should use this command only when all of the following conditions exist:
When all of these conditions prevail, RSVP is completely detached from the data flow path and, thus, has no way to view packets. Use of this command enables RSVP to view packets so that it can mark them.
Use the show ip rsvp interface command to determine whether this command is in effect for an interface or subinterface.
The following example enables RSVP on the atm2/0/0 interface to attach itself to Netflow:
RouterA# config terminal RouterA(config)# interface atm2/0/0 RouterA(config-if)# ip rsvp flow-assist
show ip rsvp interface
conform precedence-value | Specifies an IP Precedence value in the range of 0 through 7 for traffic that conforms to the RSVP flowspec. The IP Precedence value is written to the three high-order bits (bits 5 through 7) of the ToS byte of a packet's IP header. Either conform or exceed is required; both arguments may be specified. When used with the no form of the command, this argument is optional. |
exceed precedence-value
| Specifies an IP Precedence value in the range of 0 through 7 for traffic that exceeds the RSVP flowspec. The IP Precedence value is written to the three high-order bits (bits 5 through 7) of the ToS byte of a packet's IP header. Either conform or exceed is required; both arguments may be specified. When used with the no form of the command, this argument is optional. |
The IP Precedence bits of the ToS byte are left unmodified when this command is not used. The default state is equivalent to execution of the no ip rsvp precedence command.
Interface configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
Packets in an RSVP reserved path are divided into two classes: those that conform to the reservation flowspec and those that correspond to a reservation but that exceed, or are outside, the reservation flowspec.
The ip rsvp precedence command allows you to set the IP Precedence values to be applied to packets belonging to these two classes. You must specify the IP Precedence value for at least one class of traffic when you use this command. You can use a single instance of the command to specify values for both classes, in which case you can specify the conform and exceed arguments in either order.
As part of its input processing, RSVP uses the ip rsvp precedence command configuration to set the IP Precedence bits on conforming and nonconforming packets. If per-VC DWRED is configured, it uses the IP Precedence and ToS bit settings on the output interface in its packet drop process. The IP Precedence setting of a packet can also be used by interfaces on downstream routers.
Execution of the ip rsvp precedence command causes IP Precedence values for all preexisting reservations on the interface to be modified.
RSVP must be enabled on an interface before you can use this command; that is, use of the ip rsvp bandwidth command must precede use of the ip rsvp precedence command.
RSVP receives packets from the underlying forwarding mechanism. Therefore, to use the ip rsvp precedence command to set IP Precedence, one of the following features is required:
The following example sets the IP Precedence value to 3 for all traffic on the ATM0 interface that conforms to the RSVP flowspec and to 2 for all traffic that exceeds the flowspec:
RouterA# config terminal RouterA(config)# interface atm0 RouterA(config-if)# ip rsvp precedence conform 3 exceed 2
The following example sets the IP Precedence value to 2 for all traffic on the ATM1 interface that conforms to the RSVP flowspec. The IP Precedence of those packets that exceed the flowspec is not altered in any way.
interface ATM1
ip rsvp precedence conform 2
ip rsvp bandwidth
ip rsvp precedence
ip rsvp tos
show ip rsvp precedence
show ip rsvp tos
This command has no arguments or keywords.
Disabled. This command applies exclusively to RSVP-ATM QoS Interworking.
Interface configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
Usually reservations are serviced when RSVP classifies packets and a queueing mechanism schedules them for transmission to manage congestion. Traditionally, RSVP is used with weighted fair queueing (WFQ). When RSVP is coupled with WFQ, all of the packets visible to WFQ are also visible to RSVP, which allows RSVP to identify and take action on packets important to it. In this case, WFQ provides bandwidth guarantees.
However, when the ip rsvp svc-required command is used to configure an interface or subinterface, a new SVC is established and used to service each new reservation on the interface. ATM SVCs are used to provide bandwidth guarantees and Netflow is used to make packets visible to RSVP.
This command must be executed on both ends of an SVC driven by RSVP. This command is supported only for the PA-A3 ATM PA and its subinterfaces.
Use the show ip rsvp interface command to determine whether this command is in effect for any interface or subinterface.
The following example signals RSVP that reservations made on the atm2/0/0 interface will be serviced by creation of an SVC:
RouterA# config terminal RouterA(config)# interface atm2/0/0 RouterA(config-if)# ip rsvp svc-required
ip flow-cache feature accelerate
ip route-cache flow
ip rsvp atm-peak-rate-limit
ip rsvp precedence
show ip rsvp interface
conform tos-value | Specifies a ToS value in the range of 0 through 31 for traffic that conforms to the RSVP flowspec. The ToS value is written to the five low-order bits (bits 0 through 4) of the ToS byte of a packet's IP header. Either conform or exceed is required; both arguments may be specified. When used with the no form of the command, this argument is optional. |
exceed tos-value
| Specifies a ToS value in the range of 0 through 31 for traffic that exceeds the RSVP flowspec. The ToS byte value is written to the five low-order bits (bits 0 through 4) of the ToS byte of a packet's IP header. Either conform or exceed is required; both arguments may be specified. When used with the no form of the command, this argument is optional. |
The ToS bits of the ToS byte are left unmodified when this command is not used. (The default behavior is equivalent to use of the no ip rsvp tos command.)
Interface configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
Packets in an RSVP reserved path are divided into two classes: those that conform to the reservation flowspec and those that correspond to a reservation but that exceed, or are outside, the reservation flowspec. The ip rsvp tos command allows you to set the ToS values to be applied to packets belonging to these two classes. You must specify the ToS value for at least one class of traffic when you use this command. You can use a single instance of the command to specify values for both classes, in which case you can specify the conform and exceed arguments in either order.
As part of its input processing, RSVP uses the ip rsvp tos command configuration to set the ToS bits of the ToS byte on conforming and nonconforming packets. If per-VC DWRED is configured, it uses the ToS bit and IP Precedence bit settings on the output interface in its packet drop process. The ToS bit and IP Precedence bit settings of a packet can also be used by interfaces on downstream routers.
Execution of this command causes ToS bit values for all preexisting reservations on the interface to be modified.
RSVP receives packets from the underlying forwarding mechanism. Therefore, to use the ip rsvp tos command to set the ToS bits, one of the following features is required:
The following example sets the ToS bits value to 4 for all traffic on the ATM1 interface that conforms to the RSVP flowspec. ToS bits on packets exceeding the flowspec are not altered:
RouterA# config terminal RouterA(config)# interface atm1 RouterA(config-if)# ip rsvp tos conform 4
ip rsvp bandwidth
ip rsvp flow-assist
ip rsvp precedence
show ip rsvp precedence
show ip rsvp tos
attach group-name | (Optional) The name of the DWRED group. |
Per-VC DWRED drop policy is not enabled.
Interface configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
WRED is a congestion avoidance mechanism that slows traffic by randomly dropping packets when there is congestion. WRED is only useful with protocols like TCP that respond to dropped packets by decreasing the transmission rate.
When this command is used to configure an interface-level DWRED group to include per-VC DWRED as a drop policy, the configured DWRED group parameters, including this one, are inherited under the following conditions:
When an interface-level DWRED group configuration is removed, per-VC DWRED parameters are removed from any VC that inherited them from the configured interface-level DWRED group.
When an interface-level DWRED group configuration is modified, per-VC DWRED parameters are modified accordingly if the per VC DWRED parameters were inherited from the configured interface-level DWRED group configuration.
If the DWRED group specified as the attach group-name value does not exist, the VC is configured with default DWRED arguments.
This command is only supported on interfaces that are capable of VC-level queueing. The only currently supported interface is the PA-A3 ATM PA.
To use DWRED, Distributed Cisco Express Forwarding (DCEF) switching must first be enabled on the interface. For more information on DCEF, refer to the Cisco IOS Switching Services Configuration Guide and the Cisco IOS Switching Services Command Reference.
The following part of the example creates a DWRED group called Paris.
RouterA# config terminal RouterA(config)# random-detect Paris RouterA(cfg-red-group)# precedence rsvp 1 1 10 RouterA(cfg-red-group)# precedence 1 1 2000 30 RouterA(cfg-red-group)# precedence 2 1 3000 40 RouterA(cfg-red-group)# precedence 3 1 4000 50 RouterA(cfg-red-group)# precedence 4 1 3000 60 RouterA(cfg-red-group)# precedence 5 1 3000 60 RouterA(cfg-red-group)# precedence 6 1 4000 60 RouterA(cfg-red-group)# precedence 7 1 4000 60 RouterA(cfg-red-group)# exit RouterA(config)# exit
The following part of the example configures per-VC DWRED as the drop policy on interface a2/1/0 with the group Paris created in the first part of the example:
Router(config)# int a2/1/0 Router(config-if)# random-detect attach Paris
The following show queueing command displays the current settings for each of the IP Precedences following configuration of per-VC DWRED:
router# show queueing
Current RED queue configuration:
Interface:ATM2/1/0 Exp-weight-constant:9
Class Min-th Max-th Mark-prob
0 20 40 1/10
1 22 40 1/10
2 24 40 1/10
3 26 40 1/10
4 28 40 1/10
5 31 40 1/10
6 33 40 1/10
7 35 40 1/10
rsvp 37 40 1/10
random-detect
random-detect-group
interface | (Optional) The name of the interface. |
EXEC
This command first appeared in Cisco IOS Release 12.0(3)T.
The show ip rsvp atm-peak-rate-limit command displays the configured peak rate using the following notations for brevity:
If no interface name is specified, configured peak rates for all RSVP-enabled interfaces are displayed.
This example depicts results of the show ip rsvp atm-peak-rate-limit command, presuming that the subinterface atm2/0/0.1 was configured with a reservation peak rate limit of 100 kilobytes using the ip rsvp atm-peak-rate-limit command.
The following is sample output from the show ip rsvp atm-peak-rate-limit command using the interface argument:
Router# show ip rsvp atm-peak-rate-limit atm2/0/0.1 RSVP: Peak rate limit for ATM2/0/0.1 is 100K bytes
The following samples show output from the show ip rsvp atm-peak-rate-limit command when no interface name is given:
Router# show ip rsvp atm-peak-rate-limit
Interface name Peak rate limit Ethernet0/1/1 not set ATM2/0/0 not set ATM2/0/0.1 100K Router# show ip rsvp atm-peak-rate-limit Interface name Peak rate limit Ethernet0/1 not set ATM2/1/0 1M ATM2/1/0.10 not set ATM2/1/0.11 not set ATM2/1/0.12 not set
ip rsvp atm-peak-rate-limit
To display RSVP-related interface information, use the show ip rsvp interface EXEC command.
show ip rsvp interface [interface-name interface-number]
interface-name | (Optional) The name of the interface. |
interface-number | (Optional) The number of the interface. |
EXEC
This command first appeared in Cisco IOS Release 11.2.
The primary purpose of this command is to determine the status of RSVP on an interface.
Use this command to determine if the ip rsvp svc-required command was used to configure an interface or subinterface to tell RSVP that reservations made on that interface are to be serviced by creation of an SVC.
Use this command to determine if the ip rsvp flow-assist command was used to configure an interface to enable RSVP to attach itself to Netflow.
Use this command to show the current allocation budget and maximum allocatable bandwidth.
The following sample output from the show ip rsvp interface command shows that for the AT2/0/0 interface RSVP has been informed that reservations made on that interface are to be serviced by creation of an SVC. It also shows that for the AT2/0/1 interface, RSVP is enabled to attach itself to Netflow.
Router# show ip rsvp interface
interface allocate i/f max flow max per/255 UDP IP UDP_IP UDP M/C AT2/0/0 OM 116640K 116640K 0 /255 0 0 0 0 SVC AT2/0/1 OM 116640K 116640K 0 /255 0 0 0 0 FLOW Et1/0 OM 7500K 7500K 0 /255 0 1 0 0
The following sample output from the show ip rsvp interface command shows that for the AT3/0/0 interface RSVP has been configured to establish an SVC to service any reservations made on the interface. RSVP-ATM QoS Interworking has not been enabled for Et0/2.
Router# show ip rsvp interface
interface allocate i/f max flow max per/255 UDP IP UDP_IP UDP M/C Et0/2 0M 7500K 7500K 0 /255 0 1 0 0 AT3/0/0 0M 112320K 112320K 0 /255 0 1 0 0 SVC
Table 2 describes significant fields shown in this display.
| Field | Description |
|---|---|
interface | Interface name. |
allocate | Current allocation budget. |
i/f max | Maximum allocatable bandwidth. |
flow max | Largest single flow allocatable on this interface. |
per /255 | Percent of bandwidth utilized. |
UDP | Number of neighbors sending UDP-encapsulated RSVP. |
IP | Number of neighbors sending IP-encapsulated RSVP. |
UDP_IP | Number of neighbors sending both UDP- and IP-encapsulated RSVP. |
UDP M/C | Is router configured for UDP on this interface? |
SVC | Use of an SVC to service each reservation. |
FLOW | RSVP is enabled to attach itself to Netflow. |
ip rsvp flow-assist
ip rsvp svc-required
To display the IP Precedence bit values and ToS bit values to be used to mark the ToS byte of the IP headers of all packets in an RSVP reserved path that conform to or exceed the RSVP flowspec for a given interface, use the show ip rsvp EXEC command.
show ip rsvp {precedence | tos} [interface]
precedence | Displays IP Precedence bit and ToS bit conform and exceed values for all interfaces on the router. Either argument---precedence or tos---yields the same results; that is, they are Either tos or precedence may be specified; one is required. |
tos | Displays IP Precedence bit and ToS bit conform and exceed values for all interfaces on the router. Either argument---precedence or tos---yields the same results. IP Precedence and ToS bit values for all interfaces with RSVP enabled are displayed in both cases. Either tos or precedence may be specified; one is required. |
interface | (Optional) The name of the interface. If this argument is omitted, IP Precedence and ToS bit values are displayed for all interfaces with RSVP enabled. |
EXEC
This command first appeared in Cisco IOS Release 12.0(3)T.
Use this command to show the current IP Precedence bit values set for traffic conforming to or exceeding the RSVP flowspec for an interface if the ip rsvp precedence command was used to configure values for any (PA-A3 ATM PA) interface on the router.
Use this command to show the current ToS bit values set for traffic conforming to or exceeding the RSVP flowspec for an interface if the ip rsvp tos command was used to configure values for any PA-A3 ATM PA interface on the router.
The ip rsvp tos and ip rsvp precedence commands are functionally equivalent. They both show the IP Precedence and ToS bit values for all interfaces with RSVP enabled.
To display these values for a given interface exclusively, specify the interface name. If the interface argument is omitted, IP Precedence and ToS bit values are displayed for all interfaces with RSVP enabled.
The following sample output shows that for the ATM0 interface, the IP Precedence bits are set to 3 for traffic that conforms to the RSVP flowspec and to 2 for traffic that exceeds the flowspec. It also shows that for the ATM2 interface, the ToS bits are set to 6 for traffic that conforms to the RSVP flowspec and to 5 for traffic that exceeds the flowspec.
Router# show ip rsvp precedence
Interface name Precedence Precedence TOS TOS
conform exceed conform exceed
ATM0 3 2 - -
Ethernet1 - - - -
ATM2 - - 6 5
Hssi0 - - - -
Loopback0 - - - -
The following sample output shows that for the ATM0 interface, the IP Precedence bits are set to 3 for traffic that conforms to the RSVP flowspec and to 2 for traffic that exceeds the flowspec.
Router# show ip rsvp tos ATM0
Interface name Precedence Precedence TOS TOS
conform exceed conform exceed
ATM0 3 2 - -
ip rsvp precedence
ip rsvp tos
Posted: Fri Nov 5 09:04:22 PST 1999
Copyright 1989-1999©Cisco Systems Inc.