< draft-ietf-rohc-rtp-lla-r-mode-02.txt		draft-ietf-rohc-rtp-lla-r-mode-03.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group Zhigang Liu		RFC 3408
	INTERNET-DRAFT Khiem Le
	Expires: July 24 2002 Nokia
	January 24, 2002
	0-byte Support for R-mode in Extended Link-Layer Assisted ROHC Profile
	<draft-ietf-rohc-rtp-lla-r-mode-02.txt>
	Status of This Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This document is a submission of the IETF ROHC WG. Comments should be
	directed to its mailing list, rohc@cdt.luth.se.
	Abstract
	This document defines a new profile that extends the link-layer
	assisted ROHC profile [LLA-ROHC] to provide 0-byte solution for R-
	mode.
	1. Introduction
	[LLA-ROHC] defines a U/O-mode only 0-byte solution for compression of
	IP/UDP/RTP packets. This document defines a new profile that extends
	the profile defined in [LLA-ROHC] to provide 0-byte support for R-
	mode. The new profile allows a header-free packet format to be used
	in all modes to replace the majority of the 1-octet header of ROHC
	RTP packets sent during normal operation. Specifically, the
	compressor operating in R-mode is allowed to deliver an NHP packet
	when it would have used a ROHC R-0 [ROHC].
	For simplification, this profile is defined in the form of additions
	and exceptions to [LLA-ROHC] that are required to extend the LLA-ROHC
	profile with 0-byte support for R-mode. All terminologies used in
	this document are the same as in [LLA-ROHC].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.
	2. Extensions to the assisting layer (AL) interface
	This section describes additions (some are optional) to the assisting
	layer interface as defined in [LLA-ROHC, section 4.2].
	2.1. Additional parameters to the compressor to AL interface
	- Mode, indicating the mode in which the compressor is operating.
	The AL has slightly different logic depending on the mode value.
	- SN_ACKed, indicating the latest RTP SN that has been acknowledged.
	It is used only when Mode value = R-mode.
	Note that these two parameters MUST always be attached to every
	packet delivered to the AL.
	2.2. Additional interface, assisting layer to compressor
	To improve the compression efficiency of this profile in some
	specific cases, e.g. when the AL operates in such a way that it often
	becomes unsafe to send NHPs, it is RECOMMENDED to implement this
	additional interface. Here, the word "unsafe" means that the
	compressor allows the AL to send NHP but the AL cannot guarantee that
	the RTP SN of the NHP will be correctly decompressed at the receiving
	side. The interface is used to carry update_request as described in
	section 3. Note that this interface is not required in the sense that
	the impossibility of implementing such an interface should not be an
	obstacle to implement this profile over a specific link.
	3. R-mode operation
	For the R-mode, this profile extends ROHC RTP by performing a mapping
	of the R-0 packet to the NHP packet. Note that R-0 is the only type
	of packets in R-mode that can be replaced with NHP.
	On the receiving side, the RTP SN of an NHP is determined by the
	decompressor as = SN_Ref_D + Offset_D, where SN_Ref_D is the RTP SN
	of the last update packet received by the decompressor, and Offset_D
	the sequence number offset between the NHP and the last update
	packet. How to derive Offset_D depends on the implementation of this
	profile over a specific link technology and must be specified in the
	implementation document(s). For example, it can be calculated by
	counting the total number of non-context-updating packets (including
	NHPs) and packet loss indications received since the last successful
	context update. Alternatively, it can be derived using the link
	timing in the case where the linear mapping between RTP SN and link
	timing is maintained.
	On the transmitting side, the AL follows the same rule defined in
	section 4.1.1 of [LLA-ROHC] to determine whether it can send NHP or
	not, with one modification. That is, when the AL determines that it
	has become unsafe (see section 2.2) to send NHPs, the AL records the
	corresponding RTP SN as SN_break. Then it waits until the rule is
	satisfied again and SN_ACKed > SN_break before it resumes sending
	NHPs. The latter condition is essentially the counterpart of
	optimistic approach agreement [LLA-ROHC, section 4.3] of U/O-mode
	which states that when the AL in U/O-mode determines it is unsafe to
	send NHP, it must send headers in the subsequent X packets, where X
	is some agreed number. There are two reasons for the difference: a)
	R-mode relies on acknowledgements to synchronize contexts, instead of
	optimistic approach principle as in U/O-mode; and b) R-0 packets do
	not update decompressor context while UO-0 packets do. To meet the
	condition SN_ACKed > SN_break, the AL can either wait passively for
	the compressor to send a context update packet (e.g. R-0-CRC
	triggered by 6-bit SN wrap-around), or send an update_request via the
	interface from AL to the compressor (section 2.2) to request the
	compressor to send a context updating packet. The update_request
	carries the last SN_break. Upon receiving an update_request, the
	compressor can send R-0-CRC or some other context updating packet.
	Context updating packets are handled as in [ROHC].
	Note: the passive waiting as described above might take a long time
	in the worst case, during which NHPs cannot be sent. Therefore,
	sending update_request via the optional AL to compressor interface is
	RECOMMENDED to improve the worst case performance.
	Note: the update_request may be lost if the AL and compressor are at
	different locations and the channel between them are unreliable, but
	such a loss only delays the AL from resuming sending NHP. Therefore,
	how frequent the AL sends update_request is an implementation issue.
	For example, the AL may send one update_request for each packet it
	receives from the compressor until the conditions to send NHP are
	met. How quickly the compressor sends a context updating packet upon
	receiving an update_request is also an implementation issue.
	Note: as no CRC field is present in R-0 packets, only the function
	related to RTP SN and packet type identifier needs to be replaced.
	In addition, NHP packets and packet loss indications in R-mode do not
	update either the compressor or the decompressor context (as opposed
	to U/O-mode). Consequently, the secure reference principle [ROHC,
	section 5.5] is not affected in any way and there is no loss of
	robustness in this profile compared to ROHC RTP.
	4. Differences between R-mode and U/O-mode
	This section clarifies some differences between R-mode and U/O-mode
	in this profile.
	a) CRC replacement
	Unlike U/O-mode, CRC replacement [LLA-ROHC, section 3.3] is not an
	issue for R-mode since R-0 packets do not carry CRC field.
	b) Periodic context verification
	For U/O-mode, periodic context verification [LLA-ROHC, section
	4.6] is RECOMMENDED to provide additional protection against
	damage propagation after CRC is replaced. For R-mode, since there
	is no CRC replacement (see above), no change to ROHC RTP is needed
	in this regard. In particular, R-mode has this feature naturally
	built-in, since the sending of R-0-CRC when 6-bit SN wraps around
	implicitly provides periodic context verification for R-mode.
	c) CV-REQUEST option
	For the same reasons as above, the decompressor operating in R-
	mode SHOULD NOT send CV-REQUEST [LLA-ROHC, section 4.5] to
	compressor. This is to avoid unnecessary overhead on the feedback
	channel.
	d) Context Check Packet (CCP)
	When CCP [LLA-ROHC, section 4.1.3] is used, compressor operating
	in R-mode SHOULD set C-bit to 0 (zero) and not generate 7-bit CRC
	if computation cost at compressor and decompressor causes concern.
	The use of the CRC field in CCP to perform decompressor context
	verification is not critical in R-mode (see last note of section 3
	and item b) above).
	e) Handling of Acknowledgements (ACKs)
	Special care in the realization of ACKs should be taken for R-mode
	implementations. It is RECOMMENDED to avoid the use of
	interspersed feedback packets [ROHC, section 5.2.1] to carry ACK
	information. The reason is that interspersed feedback packets
	will interrupt the RTP SN sequencing and thus temporarily disable
	the sending of NHPs.
	5. IANA considerations
	A ROHC profile identifier must be reserved by the IANA for the
	profile defined in this document, preferably 0x01SS, where 0x00SS is
	the profile identifier assigned for LLA [LLA-ROHC].
	6. Acknowledgements
	The authors would like to thank Lars-Erik Jonsson and Ghyslain
	Pelletier for intriguing discussions on LLA that helped to nail down
	the R-mode operation. The authors also appreciate valuable input from
	Carsten Bormann, Christopher Clanton, Mark Cheng, and Thinh
	Nguyenphu.
	7. References		Title: Zero-byte Support for Reliable
			Bidirectional Mode (R-mode) in Extended Link-Layer
			Assisted RObust Header Compression (ROHC) Profile
			Author(s): Z. Liu, K. Le
			Status: Standards Track
			Date: December 2002
			Mailbox: zhigang.c.liu@nokia.com, khiem.le@nokia.com
			Pages: 7
			Characters: 14805
			Updates/Obsoletes/SeeAlso: None
	[LLA-ROHC] Lars-Erik Jonsson and Ghyslain Pelletier, "A Link-Layer		I-D Tag: draft-ietf-rohc-rtp-lla-r-mode-03.txt
	Assisted ROHC Profile for IP/UDP/RTP", Internet Draft,
	work in progress, October 2001. <draft-ietf-rohc-rtp-
	lla-03.txt>
	[ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)",		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3408.txt
	RFC 3095, July 2001.
	8. Authors' Addresses		This document defines an additional mode of the link-layer assisted
			RObust Header Compression (ROHC) profile, also known as the zero-byte
			profile, beyond the two defined in RFC 3242. Zero-byte header
			compression exists in order to prevent the single-octet ROHC header
			from pushing a packet voice stream into the next higher fixed packet
			size for the radio. It is usable in certain widely deployed older
			air interfaces. This document adds the zero-byte operation for ROHC
			Bidirectional Reliable mode (R-mode) to the ones specified for
			Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes
			of header compression in RFC 3242.
	Zhigang Liu Khiem Le		This document is a product of the Robust Header Compression Working
	Nokia Research Center Nokia Research Center		Group of the IETF.
	6000 Connection Drive 6000 Connection Drive
	Irving, TX 75039 Irving, TX 75039
	USA USA
	Phone: +1 972 894-5935 Phone: +1 972 894-4882		This is now a Proposed Standard Protocol.
	Fax: +1 972 894-4589 Fax: +1 972 894-4589
	E-mail: zhigang.c.liu@nokia.com E-mail: khiem.le@nokia.com
	9. Full copyright statement		This document specifies an Internet standards track protocol for
			the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	Copyright (C) The Internet Society (2002). All Rights Reserved.		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	This document and translations of it may be copied and furnished to		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	others, and derivative works that comment on or otherwise explain it		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	or assist in its implementation may be prepared, copied, published		help: ways_to_get_rfcs. For example:
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		To: rfc-info@RFC-EDITOR.ORG
	revoked by the Internet Society or its successors or assigns.		Subject: getting rfcs
	This document and the information contained herein is provided on an		help: ways_to_get_rfcs
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	This Internet-Draft expires July 24, 2002.		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	243 lines changed or deleted		44 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/