Cisco Cisco IOS Software Release 12.0(33)S
IP Header Compression Over Frame Relay for Interfaces Support
Enabing IPHC Support for Frame Relay Interfaces
3
IPHC Support for Frame Relay Interfaces
•
If you try to change the encapsulation on FR interface with IPHC configured to encapsulation on
which IPHC is not supported, IPHC configurations will be removed from the FR subinterfaces.
which IPHC is not supported, IPHC configurations will be removed from the FR subinterfaces.
•
If interface level IPHC configuration is done before enabling IPHC at slot level, IPHC will remain
disabled at interface level and will be enabled only after IHPC at slot level configurations are
successful.
disabled at interface level and will be enabled only after IHPC at slot level configurations are
successful.
•
CISCO/Original IP Header Compression format does not support negotiation of IPHC parameters
(like max-header size/compression-connections/max-period etc.) between peer interfaces
(connected back to back). So the user should make sure that IPHC configuration parameters match
on both sides for the feature to work correctly.
(like max-header size/compression-connections/max-period etc.) between peer interfaces
(connected back to back). So the user should make sure that IPHC configuration parameters match
on both sides for the feature to work correctly.
•
FRF.20 is not supported currently on Cisco 12000 Series Router.
•
MLFR, IETF FR, and IETF SNAP encapsulation format do not support IPHC Over FR.
•
Cisco 12000 Series Routers do not support TCP compression, but supports cTCP packets
decompression as the peer devices can send compressed TCP packets.
decompression as the peer devices can send compressed TCP packets.
Information About IPHC Support for Frame Relay Interfaces
The real-time transport protocol, RTP, as described in RFC 1889, is used to carry real-time data for voice
and video applications. For a typical VoIP application, the payload portion of the packet can be much
smaller than the headers. For example, using the G.729 Codec, the payload is 20 bytes but the IP/
UDP/RTP header is 40 bytes. It is inefficient to send the IP/UDP/RTP header on a slow link without
compressing it. The IPHC feature addresses this inefficiency. The basic idea behind IPHC is that
although several fields in the IP/ UDP/RTP header change from packet to packet, typically, the difference
in these fields from packet to packet is constant. The compression scheme capitalizes on this
characteristic. RFC 2508 describes the function of IPHC.
and video applications. For a typical VoIP application, the payload portion of the packet can be much
smaller than the headers. For example, using the G.729 Codec, the payload is 20 bytes but the IP/
UDP/RTP header is 40 bytes. It is inefficient to send the IP/UDP/RTP header on a slow link without
compressing it. The IPHC feature addresses this inefficiency. The basic idea behind IPHC is that
although several fields in the IP/ UDP/RTP header change from packet to packet, typically, the difference
in these fields from packet to packet is constant. The compression scheme capitalizes on this
characteristic. RFC 2508 describes the function of IPHC.
Following steps provide details for compressing, decompressing, and reconstructing an original packet:
•
When a new flow (like a VoIP phone conversation) is established over a link with IPHC enabled, the
device at the transmitting end (compressor) sends a full header (FH) packet followed by compressed
packets to the receiving end (decompressor).
device at the transmitting end (compressor) sends a full header (FH) packet followed by compressed
packets to the receiving end (decompressor).
•
The compressor and the decompressor maintain a copy of the uncompressed header and the
difference between the previous packet and the current packet. This data is referred to as the session
state and is identified by a session context ID.
difference between the previous packet and the current packet. This data is referred to as the session
state and is identified by a session context ID.
•
The context ID is added to the packet payload as it is compressed.
•
When the decompressor receives the compressed packet, it can completely reconstruct the packet
header by adding the saved first-order difference to the saved uncompressed header.
header by adding the saved first-order difference to the saved uncompressed header.
•
In a typical case, the IPHC algorithm enables the IP/UDP/RTP header to be compressed to two bytes
(four bytes if UDP checksums are being sent).
(four bytes if UDP checksums are being sent).
Enabing IPHC Support for Frame Relay Interfaces
This section explains the following procedures:
•
•
(required)
•
(required)
•
(optional)