Network Working Group Zhigang Liu INTERNET-DRAFT Khiem Le Expires: June 14 2002 Nokia December 14, 2001 0-byte Support for R-mode in Link-Layer Assisted ROHC Profile 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 0-byte solution for R-mode in the link-layer assisted ROHC profile [LLA-ROHC]. Liu, Le [Page 1] INTERNET-DRAFT 0-byte Support for R-mode December 14, 2001 1. Introduction [LLA-ROHC] defines a U/O-mode only 0-byte solution for compression of IP/UDP/RTP packets. This document extends [LLA-ROHC] to provide 0-byte support for R-mode, which allows a header-free packet format to be used in all modes. For simplification, this profile is defined as a minimal delta to [LLA-ROHC]. 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 interface This section describes additions (some are optional) to the assisting layer interface as defined in [LLA-ROHC]. 2.1. Additional parameters to the compressor to AL interface (Editing note: refer to section 4.2.1, [LLA-ROHC]) - 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. New interface, assisting layer to compressor (Editing note: could be section 4.2.3, [LLA-ROHC]) This interface is RECOMMENDED to improve the compression efficiency of this profile in some cases, e.g., when the AL operates in such a way that it often becomes unsafe to send NHPs. 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. Liu, Le [Page 2] INTERNET-DRAFT 0-byte Support for R-mode December 14, 2001 3. R-mode operation (Editing note: could go after section 4.3, [LLA-ROHC]) 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-CRC packets cannot 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. 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. When the AL determines that it has become unsafe to send NHPs (caused by other conditions than the disallowance from the compressor), the AL records the corresponding RTP SN as SN_break. Then it waits until the SN_ACKed > SN_break before it resuming sending NHPs. To make this happen, 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 condition is 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 needs to be replaced. In addition, NHP packets in R-mode do not update either the compressor or the decompressor context (as opposed to U/O-mode). Consequently, the secure reference principle (section 5.5, [ROHC]) is not affected in any way and there Liu, Le [Page 3] INTERNET-DRAFT 0-byte Support for R-mode December 14, 2001 is no loss of robustness in this profile compared to ROHC RTP. 4. 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 value to be assigned by IANA for LLA. 5. 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. 6. 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. [ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)", RFC 3095, July 2001. 7. 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 Appendix A. Clarifications of this profile compared to LLA The main body of this document defines the major delta (i.e. section 2 and 3) between the new profile and the LLA. For completeness, this appendix lists other minor clarifications about the new profile. Again, [LLA-ROHC] is used as reference and only the differences (some Liu, Le [Page 4] INTERNET-DRAFT 0-byte Support for R-mode December 14, 2001 of which are editorial) are listed here. 1) [LLA-ROHC], section 1, page 4, second paragraph: LLA: "can replace a majority of the 1-octet header ROHC RTP packets during normal U/O-mode operation" This profile: "can replace a majority of the 1-octet header ROHC RTP packets during normal operation" 2) [LLA-ROHC], section 3, page 6: LLA: "Basically, what this profile does is to replace the smallest and most frequent ROHC U/O-mode headers with a no-header format" This profile: "Basically, what this profile does is to replace the smallest and most frequent ROHC headers with a no-header format" 3) [LLA-ROHC], section 3, page 6: LLA: "The fields present in the ROHC RTP headers for U/O-mode PT0 are the packet type identifier, the sequence number and the CRC." This profile: "The fields present in 1-octet ROHC RTP headers are the packet type identifier, the sequence number and the CRC (not present in PT R-0)." 4) [LLA-ROHC], section 3.3: This profile: add following note: "This section does not apply to R- mode as R-0 packets do not contain CRC field". 5) [LLA-ROHC], section 4.1.1: This profile: remove the following statement from the first paragraph: "An LLA compressor is not allowed to deliver NHP packets when operating in R-mode." 6) [LLA-ROHC] section 4.2.1: LLA: "Recall that delivery of an NHP packet occurs when the ROHC RTP compressor would have used a ROHC UO-0." This profile: "Recall that delivery of an NHP packet occurs when the ROHC RTP compressor would have used a ROHC UO-0 or R-0". 7) [LLA-ROHC], section 4.2.2, last paragraph: Liu, Le [Page 5] INTERNET-DRAFT 0-byte Support for R-mode December 14, 2001 LLA: "Note that the context is updated from a packet loss indication." This profile: "Note that in U/O-mode the context is updated from a packet loss indication." 8) [LLA-ROHC], section 4.6: This profile: add following note at the end of section: "Note that this section does not apply to R-mode since there is no CRC replacement. Furthermore, the sending of R-0-CRC when 6-bit SN wraps around already provides periodic context verification for R- mode". Liu, Le [Page 6]