< draft-ietf-rohc-rfc3095bis-framework-03.txt		draft-ietf-rohc-rfc3095bis-framework-04.txt >
	Network Working Group L-E. Jonsson		Network Working Group L-E. Jonsson
	INTERNET-DRAFT G. Pelletier		INTERNET-DRAFT G. Pelletier
	Expires: May 2007 K. Sandlund		Expires: May 2007 K. Sandlund
	Ericsson		Ericsson
	November 6, 2006		November 29, 2006
	The RObust Header Compression (ROHC) Framework		The RObust Header Compression (ROHC) Framework
	<draft-ietf-rohc-rfc3095bis-framework-03.txt>		<draft-ietf-rohc-rfc3095bis-framework-04.txt>
	Status of this memo		Status of this memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	By submitting this Internet-Draft, each author accepts the provisions		By submitting this Internet-Draft, each author accepts the provisions
	of Section 3 of BCP 78.		of Section 3 of BCP 78.
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 31 ¶
	ACK Acknowledgment.		ACK Acknowledgment.
	CID Context Identifier.		CID Context Identifier.
	CO Compressed packet format.		CO Compressed packet format.
	CRC Cyclic Redundancy Check.		CRC Cyclic Redundancy Check.
	IR Initialization and Refresh.		IR Initialization and Refresh.
	IR-DYN Initialization and Refresh, Dynamic part.		IR-DYN Initialization and Refresh, Dynamic part.
	LSB Least Significant Bit(s).		LSB Least Significant Bit(s).
	MRRU Maximum Reconstructed Reception Unit.		MRRU Maximum Reconstructed Reception Unit.
	MSB Most Significant Bit(s).		MSB Most Significant Bit(s).
	MSN Master Sequence Number.		MSN Master Sequence Number.
	NACK Negative Acknowledgement.		NACK Negative Acknowledgment.
	ROHC RObust Header Compression.		ROHC RObust Header Compression.
	2.2. ROHC Terminology		2.2. ROHC Terminology
	Context		Context
	The context of the compressor is the state it uses to compress a		The context of the compressor is the state it uses to compress a
	header. The context of the decompressor is the state it uses to		header. The context of the decompressor is the state it uses to
	decompress a header. Either of these or the two in combination		decompress a header. Either of these or the two in combination
	are usually referred to as "context", when it is clear which is		are usually referred to as "context", when it is clear which is
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 44 ¶
	encoding for sequentially changing fields. The CTCP compressor		encoding for sequentially changing fields. The CTCP compressor
	detects transport-level retransmissions and sends a header that		detects transport-level retransmissions and sends a header that
	updates the entire context when they occur. This repair mechanism		updates the entire context when they occur. This repair mechanism
	does not require any explicit signaling between compressor and		does not require any explicit signaling between compressor and
	decompressor.		decompressor.
	A general IP header compression scheme, IP header compression [16],		A general IP header compression scheme, IP header compression [16],
	improves somewhat on CTCP. IPHC can compress arbitrary IP, TCP, and		improves somewhat on CTCP. IPHC can compress arbitrary IP, TCP, and
	UDP headers. When compressing non-TCP headers, IPHC does not use		UDP headers. When compressing non-TCP headers, IPHC does not use
	delta encoding and is robust. The repair mechanism of CTCP is		delta encoding and is robust. The repair mechanism of CTCP is
	augmented with negative acknowledgements, called CONTEXT_STATE		augmented with negative acknowledgments, called CONTEXT_STATE
	messages, which speeds up the repair. This context repair mechanism		messages, which speeds up the repair. This context repair mechanism
	is thus limited by the round-trip time of the link. IPHC does not		is thus limited by the round-trip time of the link. IPHC does not
	compress RTP headers.		compress RTP headers.
	CRTP [17] is an RTP extension to IPHC. CRTP compresses the 40 octets		CRTP [17] is an RTP extension to IPHC. CRTP compresses the 40 octets
	of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP		of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP
	Checksum is not enabled. If the UDP Checksum is enabled, the minimum		Checksum is not enabled. If the UDP Checksum is enabled, the minimum
	CRTP header is 4 octets.		CRTP header is 4 octets.
	On lossy links with long round-trip times, CRTP does not perform well		On lossy links with long round-trip times, CRTP does not perform well
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 44 ¶
	RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four		RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four
	profiles: RTP, UDP, ESP, and uncompressed", was published 2001, as		profiles: RTP, UDP, ESP, and uncompressed", was published 2001, as
	the first output of the ROHC WG. ROHC is a general and extendable		the first output of the ROHC WG. ROHC is a general and extendable
	framework for header compression, on top of which profiles can be		framework for header compression, on top of which profiles can be
	defined for compression of different protocols headers. RFC 3095		defined for compression of different protocols headers. RFC 3095
	introduced a number of new compression techniques, and was successful		introduced a number of new compression techniques, and was successful
	at living up to the requirements placed on it, as described in [18].		at living up to the requirements placed on it, as described in [18].
	Interoperability testing of RFC 3095 confirms the capabilities of		Interoperability testing of RFC 3095 confirms the capabilities of
	ROHC to meet its purposes, but feedback from implementers have also		ROHC to meet its purposes, but feedback from implementers has also
	indicated that the protocol specification is complex and sometimes		indicated that the protocol specification is complex and sometimes
	obscure. Most importantly, a clear distinction between framework and		obscure. Most importantly, a clear distinction between framework and
	profiles is not obvious in [3], which also makes development of		profiles is not obvious in [3], which also makes development of
	additional profiles troublesome. This document therefore aims at		additional profiles troublesome. This document therefore aims at
	explicitly specifying the ROHC framework, while a companion document		explicitly specifying the ROHC framework, while a companion document
	[8] specifies revised versions of the compression profiles of RFC		[8] specifies revised versions of the compression profiles of RFC
	3095.		3095.
	4.4. Operational Characteristics of the ROHC Channel		4.4. Operational Characteristics of the ROHC Channel
	skipping to change at page 12, line 44 ¶		skipping to change at page 12, line 44 ¶
	function to a sequence number, called the Master Sequence Number		function to a sequence number, called the Master Sequence Number
	(MSN). This function describes the change pattern of the field with		(MSN). This function describes the change pattern of the field with
	respect to a change in the MSN.		respect to a change in the MSN.
	Change patterns include e.g. fields that increase monotonically or by		Change patterns include e.g. fields that increase monotonically or by
	a small value, but also fields that seldom change as well as fields		a small value, but also fields that seldom change as well as fields
	that remain unchanging for the entire lifetime of the packet flow, in		that remain unchanging for the entire lifetime of the packet flow, in
	which case the function to the MSN is equivalent to a constant value.		which case the function to the MSN is equivalent to a constant value.
	The compressor first establishes functions for each of the header		The compressor first establishes functions for each of the header
	fields, and it then reliably communicates the MSN. When the change		fields, and then reliably communicates the MSN. When the change
	pattern of the field does not match the established function, i.e.,		pattern of the field does not match the established function, i.e.,
	the existing function gives a result that is different from the field		the existing function gives a result that is different from the field
	in the header being compressed, additional information can be sent to		in the header being compressed, additional information can be sent to
	update the parameters of that function.		update the parameters of that function.
	The MSN is defined per profile. It can be either derived directly		The MSN is defined per profile. It can be either derived directly
	from one of the fields of the protocol being compressed (e.g. the RTP		from one of the fields of the protocol being compressed (e.g. the RTP
	SN [8]), or it can be created and maintained by the compressor (e.g.		SN [8]), or it can be created and maintained by the compressor (e.g.
	the MSN for compression of UDP in profile 0x0102 [8] or the MSN in		the MSN for compression of UDP in profile 0x0102 [8] or the MSN in
	ROHC-TCP [9]).		ROHC-TCP [9]).
	skipping to change at page 14, line 9 ¶		skipping to change at page 14, line 9 ¶
	The CID space can be either small, which means that CIDs can take the		The CID space can be either small, which means that CIDs can take the
	values 0 through 15, or large, which means that CIDs take values		values 0 through 15, or large, which means that CIDs take values
	between 0 and 2^14 - 1 = 16383. Whether the CID space is large or		between 0 and 2^14 - 1 = 16383. Whether the CID space is large or
	small MUST be established, possibly by negotiation, before any		small MUST be established, possibly by negotiation, before any
	compressed packet may be sent over the ROHC channel.		compressed packet may be sent over the ROHC channel.
	The CID space is distinct for each channel, i.e., CID 3 over channel		The CID space is distinct for each channel, i.e., CID 3 over channel
	A and CID 3 over channel B do not refer to the same context, even if		A and CID 3 over channel B do not refer to the same context, even if
	the endpoints of A and B are the same nodes. In particular, CIDs for		the endpoints of A and B are the same nodes. In particular, CIDs for
	any pair of ROHC channels are not related (two associated ROHC		any pair of ROHC channels are not related (two associated ROHC
	channels serving as feedback channels for one another need not even		channels serving as feedback channels for one another do not even
	have CID spaces of the same size).		need to have CID spaces of the same size).
	5.1.2. Per-Channel Parameters		5.1.2. Per-Channel Parameters
	The ROHC channel is based on a number of parameters that form part of		The ROHC channel is based on a number of parameters that form part of
	the established channel state and the per-context state. The state of		the established channel state and the per-context state. The state of
	the ROHC channel MUST be established before the first ROHC packet may		the ROHC channel MUST be established before the first ROHC packet may
	be sent, which may be achieved using negotiation protocols provided		be sent, which may be achieved using negotiation protocols provided
	by the link layer (see also [4], which describes an option for		by the link layer (see also [4], which describes an option for
	negotiation of ROHC parameters for PPP). This section describes some		negotiation of ROHC parameters for PPP). This section describes some
	of this channel state information in an abstract way:		of this channel state information in an abstract way:
	skipping to change at page 21, line 54 ¶		skipping to change at page 21, line 54 ¶
	interspersed feedback, SHOULD be maintained for the lifetime of the		interspersed feedback, SHOULD be maintained for the lifetime of the
	ROHC channel. Otherwise, it is RECOMMENDED that the compressor be		ROHC channel. Otherwise, it is RECOMMENDED that the compressor be
	notified if the feedback channel is no longer available: the		notified if the feedback channel is no longer available: the
	compressor SHOULD then restart compression by creating a new context		compressor SHOULD then restart compression by creating a new context
	for each packet flow, and SHOULD use a CID value that was not		for each packet flow, and SHOULD use a CID value that was not
	previously associated with the profile used to compress the flow.		previously associated with the profile used to compress the flow.
	5.2.4.1. ROHC Feedback Format		5.2.4.1. ROHC Feedback Format
	ROHC defines three different categories of feedback messages:		ROHC defines three different categories of feedback messages:
	acknowledgement (ACK), negative ACK (NACK) and NACK for the entire		acknowledgment (ACK), negative ACK (NACK) and NACK for the entire
	context (STATIC-NACK). Other type of information may be defined in		context (STATIC-NACK). Other type of information may be defined in
	profile-specific feedback information.		profile-specific feedback information.
	ACK : Acknowledges successful decompression of a packet.		ACK : Acknowledges successful decompression of a packet.
	Indicates that the decompressor considers its context		Indicates that the decompressor considers its context
	to be valid.		to be valid.
	NACK : Indicates that the decompressor considers some or all		NACK : Indicates that the decompressor considers some or all
	of the dynamic part of its context invalid.		of the dynamic part of its context invalid.
	skipping to change at page 30, line 47 ¶		skipping to change at page 30, line 47 ¶
	Bits and groups of bits from the packet format layout, referred		Bits and groups of bits from the packet format layout, referred
	to as compressed fields, represents the result of an encoding		to as compressed fields, represents the result of an encoding
	method specific for that compressed field within a specific		method specific for that compressed field within a specific
	packet format. The profile defines these encoding methods.		packet format. The profile defines these encoding methods.
	o Updating properties		o Updating properties
	The profile-specific packet formats may update the state of the		The profile-specific packet formats may update the state of the
	decompressor, and may do so in different ways. The profile		decompressor, and may do so in different ways. The profile
	defines how individual profile-specific fields, or entire		defines how individual profile-specific fields, or entire
	profile-specific packet types, updates the decompressor context.		profile-specific packet types, update the decompressor context.
	o Verification		o Verification
	Packets that update the state of the decompressor are verified,		Packets that update the state of the decompressor are verified,
	to prevent incorrect updates to the decompressor context. The		to prevent incorrect updates to the decompressor context. The
	profile defines the mechanisms used to verify the decompression		profile defines the mechanisms used to verify the decompression
	of a packet.		of a packet.
	Context management:		Context management:
	skipping to change at page 34, line 31 ¶		skipping to change at page 34, line 31 ¶
	[21] IANA registry, "RObust Header Compression (ROHC) Profile		[21] IANA registry, "RObust Header Compression (ROHC) Profile
	Identifiers", http://www.iana.org/assignments/rohc-pro-ids		Identifiers", http://www.iana.org/assignments/rohc-pro-ids
	[22] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA		[22] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	11. Authors' Addresses		11. Authors' Addresses
	Lars-Erik Jonsson		Lars-Erik Jonsson
	Ericsson AB		Optand 737
	Box 920		SE-831 92 Ostersund, Sweden
	SE-971 28 Lulea, Sweden		Phone: +46 70 365 20 58
	Phone: +46 8 404 29 61		EMail: lars-erik@lejonsson.com
	Fax: +46 920 996 21
	EMail: lars-erik.jonsson@ericsson.com
	Ghyslain Pelletier		Ghyslain Pelletier
	Ericsson AB		Ericsson AB
	Box 920		Box 920
	SE-971 28 Lulea, Sweden		SE-971 28 Lulea, Sweden
	Phone: +46 8 404 29 43		Phone: +46 8 404 29 43
	Fax: +46 920 996 21		Fax: +46 920 996 21
	EMail: ghyslain.pelletier@ericsson.com		EMail: ghyslain.pelletier@ericsson.com
	Kristofer Sandlund		Kristofer Sandlund
	skipping to change at page 37, line 45 ¶		skipping to change at page 37, line 45 ¶
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	This Internet-Draft expires May 6, 2007.		This Internet-Draft expires May 29, 2007.
End of changes. 11 change blocks.
	16 lines changed or deleted		14 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/