RFC 3241 (rfc3241) - Page 2 of 12
Robust Header Compression (ROHC) over PPP
Alternative Format: Original Text Document
RFC 3241 ROHC over PPP April 2002 ROHC does not require that the link layer be able to indicate the types of datagrams carried in the link layer frames. However, there are two basic types of ROHC headers defined in the ROHC framework: small-CID headers (zero or one bytes are used to identify the compression context) and large-CID headers (one or two bytes are used for this purpose). To keep the PPP packets self-describing, in this document two new types for the PPP Data Link Layer Protocol Field are defined, one for small-CID ROHC packets and one for large-CID ROHC packets. (This also avoids a problem that would occur if PPP were to negotiate which of the formats to use in each of IPCP and IPV6CP and the two negotiation processes were to arrive at different results.) A PPP ROHC sender may send packets in either small-CID or large-CID format at any time, i.e., the LARGE_CIDS parameter from [RFC 3095] is not used. Any PPP ROHC receiver MUST be able to process both small- CID and large-CID ROHC packets, therefore no negotiation of this function is required. ROHC assumes that the link layer delivers packets in sequence. PPP normally does not reorder packets. When using reordering mechanisms such as multiclass multilink PPP [RFC 2686], care must be taken so that packets that share the same compression context are not reordered. (Note that in certain cases, reordering may be acceptable to ROHC, such as within a sequence of packets that all do not change the decompression context.) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Configuration Option This document specifies a new compression protocol value for the IPCP IP-Compression-Protocol option as specified in [RFC 1332]. The new value and the associated option format are described in section 2.1. The option format is structured to allow future extensions to the ROHC scheme. It may be worth repeating [RFC 1332], section 4: "The IP-Compression- Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired." I.e., the option describes the capabilities of the decompressor (receiving side) of the peer that sends the Configure-Request. Bormann Standards Track
