< draft-ietf-rohc-ip-only-01.txt		draft-ietf-rohc-ip-only-02.txt >
	Network Working Group L-E. Jonsson		Network Working Group Lars-Erik Jonsson, Ericsson
	INTERNET-DRAFT Ericsson		INTERNET-DRAFT Ghyslain Pelletier, Ericsson
	Expires: July 2003 January 23, 2003		Expires: December 2003
			June 27, 2003
	RObust Header Compression (ROHC):		RObust Header Compression (ROHC):
	A Compression Profile for IP		A Compression Profile for IP
	<draft-ietf-rohc-ip-only-01.txt>		<draft-ietf-rohc-ip-only-02.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 RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	in RFC 3095. This document defines a ROHC compression profile for IP,		in RFC 3095. This document defines a ROHC compression profile for IP,
	similar to the IP/UDP profile defined by RFC 3095, but simplified to		similar to the IP/UDP profile defined by RFC 3095, but simplified to
	exclude UDP, and enhanced to compress IP header chains of arbitrary		exclude UDP, and enhanced to compress IP header chains of arbitrary
	length.		length.
	Table of Contents		Table of Contents
	1. Introduction..................................................2		1. Introduction..................................................2
	2. Terminology...................................................3		2. Terminology...................................................3
	3. ROHC IP Compression (Profile 0x0004)..........................3		3. ROHC IP Compression (Profile 0x0004)..........................3
	3.1. Static chain termination and multiple IP headers.......3		3.1. Static chain termination...............................3
	3.2. Initialization.........................................4		3.2. Handling multiple levels of IP headers.................3
	3.3. Packet types...........................................5		3.3. Constant IP-ID.........................................4
	4. Security Considerations.......................................6		3.4. Additional mode transition logic.......................6
	5. IANA Considerations...........................................6		3.5. Initialization.........................................7
	6. Acknowledgements..............................................6		3.6. Packet types...........................................8
	7. References....................................................6		4. Security Considerations.......................................9
	8. Author's Address..............................................7		5. IANA Considerations...........................................9
			6. Acknowledgements..............................................9
			7. References....................................................9
			8. Authors' Addresses...........................................10
			Appendix A. Detailed procedures for canceling mode transitions..11
			A.1. Transition from Optimistic to Reliable mode................11
			A.2. Transition from Unidirectional to Reliable mode............12
			A.3. Transition from Reliable to Optimistic mode................12
			A.4. Transition back to Unidirectional mode.....................13
	1. Introduction		1. Introduction
	The original RObust Header Compression (ROHC) RFC [RFC-3095] defines		The original RObust Header Compression (ROHC) RFC [RFC-3095] defines
	a framework for header compression, along with compression protocols		a framework for header compression, along with compression protocols
	(profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for		(profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for
	uncompressed packet streams. The profile for uncompressed data was		uncompressed packet streams. The profile for uncompressed data was
	defined to provide means to encapsulate all traffic over a link		defined to provide means to encapsulate all traffic over a link
	within ROHC packets. Through this profile, the lower layers do not		within ROHC packets. Through this profile, the lower layers do not
	have to provide multiplexing for different packet types, but instead		have to provide multiplexing for different packet types, but instead
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 30 ¶
	In general, there are no major difference between the ROHC UDP		In general, there are no major difference between the ROHC UDP
	profile and the IP profile (ROHC IP) defined in this document, since		profile and the IP profile (ROHC IP) defined in this document, since
	the removal of UDP has no impact on the compression mechanisms. As		the removal of UDP has no impact on the compression mechanisms. As
	for ROHC UDP, the compressor generates a 16-bit sequence number which		for ROHC UDP, the compressor generates a 16-bit sequence number which
	increases by one for each packet compressed in the packet stream,		increases by one for each packet compressed in the packet stream,
	simply called SN below. The most important difference between this		simply called SN below. The most important difference between this
	profile and ROHC UDP is about static chain termination and handling		profile and ROHC UDP is about static chain termination and handling
	of multiple IP headers. Unless stated explicitly below, mechanisms		of multiple IP headers. Unless stated explicitly below, mechanisms
	and formats are as for ROHC UDP.		and formats are as for ROHC UDP.
	3.1. Static chain termination and multiple IP headers		3.1. Static chain termination
	The most important difference for IP-only compression, compared to		One difference for IP-only compression, compared to IP/UDP
	IP/UDP compression, is about how to terminate compression, i.e. how		compression, is related to the termination of the static chain in IR
	to end the static chain in IR headers. For the UDP profile, the chain		headers. For the UDP profile, the chain always ends with a UDP header
	always ends with a UDP header part, which per definition terminates		part, which per definition provides the boundaries for the chain. The
	compression, and the UDP header is also the last header in the		UDP header is also the last header in the uncompressed packet (except
	uncompressed packet (except for potential application header). For		for potential application header). For the IP-only profile, there is
	the case of IP-only compression, there is no single last header that		no single last header that per profile definition terminates the
	per profile definition terminates the chain. Instead, the static		chain. Instead, the static chain is terminated if the "Next Header /
	chain is terminated if the "Next Header / Protocol" field of a static		Protocol" field of a static IP header part indicates anything but IP
	IP header part indicates anything but IP (IPinIP or IPv6).		(IPinIP or IPv6).
	Another difference with IP-only compression is related to the		3.2. Handling multiple levels of IP headers
	potential compression of multiple IP headers. ROHC UDP can compress
	at most two IP headers, but additional IP headers would completely
	disable the use of header compression, since the compressed chain
	must end with the UDP header part. However, as there is no single
	packet type that ends the compressed chain with the IP profile,
	additional IP headers would not have to cause header compression to
	be disabled. By implicitly terminating the chain after at most 2 IP
	headers, additional IP headers could just be left uncompressed.
	The IP profile defined in this document goes one step further, and		The ROHC IR and IR-DYN packets defined in [RFC-3095] are used to
	supports compression of an arbitrary number of IP headers. The static		communicate static and/or dynamic parts of a context. For each of the
	chain can obviously be of an arbitrary length, and is simply		compression profiles defined in [RFC-3095], there is a single last
	terminated through the presence of a non-IP header (not IPinIP nor		header in the header chain that clearly marks the termination of the
	IPv6). The dynamic chain is structured analogously. In compressed		static chain. The length of the dynamic chain is then inferred from
	packet headers, header information related to the initial two IP		the static chain in the IR header itself, or from the static chain in
	headers are carried as in the IP/UDP profile, while a dynamic header		the context for the IR-DYN header. The length of both static and
	chain is added at the end of the compressed header for each and every		dynamic chains may thus be of arbitrary length and may, in theory,
	additional IP header. The data structure used for these header		initialize a context with an arbitrary number of IP levels.
	portions in compressed headers is thus exactly the same as the one
	used in IR and IR-DYN packets.
	The following sections describe how the IP profile differs from the		However, the general compressed header formats defined in [RFC-3095,
	IP/UDP profile, providing the details of the general principles		section 5.7.] specifies that a most two levels of IP headers (the
	described in the previous paragraph.		'Inner' and the 'Outer' level of IP headers) may be included in a
			compressed header. Specifically, the format defined for Extension 3
			[RFC-3095, section 5.7.5.] can only carry the 'Outer' IP header. In
			addition, while list compression may be used to compress other types
			of headers, it cannot be used to compress additional IP headers as IP
			headers may not be part of an extension header chain in compressed
			headers [ROHC, section 5.8.].
	3.2. Initialization		For the compression profiles defined in [RFC-3095], the consequence
			is that at most two levels of IP headers can be compressed. In other
			words, the presence of additional IP headers at best partially
			disables header compression and compression will not go beyond the IR
			state (as only IR and IR-DYNs can be used in such case).
			For the compression of IP headers only, the additional IP headers
			would however not have to cause header compression to be disabled
			because there is no single packet type that ends the compressed
			chain. The excess IP headers could simply be left uncompressed by
			implicitly terminating the static and dynamic chains after at most
			two levels of IP headers.
			The IP-only profile defined in this document takes one step further
			and supports compression of an arbitrary number of IP levels. This is
			achieved by adding a dynamic chain to the general format of
			compressed headers, to include the header part of each IP level in
			excess of the first two.
			As explained above, the static chain within IR packets can be of
			arbitrary length, and the chain is terminated by the presence of a
			non-IP header (not IPinIP nor IPv6). The dynamic chain is structured
			analogously.
			For compressed headers, the information related to the initial two IP
			headers is carried as for the IP/UDP profile, and a chain of dynamic
			header information is added to the end of the compressed header for
			each and every additional IP header. This additional data structure
			is thus exactly the same as the one used in IR and IR-DYN packets.
			The length of the chain is inferred from the chain of static
			parameters in the context. While a dynamic chain carries dynamically
			changing parameters using an uncompressed representation, this
			ensures that flows with arbitrary levels of IP headers will not
			impair compression efficiency.
			3.3. Constant IP-ID
			Most IPv4 stacks assigns IP-ID according to the value of a counter
			increasing by one for each outgoing packet. ROHC UDP compresses the
			IP-ID field using offset IP-ID encoding based on the UDP SN [RFC-
			3095]. For stacks generating IP-ID values using a pseudo-random
			number generator, the field is not compressed and is sent as-is in
			its entirety as additional octets after the compressed header.
			Cases have also been found where an IPv4 stack uses a constant value
			for the IP Identifier. When the IP-ID field is constant, it cannot be
			compressed using offset IP-ID encoding and the field must be sent in
			its entirety. This overhead can be avoided with the addition of a
			flag within the dynamic part of the chain used to initialize the IPv4
			header, as follow:
			Dynamic part:
			+---+---+---+---+---+---+---+---+
			| Type of Service |
			+---+---+---+---+---+---+---+---+
			| Time to Live |
			+---+---+---+---+---+---+---+---+
			/ Identification / 2 octets
			+---+---+---+---+---+---+---+---+
			| DF|RND|NBO|SID| 0 |
			+---+---+---+---+---+---+---+---+
			/ Generic extension header list / variable length
			+---+---+---+---+---+---+---+---+
			SID: Static IP Identifier.
			For IR and IR-DYN packets, the logic is the same as for ROHC UDP
			with the addition that field(SID) must be kept in the context.
			For compressed headers other than IR and IR-DYN:
			If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is
			compressed using Offset IP-ID encoding (see [RFC-3095 section
			4.5.5]) using p = 0 and default-slope(IP-ID offset) = 0.
			If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant
			and compressed away; hdr(IP-ID) is the value of context(IP-ID).
			If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID
			is then passed as additional octets at the end of the
			compressed header, after any extensions.
			Note: Only IR and IR-DYN packets can update context(SID).
			Note: All other fields are the same as for ROHC UDP [RFC-3095].
			3.4. Additional mode transition logic
			The profiles defined in [ROHC] operate using different modes of
			compression. A mode transition can be requested once a packet has
			reached the decompressor by sending feedback indicating the desired
			mode. As per the specifications found in [ROHC], the compressor is
			compelled to honor such request.
			The Mode parameter for the value mode = 0, for packet types UOR-2, IR
			and IR-DYN, is redefined to allow the compressor to decline a mode
			transition requested by the decompressor:
			Mode: Compression mode. 0 = (C)ancel Mode Transition
			Upon receiving the Mode parameter set to '0', the decompressor MUST
			stay in its current mode of operation and SHOULD refrain from sending
			further mode transition requests for a certain amount of time.
			More specifically, with reference to the parameters C_TRANS, C_MODE,
			D_TRANS and D_MODE defined in [ROHC, section 5.6.1.], the following
			modifications apply when the compressor cancels a mode transition:
			Parameters for the compressor side:
			- C_MODE:
			This value must not be changed when sending mode information
			within packets when the mode parameter set to '0' (as a
			response to a mode transition request from the decompressor).
			- C_TRANS:
			C_TRANS is (P)ending when receiving a mode transition request
			from the decompressor. C_TRANS is set to (D)one when the
			compressor receives an ACK for a UOR-2, IR-DYN, or IR packet
			sent with the mode parameter set to the mode in use at the time
			when the mode transition request was initiated.
			Parameters for the decompressor side:
			- D_MODE:
			D_MODE MUST remain unchanged when receiving a UOR-2, an IR-DYN,
			or an IR packet sent with the mode parameter set to '0'.
			- D_TRANS:
			D_TRANS is (P)ending when a UOR-2, IR-DYN, or IR packet sent
			with the mode parameter set to '0' is received. It is set to
			(D)one when a packet of type 1 or 0 corresponding to the
			unchanged mode is received.
			The resulting mode transition procedure is described below:
			Compressor Decompressor
			----------------------------------------------
			C_MODE = X | | D_MODE = X
			| Mode Request(Y) +-<-<-<-| D_TRANS = I
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = P |-<-<-<-+ |
			C_MODE = X | |
			|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
			| +->->->->->->->-+ |
			|->-.. +->->->-| D_TRANS = P
			|->-.. | D_MODE = X
			| ACK(SN,X) +-<-<-<-|
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = D |-<-<-<-+ |
			| |
			|->->->-+ X-0, X-1* |
			| +->->->->->->->-+ |
			| +->->->-| D_TRANS = D
			| |
			where X: mode in use before the mode transition was initiated
			Y: mode requested by the decompressor
			C: (C)ancel mode transition
			3.5. Initialization
	The static context for ROHC IP compression can be initialized in		The static context for ROHC IP compression can be initialized in
	either of two ways:		either of two ways:
	1) By using an IR packet as in ROHC UDP, where the profile is		1) By using an IR packet as in ROHC UDP, where the profile is
	0x0004, and the static chain ends with the static part of an		0x0004, and the static chain ends with the static part of an
	IP header, where the Next Header/Protocol field has any value but		IP header, where the Next Header/Protocol field has any value but
	IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is		IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is
	initialized to a random value when the first IR packet is sent.		initialized to a random value when the first IR packet is sent.
	skipping to change at page 4, line 39 ¶		skipping to change at page 7, line 55 ¶
	with an IP header where the Next Header/Protocol field has any		with an IP header where the Next Header/Protocol field has any
	value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor,		value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor,
	SN is initialized to a random value when the first IR-DYN packet		SN is initialized to a random value when the first IR-DYN packet
	is sent.		is sent.
	For ROHC IP, the dynamic part of an IR or IR-DYN packet is similar to		For ROHC IP, the dynamic part of an IR or IR-DYN packet is similar to
	the one for ROHC UDP, with a two-octet field containing the SN		the one for ROHC UDP, with a two-octet field containing the SN
	present at the end of the dynamic chain in IR and IR-DYN packets. It		present at the end of the dynamic chain in IR and IR-DYN packets. It
	should be noted that the static and dynamic chains have an arbitrary		should be noted that the static and dynamic chains have an arbitrary
	length, and the SN is added only once, at the end of the dynamic		length, and the SN is added only once, at the end of the dynamic
	chain in IR and IR-DYN packets. Note further that additional dynamic		chain in IR and IR-DYN packets.
	chains in compressed packets do not have this sequence number at the
	end of the chain, as SN is present within compressed base headers.
	3.3. Packet types		3.6. Packet types
	The only packet format that differs from ROHC UDP is the general		The only packet format that differs from ROHC UDP is the general
	format for compressed packets, which has no UDP checksum in the end.		format for compressed packets, which has no UDP checksum in the end.
	Instead, it ends with a list of dynamic header portions, one for each		Instead, it ends with a list of dynamic header portions, one for each
	IP header above the initial two (if any, as indicated by the presence		IP header above the initial two (if any, as indicated by the presence
	of corresponding header portions in the static chain).		of corresponding header portions in the static chain).
	The general format for a compressed header is thus as follows:		The general format for a compressed header is thus as follows:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	skipping to change at page 5, line 33 ¶		skipping to change at page 8, line 33 ¶
	: : |		: : |
	+---+---+---+---+---+---+---+---+ |		+---+---+---+---+---+---+---+---+ |
	/ remainder of base header / |		/ remainder of base header / |
	+---+---+---+---+---+---+---+---+ |		+---+---+---+---+---+---+---+---+ |
	: : |		: : |
	/ Extension / |		/ Extension / |
	: : |		: : |
	--- --- --- --- --- --- --- --- |		--- --- --- --- --- --- --- --- |
	: : |		: : |
	+ IP-ID of outer IPv4 header +		+ IP-ID of outer IPv4 header +
	: : (see section 5.7 or [RFC-3095])		: : (see section 5.7 of [RFC-3095])
	--- --- --- --- --- --- --- ---		--- --- --- --- --- --- --- ---
	/ AH data for outer list / |		/ AH data for outer list / |
	--- --- --- --- --- --- --- --- |		--- --- --- --- --- --- --- --- |
	: : |		: : |
	+ GRE checksum + |		+ GRE checksum + |
	: : |		: : |
	--- --- --- --- --- --- --- --- |		--- --- --- --- --- --- --- --- |
	: : |		: : |
	+ IP-ID of inner IPv4 header + |		+ IP-ID of inner IPv4 header + |
	: : |		: : |
	skipping to change at page 6, line 5 ¶		skipping to change at page 9, line 5 ¶
	--- --- --- --- --- --- --- --- |		--- --- --- --- --- --- --- --- |
	: : |		: : |
	+ GRE checksum + |		+ GRE checksum + |
	: : |		: : |
	--- --- --- --- --- --- --- ---		--- --- --- --- --- --- --- ---
	: List of :		: List of :
	/ Dynamic chains / variable, given by static chain		/ Dynamic chains / variable, given by static chain
	: for additional IP headers : (includes no SN)		: for additional IP headers : (includes no SN)
	--- --- --- --- --- --- --- ---		--- --- --- --- --- --- --- ---
			Note that the list of dynamic chains for the additional IP headers in
			compressed packets do not have a sequence number at the end of the
			chain, as SN is present within compressed base headers.
	4. Security Considerations		4. Security Considerations
	The security considerations of [RFC-3095] apply equally to this		The security considerations of [RFC-3095] apply equally to this
	document, without exceptions or additions.		document, without exceptions or additions.
	5. IANA Considerations		5. IANA Considerations
	ROHC profile identifier 0x0004 has been reserved by the IANA for the		ROHC profile identifier 0x0004 has been reserved by the IANA for the
	profile defined in this document.		profile defined in this document.
	skipping to change at page 6, line 34 ¶		skipping to change at page 9, line 38 ¶
	OLD: 0xnn04 To be Assigned by IANA		OLD: 0xnn04 To be Assigned by IANA
	NEW: 0x0004 ROHC IP [RFCXXXX (this)]		NEW: 0x0004 ROHC IP [RFCXXXX (this)]
	0xnn04 Reserved		0xnn04 Reserved
	{ END OF NOTE }		{ END OF NOTE }
	6. Acknowledgements		6. Acknowledgements
	The author would like to thank Carsten Bormann and Ghyslain Pelletier		The authors would like to thank Carsten Bormann and Fredrik Lindstr÷m
	for valuable input and review.		for valuable input and review.
	7. References		7. References
	[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,		[RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
	H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,		H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
	Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,		Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
	skipping to change at page 7, line 5 ¶		skipping to change at page 10, line 8 ¶
	Header Compression (ROHC)", RFC 3095, July 2001.		Header Compression (ROHC)", RFC 3095, July 2001.
	[RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981.		[RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981.
	[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at:		[PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at:
	http://www.iana.org/assignments/protocol-numbers		http://www.iana.org/assignments/protocol-numbers
	8. Author's Address		8. Authors' Addresses
	Lars-Erik Jonsson Tel: +46 920 20 21 07		Lars-Erik Jonsson
	Ericsson AB Fax: +46 920 20 20 99		Ericsson AB
	Box 920		Box 920
	SE-971 28 Lulea		SE-971 28 Lulea, Sweden
	Sweden EMail: lars-erik.jonsson@ericsson.com
			Phone: +46 920 20 21 07
			Fax: +46 920 20 20 99
			Email: lars-erik.jonsson@ericsson.com
			Ghyslain Pelletier
			Box 920
			Ericsson AB
			SE-971 28 Lulea, Sweden
			Phone: +46 920 20 24 32
			Fax: +46 920 20 20 99
			Email: ghyslain.pelletier@epl.ericsson.se
			Appendix A. Detailed procedures for canceling mode transitions
			[Author's note: This appendix may be removed before publication]
			The profiles defined in [ROHC] operate using different modes of
			compression: Unidirectional (U-Mode), Bi-directional Optimistic (O-
			Mode) and Bi-directional Reliable (R-Mode). Compression always starts
			in the U-Mode, and mode transitions can only be initiated by the
			decompressor [ROHC, section 5.6.]. A mode transition can be requested
			once a packet has reached the decompressor by sending feedback
			indicating the desired mode.
			With reference to the parameters C_TRANS, C_MODE, D_TRANS and D_MODE
			defined in [ROHC, section 5.6.1.], the following sub-sections
			describe the resulting procedures when a compressor declines a mode
			transition request from the decompressor as described in section 3.4.
			A.1. Transition from Optimistic to Reliable mode
			When the decompressor initiates a mode transition from Optimistic to
			Reliable mode, the cancellation of the transition procedure is
			described as follows:
			Compressor Decompressor
			----------------------------------------------
			| |
			| ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = P |-<-<-<-+ |
			C_MODE = O | |
			|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
			| +->->->->->->->-+ |
			|->-.. +->->->-| D_TRANS = P
			|->-.. | D_MODE = O
			| ACK(SN,O) +-<-<-<-|
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = D |-<-<-<-+ |
			| |
			|->->->-+ UO-0, UO-1* |
			| +->->->->->->->-+ |
			| +->->->-| D_TRANS = D
			The compressor must not send packet types 1 or 0 when C_TRANS is P,
			i.e. not until it has received an ACK for a UOR-2, IR-DYN, or IR
			packet sent with the mode transition parameter set to C. When the
			decompressor receives a UOR-2, IR-DYN, or IR packet sent with the
			mode transition parameter set to C, it must keep the value D_MODE to
			O and it sets D_TRANS to P. When the decompressor receives packet
			types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it
			sets D_TRANS to D.
			A.2. Transition from Unidirectional to Reliable mode
			The cancellation of a transition from Unidirectional to Reliable mode
			follows the same procedure as defined in section 4.2 above.
			A.3. Transition from Reliable to Optimistic mode
			When the decompressor initiates a mode transition from Reliable to
			Optimistic mode, the cancellation of the transition procedure is
			described as follows:
			Compressor Decompressor
			----------------------------------------------
			| |
			| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = P |-<-<-<-+ |
			C_MODE = R | |
			|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
			| +->->->->->->->-+ |
			|->-.. +->->->-| D_MODE = R
			|->-.. |
			| ACK(SN,R) +-<-<-<-|
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = D |-<-<-<-+ |
			| |
			|->->->-+ R-0, R-1* |
			| +->->->->->->->-+ |
			| +->->->-| D_TRANS = D
			| |
			The compressor must not send packet types 1 or 0 when C_TRANS is P,
			i.e. not until it has received an ACK for a UOR-2, IR-DYN, or IR
			packet sent with the mode transition parameter set to C. When the
			decompressor receives a UOR-2, IR-DYN, or IR packet sent with the
			mode transition parameter set to C, it must keep the value D_MODE to
			R. When the decompressor receives packet types 0 or 1, after having
			ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
			A.4. Transition back to Unidirectional mode
			When the decompressor initiates a mode transition from Reliable or
			Optimistic mode back to Unidirectional mode, the cancellation of the
			transition procedure is described as follows:
			Compressor Decompressor
			----------------------------------------------
			| |
			| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = P |-<-<-<-+ |
			C_MODE = O/R| |
			|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
			| +->->->->->->->-+ |
			|->-.. +->->->-|
			|->-.. |
			| ACK(SN,O/R) +-<-<-<-|
			| +-<-<-<-<-<-<-<-+ |
			C_TRANS = D |-<-<-<-+ |
			| R-0, R-1* or |
			|->->->-+ UO-0, UO-1* |
			| +->->->->->->->-+ |
			| +->->->-| D_TRANS = D
			D_MODE = O/R
			When the decompressor receives a UOR-2, IR-DYN, or IR packet sent
			with the mode transition parameter set to C, it must keep the value
			D_MODE to the bi-directional mode already in use (either O- or R-
			mode). After ACKing the first UOR-2(C), IR-DYN(C), or IR(C), the
			decompressor MUST continue to send feedback with the Mode parameter
			set to the bi-directional mode in use (either O- or R-mode) until it
			receives packet types 0 or 1. When the decompressor receives packet
			types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it
			sets D_TRANS to D.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	skipping to change at page 8, line 33 ¶		skipping to change at page 14, line 33 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	This Internet-Draft expires July 23, 2003.		This Internet-Draft expires December 27, 2003.
End of changes. 18 change blocks.
	58 lines changed or deleted		364 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/