PfR RSVP Control

The PfR RSVP Control feature introduces the ability to perform application-aware path selection for traffic that is controlled by Resource Reservation Protocol (RSVP). This feature allows RSVP flows to be learned by Performance Routing (PfR) and protocol Path messages to be redirected after the PfR master controller determines the best exit using PfR policies.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

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

PfR can monitor and control applications and prefixes that are configured or learned by observing traffic that is flowing on the network. The master controller (MC) is a centralized policy decision point at which policies are defined and applied to various traffic classes that traverse the border routers (BRs). The MC can be configured to learn and control traffic classes on the network. The MC makes exit selections and instructs the BRs to enforce the exit selection. While the current PfR implementation can be used to optimize voice/video traffic, the control exercised by PfR is not aware of technologies such as RSVP. The PfR RSVP integration will help RSVP leverage the application-specific control of routes that PfR can provide.

RSVP is a standards-based control protocol that allows for resources to be reserved to allow for better reliability for voice/video traffic. RSVP achieves this by signaling the traffic profile before the actual data flow to reserve resources for the data flow. Establishing end-to-end resource reservations along a media path allows RSVP to guarantee that resources are available when they are needed. RSVP consults the forwarding plane database (or CEF) in order to achieve path congruency with the media flow. The routes in the CEF database are mostly dictated by the routing protocols where the only metric for determining the best route is the cumulative cost of the links on that path.

In the diagram shown below, there are two paths for the network on the left to reach the campus network on the right. One path uses the DMVPN cloud, and the other path uses the MPLS-VPN cloud. Depending on the speed and bandwidth required, it might make sense to route video applications over the MPLS-VPN network while routing voice applications over the DMVPN network. Such kind of application-aware path selection is not possible in CEF, but PfR can determine the best path for specific application traffic based on performance criteria.

Figure 1. Application-Aware Path Selection

With the RSVP integration, PfR will learn, monitor, and optimize RSVP flows. RSVP is included as a new learn source. PfR will learn RSVP flows that traverse internal and external interfaces. Each RSVP flow is learned as a PfR traffic class and is controlled independently of the other RSVP flows. While filtering of the learned flows is supported with prefix lists and route maps, aggregating RSVP flows is not advised. The PfR master controller (MC) chooses a best exit based on the configured PfR policies and installs route maps to redirect traffic. If any of the RSVP flows enters an Out-of-Policy (OOP) condition, PfR will find and switch the RSVP flow to a new exit. RSVP will reinstall the reservation on the new path at the time of refresh (usually within a span of 30 seconds) or as a Fast Local Repair (FLR) case in less than 5 seconds.

The intent of the PfR RSVP Control feature is to identify and install route maps at the time the router receives an RSVP Path message. The route map captures the data traffic, while RSVP uses this path for the Path message.

RSVP flows are learned as PfR traffic classes defined as a single application flow that can be identified by the source address, source port, destination address, destination port and IP protocol. This microflow is optimized as an application by PfR, and a dynamic policy route is created by PfR to forward this traffic class over the selected exit.

All RSVP flows are optimized only after PfR checks that there is enough bandwidth on the exit that is being considered. This information is pushed periodically from the BRs to the MC. On the BR itself, RSVP notifies PfR every time the bandwidth pool on an interface changes.

Equivalent-Path Round-Robin Resolver

PfR introduced a new resolver with the PfR RSVP Control feature. PfR, by default, uses a random resolver to decide between equivalent paths, exits with the same cost determined by the PfR policies. When the round-robin resolver is configured using the
equivalent-path-round-robin command, the next exit (next-hop interface) is selected and compared to the running PfR policy. The round-robin resolver is handed an array of equivalent exits from which it chooses in a round-robin fashion. Exits are pruned in the same fashion they are today by each resolver. If the exit matches the policy, the exit becomes the best exit. The round-robin resolver does not do any specific RSVP checking. To return to using the random resolver, enter the no form of the
equivalent-path-round-robin command.

Any PfR traffiic class can use the round-robin resolver, and it provides a load-balancing scheme for multiple equivalent paths as determined by PfR policy.

RSVP Post Dial Delay Timer for Best Path Selection

In the PfR RSVP Control feature, the
rsvp post-dial-delay command was introduced to set a value for the RSVP post dial delay timer that runs on the border routers when RSVP flow learning is enabled on a PfR master controller. The timer is updated on the border routers at the start of every PfR learn cycle, and the timer determines the delay, in milliseconds, before the routing path is returned to RSVP. When the PfR and RSVP integration is enabled, PfR tries to locate a best path for any RSVP flows that are learned before the delay timer expires. If the current path is not the best path, PfR attempts to install the new path. RSVP reacts to this policy route injection as a case of Fast Local Repair (FLR) and resignals a new reservation path.

RSVP Signaling Retries for Alternative Reservation Path

The PfR RSVP Control feature introduced a new command,
rsvp signaling-retries, which is configured on a master controller and is used to instruct PfR to provide an alternate reservation path when an RSVP reservation returns an error condition. If an alternate path is provided by PfR, RSVP can resend the reservation signal. The default number of retries is set to 0; no signaling retries are to be permitted, and a reservation error message is sent when a reservation failure occurs.

Performance Statistics from PfR Commands

The PfR master controller learns and monitors IP traffic that flows through the border routers, and the master controller selects the best exit for a traffic flow based on configured policies and the performance information received from the border routers. To view some of the performance data collected by the master controller, you can use the following commands:

show pfr master active-probes

show pfr master border

show pfr master exits

show pfr master statistics

show pfr master traffic-class

show pfr master traffic-class performance

All these commands are entered at the master controller, and some of the commands have keywords and arguments to filter the output. For detailed information about these commands, see the
Cisco IOS Performance Routing Command Reference.

How to Configure PfR RSVP Control

Configuring PfR RSVP Control Using a Learn List

Perform this task on the master controller to define a learn list that contains traffic classes that are automatically learned based on RSVP flows and filtered by a prefix list. In this task, the goal is to optimize all video traffic that is learned from RSVP flows.

The VIDEO traffic class is defined as any prefix that matches 10.100.0.0/16 or 10.200.0.0/16 and a PfR policy, named POLICY_RSVP_VIDEO, is created.

The learn lists are referenced in a PfR policy using a PfR map and are activated using the
policy-rules (PfR) command.

Displaying PfR RSVP Control Information

Although the PfR RSVP Control feature is configured on a master controller, the border routers actually collect the performance information, and there are
show and
debug commands available to display the RSVP information for both the master controller and border routers. The first few commands in this task are entered on a master controller and, for the rest of the commands, there is a step to move to a border router through which the application traffic is flowing. These
show and
debug commands can be entered in any order.

This command is used to display policy information. The following example uses the
dynamic keyword to display the policies dynamically created by provider applications. Note the RSVP configuration commands.

This command is
used to display information about traffic classes that are monitored and
controlled by a PfR master controller. In this example, the
state in
keywords are used to filter the output to show only traffic classes that are in
an in-policy state.

Use this
command to display information about the exits used for PfR traffic classes,
including the IP address, nickname of the PfR managed external interface, the
exit policy, interface of the border router, and exit performance data. The
example below shows RSVP pool information.

Configuration Examples for PfR RSVP Control

Example Defining Traffic Classes Using RSVP Flows

The following example, configured on the master controller, defines a learn list that will contain traffic classes that are automatically learned based on RSVP flows and filtered by a prefix list. In this example, the goal is to optimize all video traffic using the policy named POLICY_RSVP_VIDEO. The RSVP_VIDEO traffic class is defined as any prefix that matches 10.100.0.0/16 or 10.200.0.0/16 and is learned from RSVP flows.

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Feature Information for PfR RSVP Control

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

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

Table 1 Feature Information for PfR RSVP Control

Feature Name

Releases

Feature Information

PfR RSVP Control

Cisco IOS XE Release 3.4S

The PfR RSVP Control feature provides support for optimizing RSVP flows using application-aware PfR techniques.