Movatterモバイル変換

Network Working Group                                             Z. LiuRequest for Comments: 3408                                         K. LeCategory: Standards Track                                          Nokia                                                           December 2002Zero-byte Support for Bidirectional Reliable Mode (R-mode)in Extended Link-Layer Assisted RObust Header Compression(ROHC) ProfileStatus of this Memo   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 Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   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 inRFC 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 inRFC 3242.1.  Introduction   [RFC3242] defines a zero-byte solution for compression of IP/UDP/RTP   packets only for Unidirectional (U-) and Bidirectional Optimistic   (O-) modes [RFC3095].  The present specification extends the profile   defined in [RFC3242] to provide zero-byte support for Bidirectional   Reliable (R-) mode.  This specification and [RFC3242] allow a   header-free packet format to be used in all modes to replace the   majority of the 1-octet headers of ROHC RTP packets sent during   normal operation.  Specifically, the compressor operating in R-mode   is allowed to deliver a No-Header Packet (NHP) when [RFC3242] would   have required it to deliver a ROHC Reliable Packet Type Zero (R-0)   packet [RFC3095].Liu & Le                    Standards Track                     [Page 1]

RFC 3408               0-byte Support for R-mode           December 2002   For simplification, this profile is defined in the form of the   additions and exceptions to [RFC3242] that are required to extend theRFC 3242 profile with zero-byte support for R-mode.  All terminology   used in this document is the same as in [RFC3242].   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 inBCP 14,RFC 2119   [RFC2119].2.  Extensions to the assisting layer (AL) interface   This section describes additions (some are optional) to the assisting   layer interface as defined in [RFC3242,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 insection 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_DLiu & Le                    Standards Track                     [Page 2]

RFC 3408               0-byte Support for R-mode           December 2002   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 insection 4.1.1 of [RFC3242] to determine whether it can send NHP or   not, with one modification.  That is, when the AL determines that it   has become unsafe (seesection 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 [RFC3242,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 SHOULD use a context updating packet (e.g. R-0-CRC) when   sending the next packet.  Context updating packets are handled as in   [RFC3095].   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 is 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.Liu & Le                    Standards Track                     [Page 3]

RFC 3408               0-byte Support for R-mode           December 2002   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 [RFC3095,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 [RFC3242,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 [RFC3242,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 [RFC3242,section 4.5] to      compressor.  This is to avoid unnecessary overhead on the feedback      channel.   d) Context Check Packet (CCP)      When CCP [RFC3242,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 ofsection 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 [RFC3095,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.Liu & Le                    Standards Track                     [Page 4]

RFC 3408               0-byte Support for R-mode           December 20025.  IANA Considerations   A ROHC profile identifier has been reserved by the IANA for the   profile defined in this document (0x0105), where 0x0005 is the   profile identifier assigned for LLA [RFC3242].6.  Security Considerations   The security considerations of ROHC RTP [RFC3095,section 7] apply   also to this document with one addition: in the case of a denial-of-   service attack scenario where an intruder injects bogus CCP packets   onto the link using random CRC values, the CRC check will fail for   incorrect reasons at the decompressor side.  This would obviously   greatly reduce the advantages of ROHC and any extra efficiency   provided by this profile due to unnecessary context invalidation,   feedback messages and refresh packets.  However, the same remarks   related to the presence of such an intruder apply.7.  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.8.  References   [RFC3242]   Jonsson, L. and G. Pelletier, "RObust Header Compression               (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP",RFC 3242, April 2002.   [RFC3095]   Bormann, C., Burmeister, C., Degermark, M., Fukushima,               H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le,               K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,               Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header               Compression (ROHC): Framework and four profiles: RTP,               UDP, ESP, and uncompressed",RFC 3095, July 2001.   [RFC2119]   Bradner, S., "Key words for use in RFCs to indicate               requirement levels",BCP 14,RFC 2119, March 1997.Liu & Le                    Standards Track                     [Page 5]

RFC 3408               0-byte Support for R-mode           December 20029.  Authors' Addresses   Zhigang Liu   Nokia Research Center   6000 Connection Drive   Irving, TX 75039   USA   Phone: +1 972 894-5935   Fax:   +1 972 894-4589   EMail  zhigang.c.liu@nokia.com   Khiem Le   Nokia Research Center   6000 Connection Drive   Irving, TX 75039   USA   Phone: +1 972 894-4882   Fax:   +1 972 894-4589   EMail: khiem.le@nokia.comLiu & Le                    Standards Track                     [Page 6]

RFC 3408               0-byte Support for R-mode           December 200210.  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 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   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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Liu & Le                    Standards Track                     [Page 7]