diff options
Diffstat (limited to 'doc/rfc/rfc3241.txt')
| -rw-r--r-- | doc/rfc/rfc3241.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3241.txt b/doc/rfc/rfc3241.txt new file mode 100644 index 0000000..f3f5e40 --- /dev/null +++ b/doc/rfc/rfc3241.txt @@ -0,0 +1,675 @@ + + + + + + +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 not + prohibit multiple instances of one configuration option but states + that the specification of a configuration option must explicitly + allow multiple instances. From the current specification of the + IPCP IP-Compression-Protocol configuration option [RFC1332] one + can infer that it can only be used to select a single compression + protocol at any time. + + This was appropriate at a time when only one header compression + scheme existed. With the advent of IP header compression + [RFC2507, RFC2509], this did not really change, as RFC 2507 + essentially superseded RFC 1144. However, with ROHC, it may now + very well be desirable to use RFC 2507 TCP compression in + conjunction with RFC 3095 RTP/UDP compression. + + The present document now updates RFC 1332 by explicitly allowing the + sending of multiple instances of the IP-Compression-Protocol + configuration option, each with a different value for IP- + Compression-Protocol. Each type of compression protocol may + independently establish its own parameters. + + This change is believed to not cause significant harm in existing PPP + implementations, as they would most likely Configure-Nak or + Configure-Reject the duplicate option, or simply happen to accept the + one option they understand. To aid interoperability, the peer + implementing the present specification SHOULD react to a Configure- + Nak or Configure-Reject by reducing the number of options offered to + one. + +2.1. Configuration Option Format + + Both the network control protocol for IPv4, IPCP [RFC1332] and the + IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header + Compression parameters for their respective protocols. The format of + the configuration option is the same for both IPCP and IPV6CP. + + Description + + This NCP configuration option is used to negotiate parameters for + Robust Header Compression. The option format is summarized below. + The fields are transmitted from left to right. + + + + + + + + + +Bormann Standards Track [Page 3] + +RFC 3241 ROHC over PPP April 2002 + + + Figure 1: Robust Header Compression (ROHC) Option + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAX_CID | MRRU | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAX_HEADER | suboptions... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 2 + + Length + >= 10 + + The length may be increased if the presence of additional + parameters is indicated by additional suboptions. + + IP-Compression-Protocol + 0003 (hex) + + MAX_CID + The MAX_CID field is two octets and indicates the maximum value of + a context identifier. + + Suggested value: 15 + + MAX_CID must be at least 0 and at most 16383 (The value 0 implies + having one context). + + MRRU + The MRRU field is two octets and indicates the maximum + reconstructed reception unit (see [RFC3095], section 5.1.1). + + Suggested value: 0 + + MAX_HEADER + The largest header size in octets that may be compressed. + + Suggested value: 168 octets + + + + + + + + +Bormann Standards Track [Page 4] + +RFC 3241 ROHC over PPP April 2002 + + + The value of MAX_HEADER should be large enough so that at least + the outer network layer header can be compressed. To increase + compression efficiency MAX_HEADER should be set to a value large + enough to cover common combinations of network and transport layer + headers. + + NOTE: The four ROHC profiles defined in RFC 3095 do not provide + for a MAX_HEADER parameter. The parameter MAX_HEADER defined by + this document is therefore without consequence in these profiles. + Other profiles (e.g., ones based on RFC 2507) can make use of the + parameter by explicitly referencing it. + + suboptions + The suboptions field consists of zero or more suboptions. Each + suboption consists of a type field, a length field and zero or + more parameter octets, as defined by the suboption type. The + value of the length field indicates the length of the suboption in + its entirety, including the lengths of the type and length fields. + + Figure 2: Suboption + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Parameters... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.2. PROFILES Suboption + + The set of profiles to be enabled is subject to negotiation. Most + initial implementations of ROHC implement profiles 0x0000 to 0x0003. + This option MUST be supplied. + + Description + + Define the set of profiles supported by the decompressor. + + Figure 3: PROFILES suboption + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Profiles... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 1 + + + + +Bormann Standards Track [Page 5] + +RFC 3241 ROHC over PPP April 2002 + + + Length + 2n+2 + + Value + n octet-pairs in ascending order, each octet-pair specifying a + ROHC profile supported. + +3. Multiple Network Control Protocols + + The ROHC protocol is able to compress both IPv6 and IPv4 datagrams. + Both IPCP and IPV6CP are able to negotiate option parameter values + for ROHC. The ROHC capability negotiated as a whole applies to the + compression of packets where the outer header is an IPv4 header and + an IPv6 header, respectively; e.g., an outer IPv6 header MUST NOT be + sent if the ROHC IP-Compression-Protocol option was not negotiated + for IPV6CP. + + Offering a specific ROHC capability in a Configure-Request in either + IPCP or IPV6CP indicates that the capability is provided for the + entire ROHC channel formed by the PPP link. When the option has been + negotiated with different values in IPCP and IPV6CP, the result is + that the set of parameter values for the entire ROHC channel is the + logical union of the two values, i.e., the maximum for MAX_CID, MRRU + or MAX_HEADER, and the logical union of the suboptions. For the + PROFILES suboption, the logical union is the union of the two sets of + profiles. The unified values are kept as valid parameter values for + the ROHC channel even when either of the NCPs is taken down. + + Note that each new suboption for this option must define the meaning + of "logical union", if the concept applies. + +3.1. Sharing Context Identifier Space + + For the compression and decompression of IPv4 and IPv6 datagram + headers, the context identifier space is shared. While the parameter + values are independently negotiated, sharing the context identifier + spaces becomes more complex when the parameter values differ. Since + the compressed packets share context identifier space, the + compression engine must allocate context identifiers out of a common + pool; for compressed packets, the decompressor has to examine the + context state to determine what parameters to use for decompression. + + In particular, the context identifier space is shared between ROHC + small-CID packets and ROHC large-CID packets. From the point of view + of the ROHC framework, the PPP NCP instances for IPCP and IPV6CP + together constitute exactly one ROHC channel; its feedback is + destined for the ROHC channel defined by the NCP instances for IPCP + and IPV6CP in the reverse direction on the same PPP link. + + + +Bormann Standards Track [Page 6] + +RFC 3241 ROHC over PPP April 2002 + + + In particular, this means that taking down either of the NCPs while + the other is still open means that the contexts of the channel stay + active. To avoid race conditions, the same is true if both NCPs are + taken down and then one or more is reopened. Taking down LCP + destroys the channel, however; reopening LCP and then one or more of + IPCP and IPV6CP restarts ROHC with all contexts in no-context state. + +4. Demultiplexing of Datagrams + + The ROHC specification [RFC3095] defines a single header format for + all different types of compressed headers, with a variant for small + CIDs and a variant for large CIDs. Two PPP Data Link Layer Protocol + Field values are specified below. + + ROHC small-CIDs + + The frame contains a ROHC packet with small CIDs as defined in + [RFC3095]. + + Value: 0003 (hex) + + ROHC large-CIDs + + The frame contains a ROHC packet with large CIDs as defined in + [RFC3095]. + + Value: 0005 (hex) + + Note that this implies that all CIDs within one ROHC packet MUST be + of the same size as indicated by the Data Link Layer Protocol field, + either small or large. In particular, embedded feedback MUST have a + CID of the same size as indicated by the Protocol field value. For + piggybacking feedback, a compressor must be able to control the + feedback CID size used by the associated decompressor, ensure that + all CIDs are of the same size, and indicate this size with the + appropriate Protocol Field value. + + To make CID interpretation unambiguous when ROHC segmentation is + used, all packets that contribute to a segment MUST be sent with the + same Data Link Layer Protocol Field value, either 0003 or 0005, which + then also applies to the CID size in the reconstructed unit. A unit + reconstructed out of packets with Protocol field values that differ + MUST be discarded. + + + + + + + + +Bormann Standards Track [Page 7] + +RFC 3241 ROHC over PPP April 2002 + + +5. ROHC Usage Considerations + + Certain considerations are required for any ROHC-over-X protocol. + This section describes how some of these are handled for ROHC over + PPP. + +5.1. Uncompressed profile + + There is no need for the ROHC uncompressed profile in ROHC over PPP, + as uncompressed packets can always be sent using the PPP protocol + demultiplexing method. Therefore, no consideration was given to + locking down one of the context numbers for the uncompressed profile + (see [RFC3095] section 5.1.2). Note, however, that according to the + ROHC specification, profile 0x0000 must not be rejected [RFC3095], so + it MUST be implemented by all receivers. + +5.2. Parameter selection + + For each of the ROHC channel parameters MAX_CID and MRRU, the value + is the maximum of the respective values negotiated for the IPCP and + IPv6CP instances, if any. The ROHC channel parameter FEEDBACK_FOR is + set implicitly to the reverse direction on the same PPP link (see + "Sharing Context Identifier Space" above). The ROHC channel + parameter LARGE_CIDS is not used, instead the PPP protocol ID on the + packet is used (see "Demultiplexing of Datagrams" above). + + A number of parameters for ROHC must be set correctly for good + compression on a specific link. E.g., the parameters k_1, n_1, k_2, + n_2 in section 5.3.2.2.3 of [RFC3095] need to be set based on the + error characteristics of the underlying links. As PPP links are + usually run with a strong error detection scheme [RFC1662], k_1 = n_1 + = k_2 = n_2 = 1 is usually a good set of values. (Note that in any + case k values need to be set low enough relative to n values to allow + for the limited ability of the CRC to detect errors, i.e., the CRC + will succeed for about 1/8 of the packets even in case of context + damage, so k/n should be significantly less than 7/8.) + +6. Security Considerations + + Negotiation of the option defined here imposes no additional security + considerations beyond those that otherwise apply to PPP [RFC1661]. + + The security considerations of ROHC [RFC3095] apply. + + The use of header compression can, in rare cases, cause the + misdelivery of packets. If necessary, confidentiality of packet + contents should be assured by encryption. + + + + +Bormann Standards Track [Page 8] + +RFC 3241 ROHC over PPP April 2002 + + + Encryption applied at the IP layer (e.g., using IPSEC mechanisms) + precludes header compression of the encrypted headers, though + compression of the outer IP header and authentication/security + headers is still possible as described in [RFC3095]. For RTP + packets, full header compression is possible if the RTP payload is + encrypted by itself without encrypting the UDP or RTP headers, as + described in [RFC1889]. This method is appropriate when the UDP and + RTP header information need not be kept confidential. + +7. IANA considerations + + The ROHC suboption identifier is a non-negative integer. Following + the policies outlined in [RFC2434], the IANA policy for assigning new + values for the suboption identifier shall be Specification Required: + values and their meanings must be documented in an RFC or in some + other permanent and readily available reference, in sufficient detail + that interoperability between independent implementations is + possible. The range 0 to 127 is reserved for IETF standard-track + specifications; the range 128 to 254 is available for other + specifications that meet this requirement (such as Informational + RFCs). The value 255 is reserved for future extensibility of the + present specification. + + The following suboption identifiers are already allocated: + + Suboption Document Usage + identifier + + 1 RFC3241 Profiles + + The RFC 3006 compressibility hint [RFC3006] for ROHC is 0x0003pppp, + where 0xpppp is the profile assumed. + + (Note that the PPP protocol identifier values 0003 and 0005 were + taken from a previously reserved space that exhibits inefficient + transparency in the presence of asynchronous control character + escaping, as it is considered rather unlikely that ROHC will be used + over links with highly populated ACCMs.) + +8. Acknowledgments + + The present document borrows heavily from [RFC2509]. + + The author would like to thank Pete McCann and James Carlson for + clarifying the multiple option instance issue, Craig Fox for helping + with some PPP arcana, and Lars-Erik Jonsson for supplying some final + clarifications. + + + + +Bormann Standards Track [Page 9] + +RFC 3241 ROHC over PPP April 2002 + + +9. References + +9.1. Normative References + + + [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol + (IPCP)", RFC 1332, May 1992. + + [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [RFC2472] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC 2472, + December 1998. + + [RFC3006] Davie, B., Casner, S., Iturralde, C., Oran, D. and J. + Wroclawski, "Integrated Services in the Presence of + Compressible Flows", RFC 3006, November 2000. + + [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., + Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, + T., Yoshimura, T. and H. Zheng, "RObust Header Compression + (ROHC): Framework and four profiles: RTP, UDP, ESP, and + uncompressed", RFC 3095, July 2001. + +9.2. Informative References + + [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed + Serial Links", RFC 1144, February 1990. + + [RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. + Jacobson, "RTP: A Transport Protocol for real-time + applications", RFC 1889, January 1996. + + [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header + Compression", RFC 2507, February 1999. + + [RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header + Compression over PPP", RFC 2509, February 1999. + + [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", + RFC 2686, September 1999. + + + + + +Bormann Standards Track [Page 10] + +RFC 3241 ROHC over PPP April 2002 + + +10. Author's Address + + Carsten Bormann + Universitaet Bremen FB3 TZI + Postfach 330440 + D-28334 Bremen, GERMANY + + Phone: +49.421.218-7024 + Fax: +49.421.218-7000 + EMail: cabo@tzi.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bormann Standards Track [Page 11] + +RFC 3241 ROHC over PPP April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Bormann Standards Track [Page 12] + |