- Signalling Overview
- Configuring RSVP
- Control Plane DSCP Support for RSVP
- Configuring RSVP Support for Frame Relay
- RSVP Scalability Enhancements
- RSVP Support for ATM/PVCs
- RSVP Local Policy Support
- RSVP Refresh Reduction and Reliable Messaging
- RSVP Support for RTP Header Compression, Phase 1
- RSVP Message Authentication
- RSVP---Previous Hop Overwrite
- RSVP Application ID Support
- RSVP Fast Local Repair
- RSVP Interface-Based Receiver Proxy
- RSVP--VRF Lite Admission Control
- Configuring RSVP Support for LLQ
- Configuring RSVP-ATM QoS Interworking
- Configuring COPS for RSVP
- RSVP Aggregation
- MPLS TE---Tunnel-Based Admission Control (TBAC)
- Configuring Subnetwork Bandwidth Manager
- Contents
- Prerequisites for RSVP Application ID Support
- Restrictions for RSVP Application ID Support
- Information About RSVP Application ID Support
- How to Configure RSVP Application ID Support
- Configuration Examples for RSVP Application ID Support
RSVP Application ID Support
The RSVP Application ID Support feature introduces application-specific reservations, which enhance the granularity for local policy match criteria so that you can manage quality of service (QoS) on the basis of application type.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported use the "Feature Information for RSVP Application ID Support" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
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.
Contents
•
Prerequisites for RSVP Application ID Support
•
Restrictions for RSVP Application ID Support
•
Information About RSVP Application ID Support
•
How to Configure RSVP Application ID Support
•
Configuration Examples for RSVP Application ID Support
•
Feature Information for RSVP Application ID Support
Prerequisites for RSVP Application ID Support
You must configure RSVP on one or more interfaces on at least two neighboring routers that share a link within the network.
Restrictions for RSVP Application ID Support
•
RSVP policies apply only to PATH, RESV, PATHERROR, and RESVERROR messages.
•
Merging of global and interface-based local policies is not supported; therefore, you cannot match on multiple policies.
Information About RSVP Application ID Support
To use the RSVP Application IP Support feature, you should understand the following concepts:
•
Feature Overview of RSVP Application ID Support
•
Benefits of RSVP Application ID Support
Feature Overview of RSVP Application ID Support
This section provides the following information:
•
Global and Per-Interface RSVP Policies
•
How RSVP Policies Are Applied
How RSVP Functions
Multiple applications such as voice and video need RSVP support. RSVP admits requests until the bandwidth limit is reached. RSVP does not differentiate between the requests and is not aware of the type of application for which the bandwidth is requested.
As a result, RSVP can exhaust the allowed bandwidth by admitting requests that represent just one type of application, causing all subsequent requests to be rejected because of unavailable bandwidth. For example, a few video calls could prevent all or most of the voice calls from being admitted because the video calls require a large amount of bandwidth and not enough bandwidth remains to accommodate the voice calls. With this limitation, you would probably not deploy RSVP for multiple applications especially if voice happens to be one of the applications for which RSVP is required.
The solution is to allow configuration of separate bandwidth limits for individual applications or classes of traffic. Limiting bandwidth per application requires configuring a bandwidth limit per application and having each reservation flag the application to which the reservation belongs so that it can be admitted against the appropriate bandwidth limit.
Application and Sub Application Identity Policy Element for Use with RSVP (IETF RFC 2872) allows for creation of separate bandwidth reservation pools. For example, an RSVP reservation pool can be created for voice traffic, and a separate RSVP reservation pool can be created for video traffic. This prevents video traffic from overwhelming voice traffic.
Note
Before this feature, you could create access control lists (ACLs) that match on the differentiated services code points (DSCPs) of the IP header in an RSVP message. However, multiple applications could use the same DSCP; therefore, you could not uniquely identify applications in order to define separate policies for them.
Sample Solution
Figure 1 shows a sample solution in which application ID is used. In this example, bandwidth is allocated between the voice and video sessions that are being created by Cisco CallManager (CCM). Video requires much more bandwidth than voice, and if you do not separate the reservations, the video traffic could overwhelm the voice traffic.
CCM has been enhanced to use the RSVP Application ID Support feature. In this example, when CCM makes the RSVP reservation, CCM has the ability to specify whether the reservation should be made against a video RSVP bandwidth pool or a voice RSVP bandwidth pool. If there is not enough bandwidth remaining in the requested pool, even though there is enough bandwidth in the total RSVP allocation, RSVP signals CCM that there is a problem with the reservation. Figure 1 shows some of the signaling and data traffic that is sent during the session setup.
Figure 1 Sample Solution Using RSVP Application ID Support
In this scenario, the IP phones and IP video devices do not directly support RSVP. In order to allow RSVP to reserve the bandwidth for these devices, the RSVP agent component in the Cisco IOS router creates the reservation. During the setup of the voice or video session, CCM communicates with the RSVP agent and sends the parameters to reserve the necessary bandwidth.
When you want to make a voice or video call, the device signals CCM. CCM signals the RSVP agent, specifying the RSVP application ID that corresponds to the type of call, which is voice or video in this example. The RSVP agents establish the RSVP reservation across the network and tell CCM that the reservation has been made. CCM then completes the session establishment, and the Real-Time Transport Protocol (RTP) traffic streams flow between the phones (or video devices). If the RSVP agents are unable to create the bandwidth reservations for the requested application ID, they communicate that information back to CCM, which signals this information back to you.
Global and Per-Interface RSVP Policies
You can configure RSVP policies globally and on a per-interface basis. You can also configure multiple global policies and multiple policies per interface.
Global RSVP policies restrict how much RSVP bandwidth a router uses regardless of the number of interfaces. You should configure a global policy if your router has CPU restrictions, one interface, or multiple interfaces that do not require different bandwidth limits.
Per-interface RSVP policies allow you to configure separate bandwidth pools with varying limits so that no one application, such as video, can consume all the RSVP bandwidth on a specified interface at the expense of other applications, such as voice, which would be dropped. You should configure a per-interface policy when you need greater control of the available bandwidth.
How RSVP Policies Are Applied
RSVP searches for policies whenever an RSVP message is processed. The policy tells RSVP if any special handling is required for that message.
If your network configuration has global and per-interface RSVP policies, the per-interface policies are applied first meaning that RSVP looks for policy-match criteria in the order in which the policies were configured. RSVP searches for policy-match criteria in the following order:
•
Nondefault interface policies
•
Default interface policy
•
Nondefault global policies
•
Global default policy
If RSVP finds no policy-match criteria, it accepts all incoming messages. To change this decision from accept to reject, issue the ip rsvp policy default-reject command.
Preemption
Preemption happens when one reservation receives priority over another because there is insufficient bandwidth in an RSVP pool. There are two types of RSVP bandwidth pools: local policy pools and interface pools. Local policies can be global or interface-specific. RSVP performs admission control against these pools when a RESV message arrives.
If an incoming reservation request matches an RSVP local policy that has an RSVP bandwidth limit (as configured with the maximum bandwidth group submode command) and that limit has been reached, RSVP tries to preempt other lower-priority reservations admitted by that policy. When there are too few of these lower-priority reservations, RSVP rejects the incoming reservation request. Then RSVP looks at the interface bandwidth pool that you configured by using the ip rsvp bandwidth command. If that bandwidth limit has been reached, RSVP tries to preempt other lower-priority reservations on that interface to accommodate the new reservation request. At this point, RSVP does not consider which local policies admitted the reservations. When not enough bandwidth on that interface pool can be preempted, RSVP rejects the new reservation even though the new reservation was able to obtain bandwidth from the local policy pool.
Preemption can also happen when you manually reconfigure an RSVP bandwidth pool of any type to a lower value such that the existing reservations using that pool no longer fit in the pool.
How Preemption Priorities Are Assigned and Signaled
If a received RSVP PATH or RESV message contains preemption priorities (signaled with an IETF RFC 3181 preemption priority policy element inside an IETF RFC 2750 POLICY_DATA object) and the priorities are higher than those contained in the matching local policy (if any), the offending message is rejected and a PATHERROR or RESVERROR message is sent in response. If the priorities are approved by the local policy, they are stored with the RSVP state in the router and forwarded to its neighbors.
If a received RSVP PATH or RESV message does not contain preemption priorities (as previously described) and you issued a global ip rsvp policy preempt command, and the message matches a local policy that contains a preempt-priority command, a POLICY_DATA object with a preemption priority element that contains the local policy's priorities is added to the message as part of the policy decision. These priorities are then stored with the RSVP state in the router and forwarded to neighbors.
Controling Preemption
The ip rsvp policy preempt command controls whether or not a router preempts any reservations when required. When you issue this command, a RESV message that subsequently arrives on an interface can preempt the bandwidth of one or more reservations on that interface if the assigned setup priority of the new reservation is higher than the assigned hold priorities of the installed reservations.
Benefits of RSVP Application ID Support
The RSVP Application ID Support feature provides the following benefits:
•
Allows RSVP to identify applications uniquely and to separate bandwidth pools to be created for different applications so that one application cannot consume all the available bandwidth, thereby forcing others to be dropped.
•
Integrates with the RSVP agent and CCM to provide a solution for call admission control (CAC) and QoS for Voice over IP (VoIP) and video conferencing applications in networks with multitiered, meshed topologies using signaling protocols such as SCCP to ensure that a single application does not overwhelm the available reserved bandwidth.
•
Functions with any endpoint that complies with RFC 2872 or RFC 2205.
How to Configure RSVP Application ID Support
You can configure application IDs and local policies to use with RSVP-aware software programs such as CCM or to use with non-RSVP-aware applications such as static PATH and RESV messages.
This section contains the following procedures:
•
Configuring RSVP Application IDs and Local Policies for RSVP-Aware Software Programs (optional)
•
Configuring RSVP Application IDs with Static Senders and Receivers for Non-RSVP-Aware Software Programs (optional)
•
Verifying the RSVP Application ID Support Configuration (optional)
Configuring RSVP Application IDs and Local Policies for RSVP-Aware Software Programs
This section contains the following procedures:
•
Configuring an Application ID (required)
Note
The following two local policy configuration procedures are optional; however, you must choose one or both.
•
Configuring a Local Policy Globally (optional)
•
Configuring a Local Policy on an Interface (optional)
Configuring an Application ID
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip rsvp policy identity alias policy-locator locator
4.
Repeat Step 3 as needed to configure additional application IDs.
5.
end
DETAILED STEPS
|
|
|
|
|---|---|---|
Step 1 |
enable Router> enable |
Enables privileged EXEC mode. • |
Step 2 |
configure terminal Router# configure terminal |
Enters global configuration mode. |
Step 3 |
ip rsvp policy identity alias policy-locator
locator
Router(config)# ip rsvp policy identity rsvp-voice policy-locator APP=Voice |
Defines RSVP application IDs to use as match criteria for local policies. • Note • |
Step 4 |
Repeat Step 3 as needed to configure additional application IDs. |
Defines additional application IDs. |
Step 5 |
end Router(config)# end |
Exits global configuration mode and returns to privileged EXEC mode. |
What to Do Next
Configure a local policy globally, on an interface, or both.
Configuring a Local Policy Globally
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip rsvp policy local {acl acl1 [acl2...acl8] | default | identity alias1 [alias2...alias4] | origin-as as1 [as2...as8]}
4.
Repeat Step 3 as needed to configure additional local policies.
5.
{accept | forward [all | path | path-error | resv | resv-error] | default | exit | fast-reroute | local-override | maximum [bandwidth [group x] [single y] | senders n] | preempt-priority [traffic-eng x] setup-priority [hold-priority]}
6.
Repeat Step 5 as needed to configure additional submode commands.
7.
end
DETAILED STEPS
Configuring a Local Policy on an Interface
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type number
4.
Repeat Step 3 as needed to configure additional interfaces.
5.
ip rsvp bandwidth [interface-kbps] [single-flow-kbps]
6.
Repeat Step 5 as needed to configure bandwidth for additional interfaces.
7.
ip rsvp policy local {acl acl1 [acl2...acl8] | default | identity alias1 [alias2...alias4] | origin-as as1 [as2...as8]}
8.
Repeat Step 7 as needed to configure additional local policies.
9.
{accept | forward [all | path | path-error | resv | resv-error] | default | exit | fast-reroute | local-override | maximum [bandwidth [group x] [single y] | senders n] | preempt-priority [traffic-eng x] setup-priority [hold-priority]}
10.
Repeat Step 9 as needed to configure additional submode commands.
11.
end
DETAILED STEPS
Configuring RSVP Application IDs with Static Senders and Receivers for Non-RSVP-Aware Software Programs
•
Configuring an Application ID (required)
•
Configuring a Static Sender with an Application ID (optional)
•
Configuring a Static Receiver with an Application ID (optional)
Configuring an Application ID
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip rsvp policy identity alias policy-locator locator
4.
Repeat step 3 to configure additional application IDs.
5.
end
DETAILED STEPS
Configuring a Static Sender with an Application ID
Perform this task to configure a static RSVP sender with an application ID to make the router proxy an RSVP PATH message containing an application ID on behalf of an RSVP-unaware sender application.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip rsvp sender-host session-ip-address sender-ip-address {tcp | udp | ip-protocol} session-d-port sender-s-port bandwidth burst-size [identity alias]
4.
end
DETAILED STEPS
Configuring a Static Receiver with an Application ID
Perform this task to configure a static RSVP receiver with an application ID to make the router proxy an RSVP RESV message containing an application ID on behalf of an RSVP-unaware receiver application.
Note
You can also configure a static listener to use with an application ID. If an incoming PATH message contains an application ID and/or a preemption priority value, the listener includes them in the RESV message sent in reply. See the "Feature Information for RSVP Application ID Support" section for more information.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip rsvp reservation-host session-ip-address sender-ip-address {tcp | udp | ip-protocol} session-d-port sender-s-port {ff | se | wf} {rate | load} bandwidth burst-size [identity alias]
or
ip rsvp reservation session-ip-address sender-ip-address {tcp | udp | ip-protocol} session-d-port sender-s-port next-hop-ip-address next-hop-interface {ff | se | wf} {rate | load} bandwidth burst-size [identity alias]
Note
Use the ip rsvp reservation-host command if the router is the destination or the ip rsvp reservation command to have the router proxy on behalf of a downstream host.
4.
end
DETAILED STEPS
Verifying the RSVP Application ID Support Configuration
SUMMARY STEPS
1.
enable
Note
You can use the following commands in user EXEC or privileged EXEC mode.
2.
show ip rsvp host {senders | receivers} [group-name | group-address]
3.
show ip rsvp policy identity [regular-expression]
4.
show ip rsvp policy local [detail] [interface name] [default | acl acl | origin-as as | identity alias]
5.
show ip rsvp reservation [detail] [filter [destination ip-addr | hostname] [source ip-addr | hostname] [dst-port port] [src-port port]]
6.
show ip rsvp sender [detail] [filter [destination ip-addr | hostname] [source ip-addr | hostname] [dst-port port] [src-port port]]
7.
end
DETAILED STEPS
|
|
|
|
|---|---|---|
Step 1 |
enable Router> enable |
(Optional) Enables privileged EXEC mode. • Note |
Step 2 |
show ip rsvp host {senders | receivers}
[group-name | group-address]
Router# show ip rsvp host senders |
Displays specific information for an RSVP host. Note |
Step 3 |
show ip rsvp policy identity [regular-expression] Router# show ip rsvp policy identity voice100 |
Displays selected RSVP identities in a router configuration. • Note |
Step 4 |
show ip rsvp policy local [detail] [interface name] [default | acl acl | origin-as as | identity alias] Router# show ip rsvp policy local identity voice100 |
Displays the local policies currently configured. • |
Step 5 |
show ip rsvp reservation [detail] [filter [destination ip-addr | hostname] [source ip-addr | hostname] [dst-port port] [src-port port]] Router# show ip rsvp reservation detail |
Displays RSVP-related receiver information currently in the database. • Note |
Step 6 |
show ip rsvp sender [detail] [filter [destination ip-addr | hostname] [source ip-addr | hostname] [dst-port port] [src-port port]] Router# show ip rsvp sender detail |
Displays RSVP PATH-related sender information currently in the database. • Note |
Step 7 |
exit Router# exit |
Exits privileged EXEC mode and returns to user EXEC mode. |
Configuration Examples for RSVP Application ID Support
•
Example: Configuring RSVP Application ID Support
•
Example: Verifying RSVP Application ID Support
Example: Configuring RSVP Application ID Support
The four-router network in Figure 2 contains the following configurations:
•
Configuring a Proxy Receiver on R4
•
Configuring an Application ID and a Global Local Policy on R3
•
Configuring an Application ID and Separate Bandwidth Pools on R2 for Per-Interface Local Policies
•
Configuring an Application ID and a Static Reservation from R1 to R4
Figure 2 Sample Network with Application Identities and Local Policies
Configuring a Proxy Receiver on R4
The following example configures R4 with a proxy receiver to create an RESV message to match the PATH message for the destination 10.0.0.7:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip rsvp listener 10.0.0.7 any any reply
Router(config)# end
Configuring an Application ID and a Global Local Policy on R3
The following example configures R3 with an application ID called video and a global local policy in which all RSVP messages are being accepted and forwarded:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip rsvp policy identity video policy-locator video
Router(config)# ip rsvp policy local identity video
Router(config-rsvp-policy-local)# forward all
Router(config-rsvp-policy-local)# end
Configuring an Application ID and Separate Bandwidth Pools on R2 for Per-Interface Local Policies
The following example configures R2 with an application ID called video, which is a wildcard regular expression to match any application ID that contains the substring video:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip rsvp policy identity video policy-locator .*Video.*
Router(config-rsvp-id)# end
The following example configures R2 with a local policy on ingress Ethernet interface 0/0:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface Ethernet0/0
Router(config-if)# ip address 10.0.0.2 255.0.0.0
Router(config-if)# no cdp enable
Router(config-if)# ip rsvp bandwidth 200
Router(config-if)# ip rsvp policy local identity video
Router(config-rsvp-policy-local)# maximum senders 10
Router(config-rsvp-policy-local)# maximum bandwidth group 100
Router(config-rsvp-policy-local)# maximum bandwidth single 10
Router(config-rsvp-policy-local)# forward all
Router(config-rsvp-policy-local)# end
The following example configures R2 with a local policy on egress Ethernet interface 3/0:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface Ethernet3/0
Router(config-if)# ip address 10.0.0.3 255.0.0.0
Router(config-if)# no cdp enable
Router(config-if)# ip rsvp bandwidth 200
Router(config-if)# ip rsvp policy local identity video
Router(config-rsvp-policy-local)# maximum senders 10
Router(config-rsvp-policy-local)# maximum bandwidth group 100
Router(config-rsvp-policy-local)# maximum bandwidth single 10
Router(config-rsvp-policy-local)# forward all
Router(config-rsvp-policy-local)# end
Note
PATH messages arrive on ingress Ethernet interface 0/0 and RESV messages arrive on egress Ethernet interface 3/0.
Configuring an Application ID and a Static Reservation from R1 to R4
The following example configures R1 with an application ID called video and initiates a host generating a PATH message with that application ID:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip rsvp policy identity video policy-locator "GUID=www.cisco.com, APP=Video, VER=1.0"
Router(config)# ip rsvp sender-host 10.0.0.7 10.0.0.1 udp 1 1 10 10 identity video
Router(config)# end
Example: Verifying RSVP Application ID Support
This section contains the following verification examples:
•
Verifying the Application ID and the Global Local Policy on R3
•
Verifying the Application ID and the Per-Interface Local Policies on R2
•
Verifying the Application ID and the Reservation on R1
Verifying the Application ID and the Global Local Policy on R3
The following example verifies that a global local policy has been configured on R3 with an application ID called Video:
Router# show ip rsvp policy local detail
Global:
Policy for ID(s): Video
Preemption Scope: Unrestricted.
Local Override: Disabled.
Fast ReRoute: Accept.
Handle: 23000404.
Accept Forward
Path: Yes Yes
Resv: Yes Yes
PathError: Yes Yes
ResvError: Yes Yes
Setup Priority Hold Priority
TE: N/A N/A
Non-TE: N/A N/A
Current Limit
Senders: 1 N/A
Receivers: 1 N/A
Conversations: 1 N/A
Group bandwidth (bps): 10K N/A
Per-flow b/w (bps): N/A N/A
Generic policy settings:
Default policy: Accept all
Preemption: Disabled
Verifying the Application ID and the Per-Interface Local Policies on R2
The following example verifies that an application ID called Video has been created on R2:
Router# show ip rsvp policy identity
Alias: Video
Type: Application ID
Locator: .*Video.*
The following example verifies that per-interface local policies have been created on Ethernet interface 0/0 and Ethernet interface 3/0 on R2:
Router# show ip rsvp policy local detail
Ethernet0/0:
Policy for ID(s): Video
Preemption Scope: Unrestricted.
Local Override: Disabled.
Fast ReRoute: Accept.
Handle: 26000404.
Accept Forward
Path: Yes Yes
Resv: Yes Yes
PathError: Yes Yes
ResvError: Yes Yes
Setup Priority Hold Priority
TE: N/A N/A
Non-TE: N/A N/A
Current Limit
Senders: 1 10
Receivers: 0 N/A
Conversations: 0 N/A
Group bandwidth (bps): 0 100K
Per-flow b/w (bps): N/A 10K
Ethernet3/0:
Policy for ID(s): Video
Preemption Scope: Unrestricted.
Local Override: Disabled.
Fast ReRoute: Accept.
Handle: 5A00040A.
Accept Forward
Path: Yes Yes
Resv: Yes Yes
PathError: Yes Yes
ResvError: Yes Yes
Setup Priority Hold Priority
TE: N/A N/A
Non-TE: N/A N/A
Current Limit
Senders: 0 10
Receivers: 1 N/A
Conversations: 1 N/A
Group bandwidth (bps): 10K 100K
Per-flow b/w (bps): N/A 10K
Generic policy settings:
Default policy: Accept all
Preemption: Disabled
Note
Notice in the above display that the ingress interface has only its senders counter incremented because the PATH message is checked there. However, the egress interface has its receivers, conversations, and group bandwidth counters incremented because the reservation is checked on the incoming interface, which is the egress interface on R2.
Verifying the Application ID and the Reservation on R1
The following example verifies that a PATH message containing the application ID called Video has been created on R1:
Router# show ip rsvp sender detail
PATH Session address: 10.0.0.7, port: 1. Protocol: UDP
Sender address: 10.0.0.1, port: 1
Inbound from: 10.0.0.1 on interface:
Traffic params - Rate: 10K bits/sec, Max. burst: 10K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytes
Path ID handle: 02000402.
Incoming policy: Accepted. Policy source(s): Default
Application ID: 'GUID=www.cisco.com, APP=Video, VER=1.0'
Status: Proxied
Output on Ethernet0/0. Policy status: Forwarding. Handle: 01000403
Policy source(s): Default
Note
You can issue the debug ip rsvp dump path and the debug ip rsvp dump resv commands to get more information about a sender and the application ID that it is using.
The following example verifies that a reservation with the application ID called Video has been created on R1:
Router# show ip rsvp reservation detail
RSVP Reservation. Destination is 10.0.0.7, Source is 10.0.0.1,
Protocol is UDP, Destination port is 1, Source port is 1
Next Hop is 10.0.0.2, Interface is Ethernet0/0
Reservation Style is Fixed-Filter, QoS Service is Guaranteed-Rate
Resv ID handle: 01000405.
Created: 10:07:35 EST Thu Jan 12 2006
Average Bitrate is 10K bits/sec, Maximum Burst is 10K bytes
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
Status:
Policy: Forwarding. Policy source(s): Default
Application ID: 'GUID=www.cisco.com, APP=Video, VER=1.0'
Additional References
The following sections provide references related to the RSVP Application ID Support feature.
Related Documents
|
|
|
|---|---|
QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples |
|
QoS configuration tasks related to RSVP |
"Configuring RSVP" module |
Cisco United Communications Manager (CallManager) and related features |
"Overview of Cisco Unified Communications Manager and Cisco IOS Interoperability" module |
Regular expressions |
|
Cisco IOS commands |
Standards
|
|
|
|---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature. |
— |
MIBs
RFCs
Technical Assistance
Command Reference
The following commands are introduced or modified in the feature or features documented in this module. For information about these commands, see the Cisco IOS Quality of Service Solutions Command Reference at http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_book.html. For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
•
ip rsvp listener
•
ip rsvp policy identity
•
ip rsvp policy local
•
ip rsvp reservation
•
ip rsvp reservation-host
•
ip rsvp sender
•
ip rsvp sender-host
•
maximum (local policy)
•
show ip rsvp host
•
show ip rsvp policy identity
•
show ip rsvp policy local
Feature Information for RSVP Application ID Support
Table 1 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Glossary
ACL—access control list. An ACL consists of individual filtering rules grouped together in a single list. It is generally used to provide security filtering, although it may be used to provide a generic packet classification facility.
admission control—The process in which an RSVP reservation is accepted or rejected on the basis of end-to-end available network resources.
application identity (ID)—A string that can be inserted in a policy element in a POLICY_DATA object of an RSVP message to identify the application and associate it with the RSVP reservation request, thus allowing routers along the path to make appropriate decisions based on the application information.
autonomous system—A collection of networks that share the same routing protocol and that are under the same system administration.
bandwidth—The difference between the highest and lowest frequencies available for network signals. The term also is used to describe the rated throughput capacity of a given network medium or protocol.
CCM—Cisco CallManager. The software-based, call-processing component of the Cisco IP telephony solution. The software extends enterprise telephony features and functions to packet telephony network devices such as IP phones, media processing devices, Voice-over-IP (VoIP) gateways, and multimedia applications.
DSCP—differentiated services code point. The six most significant bits of the 1-byte IP type of service (ToS) field. The per-hop behavior represented by a particular DSCP value is configurable. DSCP values range between 0 and 63.
policy—Any defined rule that determines the use of resources within the network. A policy can be based on a user, a device, a subnetwork, a network, or an application.
QoS—quality of service. A measure of performance for a transmission system that reflects its transmission quality and service availability.
RSVP—Resource Reservation Protocol. A protocol for reserving network resources to provide quality of service guarantees to application flows.
RSVP agent—Implements a Resource Reservation Protocol (RSVP) agent on Cisco IOS voice gateways that support Cisco CallManager 5.0.
RTP—Real-Time Transport Protocol. An Internet protocol for transmitting real-time data such as voice and video.
router—A network layer device that uses one or more metrics to determine the optimal path along which network traffic should be forwarded. Routers forward packets from one network to another on the basis of network layer information.
TE—traffic engineering. The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been used.
Feedback