draft-ietf-rohc-over-ppp-02.txt   draft-ietf-rohc-over-ppp-03.txt 
INTERNET-DRAFT Carsten Bormann INTERNET-DRAFT Carsten Bormann
Expires: January 2002 TZI/Uni Bremen Expires: February 2002 TZI/Uni Bremen
July 2001 August 2001
ROHC over PPP ROHC over PPP
draft-ietf-rohc-over-ppp-02.txt draft-ietf-rohc-over-ppp-03.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 6, line 9 skipping to change at page 6, line 9
2n+2 2n+2
Value Value
n octet-pairs in ascending order, each octet-pair specifying n octet-pairs in ascending order, each octet-pair specifying
a ROHC profile supported. a ROHC profile supported.
3. Multiple Network Control Protocols 3. Multiple Network Control Protocols
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. These values apply to the compression of packets where the for ROHC. The ROHC capability negotiated as a whole applies to the
outer header is an IPv4 header and an IPv6 header, respectively. 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
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
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.
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 25 skipping to change at page 7, line 40
demultiplexing method. Therefore, no consideration was given to demultiplexing method. Therefore, no consideration was given to
locking down one of the context numbers for the uncompressed profile locking down one of the context numbers for the uncompressed profile
(see [RFC3095] section 5.1.2). Note, however, that according to the (see [RFC3095] section 5.1.2). Note, however, that according to the
ROHC specification profile 0x0000 must not be rejected [RFC3095], so ROHC specification profile 0x0000 must not be rejected [RFC3095], so
it MUST be implemented by all receivers. it MUST be implemented by all receivers.
5.2. Parameter selection 5.2. Parameter selection
For each of the ROHC channel parameters MAX_CID and MRRU, the value 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 is the maximum of the respective values negotiated for the IPCP and
IPv6CP instances, if any. IPv6CP instances, if any. The ROHC channel parameter FEEDBACK_FOR is
set implicitly to the reverse direction on the same PPP link (see
The ROHC channel parameter FEEDBACK_FOR is set implicitly to the "Sharing Context Identifier Space" above). The ROHC channel
reverse direction on the same PPP link (see "Sharing Context parameter LARGE_CIDS is not used, instead the PPP protocol ID on the
Identifier Space" above). packet is used (see "Demultiplexing of Datagrams" above).
A number of parameters for ROHC must be set correctly for good 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, 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 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 error characteristics of the underlying links. As PPP links are
usually run with a strong error detection scheme [RFC1662], k_1 = n_1 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 = 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 case k values need to be set low enough relative to n values to allow
for limited ability of the CRC to detect errors, i.e., the CRC will for 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, succeed for about 1/8 of the packets even in case of context damage,
 End of changes. 

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