Configuring RSVP

There are the two types of multicast flows:

• Distinct reservation--A flow that originates from exactly one sender.
• Shared reservation--A flow that originates from one or more senders.

RSVP describes these reservations as having certain algorithmic attributes.

An example of a distinct reservation is a video application in which each sender emits a distinct data stream that requires admission and management in a queue. Such a flow, therefore, requires a separate reservation per sender on each transmission facility it crosses (such as Ethernet, a High-Level Data Link Control (HDLC) line, a Frame Relay data-link connection identifier (DLCI), or an ATM virtual channel). RSVP refers to this distinct reservation as explicit and installs it using a fixed filter style of reservation.

Use of RSVP for unicast applications is generally a degenerate case of a distinct flow.

An example of a shared reservation is an audio application in which each sender emits a distinct data stream that requires admission and management in a queue. However, because of the nature of the application, a limited number of senders are sending data at any given time. Such a flow, therefore, does not require a separate reservation per sender. Instead, it uses a single reservation that can be applied to any sender within a set as needed.

RSVP installs a shared reservation using a Wild Card or Shared Explicit style of reservation, with the difference between the two determined by the scope of application (which is either wild or explicit):

• The Wild Card Filter reserves bandwidth and delay characteristics for any sender and is limited by the list of source addresses carried in the reservation message.
• The Shared Explicit style of reservation identifies the flows for specific network resources.

You must plan carefully to successfully configure and use RSVP on your network. At a minimum, RSVP must reflect your assessment of bandwidth needs on router interfaces. Consider the following questions as you plan for RSVP configuration:

• How much bandwidth should RSVP allow per end-user application flow? You must understand the "feeds and speeds" of your applications. By default, the amount reservable by a single flow can be the entire reservable bandwidth. You can, however, limit individual reservations to smaller amounts using the single flow bandwidth parameter. The reserved bandwidth value may not exceed the interface reservable amount, and no one flow may reserve more than the amount specified.
• How much bandwidth is available for RSVP? By default, 75 percent of the bandwidth available on an interface is reservable. If you are using a tunnel interface, RSVP can make a reservation for the tunnel whose bandwidth is the sum of the bandwidths reserved within the tunnel.
• How much bandwidth must be excluded from RSVP so that it can fairly provide the timely service required by low-volume data conversations? End-to-end controls for data traffic assume that all sessions will behave so as to avoid congestion dynamically. Real-time demands do not follow this behavior. Determine the bandwidth to set aside so bursty data traffic will not be deprived as a side effect of the RSVP QoS configuration.

Note	Before entering RSVP configuration commands, you must plan carefully.

You should be aware of RSVP implementation considerations as you design your reservation system. RSVP does not model all data links likely to be present on the internetwork. RSVP models an interface as having a queueing system that completely determines the mix of traffic on the interface; bandwidth or delay characteristics are deterministic only to the extent that this model holds. Unfortunately, data links are often imperfectly modeled this way. Use the following guidelines:

• Serial line interfaces--PPP; HDLC; Link Access Procedure, Balanced (LAPB); High-Speed Serial Interface (HSSI); and similar serial line interfaces are well modeled by RSVP. The device can, therefore, make guarantees on these interfaces. Nonbroadcast multiaccess (NBMA) interfaces are also most in need of reservations.
• Multiaccess LANs--These data links are not modeled well by RSVP interfaces because the LAN itself represents a queueing system that is not under the control of the device making the guarantees. The device guarantees which load it will offer, but cannot guarantee the competing loads or timings of loads that neighboring LAN systems will offer. The network administrator can use admission controls to control how much traffic is placed on the LAN. The network administrator, however, should focus on the use of admission in network design in order to use RSVP effectively.

The Subnetwork Bandwidth Manager (SBM) protocol is an enhancement to RSVP for LANs. One device on each segment is elected the Designated SBM (DSBM). The DSBM handles all reservations on the segment, which prevents multiple RSVP devices from granting reservations and overcommitting the shared LAN bandwidth. The DSBM can also inform hosts of how much traffic they are allowed to send without valid RSVP reservations.

• Public X.25 networks--It is not clear that rate or delay reservations can be usefully made on public X.25 networks.

You must use a specialized configuration on Frame Relay and ATM networks, as discussed in the next sections.

• Frame Relay Internetwork Considerations
  
• ATM Internetwork Considerations
  
• Flexible Bandwidth Considerations
  

The RSVP Ingress CAC feature extends the Cisco IOS RSVP IPv4 implementation to guarantee bandwidth resources not only on a given flow's outgoing interface, but also on the inbound interfaces.

The figure below presents a deployment scenario where the ingress CAC functionality is implemented. The headquarters and branch office of a company are connected over a non-RSVP Internet service provider (ISP) cloud. In this scenario, the ISP cloud can guarantee the required bandwidth without the need to run RSVP. Therefore, only the customer edge (CE) routers run RSVP, and not the provider edge (PE) routers.

IMAGE MISSING HERE; illos embedded not referenced

Consider a scenario where the CE-PE link used in the headquarters has a bandwidth of 10 Gb/s, whereas the CE-PE link used in the branch office has a bandwidth of 1 Gb/s. Some media traffic from the headquarters to the branch office requires a guaranteed bandwidth of 5 Gb/s. In the RSVP implementation presented in the figure above, the CE-PE link used in the headquarters can participate in the RSVP bandwidth reservation and, therefore can guarantee the required QoS for this 5 Gb/s flow. The CE-PE link used in the branch office is a bottleneck because it has only 1 Gb/s capacity. However, this does not get detected because RSVP CAC is performed only against the egress interface in the branch office (CE to the branch office). Hence, traffic of 5 Gb/s is admitted. This situation can be avoided if RSVP CAC functionality is extended to check the ingress interface bandwidth before admitting this traffic.

The benefits of the RSVP Ingress CAC feature are as follows:

• Extends the bandwidth reservation to perform CAC on inbound interfaces if ingress RSVP bandwidth pools have been configured on those interfaces.
• Extends the preemption logic whenever the ingress interface bandwidth changes (due to link bandwidth changes, ingress bandwidth pool changes, or due to changes in ingress policy), or if a new reservation request is received.
• Extends the RSVP policy to include ingress policy parameters.

This feature is supported over all RSVP-supported transport layers.

The ingress CAC functionality is not enabled by default. Use the ip rsvp bandwidth command to enable ingress CAC and to define an ingress RSVP bandwidth pool. The ingress CAC functionality is applicable to only those reservations that are established after the feature is enabled.

• Admission Control on the Intermediate RSVP-Aware Nodes
  
• Admission Control on IP Tunnel Interfaces
  
• RSVP Preemption
  

Dynamic Multipoint Virtual Private Network (DMVPN) allows users to scale large and small IPsec VPNs by combining GRE tunnels, IPsec encryption, and Next Hop Resolution Protocol (NHRP). For more information on DMVPN, refer to the DMVPN module.

The RSVP over DMVPN feature supports the following types of configuration:

• RSVP over manually configured GRE/multipoint generic routing encapsulation (mGRE) tunnels
• RSVP over manually configured GRE/mGRE tunnels in an IPsec protected mode
• RSVP over GRE/mGRE tunnels (IPsec protected and IPsec unprotected) in a DMVPN environment

The figure below shows a spoke-hub-spoke or phase 1 DMVPN mode. Two static spoke-to-hub tunnels called Tunnel0 have been established. Tunnel0 is presented as a GRE interface on spoke-A and spoke-B. On the hub, Tunnel0 is modeled as an mGRE interface.

IMAGE MISSING HERE; illos embedded not referenced

There are some differences in the way RSVP operates over tunnels and RSVP operates over a subinterface. If RSVP is configured on a subinterface, Cisco IOS software automatically applies RSVP configuration on the main interface as well. This is possible because the binding between the subinterface and the main interface is static. However, the association between a tunnel interface and a physical interface is dynamic. Therefore, when you configure RSVP over a tunnel, the same configuration cannot be directly applied to any physical interface because the tunnel-to-physical association can change. Hence, you must configure RSVP appropriately on the physical interface (main and/or subinterface) that a tunnel can egress over.

If a device such as an IP phone attached on the 192.168.1.0/24 network has to establish reservation for a call to another device, such as another IP phone, attached on the 192.168.2.0/24 network, spoke A sends out a PATH message directed towards spoke B over tunnel interface 0. The RESV message is intercepted by the hub and forwarded to spoke B. Spoke B responds with a RESV message, which is sent to the hub. The hub attempts to reserve bandwidth over the Tunnel0 mGRE interface and its associated physical interface. If the hub is able reserve the necessary bandwidth, a reservation is installed and the RESV message is forwarded to spoke A. Spoke A receives a RESV message on Tunnel0 and attempts to reserve bandwidth over the Tunnel0 GRE interface and its associated physical interface. If spoke A is successful in reserving the necessary bandwidth, a reservation is installed.

Note

RSVP Call Admission Control (CAC) is performed over the new physical interface when there is a change in the tunnel-to-physical interface association for a given session. This might potentially cause the once-established RSVP reservation to fail. In such a case, RSVP removes only the existing reservation. The data flow is determined by other specific applications, such as, Cisco Unified Communications Manager Express (Cisco UCME) in case of voice traffic.

During bandwidth admission control, Cisco IOS software must take into account the additional IP overhead introduced due to tunneling and a possible encryption over these tunnels. Default values are provided for the additional overhead based on the average size of an Internet packet. However, you can use the ip rsvp tunnel overhead-percent command to override these values.

The RSVP Transport for Medianet feature extends the RSVP functionality to act as a transport mechanism for the clients. This is achieved by adding three more parameters to the existing 5-tuple flow that is used to reserve a path from the sender to the receiver for data flow. The 5-tuple flow consists of the destination IP address, source IP address, IP protocol, destination port, and source port.

In this model, for every transport service requested by the clients, RSVP creates a transport protocol (TP) session. Each such transport service request is identified by the 8-tuple flow as shown in the table below:

The 8-tuple flow identifies RSVP TP sessions and maps them to the specific client transport service requests.

When a TP client requests a transport service from RSVP, RSVP creates a TP session specific to that transport service request, and uses it to transport any other messages being sent by the client for the service request. RSVP also maintains the state of this TP session by refreshing PATH messages periodically.

RSVP provides two types of transport mechanisms to the clients for the transport service requests:

• Path-based transport mechanism--In this mechanism, the initiator node transports a TP client's message (also referred to as TP-Client-Data) to the destination for a particular flow. RSVP creates TP session specific to the transport service request from the client and uses the PATH message to send the TP-Client-Data. It ensures that the TP-Client-Data is transported in the same path as the data flow for the corresponding 5-tuple. RSVP maintains the state of this transport session on all the intermediate nodes from the initiator to either the destination or to the node on which the TP session will be terminated.
• Transport notify-based transport mechanism--In this mechanism, TP-Client-Data from any node in the path of the flow is transported to any other node in the same path. RSVP uses the Transport-Notify message to send the TP-Client-Data.

In the path-based transport mechanism, RSVP PATH message is used to carry the TP-Client-Data along the path from the sender to the receiver. RSVP hands over the TP-Client-Data to the client stack on each of the RSVP-enabled hops where the client stack is running. The client can then perform one of the following tasks:

• Request RSVP to send out the TP-Client-Data that is modified or not modified further downstream towards the receiver. In this case, RSVP embeds the client's outgoing TP-Client-Data in the PATH message and forwards it towards the receiver.
• Terminate the TP-Client-Data if the client decides to close the transport session on a particular node. In this case, RSVP does not send any PATH message downstream.

In the transport notify-based transport mechanism, RSVP uses Transport-Notify message to send the client's message. In this case, the TP client can request RSVP to perform one of the following tasks:

• Request RSVP to send the TP-Client-Data for the 8-tuple flow to a target IP address. This request works even if the RSVP TP session does not exist for the corresponding 8-tuple flow.
• Request RSVP to send the TP-Client-Data to the previous upstream RSVP hop. This process assumes that an RSVP TP session exists for the corresponding 8-tuple flow. In this case, RSVP derives the previous RSVP-aware hop IP address from the Path State Block (PSB) for the 8-tuple flow and sends the Transport-Notify message to that IP address with TP-Client-Data embedded into it.

RSVP hands over the Transport-Notify message with the embedded transport object to the corresponding TP client running on the router. If the corresponding TP client does not exist on the router, and if there is an existing RSVP TP session for the 8-tuple flow in the RSVP Transport-Notify message, then RSVP further sends this message to the previous upstream RSVP-enabled router. This continues until RSVP is able to deliver this message to the TP client.

If the corresponding TP client does not exist on the router, and if there is no existing RSVP TP session for the 8-tuple flow, RSVP drops the message.

The NAT Aware RSVP feature enables the RSVP-Network Address Translation (NAT)-Application Layer Gateway (ALG) functionality. With the RSVP-NAT-ALG functionality enabled, when the RSVP messages pass through a NAT device, the IP addresses embedded in the RSVP payload get translated appropriately. You can use the show ip nat translations command to view the active NATs for RSVP messages.

The RSVP-NAT-ALG is present in both pre-routing and post-routing stages. When a packet is travelling from the local to global stage, only the RSVP-NAT-ALG on the post-routing stage will be effective and will perform the local to global address and port translations; where as, if the packet is travelling from the global to local stage, the RSVP-NAT-ALG present in the pre-routing stage will be effective and will perform the global-to-local address and port translations.

With RSVP enabled, the packets are considered after the pre-routing stage. If the packet is travelling from the local to global stage, it acts on the packet before the local to global translations are performed. However, if the packet is travelling from the global to local stage, it acts on the packet after the global to local translations are performed. Hence RSVP states are maintained based on the local addresses.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip rsvp bandwidth [interface-bandwidth[percent percent-bandwidth | [single-flow-bandwidth] [sub-pool bandwidth]]]

5.    end

1.    enable

2.    configure terminal

3.    interface type number

4.   Do one of the following:

5.   Do one of the following:

6.    end

1.    enable

2.    configure terminal

3.    interface type number

4.    ip rsvp policy local identity alias1 [alias2...alias4]

5.    maximum bandwidth [group | single] bandwidth

6.    maximum bandwidth ingress {group | single} bandwidth

7.    end

1.    enable

2.    configure terminal

3.    ip rsvp sender session-ip-address sender-ip-address [tcp | udp | ip-protocol] session-dport sender-sport previous-hop-ip-address previous-hop-interface bandwidth burst-size

4.    ip rsvp reservation session-ip-address sender-ip-address [tcp | udp | ip-protocol] session-dport sender-sport next-hop-ip-address next-hop-interface {ff | se | wf} {rate | load} bandwidth burst-size

5.    end

1.    enable

2.    configure terminal

3.    ip rsvp transport client client-id

4.    ip rsvp transport sender-host [tcp| udp] destination-address source-address ip-protocol dest-port source-port client-id init-id instance-id[vrf vrf-name] [data data-value]

5.    end

1.    enable

2.    configure terminal

3.    ip rsvp udp-multicasts [multicast-address]

4.    end

1.    enable

2.    configure terminal

3.    ip rsvp neighbor access-list-number

4.    end

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, perform the following task. This task is optional for the following reason: When the interface is configured with the ip rsvp svc-required command to use ATM switched virtual circuits (SVCs), RSVP automatically attaches itself to NetFlow to perform packet flow identification. However, if you want to perform IP Precedence-type of service (ToS) bit setting in every packet without using ATM SVCs, then you must use the ip rsvp flow-assist command to instruct RSVP to attach itself to NetFlow.

Note	If you use WFQ, then the ToS and IP Precedence bits will be set only on data packets that RSVP sees, due to congestion.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip rsvp flow-assist

5.    end

Note

To configure the IP Precedence and ToS values to be used to mark packets in an RSVP reserved path that either conform to or exceed the RSVP flow specification (flowspec), perform the following task.You must configure the ip rsvp flow-assist command if you want to set IP Precedence or ToS values in every packet and you are not using ATM SVCs; that is, you have not configured the ip rsvp svc-required command.

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 the source and destination addresses and port numbers of a packet 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 flowspec of the reservation. During this process, RSVP determines if the packet conforms to or exceeds the flowspec, and it sets the IP header IP Precedence and ToS bits of the packet accordingly. These IP Precedence and ToS bit settings are used by per-VC Distributed Weighted Random Early Detection (DWRED) on the output interface, and they can be used by interfaces on downstream routers.

The combination of scheduling performed by the Enhanced ATM port adapter (PA-A3) and the per-SVC DWRED drop policy ensures that any packet that matches a reservation but exceeds the flowspec (that is, it 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.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip rsvp precedence {conform| exceed} precedence-value

5.    ip rsvp tos {conform| exceed} tos-value

6.    end

1.    enable

2.    configure terminal

3.    interface tunnel number

4.    ip rsvp tunnel overhead-percent [overhead-percent]

5.    end

• Troubleshooting Tips
  

1.    enable

2.    configure terminal

3.    snmp-server enable traps rsvp

4.    end

1.    enable

2.    show ip rsvp interface [type number]

3.    show ip rsvp installed [type number]

4.    show ip rsvp neighbor [type number]

5.    show ip rsvp sender [type number]

6.    show ip rsvp request [type number]

7.    show ip rsvp reservation [type number]

8.    show ip rsvp ingress interface [detail] [type number]