RFC2508.docVIP

RFC2508 组织：中国互动出版网（/） RFC文档中文翻译计划（/compters/emook/aboutemook.htm） E-mail：ouyang@ 译者： 李超（licc_li licc_li@） 译文发布时间：2001-5-23 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。 Network Working Group S. Casner Request for Comments: 2508 Cisco Systems Category: Standards Track V. Jacobson Cisco Systems February 1999 低速串行链路下IP/UDP/RTP数据包头的压缩 （RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links） 本备忘录的状态 本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以 得到改进。请参考最新版的“Internet正式协议标准” STD1 来获得本协议的标准化程度 和状态。本备忘录的发布不受任何限制。 版权声明 Copyright C The Internet Society 1999 . All Rights Reserved. 摘要 本文描述了一种对IP/UDP/RTP数据报头进行压缩的方法，它可以降低在低速串行链路上 的网络开销。多数情况下，三个头可压缩到2-4字节。 请赐教并将您的建议发送到工作组邮件列表rem-conf@或直接给作者。 本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”， “建议”，“或许”，“可选的”在 RFC 2119 中解释。 目录 本备忘录的状态 1 版权声明 1 摘要 1 1. 介绍 2 2. 设想和折中 2 2.1. 单工与全双工 3 2.2. 分片与分层 3 3.压缩算法 3 3.1.基本概念 3 3.2 RTP数据包头压缩 4 3.3协议 5 3.4. RTCP控制包压缩 12 3.5.非RTP UDP包压缩 13 4.与分片的交互 13 5.压缩协商 13 6.致谢 14 7.参考文献 14 8. 安全性考虑 14 9.作者地址 15 10.版权声明 15 1. 介绍 随着实时传输协议 RTP 成为正式的RFC[1]发行，人们对于利用RTP实现不同的网络音视 频应用程序间互操作的兴趣也日益增长。然而，我们也注意到，当使用低速链路如14.4Kb/s 或28.8Kb/s拨号时，12字节的RTP头对于仅有20字节的负载而言开销实在太大。（为了减少 头占用的字节，一些已经在类似环境下存在的应用通常使用自定义的协议，而这样做的代价 就是削减了RTP相关的功能。） 事实上，正如在TCP中已经取得巨大成功，也可通过压缩技术来令IP/UDP/RTP包头变小。 这时，压缩可以针对于RTP头（在端到端应用中），或者IP，UDP，RTP的组合头（在Link-by-Link 应用中）。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果，因为两 种情况下的结果大小均为约2-4字节。同时，由于延迟和丢失率都很低，对Link-by-Link应 用进行压缩性能上也更好。因此我们在这里定义的方法就是针对Link-by-link应用下 IP/UDP/RTP头进行组合压缩。 本文定义的压缩方案可应用于IPv4包、IPv6包或封装了多个IP头的包。为了能同时在IPv6 和IPv4下使用，这里定义的IP/UDP/RTP压缩符合[3]中规定的通用压缩框架。该框架把TCP 和非TCP定义为IP之上的两个传输类。本规范将IP/UDP/TCP从非TCP类中抽取出来创建为第三 类。 2. 设想和折中 本压缩方案的目标是，在不发送UDP校验和的情况下，将大多数包的IP/UDP/RTP头压缩到 2个字节，在带校验和时则压缩到4个字节。这一方案的提出主要是受使用14.4kb/s和 28.8kb/s拨号调制解调器发送音视频时遇到的相关问题所引起。这些链路提供全双工通信， 所以协议利用了这点，尽管协议在用于单工链路时可能性能会有所下降。该方案在本地链路 上往返时间 RTT 很低，从而实现性能最高。 为了降低低速链路下的延迟，除了在第四节中确定了分片和压缩中可能使用的一些交互 外，本规范并未提出大型数据包的分片和占先策略。分片方案可能会单独定义并与本压缩方 案配合使用。 应该注意到，实现的简单性是评价压缩方案的一个重要因素。通信服务器可能要用一个 处理器支持多达100个拨号调制解调器的数据压缩。因此，如下的考虑都是比较恰当的，