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/