RSVP Support for RTP Header Compression Phase 1

RSVP Support for RTP Header Compression
Phase 1
Last Updated: January 12, 2012
The Resource Reservation Protocol (RSVP) Support for Real-Time Transport Protocol (RTP) Header
Compression, Phase 1 feature provides a method for decreasing a flow’s reserved bandwidth requirements
so that a physical link can accommodate more voice calls.
Feature Specifications for RSVP Support for RTP Header Compression, Phase 1
Feature History
Release
Modification
12.2(15)T
This feature was introduced.
Supported Platforms
For platforms supported in Cisco IOS Release
12.2(15)T, consult Cisco Feature Navigator.
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.
•
•
•
•
•
•
•
•
Finding Feature Information, page 2
Prerequisites for RSVP Support for RTP Header Compression Phase 1, page 2
Restrictions for RSVP Support for RTP Header Compression Phase 1, page 2
Information About RSVP Support for RTP Header Compression Phase 1, page 2
How to Configure RSVP Support for RTP Header Compression Phase 1, page 4
Configuration Examples for RSVP Support for RTP Header Compression Phase 1, page 7
Additional References, page 8
Glossary, page 10
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Feature Design of RSVP Support for RTP Header Compression Phase 1
Finding Feature Information
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature
information and caveats, see 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 at the end of this document.
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.
Prerequisites for RSVP Support for RTP Header Compression
Phase 1
•
•
Ensure that Real-Time Transport Protocol (RTP) or User Data Protocol (UDP) header compression is
configured in the network.
Ensure that RSVP is configured on two or more routers within the network before you can use this
feature.
Restrictions for RSVP Support for RTP Header Compression
Phase 1
•
•
•
Routers do not generate compression hints, as described in RFC 3006, in this release.
Signalled compression hints are not supported.
Admission control with compression is limited to reservations with one sender per session.
Information About RSVP Support for RTP Header Compression
Phase 1
•
•
Feature Design of RSVP Support for RTP Header Compression Phase 1, page 2
Benefits of RSVP Support for RTP Header Compression Phase 1, page 4
Feature Design of RSVP Support for RTP Header Compression Phase 1
Network administrators use RSVP with Voice over IP (VoIP) to provide quality of service (QoS) for voice
traffic in a network. Because VoIP is a real-time application, network administrators often configure
compression within the network to decrease bandwidth requirements. Typically, compression is configured
on slow serial lines (see the figure below), where the savings from reduced bandwidth requirements
outweigh the additional costs associated with the compression and decompression processes.
2
Feature Design of RSVP Support for RTP Header Compression Phase 1
Predicting Compression within Admission Control
Note
RTP header compression is supported by Cisco routers.
Figure 1
Configuring Compression
Originating applications know if their traffic is considered compressible, but not whether the network can
actually compress the data. Additionally, compression may be enabled on some links along the call’s path,
but not on others. Consequently, the originating applications must advertise their traffic’s uncompressed
bandwidth requirements, and receiving applications must request reservation of the full amount of
bandwidth. This causes routers whose RSVP implementations do not take compression into consideration
to admit the same number of flows on a link running compression as on one that is not.
•
Predicting Compression within Admission Control, page 3
Predicting Compression within Admission Control
Network administrators, especially those whose networks have very low speed links, may want RSVP to
use their links as fully as possible. Such links typically have minimum acceptable outgoing committed
information rate (minCIR) values between 19 and 30 kbps. Without accounting for compression, RSVP can
admit (at most) one G.723 voice call onto the link, despite the link’s capacity for two compressed calls.
Under these circumstances, network administrators may be willing to sacrifice a QoS guarantee for the last
call, if the flow is less compressible than predicted, in exchange for the ability to admit it.
In order to account for compression during admission control, routers use signalled Tspec information, as
well as their awareness of the compression schemes running on the flow’s outbound interfaces, to make
local decisions as to how much bandwidth should actually be reserved for a flow. By reserving fewer
resources than signalled by the receiver, RSVP can allow links to be more fully used.
3
Benefits of RSVP Support for RTP Header Compression Phase 1
How to Configure RSVP Support for RTP Header Compression Phase 1
Benefits of RSVP Support for RTP Header Compression Phase 1
Additional Calls Accommodated on the Same Link
The RSVP Support for RTP Header Compression, Phase 1 feature performs admission control based on
compressed bandwidth so that additional voice calls can be accommodated on the same physical link.
How to Configure RSVP Support for RTP Header Compression
Phase 1
•
•
Configuring RSVP Admission-Control Compression, page 4
Verifying RSVP Support for RTP Header Compression Phase 1 Configuration, page 5
Configuring RSVP Admission-Control Compression
Note
RSVP predicted compression is enabled by default.
Perform this task to configure RSVP admission-control compression.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface [type number]
4. ip rsvp admission-control compression predict [method {rtp | udp} [bytes-saved N]]
5. end
DETAILED STEPS
Command or Action
Step 1 enable
Purpose
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
Step 2 configure terminal
Example:
Router# configure terminal
4
Enters global configuration mode.
Verifying RSVP Support for RTP Header Compression Phase 1 Configuration
How to Configure RSVP Support for RTP Header Compression Phase 1
Command or Action
Purpose
Step 3 interface [type number]
Enters interface configuration mode.
•
Example:
The type number argument identifies the interface to be
configured.
Router(config-if)# interface Serial3/0
Step 4 ip rsvp admission-control compression predict
[method {rtp | udp} [bytes-saved N]]
Example:
Configures RSVP admission-control compression prediction.
•
•
ip rsvp admission-control
compression predict method udp bytes-saved
16
Router(config-if)#
Step 5 end
The optional method keyword allows you to select Real-Time
Transport Protocol (rtp) or User Data Protocol (udp) for your
compression scheme.
The optional bytes-saved N keyword allows you to configure
the predicted number of bytes saved per packet when RSVP
predicts that compression will occur using the specified
method.
Exits to privileged EXEC mode.
Example:
Router(config-if)#
end
Verifying RSVP Support for RTP Header Compression Phase 1 Configuration
Perform this task to verify that the RSVP Support for RTP Header Compression, Phase 1 feature is
functioning.
SUMMARY STEPS
1. enable
2. show ip rsvp installed [detail]
3. show ip rsvp interface [interface-type interface-number] [detail]
DETAILED STEPS
Command or Action
Step 1 enable
Purpose
Enables privileged EXEC mode.
•
Enter your password if prompted.
Example:
Router> enable
5
Verifying RSVP Support for RTP Header Compression Phase 1 Configuration
Examples
Command or Action
Purpose
Step 2 show ip rsvp installed [detail]
Example:
Displays information about interfaces and their admitted reservations and the
resources needed for a traffic control state block (TCSB) after taking compression
into account.
•
Router# show ip rsvp installed
detail
Step 3 show ip rsvp interface [interfacetype interface-number] [detail]
Displays information about interfaces on which RSVP is enabled, including the
current allocation budget and maximum available bandwidth and the RSVP
bandwidth limit counter, taking compression into account.
•
Example:
The optional detail keyword displays the reservation’s traffic parameters,
downstream hop, compression, and resources used by RSVP to ensure QoS
for this reservation.
The optional detail keyword displays RSVP parameters associated with an
interface including bandwidth, admission control, and compression methods.
Router# show ip rsvp interface
detail
•
•
Examples, page 6
Troubleshooting Tips, page 7
•
•
Sample Output for the show ip rsvp installed detail Command, page 6
Sample Output for the show ip rsvp interface detail Command, page 6
Examples
Sample Output for the show ip rsvp installed detail Command
In this example, the show ip rsvp installed detail command displays information, including the predicted
compression method, its reserved context ID, and the observed bytes saved per packet average, for the
admitted flowspec.
Router# show ip rsvp installed detail
RSVP: Ethernet2/1 has no installed reservations
RSVP: Serial3/0 has the following installed reservations
RSVP Reservation. Destination is 10.1.1.2. Source is 10.1.1.1,
Protocol is UDP, Destination port is 18054, Source port is 19156
Compression: (method rtp, context ID = 1, 37.98 bytes-saved/pkt avg)
Admitted flowspec:
Reserved bandwidth: 65600 bits/sec, Maximum burst: 328 bytes, Peak rate: 80K bits/sec
Min Policed Unit: 164 bytes, Max Pkt Size: 164 bytes
Admitted flowspec (as required if compression were not applied):
Reserved bandwidth: 80K bits/sec, Maximum burst: 400 bytes, Peak rate: 80K bits/sec
Min Policed Unit: 200 bytes, Max Pkt Size: 200 bytes
Resource provider for this flow:
WFQ on FR PVC dlci 101 on Se3/0: PRIORITY queue 24. Weight: 0, BW 66 kbps
Conversation supports 1 reservations [0x1000405]
Data given reserved service: 3963 packets (642085 bytes)
Data given best-effort service: 0 packets (0 bytes)
Reserved traffic classified for 80 seconds
Long-term average bitrate (bits/sec): 64901 reserved, 0 best-effort
Policy: INSTALL. Policy source(s): Default
Sample Output for the show ip rsvp interface detail Command
6
Verifying RSVP Support for RTP Header Compression Phase 1 Configuration
Troubleshooting Tips
In this example, the show ip rsvp interface detail command displays the current interfaces and their
configured compression parameters.
Router# show ip rsvp interface detail
Et2/1:
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 1158K bits/sec
Max. allowed (per flow): 128K bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Neighbors:
Using IP encap: 0. Using UDP encap: 0
Signalling:
Refresh reduction: disabled
Authentication: disabled
Se3/0:
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 1158K bits/sec
Max. allowed (per flow): 128K bits/sec
Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
Set aside by policy (total): 0 bits/sec
Admission Control:
Header Compression methods supported:
rtp (36 bytes-saved), udp (20 bytes-saved)
Neighbors:
Using IP encap: 1. Using UDP encap: 0
Signalling:
Refresh reduction: disabled
Authentication: disabled
Troubleshooting Tips
The observed bytes-saved per packet value should not be less than the configured or default value.
Otherwise, the flow may be experiencing degraded QoS. To avoid any QoS degradation for future flows,
configure a lower bytes-saved per packet value.
Flows may achieve less compressibility than the default RSVP assumes for many reasons, including
packets arriving out of order or having different differentiated services code point (DSCP) or precedence
values, for example, due to policing upstream within the network.
If compression is enabled on a flow’s interface, but the compression prediction was unsuccessful, the
reason appears in the output instead of the reserved compression ID and the observed bytes-saved per
packet.
Configuration Examples for RSVP Support for RTP Header
Compression Phase 1
•
Example RSVP Support for RTP Header Compression Phase 1, page 8
7
Example RSVP Support for RTP Header Compression Phase 1
Additional References
Example RSVP Support for RTP Header Compression Phase 1
The following sample configuration shows the compression prediction enabled for flows using UDP and
disabled for flows using RTP:
Router#
configure terminal
Router(config)# interface Serial3/0
Router(config-if)# ip rsvp admission-control compression predict method udp bytes-saved 16
Router(config-if)# no
ip rsvp admission-control compression predict method rtp
Use the show run command to display all the RSVP configured parameters:
Router# show run
2d18h: %SYS-5-CONFIG_I: Configured from console by console
Router# show run int se3/0
Building configuration...
Current configuration : 339 bytes
!
interface Serial3/0
ip address 10.2.1.1 255.255.0.0
fair-queue 64 256 8
serial restart_delay 0
clock rate 128000
ip rtp header-compression
ip rsvp bandwidth
no ip rsvp admission-control compression predict method rtp
ip rsvp admission-control compression predict method udp bytes-saved 16
end
Additional References
For additional information related to RSVP Support for RTP Header Compression, Phase 1, refer to the
following references:
Related Documents
Related Topic
Document Title
Cisco IOS commands
Cisco IOS Master Commands List, All Releases
QoS commands: complete command syntax,
Cisco IOS Quality of Service Solutions Command
command modes, command history, defaults, usage Reference
guidelines, and examples
8
Signalling
"Signalling Overview" module
RSVP
"Configuring RSVP" module
Header compression concepts and topics
"Header Compression" module
Example RSVP Support for RTP Header Compression Phase 1
Additional References
Standards
Standard
Title
No new or modified standards are supported by this -feature, and support for existing standards has not
been modified by this feature.
MIBs
MIB1
•
RFC 2206, RSVP Management Information
Base using SMIv2
MIBs Link
To obtain lists of supported MIBs by platform and
Cisco IOS release, and to download MIB modules,
go to the Cisco MIB website on Cisco.com at the
following URL:
http://www.cisco.com/public/sw-center/netmgmt/
cmtk/mibs.shtml
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB
Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of
supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your
account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that
your e-mail address is registered with Cisco.com. If the check is successful, account details with a new
random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by
following the directions found at this URL:
http://www.cisco.com/register
RFCs
RFCs2
Title
RFC 2205
Resource Reservation Protocol (RSVP)
RFC 2508
Compressing IP/UDP/RTP Headers for Low-Speed
Serial Links
RFC 3006
Integrated Services in the Presence of Compressible
Flows
1 Not all supported MIBs are listed.
2 Not all supported RFCs are listed.
9
Example RSVP Support for RTP Header Compression Phase 1
Glossary
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.
http://www.cisco.com/cisco/web/support/
index.html
Glossary
admission control --The process in which a Resource Reservation Protocol (RSVP) reservation is accepted
or rejected based on end-to-end available network resources.
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.
compression --The running of a data set through an algorithm that reduces the space required to store or
the bandwidth required to transmit the data set.
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.
flow --A stream of data traveling between two endpoints across a network (for example, from one LAN
station to another). Multiple flows can be transmitted on a single circuit.
flowspec --In IPv6, the traffic parameters of a stream of IP packets between two applications.
G.723 --A compression technique that can be used for compressing speech or audio signal components at a
very low bit rate as part of the H.324 family of standards. This codec has two bit rates associated with it:
5.3 and 6.3 kbps. The higher bit rate is based on ML-MLQ technology and provides a somewhat higher
quality of sound. The lower bit rate is based on code excited linear prediction (CELP) compression and
provides system designers with additional flexibility. Described in the ITU-T standard in its G-series
recommendations.
minCIR --The minimum acceptable incoming or outgoing committed information rate (CIR) for a Frame
Relay virtual circuit.
packet --A logical grouping of information that includes a header containing control information and
(usually) user data. Packets most often refer to network layer units of data.
QoS --quality of service. A measure of performance for a transmission system that reflects its transmission
quality and service availability.
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 based on
network layer information.
RSVP --Resource Reservation Protocol. A protocol that supports the reservation of resources across an IP
network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature
(bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive.
10
Example RSVP Support for RTP Header Compression Phase 1
RTP --Real-Time Transport Protocol. A protocol that is designed to provide end-to-end network transport
functions for applications transmitting real-time data, such as audio, video, or simulation data, over
multicast or unicast network services. RTP provides such services as payload type identification, sequence
numbering, timestamping, and delivery monitoring to real-time applications.
TCSB --traffic control state block. A Resource Reservatiion Protocol (RSVP) state that associates
reservations with their reserved resources required for admission control.
Tspec --Traffic specification. The traffic characteristics of a data stream from a sender or receiver
(included in a Path message).
UDP--User Datagram Protocol. A connectionless transport layer protocol in the TCP/IP protocol stack.
UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery,
requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC
768.
VoIP --Voice over IP. The ability to carry normal telephony-style voice over an IP-based Internet
maintaining telephone-like functionality, reliability, and voice quality.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S.
and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks.
Third-party trademarks mentioned are the property of their respective owners. The use of the word partner
does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be
actual addresses and phone numbers. Any examples, command display output, network topology diagrams,
and other figures included in the document are shown for illustrative purposes only. Any use of actual IP
addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2012 Cisco Systems, Inc. All rights reserved.
11
Download PDF
Similar pages