Network Working Group L-E. Jonsson
Request for Comments: 3243 Ericsson
Category: Informational April 2002
Network Working Group L-E. Jonsson
Request for Comments: 3243 Ericsson
Category: Informational April 2002
RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression
健壮的报头压缩（ROHC）：0字节IP/UDP/RTP压缩的要求和假设
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.
本文件包含由ROHC工作组开发的0字节IP/UDP/RTP（互联网协议/用户数据报协议/实时传输协议）报头压缩方案的要求。它还包括可在其上实现0字节压缩的典型链路层的基本假设，以及关于其一般用途的假设。
The goal of the Robust Header Compression (ROHC) Working Group is to develop header compression schemes that perform well over links with high error rates and long link roundtrip times. The schemes must perform well for cellular links, using technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes should also be applicable to other future link technologies with high loss and long roundtrip times.
鲁棒报头压缩（ROHC）工作组的目标是开发在高错误率和长链路往返时间的链路上表现良好的报头压缩方案。这些方案必须在使用WCDMA、EDGE和CDMA-2000等技术的蜂窝链路上表现良好。然而，这些方案也应适用于未来其他具有高损耗和长往返时间的链路技术。
ROHC RTP has become a very efficient, robust and capable compression scheme, able to compress the IP/UDP/RTP headers down to a total size of only one octet. This makes ROHC RTP an excellent solution for future cellular environments with new air interfaces, such as WCDMA, making even speech services possible over IP with an insignificantly lower spectrum efficiency compared to existing circuit switched solutions.
ROHC-RTP已经成为一种非常高效、健壮和有能力的压缩方案，能够将IP/UDP/RTP报头压缩到只有一个八位组的总大小。这使得ROHC RTP成为具有新空中接口（如WCDMA）的未来蜂窝环境的优秀解决方案，使得通过IP提供语音服务成为可能，与现有电路交换解决方案相比，频谱效率要低得多。
However, all-IP cellular networks will also be built with already existing air interfaces such as GSM and IS-95, which are less flexible using radio bearers optimized for specific frame sizes matching the speech codecs used. This means that not a single octet of header can be added without switching to the next higher fixed packet size supported by the link, something which is obviously very costly. In the long term, this drawback should of course be eliminated with new, more flexible air interfaces, but in the short term it would be desirable if an efficiency comparable to the circuit switched case could also be achieved for already deployed speech codecs when used over the existing air interfaces. To achieve that, it must be possible to completely eliminate the headers for a majority of the packets during normal operation, and this is the purpose of 0-byte header compression. All functionality normally provided by the 1-octet header must then be provided by some other means, typically by utilizing functionality from the lower layer. It is important to remember that the purpose of 0-byte header compression is to provide optimal efficiency for applications matching the link layer characteristics, not efficiency in general.
然而，所有IP蜂窝网络也将使用现有的空中接口（如GSM和IS-95）来构建，这些接口使用针对特定帧大小优化的无线电承载来匹配所使用的语音编解码器，灵活性较低。这意味着在不切换到链路支持的下一个更高的固定数据包大小的情况下，不能添加一个八位字节的报头，这显然是非常昂贵的。从长远来看，这一缺点当然应该通过新的、更灵活的空中接口来消除，但从短期来看，如果在现有空中接口上使用时，已经部署的语音编解码器也能达到与电路交换情况相当的效率，则这将是可取的。为了实现这一点，必须能够在正常操作期间完全消除大多数数据包的报头，这就是0字节报头压缩的目的。通常由1-octet报头提供的所有功能必须通过其他方式提供，通常通过利用较低层的功能。请务必记住，0字节报头压缩的目的是为匹配链路层特征的应用程序提供最佳效率，而不是一般的效率。
As a starting point for these requirements, the well-established requirements base developed in the ROHC WG has been used. From that, the requirements have evolved through input from the 3GPP2 community and from discussions within the WG.
作为这些需求的起点，已使用ROHC工作组中开发的成熟需求库。从那以后，需求通过3GPP2社区的输入和工作组内部的讨论而演变。
The purpose of 0-byte header compression is to provide optimal usage of certain links when the traffic pattern of a packet stream completely matches the characteristics of that link. There are no assumptions that only packet streams complying with that pattern will occur, but optimal efficiency cannot of course be provided when this is not the case.
0字节报头压缩的目的是当分组流的业务模式完全匹配该链路的特征时，提供对某些链路的最佳使用。没有假设只有符合该模式的数据包流才会出现，但如果不是这样，当然不能提供最佳效率。
To make 0-byte header compression feasible, it is assumed that lower layers can provide the necessary functionality needed to replace the 1-octet headers and fulfill the requirements defined in section 3. An example is the synchronized nature of most cellular links, which can provide sequencing and timing information and make packet loss detection possible.
为了使0字节头压缩成为可能，假设较低的层可以提供替换1字节头所需的必要功能，并满足第3节中定义的要求。一个例子是大多数蜂窝链路的同步性质，它可以提供序列和定时信息，并使包丢失检测成为可能。
Since 0-byte header compression for ROHC IP/UDP/RTP is a variant of regular ROHC RTP compression [ROHC], these requirements are described as deltas to those defined in the regular RTP requirements [RTP-REQ]. For simplicity, this section is also separated into the same three subsections as the requirements in [RTP-REQ], where the first deals
由于ROHC IP/UDP/RTP的0字节报头压缩是常规ROHC RTP压缩[ROHC]的变体，因此这些要求被描述为常规RTP要求[RTP-REQ]中定义的增量。为简单起见，本节也分为与[RTP-REQ]中的要求相同的三个小节，其中第一个小节涉及
with the impact of header compression on the rest of the Internet infrastructure, the second concerns the headers to be compressed, and the third covers efficiency and link technology related issues.
由于报头压缩对互联网基础设施的其余部分的影响，第二个涉及要压缩的报头，第三个涉及效率和链路技术相关问题。
The meaning of header compression is in no way changed by the introduction of 0-byte header compression. No additional impact on the Internet infrastructure is thus allowed. The "Transparency" and "Ubiquity" requirements of [RTP-REQ, section 2.1] therefore also apply to 0-byte RTP compression without any modifications.
0字节头压缩的引入不会改变头压缩的含义。因此，不允许对互联网基础设施产生额外影响。因此，[RTP-REQ，第2.1节]的“透明度”和“普遍性”要求也适用于0字节RTP压缩，无需任何修改。
The 0-byte RTP compression scheme in general imposes the same requirements on supported headers and RTP streams as regular ROHC RTP [RTP-REQ, section 2.2]. However, there are some aspects regarding the "Genericity" and IPSEC requirements that should be noted.
0字节RTP压缩方案通常对支持的报头和RTP流施加与常规ROHC RTP相同的要求[RTP-REQ，第2.2节]。但是，有一些关于“通用性”和IPSEC要求的方面需要注意。
The "Genericity" requirement of [RTP-REQ] states that compression of headers of arbitrary RTP streams must be supported, and this is also true for the 0-byte compression scheme to the extent that it is not allowed to assume certain RTP behavior. However, as also stated in [RTP-REQ], this does not preclude optimizations for certain media types where the traffic pattern is known. For 0-byte RTP, this means that the scheme must be able to handle arbitrary RTP streams in order to fulfill the requirements of section 3.1. However, due to the typical characteristics of 0-byte compression, by requiring a traffic pattern that suits the link over which it is implemented to be able to compress down to 0-byte headers, it becomes optimized for applications with link-suited traffic patterns. For traffic that does not comply with the link properties, the scheme must automatically and immediately fall back to non-0-byte RTP compression and must not have any impact on the packet stream.
[RTP-REQ]的“通用性”要求指出，必须支持对任意RTP流的报头进行压缩，对于0字节压缩方案也是如此，因为不允许假设某些RTP行为。然而，正如[RTP-REQ]中所述，这并不排除对已知流量模式的某些媒体类型进行优化。对于0字节RTP，这意味着该方案必须能够处理任意RTP流，以满足第3.1节的要求。然而，由于0字节压缩的典型特征，通过要求适合其实现的链路的流量模式能够压缩到0字节的报头，它可以针对具有适合链路的流量模式的应用程序进行优化。对于不符合链路属性的流量，该方案必须自动且立即返回到非0字节RTP压缩，并且不得对数据包流产生任何影响。
Regarding IPSEC, it should be noted that 0-byte compression cannot be achieved if parts of the original headers are encrypted or carry randomly changing fields. IPSEC and 0-byte RTP header compression therefore do not go well together. If IPSEC is used and prevents 0- byte compression, the scheme must fall back to a less efficient compression that can handle all present header fields. Of course, this applies not only to IPSEC but to all cases where headers cannot be compressed down to 0-byte.
关于IPSEC，应该注意的是，如果原始头的一部分被加密或携带随机变化的字段，则无法实现0字节压缩。因此，IPSEC和0字节RTP报头压缩不能很好地结合在一起。如果使用IPSEC并阻止0字节压缩，则方案必须退回到效率较低的压缩，该压缩可以处理所有当前的头字段。当然，这不仅适用于IPSEC，而且适用于头不能压缩到0字节的所有情况。
All the performance requirements of [RTP-REQ] also apply to 0-byte RTP header compression, with the following additions and exceptions:
[RTP-REQ]的所有性能要求也适用于0字节RTP报头压缩，但有以下添加和例外情况：
- Performance/Spectral Efficiency: For packet streams with traffic patterns that match the characteristics of the link over which 0- byte header compression is implemented, the performance should be such that 0-byte header packets are generated during normal operation, most of the time. 0-byte headers would then replace most of the 1-octet headers used by regular ROHC RTP [ROHC].
- 性能/频谱效率：对于具有与实施0字节报头压缩的链路特征相匹配的业务模式的数据包流，性能应确保在正常运行期间（大多数时间）生成0字节报头数据包。然后，0字节报头将取代常规ROHC RTP[ROHC]使用的大多数1字节报头。
Justification: Spectrum efficiency is a primary goal. Studies have shown that for certain applications and link technologies, even a single octet of header may result in a significant decrease in spectrum efficiency, compared to existing circuit switched solutions.
理由：频谱效率是主要目标。研究表明，对于某些应用和链路技术，与现有的电路交换解决方案相比，即使报头的单个八位组也可能导致频谱效率显著降低。
- Header Compression Coexistence: The scheme must fit into the ROHC framework together with other ROHC profiles.
- 头压缩共存：该方案必须与其他ROHC配置文件一起适应ROHC框架。
Justification: Implementation simplicity is an important issue and the 0-byte RTP compression scheme should therefore have as much as possible in common with the regular IP/UDP/RTP profile.
理由：实现的简单性是一个重要问题，因此0字节RTP压缩方案应尽可能与常规IP/UDP/RTP配置文件相同。
- Unidirectional links: It is of less importance that the 0-byte header compression scheme be able to also work over unidirectional links.
- 单向链路：0字节报头压缩方案也能在单向链路上工作，这一点不太重要。
Justification: 0-byte header compression targets links that typically are bi-directional.
对齐：0字节头压缩的目标链接通常是双向的。
A protocol which meets these requirements, e.g., [LLA], will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
满足这些要求的协议，例如[LLA]，将要求IANA分配各种号码。然而，本文件本身不需要IANA的参与。
A protocol specified to meet these requirements, e.g., [LLA], may have a number of security aspects that need to be considered. This document by itself, however, does not add any security risks.
为满足这些要求而指定的协议，例如[LLA]，可能有许多需要考虑的安全方面。然而，本文件本身并不增加任何安全风险。
[RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RTP-REQ]Degermark，M.，“鲁棒IP/UDP/RTP报头压缩的要求”，RFC 3096，2001年7月。
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., 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)", RFC 3095, July 2001.
[ROHC]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）”，RFC 3095，2001年7月。
[LLA] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
[LLA]Jonsson，L-E.和G.Pelletier，“鲁棒头压缩（ROHC）：IP/UDP/RTP的链路层辅助配置文件”，RFC 3242，2002年4月。
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Lars Erik Jonsson Ericsson AB信箱920 SE-971 28瑞典卢利亚
Phone: +46 (920) 20 21 07
Fax: +46 (920) 20 20 99
EMail: lars-erik.jonsson@ericsson.com
Phone: +46 (920) 20 21 07
Fax: +46 (920) 20 20 99
EMail: lars-erik.jonsson@ericsson.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编辑功能的资金目前由互联网协会提供。