Network Working Group M. Degermark, Editor
Request for Comments: 3096 University of Arizona
Category: Informational July 2001
Network Working Group M. Degermark, Editor
Request for Comments: 3096 University of Arizona
Category: Informational July 2001
Requirements for robust IP/UDP/RTP header compression
对健壮的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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP.
本文件包含ROHC（鲁棒报头压缩）工作组开发的鲁棒IP/UDP/RTP（互联网协议/用户数据报协议/实时传输协议）报头压缩的要求。它基于ROHC章程、工作组讨论、3GPP文件“3GPP TR 23.922”、1999年10月1.0.0版以及3G.IP的贡献。
The goal of the ROHC WG is to develop header compression schemes that perform well over links with high error rates and long link round trip times. The schemes must perform well for cellular links built 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 round trip times.
ROHC工作组的目标是开发在高错误率和长链路往返时间的链路上表现良好的报头压缩方案。对于使用WCDMA、EDGE和CDMA-2000等技术构建的蜂窝链路，这些方案必须表现良好。然而，这些方案也应适用于未来其他高损耗和长往返时间的链路技术。
The following requirements have, more or less arbitrarily, been divided into three groups. The first group deals with requirements concerning the impact of an header compression scheme on the rest of the Internet infrastructure. The second group concerns what kind of headers that must be compressed efficiently. The final group concerns efficiency requirements and requirements which stem from the properties of the anticipated link technologies.
以下要求或多或少被任意分为三类。第一组处理关于报头压缩方案对互联网基础设施其余部分的影响的需求。第二组涉及必须有效压缩的头类型。最后一组涉及效率要求和源自预期链路技术特性的要求。
Several current standardization efforts in the cellular arena aim at supporting voice over IP and other real-time services over IP, e.g., GERAN (specified by the ETSI SMG2 standards group), and UTRAN
蜂窝领域的一些当前标准化工作旨在支持IP语音和其他IP实时服务，例如GERAN（由ETSI SMG2标准组指定）和UTRAN
(specified by the 3GPP standards organization). It is critical for these standardization efforts that a suitable header compression scheme is developed before completion of the Release 2000 standards. Therefore, it is imperative that the ROHC WG keeps its schedule.
（由3GPP标准组织指定）。对于这些标准化工作来说，在2000版标准完成之前开发合适的报头压缩方案是至关重要的。因此，ROHC工作组必须遵守其时间表。
1. Transparency: When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. If this cannot be achieved, the packet containing the erroneous header must be discarded.
1. 透明性：当一个头被压缩然后被解压时，得到的头在语义上必须与原始头相同。如果无法实现，则必须丢弃包含错误报头的数据包。
Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure.
理由：标头压缩过程不得产生可能会对Internet基础设施的任何当前或未来部分造成问题的标头。
2. Ubiquity: Must not require modifications to existing IP (v4 or v6), UDP, or RTP implementations.
2. 普遍性：不得要求修改现有的IP（v4或v6）、UDP或RTP实现。
Justification: Ease of deployment.
理由：易于部署。
Note: The ROHC WG may recommend changes that would increase the compression efficiency for the RTP streams emitted by implementations. However, ROHC cannot rely on such recommendations being followed.
注：ROHC工作组可能会建议进行一些更改，以提高实现所发出的RTP流的压缩效率。然而，ROHC不能依靠这些建议得到遵守。
1. IPv4 and IPv6: Must support both IPv4 and IPv6.
1. IPv4和IPv6:必须同时支持IPv4和IPv6。
Justification: IPv4 and IPv6 will both be around during the foreseeable future.
理由：IPv4和IPv6都将在可预见的未来出现。
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be compressed efficiently. For IPv4 these include headers of tunneled packets. For IPv6 these include headers containing the Routing Header, the Binding Update Destination Option, and the Home Address option.
2. mobileip：mobileip{v4，v6}使用的头类型应该被有效压缩。对于IPv4，这些包括隧道数据包的头。对于IPv6，这些头包括包含路由头、绑定更新目标选项和家庭地址选项的头。
Justification: It is very likely that Mobile IP will be used by cellular devices.
理由：移动IP很可能会被蜂窝设备使用。
3. Genericity: Must support compression of headers of arbitrary RTP streams.
3. 通用性：必须支持压缩任意RTP流的头。
Justification: There must be a generic scheme which can compress reasonably well for any payload type and traffic pattern. This does not preclude optimizations for certain media types where the traffic pattern is known, e.g., for low-bandwidth voice and low-bandwidth video.
理由：必须有一个通用的方案，可以对任何有效负载类型和流量模式进行合理的压缩。这并不排除对已知流量模式的某些媒体类型进行优化，例如低带宽语音和低带宽视频。
Note: This applies to the RTP stream before as well as after it has passed through an internet.
注意：这适用于RTP流通过internet之前和之后的情况。
4. IPSEC: ROHC should be able to compress headers containing IPSEC subheaders.
4. IPSEC:ROHC应该能够压缩包含IPSEC子标题的标题。
Note: It is of course not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header.
注意：当然不可能压缩ESP头的加密部分，也不可能压缩AH头中的加密数据。
1. Performance/Spectral Efficiency: Must provide low relative overhead under expected operating conditions; compression efficiency should be better than for RFC 2508 under equivalent operating conditions. The error rate should only marginally increase the overhead under expected operating conditions.
1. 性能/频谱效率：必须在预期运行条件下提供较低的相对开销；在同等操作条件下，压缩效率应优于RFC 2508。在预期操作条件下，错误率只会略微增加开销。
Justification: Spectrum efficiency is a primary goal. RFC 2508 does not perform well enough.
理由：频谱效率是主要目标。RFC2508的性能不够好。
Note: The relative overhead is the average header overhead relative to the payload. Any auxiliary (e.g., control or feedback) channels used by the scheme should be taken into account when calculating the header overhead.
注意：相对开销是相对于有效负载的平均报头开销。在计算报头开销时，应考虑方案使用的任何辅助（如控制或反馈）通道。
2. Error propagation: Error propagation due to header compression should be kept at an absolute minimum. Error propagation is defined as the loss or damage of headers subsequent to headers lost or damaged by the link, even if those subsequent headers are not lost or damaged.
2. 错误传播：报头压缩导致的错误传播应保持在绝对最小值。错误传播被定义为链接丢失或损坏的头之后的头的丢失或损坏，即使这些后续头没有丢失或损坏。
Justification: Error propagation reduces spectral efficiency and reduces quality. CRTP suffers severely from error propagation.
理由：错误传播会降低频谱效率并降低质量。CRTP受到错误传播的严重影响。
Note: There are at least two kinds of error propagation; loss propagation, where an error causes subsequent headers to be lost, and damage propagation, where an error causes subsequent headers to be damaged.
注：至少有两种错误传播；丢失传播，错误导致后续标头丢失；损坏传播，错误导致后续标头损坏。
3a. Handover loss events: There must be a way to run ROHC where loss events of length 150 milliseconds are handled efficiently and where loss or damage propagation is not introduced by ROHC during such events.
3a。移交丢失事件：必须有一种方法来运行ROHC，其中长度为150毫秒的丢失事件得到有效处理，并且ROHC在此类事件期间不会引入丢失或损坏传播。
Justification: Such loss events can be introduced by handover operations in a (radio) network between compressor and decompressor. Handover operations can be frequent in cellular systems. Failure to handle handover well can adversely impact spectrum efficiency and quality.
理由：此类丢失事件可通过压缩机和减压器之间的（无线电）网络中的切换操作引入。在蜂窝系统中，切换操作可能很频繁。未能很好地处理切换可能会对频谱效率和质量产生不利影响。
3b. Handover context recreation: There must be a way to run ROHC that deals well with events where the route of an RTP conversation changes such that either the compressor or the decompressor of the conversation is relocated to another node, where the context needs to be recreated. ROHC must not introduce erroneous headers during such events, and should not introduce packet loss during such events.
3b。切换上下文重新创建：必须有一种运行ROHC的方法，能够很好地处理RTP会话路由发生变化的事件，从而会话的压缩器或解压缩器被重新定位到另一个节点，在该节点上需要重新创建上下文。ROHC不得在此类事件期间引入错误的报头，也不得在此类事件期间引入数据包丢失。
Justification: Such events can be frequent in cellular systems where the compressor/decompressor on the network side is close to the radio base stations.
理由：在网络侧的压缩器/解压缩器靠近无线基站的蜂窝系统中，此类事件可能很频繁。
Note: In order to aid developers of context recreation schemes where context is transfered to the new node, the specification shall outline what parts of the context is to be transfered, as well as conditions for its use. Procedures for context recreation (and discard) without such context transfer will also be provided.
注：为了帮助上下文再现方案的开发人员将上下文转移到新节点，规范应概述上下文的哪些部分将被转移，以及使用条件。还将提供不进行上下文转移的上下文再现（和丢弃）程序。
4. Link delay: Must operate under all expected link delay conditions.
4. 链路延迟：必须在所有预期链路延迟条件下运行。
5. Processing delay: The scheme must not contribute significantly to system delay budget.
5. 处理延迟：方案不得对系统延迟预算造成重大影响。
6. Multiple links: The scheme must perform well when there are two or more cellular links in the end-to-end path.
6. 多链路：当端到端路径中有两个或更多蜂窝链路时，该方案必须表现良好。
Justification: Such paths will occur.
理由：将出现此类路径。
Note: loss on previous links will cause irregularities in the RTP stream reaching the compressor. Such irregularities should only marginally affect performance.
注：先前链路的丢失将导致到达压缩机的RTP流不规则。此类违规行为只会对绩效产生轻微影响。
7a. Packet Misordering: The scheme should be able to compress when there are misordered packets in the RTP stream reaching the compressor. No misordering is expected on the link between compressor and decompressor.
7a。数据包错误排序：当RTP流中到达压缩器的数据包出现错误排序时，该方案应该能够进行压缩。压缩机和减压器之间的连接不应出现误序。
Justification: Misordering happens regularly in the Internet. However, since the Internet is engineered to run TCP reasonably well, excessive misordering will not be common and need not be handled with optimum efficiently.
理由：在互联网上，乱序经常发生。然而，由于互联网被设计成可以合理地运行TCP，过度的错误排序将不会很常见，也不需要以最佳的效率来处理。
7b. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor.
7b。中度分组误序：该方案应有效处理到达压缩器的分组流中的中度误序（2-3个分组）。
Note: This kind of reordering is common.
注意：这种重新排序是常见的。
8. Unidirectional links/multicast: Must operate (possibly with less efficiency) over links where there is no feedback channel or where there are several receivers.
8. 单向链路/多播：必须在没有反馈通道或有多个接收器的链路上运行（可能效率较低）。
9. Configurable frame size fluctuation: It should be possible to restrict the number of different frame sizes used by the scheme.
9. 可配置的帧大小波动：应该可以限制方案使用的不同帧大小的数量。
Justification: Some radio technologies support only a limited number of frame sizes efficiently.
理由：某些无线电技术仅有效支持有限数量的帧大小。
Note: Somewhat degraded performance is to be expected when such restrictions are applied.
注：应用此类限制时，性能可能会有所下降。
Note: This implies that a list of "good" frame sizes must be made available and that ROHC may pick a suitable header format to utilize available space as well as possible.
注：这意味着必须提供一份“良好”帧大小的列表，ROHC可能会选择合适的标题格式以尽可能利用可用空间。
10. Delay: ROHC should not noticeably add to the end-to-end delay.
10. 延迟：ROHC不应明显增加端到端延迟。
Justification: RTP packets carrying data for interactive voice or video have a limited end-to-end delay budget.
理由：传输交互式语音或视频数据的RTP数据包具有有限的端到端延迟预算。
Note: This requirement is intended to prevent schemes that achieve robustness at the expense of delay, for example schemes that require that header i+x, x>0, is received before header i can be decompressed.
注：该要求旨在防止以延迟为代价实现鲁棒性的方案，例如要求在头i可以解压缩之前接收头i+x，x>0的方案。
Note: Together with 2.3.5, this requirement implies that ROHC will not noticeably add to the jitter of the RTP stream, other than what is caused by variations in header size.
注：与2.3.5一起，该要求意味着ROHC不会明显增加RTP流的抖动，但标头大小变化引起的抖动除外。
Note: This requirement does not prevent a queue from forming upstream a bottleneck link. Nor does it prevent a compressor from utilizing information from more than one header in such a queue.
注意：此要求不阻止队列在瓶颈链路上游形成。它也不会阻止压缩器利用来自此类队列中多个报头的信息。
11. Residual errors: For a residual bit-error rate of at most 1e-5, the ROHC scheme must not increase the error rate.
11. 残余错误：对于最大1e-5的残余误码率，ROHC方案不得增加错误率。
Justification: Some target links have a residual error rate, i.e, rate of undetected errors, of this magnitude.
理由：某些目标链路的剩余错误率（即未检测到的错误率）达到此量级。
Note: In the presence of residual bit-errors, ROHC will need error detection mechanisms to prevent damage propagation. These mechanisms will catch some residual errors, but those not caught might cause damage propagation. This requirement states that the reduction of the damage rate due to the error detection mechanisms must not be less than the increase in error rate due to damage propagation.
注：在存在残余位错误的情况下，ROHC将需要错误检测机制来防止损坏传播。这些机制将捕获一些残余误差，但未捕获的可能会导致损伤传播。该要求规定，由于错误检测机制导致的损坏率降低不得小于由于损坏传播导致的错误率增加。
A protocol which meets these requirements, e.g., [ROHC], will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
满足这些要求的协议，例如[ROHC]，将要求IANA分配各种号码。然而，本文件本身不需要IANA的参与。
A protocol specified to meet these requirements, e.g., [ROHC], must be able to compress packets containing IPSEC headers according to the IPSEC requirement, 2.2.4. There may be other security aspects to consider in such protocols. This document by itself, however, does not add any security risks.
为满足这些要求而指定的协议，例如[ROHC]，必须能够根据IPSEC要求2.2.4压缩包含IPSEC头的数据包。在这些协议中可能需要考虑其他安全方面。然而，本文件本身并不增加任何安全风险。
Mikael Degermark Dept. of Computer Science University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077 USA
亚利桑那大学计算机科学系Mikel-DeGeMar系，Tucson，AZ，85021-10077，210077号箱，美国
Phone: (May-July): +46 70 833-8933
Phone: +1 520 621-3489
Fax: +1 520 621-4246
EMail: micke@cs.arizona.edu
Phone: (May-July): +46 70 833-8933
Phone: +1 520 621-3489
Fax: +1 520 621-4246
EMail: micke@cs.arizona.edu
[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership Project; Technical Specification Group Services and Systems Aspects; Architecture for an All IP network.
[TR]3GPP TR 23.922版本1.0.0，第三代合作伙伴项目；技术规范组服务和系统方面；全IP网络的体系结构。
[TS] TS 22.101 version 3.6.0: Service Principles
[TS]TS 22.101版本3.6.0：服务原则
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[OHC] Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC 3095, June 2001.
[OHC]Bormann，C.，编辑，“鲁棒头压缩（ROHC）”，RFC30952001年6月。
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。