Network Working Group Zhigang Liu INTERNET-DRAFT Khiem Le Expires: July 17 2002 Nokia January 17, 2002 0-byte Support for R-mode in Extended 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 new profile that extends the link-layer assisted ROHC profile ([LLA-ROHC]) to provide 0-byte solution for R- mode. Liu, Le [Page 1] INTERNET-DRAFT 0-byte Support for R-mode January 17, 2001 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 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 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. (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 Liu, Le [Page 2] INTERNET-DRAFT 0-byte Support for R-mode January 17, 2001 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. 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 due to the non-context-updating nature of R-0.) 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 Liu, Le [Page 3] INTERNET-DRAFT 0-byte Support for R-mode January 17, 2001 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 (section 5.5, [ROHC]) 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 (section 3.3, [LLA-ROHC]) 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 (section 4.6, [LLA- ROHC]) is RECOMMENDED to provide additional protection against damage propagation after CRC is replaced. In R-mode, this is not needed since there is no CRC replacement (see above). Furthermore, 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 (section 4.5, [LLA-ROHC]) to compressor. This is to avoid unnecessary overhead on the feedback channel. d) Context Check Packet (CCP) When CCP is used (section 4.1.3, [LLA-ROHC]), 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). Liu, Le [Page 4] INTERNET-DRAFT 0-byte Support for R-mode January 17, 2001 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 value to be assigned by IANA for LLA. 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 [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. 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 Liu, Le [Page 5]