Number of Connections Calculated on the Basis of Bandwidth

In class-based RTP and TCP header compression, the number of header-compression connections is calculated on the basis of the amount of available bandwidth.

Note the following points about how bandwidth is used:

• The setting of the bandwidth command determines the amount of bandwidth available on the interface.
• The number of header-compression connections is calculated by dividing the available bandwidth by 4 (that is, 4 kilobits per connection).

Header-Compression Connections on HDLC and Frame Relay Interfaces

For HDLC interfaces and Frame Relay interfaces (that is, interfaces that use Frame Relay encapsulation), the number of header-compression connections on both sides of the network must match. That is, the number calculated (from the bandwidth setting) for use on the local router must match the number configured (or calculated from the bandwidth setting) for use on the remote router.

Header-Compression Connections on PPP Interfaces

For PPP interfaces, if the header-compression connection numbers on both sides of the network do not match, the number used is "autonegotiated." That is, any mismatch in the number of header-compression connections between the local router and the remote router will be automatically negotiated to the lower of the two numbers. For example, if the local router is configured to use 128 header-compression connections, and the remote router is configured to use 64 header-compression connections, the negotiated number will be 64.

Note	This autonegotiation function applies to PPP interfaces only . For HDLC interfaces and interfaces that use Frame Relay encapsulation, no autonegotiation occurs.

With class-based header compression, you can configure either RTP or TCP header compression for a specific class inside a policy map. To specify the class, to create a policy map, and to configure either RTP or TCP header compression for the class inside the policy map, perform the following steps.

Note

In the following task, the match protocolcommand is shown in step 4. The match protocolcommand matches traffic on the basis on the protocol type and is only an example of a match command you can use. You may want to use a different match command to specify another criterion. The match commands vary by Cisco IOS release. See the command documentation for the Cisco IOS release that you are using for a complete list of match commands.

After a policy map is created, the next step is to attach the policy map to an interface (or subinterface). To attach the policy map to an interface or subinterface, perform the following steps.

Note

You configure class-based RTP and TCP header compression in policy maps. Then you attach those policy maps to an interface by using the service-policy command. The service-policycommand gives you the option of specifying either an input service policy (for input interfaces) or an output service policy (for output interfaces). For class-based RTP and TCP header compression, you can specify output service policies only . >

This task allows you to verify that you created the intended configuration and that the feature is functioning correctly. To verify the configuration, perform the following steps.

In the following example, a class map called class1 and a policy map called policy1 have been configured. Policy1 contains the class called class1, within which RTP header compression has been enabled by using the compression header ip rtp command.

Router> enable

Router# configure terminal

Router(config)# class-map class1 

Router(config-cmap)# match protocol ip 

Router(config-cmap)# exit

Router(config)# policy-map policy1

Router(config-pmap)# class class1 

Router(config-pmap-c)# compression header ip rtp

Router(config-pmap-c)# end

In the following example, the policy map called policy1 has been attached to serial interface 0.

Router> enable

Router# configure terminal

Router(config)# interface serial0 

Router(config-if)# service-policy output policy1

Router(config-if)# end

This section provides sample output from a typical showpolicy-mapinterfacecommand.

Note	Depending upon the interface in use and the QoS feature enabled (such as Class-Based Weighted Fair Queuing [CBWFQ]), the output you see may vary from that shown below.

The following sample displays the statistics for serial interface 0. In this sample configuration, three classes, called gold, silver, and voice, have been configured. Traffic is classified and grouped into classes on the basis of the IP precedence value and RTP port protocol number.

class-map match-all gold
 match ip precedence 2 
class-map match-all silver
 match ip precedence 1 
class-map match-all voice
 match ip precedence 5 
 match ip rtp 16384 1000

This sample configuration also contains a policy map called mypolicy, configured as shown below. QoS features such as RTP header compression and CBWFQ are enabled for specific classes within the policy map.

policy-map mypolicy
  class voice
    priority 128              ! A priority queue and bandwidth amount are specified.
    compress header ip rtp    ! RTP header compression is enabled for class voice.
  class gold
    bandwidth 100             ! CBWFQ is enabled for class gold.
  class silver
    bandwidth 80              ! CBWFQ is enabled for class silver.
    random-detect             ! WRED is enabled for class silver.

Given the classes and policy map configured as shown above, the following content is displayed for serial interface 0:

Router# show policy-map interface
 serial0 output
 Serial0
  Service-policy output: mypolicy
 
    Class-map: voice (match-all)
      880 packets, 58080 bytes
      30 second offered rate 1000 bps, drop rate 0 bps
      Match: ip precedence 5 
      Match: ip rtp 16384 1000
      Queueing
        Strict Priority
        Output Queue: Conversation 136 
        Bandwidth 128 (kbps) Burst 3200 (Bytes)
        (pkts matched/bytes matched) 880/26510
        (total drops/bytes drops) 0/0
      compress:
          header ip rtp
          UDP/RTP (compression on, IPHC, RTP)
            Sent:    880 total, 877 compressed, 
                     31570 bytes saved, 24750 bytes sent
                     2.27 efficiency improvement factor
                     99% hit ratio, five minute miss rate 0 misses/sec, 0 max
                     rate 0 bps
 
    Class-map: gold (match-all)
      100 packets, 53000 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 2 
      Queueing
        Output Queue: Conversation 137 
        Bandwidth 100 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 100/53000
        (depth/total drops/no-buffer drops) 0/0/0
 
    Class-map: silver (match-all)
      878 packets, 1255540 bytes
      30 second offered rate 56000 bps, drop rate 0 bps
      Match: ip precedence 1 
      Queueing
        Output Queue: Conversation 138 
        Bandwidth 64 (kbps)
        (pkts matched/bytes matched) 878/1255540
        (depth/total drops/no-buffer drops) 0/0/0
         exponential weight: 9
         mean queue depth: 0
 
  class    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh prob
      0       0/0               0/0              0/0           20      40  1/10
      1     878/1255540         0/0              0/0           22      40  1/10
      2       0/0               0/0              0/0           24      40  1/10
      3       0/0               0/0              0/0           26      40  1/10
      4       0/0               0/0              0/0           28      40  1/10
      5       0/0               0/0              0/0           30      40  1/10
      6       0/0               0/0              0/0           32      40  1/10
      7       0/0               0/0              0/0           34      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10
 
    Class-map: class-default (match-any)
      3 packets, 84 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any