rfc3048.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：周昕（tomzhou  [e-mail]）
译文发布时间：2001-6-8
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。



网络工作组														B. Whetten
请求的注解: 3048            				                        Talarian
分类:  报告                              				        L. Vicisano
                                                                 Cisco
                                                         	    R. Kermode
                                                                 Motorola
                                                              	M. Handley
                                                              	ACIRI 9
                                                                	S. Floyd
                                                                 ACIRI
                                                                 M. Luby
                                                        			Digital Fountain
                                                            		2001年1月




一到多大规模数据传输可靠多播传输构建模块
（RFC3048 Reliable Multicast Transport Building Blocks for One-to-Many                   
Bulk-Data Transfer）

该备忘录的状态
	该备忘录为互联网团体提供信息。它并不制定任何互联网标准，可以被无限制的发布。

版权声明
    版权 （C） 互联网团体 （2001） 保留所有的权力

摘要
    本文描述了一种传输大量数据的可靠多播传输标准的框架。我们已经使用了当前许多类
型的可靠多播传输体系，从中获得了一些经验，我们力图将这些不同类型的协议归结为一些
构建模块。由此，我们提出了这样一个标准的框架结构。基于这个目的，本文建议把在各种
多播协议中的通用部分称为构建模块。而协议中其他包含了高级协议特别指定的紧密联系的
功能的那些部分则称为协议核心。因此，每个协议都可以通过将协议核心和在各个多播协议
中通用的部分(即许多的构建模块)合并而构成。

1 简介
1.1 协议族
2	构件模块基本原理
2.1	使用构建模块的优点
2.2	使用构建模块的代价
2.3	使用够建模块的要求
3	协议组成部件
3.1	子部件的定义
4	对于构建模块的一些建议
4.1	基于NACK的可靠性分析
4.2	FEC编码
4.3	冲突控制
4.4	对于通用路由的支持
4.5	树型结构
4.6	数据安全
4.7	通用头文件
4.8	协议核心
5	安全性
6	IANA考虑
7	结论
8	致谢
9	参考文献
10	作者地址
11	版权申明


1	简介
RFC2357列出了IETF考虑要将其标准化的可靠多播协议的要求。这些要求包括：
* 冲突控制	协议必须保证在INTERNET上使用是安全的。需要指出的是它必须满足
下列三个规则：
a）	它必须获得好的吞吐量（处理能力），也就是说它不能使过多数据传输或过多
修复性流量的连接持续超载。
b）	它必须保证对连接的较好的利用
c）	它必须满足竞争流量的需求
* 可扩放性	协议应当能够在包括不同的多播网络拓扑结构，连接速度和接收者数目等
条件下正常运行。对于协议在运行中何时以及如何崩溃的了解是十分重要
的。
* 安全性	协议必须经过分析，看看协议中的哪些成分保证了协议能够处理安全性和
保密性的事物。这就包括对于协议在数据保密、发送方身份验证等作用的
理解，同时还包括协议是如何对拒绝服务攻击提供保护等。

	这些要求主要旨在确保每个标准在internet上都能够安全的广泛使用。IRTF可靠多
播研究组织在RMCC[HFW99] 可靠多播传输冲突控制方面目前的研究工作中显示出的
突出的成熟性是使得IETF建立RMT工作组的原因之一。RMCC仅指出了设计可靠多
播系统中的一个子部分。不过碰巧的是，它所指出的要求同时是运用要求与市场要求中
最重要的部分。
	协议满足流量控制，伸缩性以及安全性要求的能力受到许多二级要求的影响，这些
在另一文档[RFC2887]中有描述。概括为以下几点：
	* 顺序保证	协议至少提供源排序或无序传输的任一种保证。但我们不建议对多
个发送者之间的完全排序的支持，这是因为这将使得协议的扩展变得困难，而且这在更
高层中的实现更为容易。
* 接受方伸缩性	协议应当能够支持在一个传输组中同时有较多数目的接收者。
典型的接收方大小至少是每个组中同时有1,000-10,000个接收者，甚至最终可扩展到在
规模更大的Internet上有上百万个接收者。
* 实时反馈	有些版本的RMCC要求软实时反馈，因此协议可能提供检测并把这
些信息返回发送方的方法。尽管这不要求协议软实时地传递数据，但能方便提供指定的
实时反馈是一个重要的运用上的要求。
* 传输保证	在许多运用程序中，一个或多个逻辑上定义的数据单元被传送到多
个客户端，例如一个文件或一组文件，一个软件包，一个债券报价，一个债券报价包，
一个事件消息，一组幻灯片，一个视频的祯或块。一个应用程序数据单元定义为逻辑上
可分的对应用程序有用的数据单元。在某些情况下，一个应用程序数据单元短到可以装
入一个包中。（例如一个时间消息或一个股票报价），而在其他情况下，数据单元可能比
一个包要大的多（例如一个软件包）。协议必须保证传输程序数据单元到接收方的良好
的处理能力。这意味着，当要把接收的数据恢复成应用程序要接收的数据单元时，大部
分传送到接收者的数据都是有用的。协议可能提供一种传输验证机制，该机制让接收者
在数据被接收时通知发送方。有两类验证机制，应用程序数据单元级和传输包一级的。
前者在应用层是有效的。例如用来通知应用程序有关接收者进度以及判断何时停止传输
某一特别的应用程序数据单元。包验证在传输层有效。例如在传送已通过验证时，通知
传输层何时可以释放存储了这些包的缓存空间。包一级的验证还可以对应用层数据单元
验证有帮助。
	* 网络拓扑	协议在应用于完全的Internet环境中时应当不会崩溃。不过，我们意
识到企业内部互联网通常是这些应用的第一个使用环境，因此对这些环境的支持是非常
重要的。而对于卫星网（包括那些有地面返回通路和完全无返回通路的）支持虽然有是
更好的但并不做要求。
	* 组成员身份		组成员身份算法应当是可扩展的。成员身份可以是匿名的（发
送方不知道接收者列表），或完全分布式的（接收者得到接收者的数目或一个接收失败
的表）。
	* 典型应用程序	一个RM（Reliable Multicast可靠多播）协议能够支持的应用应
该包括多媒体广播，实时股票数据发送，多播文件传输，以及复制服务等。

在文档其他部分“协议族”，“协议部件”，“构建块”，“协议核心”，“协议例程”等
术语使用时都有指定的含义。协议族是指一组具有相同特点的RM协议。在我们的分
类中，这些相同的特点是用来实现可靠性的机制。协议部件是决定特定的相同功能的协
议的逻辑部件。构建块是协议实现的一个组成部分，它可以构成协议的一个或多个部件
或者是部件的一个部分。协议核心是一个完整的协议例程所要求的一组功能，其他任何
构件块都没有指定这些功能。协议例程是一个用构建块和协议核心定义的实际的RM协
议。

1.1.  协议族
	设计范围文档[RFC2887]对近十年来提出的最流行的方法进行了一个分类。除了冲突控
制之外，主要的挑战是使用某种能扩张到大量接收者的方式同时确保较好的吞吐量。对于丢
失包使用备份信道（back-channel）的协议，能够利用网络元素的支持对于在有大量接收者
时保持较好的吞吐量非常有益处。而在其他的协议中，这种能力对于在有大量接收者时传输
经过编码的数据同时保持较好的吞吐量也有好处。这种分类把提出的协议分为4类。协议族
中的某些协议提供包一级的传输验证，这对于传输层是有好处的。协议族中的所有协议可以
通过一些能够提供应用程序数据单元的传输验证的高级协议来实现。
(1)	NACK。  象SRM[FJM95]和MDP2[MA99]这样的协议力图通过对请求重发包的请求
使用NACK来限制流量。它们对于网络的基础构架不做要求。
(2)	基于树的ACK。  RMTP[LP96，PSLM97]，RMTP-II[WBPM98]，TRAM[KCW98]这
些协议使用肯定确认（ACKs）。由于ACK可以用来提供传输验证，基于ACK的协议
减少了对于能提供传输验证的附属协议的需要。为了避免在不断扩大的应用中出现
ACK内爆，协议可以使用位于网络中的服务器。
(3)	异步分层编码（ALC）。  这些协议（例如[RV97]，[BLMR98]）采用的是基于发送方
的前向纠错码的方法，这些方法不需要从接收方或是从网络来的反馈来确保良好的吞
吐率。这些协议也使用基于发送方的分级广播和接收方驱动协议加入或脱离这些层，
而不需要通过向发送者发送反馈来保证可扩展的冲突控制。
(4)	路由辅助。  和SRM一样，PGM[FLST98]，[LG97]这样的协议针对包的恢复使用负
确认。这些协议利用了新的路由软件来实现集中的负确认和重传的工作。路由辅助协
议提供的其他功能相对于端到端协议效率更高些。例如[LVS99]就说明了路由辅助如
何对ALC协议提供了精细的冲突控制。路由辅助协议可以通过设计实现以上所描述
的所有协议族。

值得注意的是协议族间的差别不需要非常精细，也不一定是互斥的。实际上协议可能是
属于不同种类的各种机制的组合。例如，基于混合NACK/ACK的协议（例如[WBPM98]）
就是可能的。还有的例子就是比方说属于第一类又属于第三类的协议利用了路由支持。

2	构件模块基本原理
	RFC 2357[MRBP98]指出，不可能仅凭一个可靠多播协议就能够满足所有应用的需要。
因此，IETF希望将那些针对不同应用和网络需要的不同协议进行标准化。本文档关注的是
“一到多的大数据传输”协议的要求。但希望在今后有其他的协议和构建模块能够满足其他
类型应用的需要，例如“多到多”的应用。注意，大数据传输倾向于在一个会话期间传输大
量数据而不是不断的传输数据。研发针对这些不同情况的协议的方法及范围很大程度上取决
于本文档中提出的“构建模块”的方法成功与否。
   
2.1.  构建模块的优点
	从一些小的模块构建一个大的软件是软件工程中一个广为使用的技术。从这一技术中可
以得到的好处包括以下几点：
   o  强调重复利用。一个模块可以在多个协议中使用，这就减少了研发工作的时间要求  
   o  减小了复杂性。各个模块已经可以用一个简单的API来定义，到了这样的程度，如
果把大的协议分解为多个小的部分，就会大大减小整个系统的复杂性。
   o  减少了验证和调试时间。由于复杂性降低，调试这些模块的时间也减小了。一般而言，
验证一组小的模块也比验证一个大的模块要快一些。  
   o  将来更新升级更为容易。今后仍有关于可靠多播的研究，我们也期望着目前最新的东
西能随之进步。用小的模块构建协议能够让协议更容易的更新以体现出今后的研究成果。
   o  通用诊断。如果到了那样的程度，许多协议共享相同的包头文件，那么包的分析工具
和其他的诊断工具就可以做成针对多协议工作的。
   o  减小发展新协议所需要的工作。由于新的应用要求不断推动着新的标准，可以在这些
新的协议中重复利用这些已有的模块。
   o  研发工作可并行进行。如果API事先已经定义好，各个模块的研发工作可以并行的
进行。
2.2.  使用构建模块的代价
	像对软件所做的其他的限制一样，这种将一个协议分解成多个小的部分的方法也存在一
个权衡比较的问题。如果过了某一个点之后，弊大于利，就不值得将一个问题进一步分解。
这些代价包括： 
   o  延缓了研发工作。为两个交互作用的模块定义API是一项费时费力的事。随着模块
数目增加，API数目的增长速率就会超过线性的增长速率。一个部件耦合程度越高，越复杂，
要定一个简单的API就越难，重复利用的可能性就越小。针对传输协议建立并标准化粒化
的构件模块是一个棘手的问题，这在某些情况下对基础性的研究有一定的要求。 
   o  复杂性增加。如果模块太多，由于模块间接口的原因，系统的复杂性实际增加了。
   o  性能降低。每个API都增加了额外的处理代价。如果在通常的包处理中加入一个API
其代价就是使得协议性能下降。