|
|
This feature module describes IP RTP Priority. It includes the following sections:
The IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic.
The IP RTP Priority feature extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of User Datagram Protocol (UDP)/RTP ports whose traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first---that is, before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.
The IP RTP Priority feature does not require that you know the port of a voice call. Rather, the feature gives you the ability to identify a range of ports whose traffic is put into the priority queue. Moreover, you can specify the entire voice port range---16384 to 32767---to ensure that all voice traffic is given strict priority service. IP RTP Priority is especially useful on slow-speed links whose speed is less than 1.544 Mbps.
This feature can be used in conjunction with either Weighted Fair Queueing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
Because voice packets are small in size and the interface also can have large packets going out, the Link Fragmentation and Interleaving (LFI) feature should also be configured on lower speed interfaces. When you enable LFI, the large data packets are broken up so that the small voice packets can be interleaved between the data fragments that make up a large data packet. LFI prevents a voice packet from needing to wait until a large packet is sent. Instead, the voice packet can be sent in a shorter amount of time.
If you want to understand its behavior and properly use the IP RTP Priority feature, it is important to consider its admission control and policing characteristics. When you use the ip rtp priority command to configure the priority queue for voice, you specify a strict bandwidth limitation. This amount of bandwidth is guaranteed to voice traffic enqueued in the priority queue. (This is the case whether you use the IP RTP Priority feature with CBWFQ or WFQ.)
IP RTP Priority closely polices use of bandwidth for the priority queue, ensuring that the allocated amount is not exceeded in the event of congestion. In fact, IP RTP Priority polices the flow every second. IP RTP Priority prohibits transmission of additional packets once the allocated bandwidth is consumed. If it discovers that the configured amount of bandwidth is exceeded, IP RTP Priority drops packets, an event that is poorly tolerated by voice traffic. (Enable debugging to watch for this condition.) Close policing allows for fair treatment of other data packets enqueued in other CBWFQ or WFQ queues. To avoid packet drop, be certain to allocate to the priority queue the most optimum amount of bandwidth, taking into consideration the type of codec used and interface characteristics. IP RTP Priority will not allow traffic beyond the allocated amount.
It is always safest to allocate to the priority queue slightly more than the known required amount of bandwidth. For example, suppose you allocated 24 kbps bandwidth, the standard amount required for voice transmission, to the priority queue. This allocation seems safe because transmission of voice packets occurs at a constant bit rate. However, because the network and the router or switch can use some of the bandwidth and introduce jitter and delay, allocating slightly more than the required amount of bandwidth (such as 25 kbps) ensures constancy and availability.
The IP RTP Priority admission control policy takes RTP header compression into account. Therefore, while configuring the bandwidth parameter of the ip rtp priority command you only need to configure for the bandwidth of the compressed call. For example, if a G.729 voice call requires 24 kbps uncompressed bandwidth (not including Layer 2 payload) but only 12 kbps compressed bandwidth, you only need to configure a bandwidth of 12 kbps. You need to allocate enough bandwidth for all calls if there will be more than one call.
The sum of all bandwidth allocation for voice and data flows on the interface cannot exceed 75 percent of the total available bandwidth. Bandwidth allocation for voice packets takes into account the payload plus the IP, RTP, and UDP headers, but again, not the Layer 2 header. Allowing 25 percent bandwidth for other overhead is conservative and safe. On a PPP link, for instance, overhead for Layer 2 headers assumes 4 kbps. The amount of configurable bandwidth for IP RTP Priority can be changed using the max-reserved-bandwidth command on the interface.
If you know how much bandwidth is required for additional overhead on a link, under aggressive circumstances in which you want to give voice traffic as much bandwidth as possible, you can override the 75 percent maximum allocation for the bandwidth sum allocated to all classes or flows by using the max-reserved-bandwidth command. If you want to override the fixed amount of bandwidth, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic, and Layer 2 overhead.
As another alternative, if the importance of voice traffic far exceeds that of data, you can allocate most of the 75 percent bandwidth used for flows and classes to the voice priority queue. Unused bandwidth at any given point will be made available to the other flows or classes.
The strict priority queueing scheme allows delay-sensitive data such as voice to be dequeued and sent first---that is, before packets in other queues are dequeued. Delay-sensitive data is given preferential treatment over other traffic.
The ip rtp reserve and ip rtp priority commands cannot be configured on the same interface.
The IP RTP Priority feature is related to the following features:
This feature runs on the platforms listed. However, it is most useful on voice supported platforms, such as the Cisco 2600 series, Cisco 3600 series, Cisco 7200 series, and Cisco 7500 RSP series.
This feature supports no new MIBs.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
None
None
To use this feature, you should be familiar with the following:
See the following sections for configuration tasks for the IP RTP Priority feature. Each task in the list indicates if the task is optional or required.
| Command | Purpose |
|---|---|
Router(config-if)# ip rtp priority starting-rtp-port-number port-number-range bandwidth | Reserves a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports. |
The ip rtp reserve and ip rtp priority commands cannot be configured on the same interface.
To change the maximum reserved bandwidth allocated for CBWFQ and the IP RTP Priority feature, use the following command in interface configuration mode:
| Command | Purpose |
|---|---|
Router(config-if)# max-reserved-bandwidth percent | Changes the maximum configurable bandwidth for CBWFQ and IP RTP Priority. The default is 75 percent. |
To see the contents of the priority queue (such as queue depth and the first packet queued), use the following command in EXEC mode:
| Command | Purpose |
|---|---|
Router# show queue interface-type interface-number | Displays fair queueing configuration and statistics for a particular interface. |
To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use one or more of the following commands in EXEC mode:
| Command | Purpose |
|---|---|
Router# debug priority | Displays priority queueing events. |
Router# show queue interface-type interface-number | Lists fair queueing configuration and statistics for a particular interface. |
This section provides the following configuration examples:
The following example first defines a CBWFQ configuration and then reserves a strict priority queue:
! The following commands define a class map: router(config)# class-map class1 router(config-cmap)# match access-group 101 router(config-cmap)# exit ! The following commands create and attach a policy map: router(config)# policy-map policy1 router(config-pmap)# class class1 router(config-pmap-c)# bandwidth 3000 router(config-pmap-c)# queue-limit 30 router(config-pmap-c)# random-detect router(config-pmap-c)# random-detect precedence 0 32 256 100 router(config-pmap-c)# exit router(config)# interface Serial1 router(config-if)# service-policy output policy1 ! The following command reserves a strict priority queue: router(config-if)# ip rtp priority 16384 16383 40
The queue-limit and random-detect commands are optional commands for CBWFQ configurations. The queue-limit command is used for configuring tail drop limits for a class queue. The random-detect command is used for configuring RED drop limits for a class queue, similar to the random-detect command available on an interface.
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.
router(config)# multilink virtual-template 1 router(config)# interface virtual-template 1 router(config-if)# ip address 172.16.1.1 255.255.255.0 router(config-if)# no ip directed-broadcast router(config-if)# ip rtp priority 16384 16383 25 router(config-if)# service-policy output policy1 router(config-if)# ppp multilink router(config-if)# ppp multilink fragment-delay 20 router(config-if)# ppp multilink interleave router(config-if)# max-reserved-bandwidth 80 router(config-if)# end router(config)# interface Serial0/1 router(config-if)# bandwidth 64 router(config-if)# ip address 1.1.1.2 255.255.255.0 router(config-if)# no ip directed-broadcast router(config-if)# encapsulation ppp router(config-if)# ppp multilink router(config-if)# end
The following example configures a strict priority queue in a multilink bundle configuration with WFQ. The advantage to using multilink bundles is that you can specify different ip rtp priority parameters on different interfaces.
The following commands create multilink bundle 1, which is configured for a maximum ip rtp priority bandwidth of 200 kbps. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for WFQ and IP RTP Priority.
router(config)# interface multilink 1 router(config-if)# ip address 172.17.254.161 255.255.255.248 router(config-if)# no ip directed-broadcast router(config-if)# ip rtp priority 16384 16383 200 router(config-if)# no ip mroute-cache router(config-if)# fair-queue 64 256 0 router(config-if)# ppp multilink router(config-if)# ppp multilink fragment-delay 20 router(config-if)# ppp multilink interleave router(config-if)# max-reserved-bandwidth 80
The following commands create multilink bundle 2, which is configured for a maximum ip rtp priority bandwidth of 100 kbps:
router(config)# interface multilink 2 router(config-if)# ip address 172.17.254.162 255.255.255.248 router(config-if)# no ip directed-broadcast router(config-if)# ip rtp priority 16384 16383 100 router(config-if)# no ip mroute-cache router(config-if)# fair-queue 64 256 0 router(config-if)# ppp multilink router(config-if)# ppp multilink fragment-delay 20 router(config-if)# ppp multilink interleave
In the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1.
router(config)# interface serial 2/0 router(config-if)# bandwidth 256 router(config-if)# no ip address router(config-if)# no ip directed-broadcast router(config-if)# encapsulation ppp router(config-if)# no ip mroute-cache router(config-if)# no fair-queue router(config-if)# clockrate 256000 router(config-if)# ppp multilink router(config-if)# multilink-group 1
Next, serial interface 2/1 is configured to be part of multilink bundle 2.
router(config)# interface serial 2/1 router(config-if)# bandwidth 128 router(config-if)# no ip address router(config-if)# no ip directed-broadcast router(config-if)# encapsulation ppp router(config-if)# no ip mroute-cache router(config-if)# no fair-queue router(config-if)# clockrate 128000 router(config-if)# ppp multilink router(config-if)# multilink-group 2
The following example shows a sample output from the debug priority command:
Router# debug priority *Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.699:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.711:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.719:WFQ:dropping a packet from the priority queue 64
In this example, 64 indicates the actual priority queue depth at the time the packet was dropped.
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
To reserve a strict priority queue for a set of Real-Time Transport Protocol (RTP) packet flows belonging to a range of User Datagram Protocol (UDP) destination ports, use the ip rtp priority interface configuration command. To disable the strict priority queue, use the no form of this command.
ip rtp priority starting-rtp-port-number port-number-range bandwidth
starting-rtp-port-number | The starting RTP port number. The lowest port number to which the packets are sent. |
port-number-range | The range of UDP destination ports. Number, which added to the starting-rtp-port-number, yields the highest UDP port number. |
bandwidth | Maximum allowed bandwidth (in kbps). |
This command has no default behavior or values.
Interface configuration
| Release | Modification |
|---|---|
12.0(5)T | This command was introduced. |
This command is most useful for voice applications, or other applications that are delay-sensitive.
This command extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of UDP/RTP ports whose voice traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first---that is, before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.
This command can be used in conjunction with either Weighted Fair Queueing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; voice packets in the priority queue are always serviced first.
Keep the following guidelines in mind when configuring the bandwidth parameter:
The following example first defines a CBWFQ configuration and then reserves a strict priority queue with the following values: a starting RTP port number of 16384, a range of 16383 UDP ports, and a maximum bandwidth of 40 kbps.
! The following commands define a class map: class-map class1 match access-group 101 exit ! The following commands create and attach a policy map: policy-map policy1 class class1 bandwidth 3000 queue-limit 30 random-detect random-detect precedence 0 32 256 100 exit interface Serial1 service-policy output policy1 ! The following command reserves a strict priority queue: ip rtp priority 16384 16383 40
| Command | Description |
bandwidth (policy map) | Specifies or modifies the bandwidth allocated for a class belonging to a policy map. |
fair queue (WFQ) | Enables WFQ for an interface. |
frame-relay ip rtp priority | Reserves a strict priority queue on a Frame Relay PVC for a set of RTP packet flows belonging to a range of UDP destination ports. |
ip rtp reserve | Reserves a special queue for a set of RTP packet flows belonging to a range of UDP destination ports. |
max-reserved-bandwidth | Changes the percent of interface bandwidth allocated for CBWFQ and IP RTP Priority. |
policy-map | Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy. |
ppp multilink | Enables MLP on an interface and, optionally, enables dynamic bandwidth allocation. |
ppp multilink fragment-delay | Configures a maximum delay allowed for transmission of a packet fragment on an MLP bundle. |
ppp multilink interleave | Enables interleaving of RTP packets among the fragments of larger packets on an MLP bundle. |
priority | Gives priority to a class within a policy map. |
service-policy | Attaches a policy map to an input interface or VC, or an output interface or VC, to be used as the service policy for that interface or VC. |
show policy-map | Displays the configuration of all classes comprising the specified service policy map or all classes for all existing policy maps. |
show queue | Displays the contents of packets inside a queue for a particular interface or VC. |
To change the percent of interface bandwidth allocated for Class-Based Weighted Fair Queueing (CBWFQ) and IP RTP Priority, use the max-reserved bandwidth interface configuration command. To restore the default value, use the no form of this command.
max-reserved-bandwidth percent
percent | Percent of interface bandwidth allocated for CBWFQ and IP RTP Priority. |
75 percent
Interface configuration
| Release | Modification |
|---|---|
12.0(5)T | This command was introduced. |
The sum of all bandwidth allocation on an interface should not exceed 75 percent of the available bandwidth on an interface. The remaining 25 percent of bandwidth is used for overhead, including Layer 2 overhead, control traffic, and best-effort traffic.
If you need to allocate more than 75 percent for CBWFQ and IP RTP Priority, you can use the max-reserved- bandwidth command. The percent argument specifies the maximum percentage of the total interface bandwidth that can be used by CBWFQ classes and IP RTP Priority.
If you do use the max-reserved-bandwidth command, care should be taken not to take too much bandwidth away from best-effort and control traffic when using this command.
The max-reserved-bandwidth command can be used only on interfaces; it cannot be used on virtual circuits (VCs).
In the following example, the policy1 policy map is configured for three classes with a total of 8 Mbps configured bandwidth, as shown in the output from the show policy-map command:
Router# show policy-map policy1
Policy Map policy1
Weighted Fair Queueing
Class class1
Bandwidth 2500 (kbps) Max Threshold 64 (packets)
Class class2
Bandwidth 2500 (kbps) Max Threshold 64 (packets)
Class class3
Bandwidth 3000 (kbps) Max Threshold 64 (packets)
When the service-policy output command is entered in an attempt to attach the policy map on a 10 Mbps Ethernet interface, an error message such as the one shown below is produced:
I/f Ethernet1/1 class class3 requested bandwidth 3000 (kbps) Available only 2500 (kbps)
The error message is produced because the default maximum configurable bandwidth is 75 percent of the available interface bandwidth, which in this example is 7.5 Mbps. To change the maximum configurable bandwidth to 80 percent, use the max-reserved-bandwidth command in interface configuration mode:
max-reserved-bandwidth 80 service output policy1 end
To verify that the policy map was attached, enter the show policy-map interface command:
Router# show policy-map interface e1/1
Ethernet1/1 output :policy1
Weighted Fair Queueing
Class class1
Output Queue:Conversation 265
Bandwidth 2500 (kbps) Packets Matched 0 Max Threshold 64 (packets)
(discards/tail drops) 0/0
Class class2
Output Queue:Conversation 266
Bandwidth 2500 (kbps) Packets Matched 0 Max Threshold 64 (packets)
(discards/tail drops) 0/0
Class class3
Output Queue:Conversation 267
Bandwidth 3000 (kbps) Packets Matched 0 Max Threshold 64 (packets)
(discards/tail drops) 0/0
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum bandwidth allocated between CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.
multilink virtual-template 1 interface virtual-template 1 ip address 172.16.1.1 255.255.255.0 no ip directed-broadcast ip rtp priority 16384 16383 25 service-policy output policy1 ppp multilink ppp multilink fragment-delay 20 ppp multilink interleave max-reserved-bandwidth 80 end interface Serial0/1 bandwidth 64 ip address 10.1.1.2 255.255.255.0 no ip directed-broadcast encapsulation ppp ppp multilink end
| Command | Description |
bandwidth (policy map) | Specifies or modifies the bandwidth allocated for a class belonging to a policy map. |
Reserves a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports. |
CBWFQ---Class-Based Weighted Fair Queueing. Extends the standard WFQ functionality to provide support for user-defined traffic classes.
Class-Based Weighted Fair Queueing---See CBWFQ.
PPP---Point-to-Point Protocol. Successor to SLIP that provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. Whereas SLIP was designed to work with IP, PPP was designed to work with several network layer protocols, such as IP, IPX, and ARA. PPP also has built-in security mechanisms, such as CHAP and PAP. PPP relies on two protocols: LCP and NCP.
RTP---Real-Time Transport Protocol. One of the IPv6 protocols. RTP is designed to provide end-to-end network transport functions for applications sending real-time data such as audio, video, or simulation data over multicast or unicast network services. RTP provides services such as payload type identification, sequence numbering, time-stamping, and delivery monitoring to real-time applications.
SNA---Systems Network Architecture. Large, complex, feature-rich network architecture developed in the 1970s by IBM. Similar in some respects to the OSI reference model, but with a number of differences.
UDP---User Datagram Protocol. 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.
Weighted Fair Queueing---See WFQ.
WFQ---Weighted Fair Queueing. Congestion management algorithm that identifies conversations (in the form of traffic streams), separates packets that belong to each conversation, and ensures that capacity is shared fairly between these individual conversations. WFQ is an automatic way of stabilizing network behavior during congestion and results in increased performance and reduced retransmission.
Posted: Wed May 10 13:47:56 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.