< draft-ietf-rohc-ip-only-02.txt		draft-ietf-rohc-ip-only-03.txt >
	Network Working Group Lars-Erik Jonsson, Ericsson		Network Working Group Lars-Erik Jonsson, Ericsson
	INTERNET-DRAFT Ghyslain Pelletier, Ericsson		INTERNET-DRAFT Ghyslain Pelletier, Ericsson
	Expires: December 2003		Expires: March 2004
	June 27, 2003		September 12, 2003
	RObust Header Compression (ROHC):		RObust Header Compression (ROHC):
	A Compression Profile for IP		A Compression Profile for IP
	<draft-ietf-rohc-ip-only-02.txt>		<draft-ietf-rohc-ip-only-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 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 18 ¶		skipping to change at page 2, line 18 ¶
	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...............................3		3.1. Static chain termination...............................3
	3.2. Handling multiple levels of IP headers.................3		3.2. Handling multiple levels of IP headers.................3
	3.3. Constant IP-ID.........................................4		3.3. Constant IP-ID.........................................4
	3.4. Additional mode transition logic.......................6		3.4. Additional mode transition logic.......................6
	3.5. Initialization.........................................7		3.5. Initialization.........................................7
	3.6. Packet types...........................................8		3.6. Packet types...........................................8
	4. Security Considerations.......................................9		4. Security Considerations.......................................9
	5. IANA Considerations...........................................9		5. IANA Considerations...........................................9
	6. Acknowledgements..............................................9		6. Intellectual Property Right Claim Considerations..............9
	7. References....................................................9		7. Acknowledgements.............................................10
	8. Authors' Addresses...........................................10		8. References...................................................10
			9. Authors' Addresses...........................................10
	Appendix A. Detailed procedures for canceling mode transitions..11		Appendix A. Detailed procedures for canceling mode transitions..11
	A.1. Transition from Optimistic to Reliable mode................11		A.1. Transition from Optimistic to Reliable mode................11
	A.2. Transition from Unidirectional to Reliable mode............12		A.2. Transition from Unidirectional to Reliable mode............12
	A.3. Transition from Reliable to Optimistic mode................12		A.3. Transition from Reliable to Optimistic mode................12
	A.4. Transition back to Unidirectional mode.....................13		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
	skipping to change at page 4, line 6 ¶		skipping to change at page 4, line 6 ¶
	communicate static and/or dynamic parts of a context. For each of the		communicate static and/or dynamic parts of a context. For each of the
	compression profiles defined in [RFC-3095], there is a single last		compression profiles defined in [RFC-3095], there is a single last
	header in the header chain that clearly marks the termination of the		header in the header chain that clearly marks the termination of the
	static chain. The length of the dynamic chain is then inferred from		static chain. The length of the dynamic chain is then inferred from
	the static chain in the IR header itself, or from the static chain in		the static chain in the IR header itself, or from the static chain in
	the context for the IR-DYN header. The length of both static and		the context for the IR-DYN header. The length of both static and
	dynamic chains may thus be of arbitrary length and may, in theory,		dynamic chains may thus be of arbitrary length and may, in theory,
	initialize a context with an arbitrary number of IP levels.		initialize a context with an arbitrary number of IP levels.
	However, the general compressed header formats defined in [RFC-3095,		However, the general compressed header formats defined in [RFC-3095,
	section 5.7.] specifies that a most two levels of IP headers (the		section 5.7.] specifies that at most two levels of IP headers (the
	'Inner' and the 'Outer' level of IP headers) may be included in a		'Inner' and the 'Outer' level of IP headers) may be included in a
	compressed header. Specifically, the format defined for Extension 3		compressed header. Specifically, the format defined for Extension 3
	[RFC-3095, section 5.7.5.] can only carry the 'Outer' IP header. In		[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		addition, while list compression may be used to compress other types
	of headers, it cannot be used to compress additional IP headers as IP		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 may not be part of an extension header chain in compressed
	headers [ROHC, section 5.8.].		headers [ROHC, section 5.8.].
	For the compression profiles defined in [RFC-3095], the consequence		For the compression profiles defined in [RFC-3095], the consequence
	is that at most two levels of IP headers can be compressed. In other		is that at most two levels of IP headers can be compressed. In other
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	Note: All other fields are the same as for ROHC UDP [RFC-3095].		Note: All other fields are the same as for ROHC UDP [RFC-3095].
	3.4. Additional mode transition logic		3.4. Additional mode transition logic
	The profiles defined in [ROHC] operate using different modes of		The profiles defined in [ROHC] operate using different modes of
	compression. A mode transition can be requested once a packet has		compression. A mode transition can be requested once a packet has
	reached the decompressor by sending feedback indicating the desired		reached the decompressor by sending feedback indicating the desired
	mode. As per the specifications found in [ROHC], the compressor is		mode. As per the specifications found in [ROHC], the compressor is
	compelled to honor such request.		compelled to honor such request.
	The Mode parameter for the value mode = 0, for packet types UOR-2, IR		For the IP profile defined in this document, the Mode parameter for
	and IR-DYN, is redefined to allow the compressor to decline a mode		the value mode = 0 (packet types UOR-2, IR and IR-DYN) is redefined
	transition requested by the decompressor:		to allow the compressor to decline a mode transition requested by the
			decompressor:
	Mode: Compression mode. 0 = (C)ancel Mode Transition		Mode: Compression mode. 0 = (C)ancel Mode Transition
	Upon receiving the Mode parameter set to '0', the decompressor MUST		Upon receiving the Mode parameter set to '0', the decompressor MUST
	stay in its current mode of operation and SHOULD refrain from sending		stay in its current mode of operation and SHOULD refrain from sending
	further mode transition requests for a certain amount of time.		further mode transition requests for a certain amount of time.
	More specifically, with reference to the parameters C_TRANS, C_MODE,		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		D_TRANS and D_MODE defined in [ROHC, section 5.6.1.], the following
	modifications apply when the compressor cancels a mode transition:		modifications apply when the compressor cancels a mode transition:
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 22 ¶
	C_TRANS = P |-<-<-<-+ |		C_TRANS = P |-<-<-<-+ |
	C_MODE = X | |		C_MODE = X | |
	|->->->-+ IR/IR-DYN/UOR-2(SN,C) |		|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
	| +->->->->->->->-+ |		| +->->->->->->->-+ |
	|->-.. +->->->-| D_TRANS = P		|->-.. +->->->-| D_TRANS = P
	|->-.. | D_MODE = X		|->-.. | D_MODE = X
	| ACK(SN,X) +-<-<-<-|		| ACK(SN,X) +-<-<-<-|
	| +-<-<-<-<-<-<-<-+ |		| +-<-<-<-<-<-<-<-+ |
	C_TRANS = D |-<-<-<-+ |		C_TRANS = D |-<-<-<-+ |
	| |		| |
	|->->->-+ X-0, X-1* |		|->->->-+ X-0, X-1* |
	| +->->->->->->->-+ |		| +->->->->->->->-+ |
	| +->->->-| D_TRANS = D		| +->->->-| D_TRANS = D
	| |		| |
	where X: mode in use before the mode transition was initiated		where X: mode in use before the mode transition was initiated
	Y: mode requested by the decompressor		Y: mode requested by the decompressor
	C: (C)ancel mode transition		C: (C)ancel mode transition
	3.5. Initialization		3.5. Initialization
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 36 ¶
	registration in the "RObust Header Compression (ROHC) Profile		registration in the "RObust Header Compression (ROHC) Profile
	Identifiers" name space would then be:		Identifiers" name space would then be:
	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. Intellectual Property Right Claim Considerations
	The authors would like to thank Carsten Bormann and Fredrik Lindstr÷m		The IETF has been notified of intellectual property rights claimed in
	for valuable input and review.		regard to some or all of the specification contained in this
			document. For more information consult the online list of claimed
			rights.
	7. References		The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
			7. Acknowledgements
			The authors would like to thank Carsten Bormann, Fredrik Lindstrom,
			Kristofer Sandlund and Mark West for valuable input and review.
			8. 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,
	K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust		K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust
	Header Compression (ROHC)", RFC 3095, July 2001.		Header Compression (ROHC)", RFC 3095, July 2001.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 31 ¶
	[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,
	K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust		K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust
	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. Authors' Addresses		9. Authors' Addresses
	Lars-Erik Jonsson		Lars-Erik Jonsson
	Ericsson AB		Ericsson AB
	Box 920		Box 920
	SE-971 28 Lulea, Sweden		SE-971 28 Lulea, Sweden
	Phone: +46 920 20 21 07		Phone: +46 920 20 21 07
	Fax: +46 920 20 20 99		Fax: +46 920 20 20 99
	Email: lars-erik.jonsson@ericsson.com		Email: lars-erik.jonsson@ericsson.com
	Ghyslain Pelletier		Ghyslain Pelletier
	Box 920		Box 920
	Ericsson AB		Ericsson AB
	SE-971 28 Lulea, Sweden		SE-971 28 Lulea, Sweden
	Phone: +46 920 20 24 32		Phone: +46 920 20 24 32
	Fax: +46 920 20 20 99		Fax: +46 920 20 20 99
	Email: ghyslain.pelletier@epl.ericsson.se		Email: ghyslain.pelletier@ericsson.com
	Appendix A. Detailed procedures for canceling mode transitions		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		The profiles defined in [ROHC] operate using different modes of
	compression: Unidirectional (U-Mode), Bi-directional Optimistic (O-		compression: Unidirectional (U-Mode), Bi-directional Optimistic (O-
	Mode) and Bi-directional Reliable (R-Mode). Compression always starts		Mode) and Bi-directional Reliable (R-Mode). Compression always starts
	in the U-Mode, and mode transitions can only be initiated by the		in the U-Mode, and mode transitions can only be initiated by the
	decompressor [ROHC, section 5.6.]. A mode transition can be requested		decompressor [ROHC, section 5.6.]. A mode transition can be requested
	once a packet has reached the decompressor by sending feedback		once a packet has reached the decompressor by sending feedback
	indicating the desired mode.		indicating the desired mode.
	With reference to the parameters C_TRANS, C_MODE, D_TRANS and D_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		defined in [ROHC, section 5.6.1.], the following sub-sections
	skipping to change at page 14, 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 December 27, 2003.		This Internet-Draft expires March 12, 2004.
End of changes. 15 change blocks.
	21 lines changed or deleted		47 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/