Network Working Group Z. Liu
Request for Comments: 3408 K. Le
Category: Standards Track Nokia
December 2002
Network Working Group Z. Liu
Request for Comments: 3408 K. Le
Category: Standards Track Nokia
December 2002
Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile
在扩展链路层辅助鲁棒报头压缩（ROHC）配置文件中对双向可靠模式（R模式）的零字节支持
Status 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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 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.
除了RFC 3242中定义的两种模式外，本文档还定义了链路层辅助鲁棒报头压缩（ROHC）配置文件的另一种模式，也称为零字节配置文件。零字节报头压缩的存在是为了防止单个八位字节ROHC报头将分组语音流推送到下一个更高的无线电固定分组大小。它可用于某些广泛部署的老式空中接口。本文档将ROHC双向可靠模式（R模式）的零字节操作添加到RFC 3242中为报头压缩的单向（U模式）和双向乐观（O模式）模式指定的操作中。
[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].
[RFC3242]定义了仅用于单向（U-）和双向乐观（O-）模式的IP/UDP/RTP数据包压缩的零字节解决方案[RFC3095]。本规范扩展了[RFC3242]中定义的配置文件，为双向可靠（R-）模式提供零字节支持。本规范和[RFC3242]允许在所有模式下使用无报头数据包格式，以替换正常运行期间发送的ROHC RTP数据包的大部分1-octet报头。具体而言，当[RFC3242]需要发送ROHC可靠数据包类型零（R-0）数据包[RFC3095]时，允许在R模式下运行的压缩机发送无报头数据包（NHP）。
For simplification, this profile is defined in the form of the additions and exceptions to [RFC3242] that are required to extend the RFC 3242 profile with zero-byte support for R-mode. All terminology used in this document is the same as in [RFC3242].
为简化起见，此配置文件以[RFC3242]的添加和例外形式定义，这些添加和例外是扩展RFC 3242配置文件所需的，并为R模式提供零字节支持。本文件中使用的所有术语与[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 in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
This section describes additions (some are optional) to the assisting layer interface as defined in [RFC3242, section 4.2].
本节描述了对[RFC3242，第4.2节]中定义的辅助层接口的添加（一些是可选的）。
- Mode, indicating the mode in which the compressor is operating. The AL has slightly different logic depending on the mode value.
- 模式，指示压缩机运行的模式。根据模式值，AL的逻辑略有不同。
- SN_ACKed, indicating the latest RTP SN that has been acknowledged. It is used only when Mode value = R-mode.
- 序列号已确认，表示已确认的最新RTP序列号。仅当模式值=R模式时使用。
Note that these two parameters MUST always be attached to every packet delivered to the AL.
请注意，这两个参数必须始终附加到发送到AL的每个数据包。
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.
为了在某些特定情况下提高此配置文件的压缩效率，例如，当AL以发送NHP通常变得不安全的方式运行时，建议实施此附加接口。这里，“不安全”一词意味着压缩机允许AL发送NHP，但AL不能保证NHP的RTP SN将在接收侧正确解压缩。该接口用于执行第3节中所述的更新请求。请注意，此接口不是必需的，因为无法实现此类接口不应成为通过特定链接实现此概要文件的障碍。
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.
对于R模式，此配置文件通过执行R-0数据包到NHP数据包的映射来扩展ROHC RTP。注意，R-0是R-mode中唯一可以用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
在接收侧，NHP的RTP SN由解压缩器确定为=SN_Ref_D+Offset_D，其中SN_Ref_D是解压缩器接收的最后更新分组的RTP SN，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.
NHP和上次更新数据包之间的序列号偏移量。如何导出偏移量取决于此配置文件在特定链路技术上的实现，并且必须在实现文档中指定。例如，可以通过计算自上次成功的上下文更新以来接收到的非上下文更新分组（包括nhp）和分组丢失指示的总数来计算。或者，在保持RTP SN和链路定时之间的线性映射的情况下，可以使用链路定时来导出它。
On the transmitting side, the AL follows the same rule defined in section 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 (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 [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].
在发送端，AL遵循[RFC3242]第4.1.1节中定义的相同规则，通过一次修改确定其是否可以发送NHP。也就是说，当AL确定发送NHP变得不安全（参见第2.2节）时，AL将相应的RTP SN记录为SN_break。然后，它等待直到再次满足规则并且SN_ACKed>SN_break，然后再继续发送NHP。后一种情况本质上与U/O模式的乐观接近协议[RFC3242，第4.3节]相对应，该协议规定，当处于U/O模式的AL确定发送NHP不安全时，它必须在随后的X数据包中发送报头，其中X是某个商定的数字。造成这种差异的原因有两个：a）R模式依赖于确认来同步上下文，而不是U/O模式中的乐观方法原则；和b）R-0数据包不更新解压器上下文，而UO-0数据包更新解压器上下文。为了满足条件SN_ACKed>SN_break，AL可以被动地等待压缩器发送上下文更新包（例如，由6位SN环绕触发的R-0-CRC），或者通过接口从AL向压缩器发送更新请求（第2.2节），以请求压缩器发送上下文更新包。更新请求携带最后一个序列号中断。收到更新请求后，压缩器在发送下一个数据包时应使用上下文更新数据包（例如R-0-CRC）。上下文更新数据包按[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.
注意：在最坏的情况下，上述被动等待可能需要很长时间，在此期间无法发送NHP。因此，建议通过可选AL-to-compressor接口发送更新_请求，以提高最坏情况下的性能。
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.
注意：如果AL和压缩器位于不同的位置，并且它们之间的通道不可靠，则更新_请求可能会丢失，但这种丢失只会延迟AL恢复发送NHP。因此，AL发送update_请求的频率是一个实现问题。例如，AL可以对从压缩器接收到的每个分组发送一个更新请求，直到满足发送NHP的条件为止。
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.
注：由于R-0数据包中不存在CRC字段，因此只需替换与RTP SN和数据包类型标识符相关的功能。此外，R模式下的NHP数据包和数据包丢失指示不会更新压缩器或解压缩器上下文（与U/O模式相反）。因此，安全参考原则[RFC3095，第5.5节]不受任何影响，与ROHC RTP相比，此配置文件中的稳健性没有损失。
This section clarifies some differences between R-mode and U/O-mode in this profile.
本节澄清了此配置文件中R模式和U/O模式之间的一些差异。
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.
a) CRC替换与U/O模式不同，CRC替换[RFC3242，第3.3节]不是R模式的问题，因为R-0数据包不携带CRC字段。
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.
b) U/O模式的定期上下文验证，建议定期上下文验证[RFC3242，第4.6节]在更换CRC后提供额外保护，防止损坏传播。对于R模式，由于没有CRC替换（见上文），因此在这方面不需要对ROHC RTP进行更改。特别是，R-mode自然内置了此功能，因为当6位SN环绕时发送R-0-CRC隐式地为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.
c) CV-REQUEST选项出于与上述相同的原因，在R模式下运行的减压器不应向压缩机发送CV-REQUEST[RFC3242，第4.5节]。这是为了避免反馈通道上不必要的开销。
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 of section 3 and item b) above).
d) 上下文检查数据包（CCP）当使用CCP[RFC3242，第4.1.3节]时，在R模式下运行的压缩机应将C位设置为0（零），如果压缩机和解压缩器的计算成本引起关注，则不生成7位CRC。在R模式下，使用CCP中的CRC字段来执行解压器上下文验证并不重要（见上文第3节和第b项的最后注释）。
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.
e) 确认（ACKs）的处理对于R模式实现，应特别注意确认的实现。建议避免使用散布反馈包[RFC3095，第5.2.1节]来携带ACK信息。原因是分散的反馈数据包将中断RTP SN排序，从而暂时禁用NHP的发送。
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].
IANA已为本文件（0x0105）中定义的配置文件保留ROHC配置文件标识符，其中0x0005是为LLA[RFC3242]分配的配置文件标识符。
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.
ROHC RTP[RFC3095，第7节]的安全注意事项也适用于本文件，但有一点需要补充：在拒绝服务攻击情况下，入侵者使用随机CRC值向链路注入虚假CCP数据包，CRC检查将因解压器端的错误原因而失败。由于不必要的上下文失效、反馈消息和刷新数据包，这显然会大大降低ROHC的优势以及该配置文件提供的任何额外效率。然而，与此类入侵者的存在相关的评论同样适用。
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.
作者要感谢Lars Erik Jonsson和Ghyslain Pelletier对LLA的有趣讨论，这有助于确定R模式操作。作者还感谢Carsten Bormann、Christopher Clanton、Mark Cheng和Thinh Nguyenphu的宝贵意见。
[RFC3242] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
[RFC3242]Jonsson，L.和G.Pelletier，“鲁棒报头压缩（ROHC）：IP/UDP/RTP的链路层辅助配置文件”，RFC 3242，2002年4月。
[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.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
刘志刚诺基亚研究中心美国德克萨斯州欧文连接大道6000号75039
Phone: +1 972 894-5935
Fax: +1 972 894-4589
EMail zhigang.c.liu@nokia.com
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
美国德克萨斯州欧文市凯姆乐诺基亚研究中心6000连接路75039
Phone: +1 972 894-4882
Fax: +1 972 894-4589
EMail: khiem.le@nokia.com
Phone: +1 972 894-4882
Fax: +1 972 894-4589
EMail: khiem.le@nokia.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。