--- 1/draft-ietf-rohc-over-ppp-03.txt 2006-02-05 01:23:55.000000000 +0100 +++ 2/draft-ietf-rohc-over-ppp-04.txt 2006-02-05 01:23:55.000000000 +0100 @@ -1,17 +1,17 @@ INTERNET-DRAFT Carsten Bormann -Expires: February 2002 TZI/Uni Bremen - August 2001 +Expires: May 2002 TZI/Uni Bremen + November 2001 ROHC over PPP - draft-ietf-rohc-over-ppp-03.txt + draft-ietf-rohc-over-ppp-04.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -61,23 +61,25 @@ 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.) - 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. + 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 all of which do not change the decompression context.) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -157,21 +159,21 @@ Type 2 Length >= 10 The length may be increased if the presence of additional parameters is indicated by additional suboptions. IP-Compression-Protocol - 00SS (hex) [[IANA: to be assigned]] + 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). @@ -238,28 +240,31 @@ 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 is + 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 parameters 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 + 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. Note that each new suboption for this option must define - the meaning of "logical union", if the concept applies. + profiles. The unified values are kept as valid parameter values for + the ROHC channel also 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 @@ -284,29 +289,28 @@ 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: 00SS (hex) [[IANA: to be assigned -- same 00SS as - above]] + Value: 0003 (hex) ROHC large-CIDs The frame contains a ROHC packet with large CIDs as defined in [RFC3095]. - Value: 00LL (hex) [[IANA: to be assigned]] + Value: 0005 (hex) 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, @@ -372,37 +376,37 @@ 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 RFCthis Profiles - The RFC3006 compressibility hint [RFC3006] for ROHC is 0x00SSpppp, - where 0xpppp is the profile assumed. [[IANA: replace 00SS by the - same value above.]] + The RFC3006 compressibility hint [RFC3006] for ROHC is 0x0003pppp, + where 0xpppp is the profile assumed. - [[ The PPP protocol identifier values for 00SS and 00LL are to be - assigned by IANA before publication of this document. As it is - rather unlikely that ROHC will be used over links with highly - populated ACCMs, this could start using the values reserved for - inefficient transparency, e.g. 0003 for 00SS and 0005 for 00LL. ]] + (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, and Craig Fox for - helping with some PPP arcana. + clarifying the multiple option instance issue, Craig Fox for helping + with some PPP arcana, and Lars-Erik Jonsson for supplying some final + clarifications. 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.