Network Working Group Zhigang Liu
INTERNET-DRAFT Khiem Le
Expires: July 24 2002 Nokia
January 24, 2002
0-byteA new Request for Comments is now available in online RFC libraries.
RFC 3408
Title: Zero-byte Support for R-mode Reliable
Bidirectional Mode (R-mode) in Extended Link-Layer
Assisted ROHC RObust Header Compression (ROHC) Profile
<draft-ietf-rohc-rtp-lla-r-mode-02.txt>
Status of This Memo
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
I-D Tag: draft-ietf-rohc-rtp-lla-r-mode-03.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3408.txt
This document is defines an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents additional mode of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may link-layer assisted
RObust Header Compression (ROHC) profile, 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 known 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 zero-byte
profile, beyond the profile two defined in [LLA-ROHC] to provide 0-byte support for R-
mode. The new profile allows a header-free packet format to be used RFC 3242. Zero-byte header
compression exists in all modes order to replace the majority of prevent the 1-octet header of single-octet ROHC
RTP packets sent during normal operation. Specifically, header
from pushing a packet voice stream into the
compressor operating in R-mode is allowed to deliver an NHP next higher fixed packet
when it would have used a ROHC R-0 [ROHC].
For simplification, this profile
size for the radio. It is defined usable in certain widely deployed older
air interfaces. This document adds the form of additions
and exceptions to [LLA-ROHC] that are required zero-byte operation for ROHC
Bidirectional Reliable mode (R-mode) to extend the LLA-ROHC
profile with 0-byte support ones specified 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",
Unidirectional (U-mode) and "OPTIONAL" in this
document are to be interpreted as described Bidirectional Optimistic (O-mode) modes
of header compression in RFC 2119.
2. Extensions to the assisting layer (AL) interface 3242.
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 document 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 product 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 Robust Header Compression Working
Group of the R-0 packet to the NHP packet. Note that R-0 IETF.
This is the only type
of packets in R-mode that can be replaced with NHP.
On the receiving side, the RTP SN of now a Proposed Standard Protocol.
This document specifies 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 Internet standards track protocol for
the decompressor, Internet community, and Offset_D
the sequence number offset between the NHP requests discussion and the last update
packet. How suggestions
for improvements. Please refer 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 current edition 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
"Internet Official Protocol Standards" (STD 1) for the rule is
satisfied again
standardization state and SN_ACKed > SN_break before it resumes sending
NHPs. The latter condition is essentially the counterpart status of
optimistic approach agreement [LLA-ROHC, section 4.3] this protocol. Distribution
of U/O-mode
which states that when the AL in U/O-mode determines it this memo is unsafe to
send NHP, it must send headers in the subsequent X packets, where X unlimited.
This announcement is some agreed number. There are two reasons for the difference: a)
R-mode relies on acknowledgements sent 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 IETF list and the compressor RFC-DIST list.
Requests to be added 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 deleted from AL to the compressor (section 2.2) IETF distribution list
should be sent to request the
compressor IETF-REQUEST@IETF.ORG. Requests to be
added 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 deleted from the worst case, during which NHPs cannot RFC-DIST distribution list should
be sent. Therefore,
sending update_request via the optional AL to compressor interface is
RECOMMENDED sent to improve the worst case performance.
Note: the update_request RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL 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 obtained by 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 EMAIL message to U/O-mode). Consequently, rfc-info@RFC-EDITOR.ORG with 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 message body
help: ways_to_get_rfcs. 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 example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests 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 special distribution should be taken for R-mode
implementations. It is RECOMMENDED addressed 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 either the sending
author of NHPs.
5. IANA considerations
A ROHC profile identifier must be reserved by the IANA for the
profile defined RFC in this document, preferably 0x01SS, where 0x00SS is
the profile identifier assigned for LLA [LLA-ROHC].
6. Acknowledgements
The authors would like question, or to thank Lars-Erik Jonsson and Ghyslain
Pelletier for intriguing discussions RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise 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
[LLA-ROHC] Lars-Erik Jonsson and Ghyslain Pelletier, "A Link-Layer
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)", RFC 3095, July 2001.
8. Authors' Addresses
Zhigang Liu Khiem Le
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Phone: +1 972 894-5935 Phone: +1 972 894-4882
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
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on itself, 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 RFCs are for the purpose of
developing Internet standards in which case the procedures
unlimited distribution.echo
Submissions for
copyrights defined in the Internet Standards process must Requests for Comments should be
followed, or as required sent to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"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.
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.