draft-ietf-rohc-over-ppp-03.txt   draft-ietf-rohc-over-ppp-04.txt 
INTERNET-DRAFT Carsten Bormann INTERNET-DRAFT Carsten Bormann
Expires: February 2002 TZI/Uni Bremen Expires: May 2002 TZI/Uni Bremen
August 2001 November 2001
ROHC over PPP ROHC over PPP
draft-ietf-rohc-over-ppp-03.txt draft-ietf-rohc-over-ppp-04.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 36 skipping to change at page 2, line 36
types of datagrams carried in the link layer frames. However, there types of datagrams carried in the link layer frames. However, there
are two basic types of ROHC headers defined in the ROHC framework: are two basic types of ROHC headers defined in the ROHC framework:
small-CID headers (zero or one bytes are used to identify the small-CID headers (zero or one bytes are used to identify the
compression context) and large-CID headers (one or two bytes are used compression context) and large-CID headers (one or two bytes are used
for this purpose). To keep the PPP packets self-describing, in this 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 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 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 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 negotiate which of the formats to use in each of IPCP and IPV6CP and
the two negotiation processes were to arrive at different results.) the two negotiation processes were to arrive at different results.)
Any PPP ROHC receiver MUST be able to process both small-CID and A PPP ROHC sender may send packets in either small-CID or large-CID
large-CID ROHC packets, therefore no negotiation of this function is format at any time, i.e., the LARGE_CIDS parameter from [RFC3095] is
required. 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 ROHC assumes that the link layer delivers packets in sequence. PPP
normally does not reorder packets. When using reordering mechanisms normally does not reorder packets. When using reordering mechanisms
such as multiclass multilink PPP [RFC2686], care must be taken so such as multiclass multilink PPP [RFC2686], care must be taken so
that packets that share the same compression context are not that packets that share the same compression context are not
reordered. (Note that in certain cases, reordering may be acceptable reordered. (Note that in certain cases, reordering may be acceptable
to ROHC, such as within a sequence of packets all of which do not to ROHC, such as within a sequence of packets all of which do not
change the decompression context.) change the decompression context.)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 32 skipping to change at page 4, line 32
Type Type
2 2
Length Length
>= 10 >= 10
The length may be increased if the presence of additional The length may be increased if the presence of additional
parameters is indicated by additional suboptions. parameters is indicated by additional suboptions.
IP-Compression-Protocol IP-Compression-Protocol
00SS (hex) [[IANA: to be assigned]] 0003 (hex)
MAX_CID MAX_CID
The MAX_CID field is two octets and indicates the maximum value The MAX_CID field is two octets and indicates the maximum value
of a context identifier. of a context identifier.
Suggested value: 15 Suggested value: 15
MAX_CID must be at least 0 and at most 16383 (The value 0 implies MAX_CID must be at least 0 and at most 16383 (The value 0 implies
having one context). having one context).
skipping to change at page 6, line 17 skipping to change at page 6, line 17
The ROHC protocol is able to compress both IPv6 and IPv4 datagrams. The ROHC protocol is able to compress both IPv6 and IPv4 datagrams.
Both IPCP and IPV6CP are able to negotiate option parameter values Both IPCP and IPV6CP are able to negotiate option parameter values
for ROHC. The ROHC capability negotiated as a whole applies to the for ROHC. The ROHC capability negotiated as a whole applies to the
compression of packets where the outer header is an IPv4 header and 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 an IPv6 header, respectively; e.g., an outer IPv6 header MUST NOT be
sent if the ROHC IP-Compression-Protocol option was not negotiated sent if the ROHC IP-Compression-Protocol option was not negotiated
for IPV6CP. for IPV6CP.
Offering a specific ROHC capability in a Configure-Request in either Offering a specific ROHC capability in a Configure-Request in either
IPCP or IPV6CP indicates that the capability is provided for the 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 negotiated with different values in IPCP and IPV6CP, the result is
that the set of parameters for the entire ROHC channel is the logical that the set of parameter values for the entire ROHC channel is the
union of the two values, i.e., the maximum for MAX_CID, MRRU or logical union of the two values, i.e., the maximum for MAX_CID, MRRU
MAX_HEADER, and the logical union of the suboptions. For the 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 suboption, the logical union is the union of the two sets of
profiles. Note that each new suboption for this option must define profiles. The unified values are kept as valid parameter values for
the meaning of "logical union", if the concept applies. 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 3.1. Sharing Context Identifier Space
For the compression and decompression of IPv4 and IPv6 datagram For the compression and decompression of IPv4 and IPv6 datagram
headers the context identifier space is shared. While the parameter headers the context identifier space is shared. While the parameter
values are independently negotiated, sharing the context identifier values are independently negotiated, sharing the context identifier
spaces becomes more complex when the parameter values differ. Since spaces becomes more complex when the parameter values differ. Since
the compressed packets share context identifier space, the the compressed packets share context identifier space, the
compression engine must allocate context identifiers out of a common compression engine must allocate context identifiers out of a common
pool; for compressed packets, the decompressor has to examine the pool; for compressed packets, the decompressor has to examine the
skipping to change at page 7, line 10 skipping to change at page 7, line 17
The ROHC specification [RFC3095] defines a single header format for The ROHC specification [RFC3095] defines a single header format for
all different types of compressed headers, with a variant for small all different types of compressed headers, with a variant for small
CIDs and a variant for large CIDs. Two PPP Data Link Layer Protocol CIDs and a variant for large CIDs. Two PPP Data Link Layer Protocol
Field values are specified below. Field values are specified below.
ROHC small-CIDs ROHC small-CIDs
The frame contains a ROHC packet with small CIDs as defined in The frame contains a ROHC packet with small CIDs as defined in
[RFC3095]. [RFC3095].
Value: 00SS (hex) [[IANA: to be assigned -- same 00SS as Value: 0003 (hex)
above]]
ROHC large-CIDs ROHC large-CIDs
The frame contains a ROHC packet with large CIDs as defined in The frame contains a ROHC packet with large CIDs as defined in
[RFC3095]. [RFC3095].
Value: 00LL (hex) [[IANA: to be assigned]] Value: 0005 (hex)
5. ROHC Usage Considerations 5. ROHC Usage Considerations
Certain considerations are required for any ROHC-over-X protocol. Certain considerations are required for any ROHC-over-X protocol.
This section describes how some of these are handled for ROHC over This section describes how some of these are handled for ROHC over
PPP. PPP.
5.1. Uncompressed profile 5.1. Uncompressed profile
There is no need for the ROHC uncompressed profile in ROHC over PPP, There is no need for the ROHC uncompressed profile in ROHC over PPP,
skipping to change at page 8, line 46 skipping to change at page 8, line 52
RFCs). The value 255 is reserved for future extensibility of the RFCs). The value 255 is reserved for future extensibility of the
present specification. present specification.
The following suboption identifiers are already allocated: The following suboption identifiers are already allocated:
Suboption Document Usage Suboption Document Usage
identifier identifier
1 RFCthis Profiles 1 RFCthis Profiles
The RFC3006 compressibility hint [RFC3006] for ROHC is 0x00SSpppp, The RFC3006 compressibility hint [RFC3006] for ROHC is 0x0003pppp,
where 0xpppp is the profile assumed. [[IANA: replace 00SS by the where 0xpppp is the profile assumed.
same value above.]]
[[ The PPP protocol identifier values for 00SS and 00LL are to be (Note that the PPP protocol identifier values 0003 and 0005 were
assigned by IANA before publication of this document. As it is taken from a previously reserved space that exhibits inefficient
rather unlikely that ROHC will be used over links with highly transparency in the presence of asynchronous control character
populated ACCMs, this could start using the values reserved for escaping, as it is considered rather unlikely that ROHC will be used
inefficient transparency, e.g. 0003 for 00SS and 0005 for 00LL. ]] over links with highly populated ACCMs.)
8. Acknowledgments 8. Acknowledgments
The present document borrows heavily from [RFC2509]. The present document borrows heavily from [RFC2509].
The author would like to thank Pete McCann and James Carlson for The author would like to thank Pete McCann and James Carlson for
clarifying the multiple option instance issue, and Craig Fox for clarifying the multiple option instance issue, Craig Fox for helping
helping with some PPP arcana. with some PPP arcana, and Lars-Erik Jonsson for supplying some final
clarifications.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994. STD 51, RFC 1661, July 1994.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/