Robust Header Compression (ROHC) over PPP
RFC 3241
Document | Type |
RFC - Proposed Standard
(May 2002; No errata)
Updated by RFC 4815
Updates RFC 1332
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
This information refers to IESG processing after the RFC was initially published: | |||
IESG | IESG state | RFC 3241 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note | Responsible: Finished | ||
Send notices to | <lars-erik.jonsson@ericsson.com> |
Network Working Group C. Bormann Request for Comments: 3241 TZI/Uni Bremen Updates: 1332 April 2002 Category: Standards Track Robust Header Compression (ROHC) over PPP Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point-to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. 1. Introduction Robust Header Compression (ROHC) as defined in [RFC3095] may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. The initial version of ROHC focuses on compression of the packet headers in RTP streams, while supporting compression of other UDP flows; however, it also defines a framework into which further header compression mechanisms can be plugged as new profiles. Planned additions to the set of profiles supported by ROHC will be capable of compressing TCP transport protocol headers as well. In order to establish compression of IP datagrams sent over a PPP link each end of the link must agree on a set of configuration parameters for the compression. The process of negotiating link parameters for network layer protocols is handled in PPP by a family of network control protocols (NCPs). Since there are separate NCPs for IPv4 and IPv6, this document defines configuration options to be used in both NCPs to negotiate parameters for the compression scheme. Bormann Standards Track [Page 1] 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 [RFC3095] 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 [RFC2686], 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 [RFC1332]. 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 [RFC1332], 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 [Page 2] RFC 3241 ROHC over PPP April 2002 NOTE: The specification of link and network layer parameter negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does notShow full document text