组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：范晨&nbsp;(fanchen&nbsp;&nbsp;fan-chen@china.com)<br />
译文发布时间：2001-10-11<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M.&nbsp;Handley<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2887&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S.&nbsp;Floyd<br />
Category:&nbsp;Informational&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ACIRI<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;B.&nbsp;Whetten<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Talarian<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R.&nbsp;Kermode<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Motorola<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L.&nbsp;Vicisano<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M.&nbsp;Luby<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Digital&nbsp;Fountain,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;August&nbsp;2000<br />
<br />
大量数据传输的可靠多播设计空间<br />
（RFC2887——The&nbsp;Reliable&nbsp;Multicast&nbsp;Design&nbsp;Space&nbsp;for&nbsp;Bulk&nbsp;Data&nbsp;Transfer）<br />
<br />
本备忘录状态&nbsp;<br />
本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和<br />
建议。请参考最新版本的"Internet&nbsp;Official&nbsp;Protocol&nbsp;Standards"&nbsp;(STD&nbsp;1)&nbsp;来获得本协<br />
议的标准化进程和状态，此备忘录的发布不受任何限制。<br />
版权注意<br />
版权归因特网协会（2000）所有，保留一切权利。<br />
摘要<br />
可靠多播传输的设计空间很广，并且以及有很多可能的解决方案以及提出来了。然而，<br />
实际应用中的一些具体要求将可能的解决方案限制在一个相对很小的空间之中。本文档给出<br />
了对于设计空间的一个概述，以及实际应用的限制条件如何影响可能的解决方案。<br />
目录<br />
1.&nbsp;简介	2<br />
2.&nbsp;&nbsp;应用限制	2<br />
2.1.&nbsp;&nbsp;每个人都在接收数据吗？	3<br />
2.2.&nbsp;限制接收端的差异	3<br />
2.3.&nbsp;&nbsp;接收端集合扩展	4<br />
2.4.&nbsp;完全可靠vs半可靠	4<br />
2.5.&nbsp;限时传送	5<br />
3.&nbsp;网络限制	5<br />
3.1.&nbsp;外联网vs内联网	5<br />
3.2.&nbsp;&nbsp;返回路径	5<br />
3.3.&nbsp;&nbsp;网络协作	5<br />
4.&nbsp;实现高吞吐的机制	6<br />
4.1.&nbsp;基于ACK的机制	6<br />
4.2.&nbsp;基于NACK的机制	7<br />
4.3.&nbsp;复制	8<br />
4.4.&nbsp;分组层前向纠错	9<br />
4.5.&nbsp;分层FEC	9<br />
5.&nbsp;拥塞控制机制	10<br />
6.&nbsp;安全性问题	11<br />
7.&nbsp;结论	11<br />
8.&nbsp;致谢	12<br />
9.&nbsp;作者地址	12<br />
10.参考文献	13<br />
11.&nbsp;版权声明	15<br />
致谢	15<br />
<br />
1.&nbsp;简介<br />
术语“一般用途的可靠多播协议”是一种自相矛盾的提法。不同的应用对于可靠多播传<br />
输有不同的要求，而且这些要求往往使得要求不同的两个应用没有一个共同的解决方案。当<br />
然，也有一些设计得很好的可靠多播协议能够较好满足多种不同的特定要求。<br />
在本文档中我们试图回顾大量数据传输的可靠多播协议的设计空间。术语“大量数据传<br />
输”（bulk&nbsp;data&nbsp;transfer）在这里是一个广义的名词，主要是指数据流是连续的并且长期<br />
有效，这些限制对于我们所采取的拥塞控制方式是很有必要的。这样一个回顾的目的是为了<br />
得到对这个领域的一个总体看法，并且使得各种特定机制所带来的影响更加明晰。我们的目<br />
的是为了能够为将来这方面的协议标准化工作提供指导。在这里，我们将各种可能的解决方<br />
案收集起来并大致分成若干类，一个实际的协议可能由其中的多种组成。<br />
对解决方案最主要的一个限制是需要扩展到一个更大的接收者集合。对于一个小的接收<br />
者集合，设计空间所受到的限制是很少的。<br />
2.&nbsp;&nbsp;应用限制<br />
不同应用场合对于可靠多播（RM）的要求非常广泛和多样。然而，其中有一些要求对于<br />
RM协议的设计有重大的影响，其中主要包括：<br />
?	上层应用需要知道每个人都在接收数据吗？<br />
?	上层应用需要限制不同接收端的差异吗？<br />
?	上层应用需要扩展接收端集合吗？&nbsp;<br />
?	上层应用需要是完全可靠的吗？&nbsp;<br />
?	上层应用需要数据传输是有序的吗？&nbsp;<br />
?	上层应用需要低延时传输吗？&nbsp;<br />
?	上层应用需要传输有时间限制吗？&nbsp;<br />
?	上层应用需要有很多交互的发送端吗？&nbsp;<br />
?	数据流的传送是断断续续的吗？&nbsp;<br />
?	上层应用需要在因特网中工作吗？&nbsp;<br />
?	上层应用需要在单向信道中工作吗？（例如卫星信道）<br />
?	上层应用需要数据传输是安全的吗？&nbsp;<br />
&nbsp;&nbsp;&nbsp;在对大量数据传输协议的标准化过程中，我们可以不考虑有多个交互的发送端和断断续<br />
续的数据流的应用场合。并不是说这些应用不重要，而是因为我们对于这类应用缺乏有效的<br />
拥塞控制手段。<br />
2.1.&nbsp;&nbsp;每个人都在接收数据吗？<br />
在很多中应用中一个逻辑数据块需要发送给多个客户端，例如一个文件或一组文件，一<br />
个软件包，一个股票配额或者一组股票配额，一个事件通知，一组幻灯片，视频流中的一帧<br />
或者一块。我们将用户数据单元（Application&nbsp;data&nbsp;unit,&nbsp;ADU）定义为应用中有用的一个<br />
逻辑上分离的数据单元。在某些情况下，一个逻辑数据单元可以小到放进一个单独的分组里<br />
（例如一个时间通知或者一个股票配额），然而在另外一些情况下一个逻辑数据单元可能比<br />
一个分组的长度大出很多（例如一个软件包）。<br />
协议中可以将发送确认作为一个选项，从而保证可靠的传输。也就是接收端通知发送端<br />
数据已经送到了这样一种机制。可以有两种类型的确认，一种是在ADU层，另一种是在分组<br />
层。ADU确认在应用层非常有用，它可以使发送端了解接收端的接收进度并决定何时停止发<br />
送一个特定ADU的分组。分组确认主要用于传输层，通知发送端某个分组以及接收到，这样<br />
发送端就可以把该分组所占用的缓冲区释放掉。<br />
某些应用要求所有的接收端都要对是否收到ADU做出确认，这样就可以知道哪些接收端<br />
没有收到数据。这类应用包括收端按数据付费的应用，以及可靠文件系统复制的应用。其它<br />
的一些应用并没有这方面的要求，一个典型例子就是自由软件发布下载。<br />
如果应用确实需要知道是否每个接收端都收到了ADU，就必须从每个接收端都收到一个<br />
正向的确认，当然也可以把这些确认联合起来发送。如果应用中需要确切知道哪个接收端没<br />
有收到ADU，对于确认联合就需要有一些额外的限制。<br />
在同一个应用中ADU层确认和分组层确认可以使用不同的确认机制。比如在ADU层使用<br />
正向确认，而在分组层使用NACK或者基于FEC的传输。一般说来这种做法只是在ADU的长<br />
度远远大于分组长度的时候比较有效。<br />
2.2.&nbsp;限制接收端的差异<br />
在某些应用中需要限制接收端的差异，所有接收端的数据接收能力和特点都应当在一个<br />
特定范围之内。一个典型的例子就是传送股票价格。如果有一个接收终端的接收延时明显比<br />
其它终端要大，那么这将是不能接受的。<br />
如果不损失一点点性能的话，这个要求是很难满足的。最典型的一种解决方法是要求发<br />
送端在没有收到所有接收端的正向确认之前，发送的数据量不能超过一个限定的值。但是这<br />
样一种方案在遇到网络故障或者某个终端故障的时候就会出问题。<br />
2.3.&nbsp;&nbsp;接收端集合扩展<br />
在很多传送实时音视频的应用中并不需要扩展到很多的接收端。对于这些应用，就会有<br />
很多不满足接收端扩展要求的解决方案可以满足它们的要求。<br />
一个好的协议必须能够实现ADU到接收端的一个较高的吞吐量。这也就是说发送到接收<br />
端的大部分数据对于重建ADU都是有用的。协议中还必须提供一个好的拥塞控制机制，与其<br />
它应用公平地共享网络资源。要满足这些要求的话，接收端集合扩展是最重要的一个限制，<br />
因为它把那些可以满足这些要求的方案严格限制到那些同时能够高效实现集合扩展的子集<br />
中。为了实现这些目标，很多系统中都使用了确认分组，但必须认识到在不同方案中使用确<br />
认分组的程度和方法有所不同。<br />
在一个比较小的系统中，要求接收端对每一个分组做出确认是可行的。这样发送端就可<br />
以得到所有接收端的接收状况的最多可能的信息，然后利用这些信息来实现一个较高的吞吐<br />
量以及进行拥塞控制。<br />
在一个大系统中，这样一个“平均ACK”方案在发送端引发“确认爆炸”（acknowledge&nbsp;<br />
implosion）。有些研究人员提出可以通过以较低的频率发送联合确认（aggregate&nbsp;ACK）来<br />
缓解这个问题[RMWT98,&nbsp;BC94]，但是在这类方案中很难实现有效的拥塞控制，因为反馈信息<br />
的频率过低。<br />
用反向确认（NACKs）来替代正向确认（ACKs）能够将这个问题降低为“反向确认爆炸”。<br />
并且事实上发送端也只需要知道至少有一个接收端丢失了数据，我们可以使用多种NACK抑<br />
制机制来实现较高的吞吐率。<br />
环形拓扑ACK方案也是一种可行的解决方案，但是它比树形拓扑更难组建和维护。还有<br />
一种方法是在路由器中添加一些机制，由它们来帮助实现较高的吞吐率并尽可能降低代价。<br />
以上这些方案都有助于改善接收端集合扩展，但是它们都有一些这样那样的局限。有一<br />
类方案可以扩展到无穷多的接收端，即彻底取消所有的反馈信道，这样就可以实现很高的吞<br />
吐率。这样一类开环解决方案将原始数据用FEC机制进行编码，然后把这些编码后的数据放<br />
在一个连续的数据流中传输。接收端可以加入这个多播会话，然后接收足够多的分组直到能<br />
够解码出原始数据，之后它们就退出会话。<br />
因此，会话的目标规模显然是可能解决方案的一个限制条件。所有的解决方案对于小规<br />
模的会话都可以工作得很好，但是随着会话得目标规模增大，可用的解决方案也就越来越少。<br />
应当指出以上这些方案的混合也可能是可行的，比如在分组层使用一种方案，而在ADU<br />
层使用另一种方案（典型情况下overhead高），这在ADU远远大于分组长度的情况下也可<br />
以得到比较好的效果。<br />
2.4.&nbsp;完全可靠vs半可靠<br />
很多应用要求ADU的传输是完全可靠的。如果任何一个ADU丢失，那么接收到的所有其<br />
它ADU都没有意义。最典型的例子就是文件传输应用。<br />
然而，有些应用并不需要传输是完全可靠的。这方面的一个例子的音频广播，在这种应<br />
用中，丢失的分组会使得重建的音频信号质量下降，但并不会致使整个信号失效。这类应用<br />
在IP层之上不加任何额外可靠机制的情况下有时也可以正常工作，但是最好是能够有一个<br />
半可靠的传输协议。<br />
2.5.&nbsp;限时传送<br />
多数应用要求数据尽可能快地被传送到接收端，但通常并没有一个绝对的传输最后期<br />
限。<br />
然而，有些应用对于数据传送有硬性的时间限制，如果数据没有在一个特定时间之前到<br />
达接收端，那么传输这些数据就没有任何意义了。这些时间限制其实是音视频传输的实时限<br />
制的结果，或者是新数据取代旧数据的结果。相对于文件传输，这两类应用对于传输时间必<br />
须进行更加精确的控制。<br />
限时传送一般也隐含着传输是半可靠的，但是反过来并不成立。<br />
3.&nbsp;网络限制<br />
应用所配置的网络本身的一些特点也对可靠多播设计空间增加了一些限制条件。<br />
3.1.&nbsp;外联网vs内联网<br />
原理上外联网和内联网是一样的，但是在实际应用中，内联网是集中控制管理的，可以<br />
使用一些在外联网上根本不可能实现的解决方案。因此在内联网中，如果数据的价值非常高，<br />
可以通过适当升级路由器来协助实现一个可靠多播传输协议。而在公开的外联网中，这方面<br />
的额外开支是不可接受的。<br />
3.2.&nbsp;&nbsp;返回路径<br />
理论上讲当接收端要将反馈信息传回发送端的时候，既可以用多播，也可以用单播。用<br />
多播来传送反馈信息有更大的优势，特别是在基于NACK的协议中要抑制NACK的时候。但是，<br />
我们并不清楚ISP是否允许一个会话的所有成员都把反馈信息发向这个会话。如果不允许使<br />
用多播反馈，那么就只能用单播来进行反馈，这样的代价是引入更多的消息机制。<br />
有些网络中不允许任何形式的反馈。一个例子就是在卫星广播信道中，反向信道通常带<br />
宽非常窄，甚至根本不存在。在这样的网络中就只有基于FEC的解决方案才有可能工作。如<br />
果接收端直接从卫星信道接收数据，那么拥塞控制是不需要的。但是作这样的假定是很危险<br />
的，因为也有可能卫星信道下来以后还有一个下游网络。因此，仍然需要考虑一个不需要返<br />
回路径的拥塞控制的解决方案。<br />
3.3.&nbsp;&nbsp;网络协作<br />
一个可靠多播协议必然会涉及到运行在终端主机上的一套机制，同时也肯定会涉及到路<br />
由器转发多播分组的机制。在某些情况下，可以在一定程度上依靠某些网络元素来协助实现<br />
可靠多播传输。广义上我们按照依靠其它网络元素支持的程度来把实时多播协议分成四类：<br />
?	不需要额外支持<br />
路由器只是单纯的转发分组，可靠多播协议仅仅涉及到发送端和接收端。<br />
?	分层方式<br />
数据被分发到多个多播组中，接收端通过加入适当的多播组来接收它们所需要的数<br />
据。在某些情况下，这要求路由器能够支持快速加入和离开一个多播组，并且支持<br />
更多的转发状态。<br />
?	基于服务器的方式<br />
用一些额外的节点来协助实现数据发送和反馈信息的联合。这些额外的节点可能并<br />
不是一般意义上的发送端或者接收端，它们在反馈树中的作用只是协助实现可靠多<br />
播协议。它们并不需要接收多播数据。<br />
?	基于路由器的方式<br />
在基于路由器的方式中，从发送端到接收端的数据流路径上的路由器可以协助实现<br />
数据的发送和反馈信息的联合与抑制。因为路由器可以直接改变多播的路由，因此<br />
这种方式比起基于服务器的方式对于数据流量以及哪些流量发给哪些组成员可以有<br />
更灵活的控制。然而，一般说来路由器并没有太多剩余的存储量和运算量，这就限<br />
制了能够加入多少额外的功能。并且，路由器的代码比应用程序的代码更难维护，<br />
因此基于路由器的方式应当尽可能具有普适性，它们一旦投入使用就很难再去改变。<br />
4.&nbsp;实现高吞吐的机制<br />
作为一个可靠多播协议，有两个问题是必须解决的，一个是拥塞控制，另一个是高吞吐<br />
率。丢包是跟这两个问题都有关的一个核心问题。在多数网络中拥塞的主要征兆就是丢包。<br />
而实现高吞吐率的主要障碍也是丢包。因此度量丢包率和抑制丢包就成为解决这两个问题的<br />
关键所在。针对这些问题的可靠多播解决方案大致可以分为以下几类：<br />
?	数据包确认<br />
?	丢失数据包的反向确认<br />
?	加入冗余，使接收端能够恢复丢包<br />
这些方法还可以再进行细分，这样我们就可以检查每一种技术能够应用在何种限制条件<br />
下。在这一节中，我们重点探讨使用这些机制来实现高吞吐率，而在下一节中我们将重点研<br />
究使用这些机制来实现拥塞控制。<br />
4.1.&nbsp;基于ACK的机制<br />
在最简单的基于ACK的机制中，每个接收端对于收到的每个数据包都要发一个ACK包给<br />
发送端，对于每个丢失的数据包发一个重传包给发送端。这样一种机制只能应用于小规模的<br />
多播，否则就会在发送端引发ACK确认爆炸。由于这个原因，这种机制对于大多数应用来说<br />
是不可行的。<br />
将多个ACK放入一个单独的数据包[RMWT98]可以缓解确认爆炸的问题，多播组的规模可<br />
以更大一些。然而很快会走到另一个极端，从接收端到发送端的反馈信息频率过低，从而基<br />
于发送端的拥塞控制机制不能够可靠工作。<br />
将接收端排成一个环[WKM94]，通过在环上传送一个“ACK令牌”就可以杜绝确认爆炸问<br />
题的出现。然而环本身的生成和维护很成问题。而且如果环的生成过程中不考虑网络的实际<br />
拓扑（了解网络拓扑在实际中是一个很难的问题），那么每个数据包引发的ACK包通过网络<br />
干线的次数将随着接收端的数量以O(n)增长。<br />
4.1.1.&nbsp;基于树的ACK机制<br />
将接收端排成树形结构[MWB+98,&nbsp;KCW98]，每个接收端将ACK确认发给它的父节点，父<br />
节点再将这些ACK确认联合起来一起发给更上层的父节点。这样一种机制比起环形结构更稳<br />
健也更容易配置。这样一个树形结构只是用于ACK的联合，数据包的多播仍然按照正常方式<br />
进行。树形结构比环形结构更易于构造，因为有更多的局部信息可以利用。而且树形结构的<br />
容错能力也更强，假如有某个节点出故障，受到影响的只是它的所有后代节点。这些后代节<br />
点在发现父节点出现故障之后还可以直接越过父节点，直接向更高一层的节点报告。用这样<br />
一个优秀的ACK树形结构，基于树的ACK机制将有可能成为扩展性最好的一种可靠多播解决<br />
方案。<br />
为了更易于配置，基于树的协议必须是自组织的，也就是说那些接收端必须利用局部信<br />
息以一种可扩展的方式自己生成树形结构的拓扑。这种方式是完全可行的，但却并不容易。<br />
对于基于数的协议来说，限制扩展规模的主要因素是树的生成和维护机制，而不是ACK确认。<br />
如果没有这样一个可扩展的自动生成树形拓扑的机制，协议在实现的时候就必须依靠手工来<br />
配置，这就大大降低了它的可用性和可扩展性。<br />
与树的生成有关的另外一个问题是子树的重传问题。通过适当的路由机制，或者使用多<br />
个多播组，可以由中间节点来把下层节点丢失的数据包重新发给它们，而不是由发送端来重<br />
传这些数据。这依赖于ACK树拓扑和实际数据树的拓扑的中间节点有很好的相关性，并且需<br />
要有相关的机制来限制从发送端到子树的重传。一个好的树拓扑自动生成机制与分区管理的<br />
多播组结合起来可能提供这样一个解决方案。如果没有这样的一个树自动生成机制，就很难<br />
在Internet上的一个很大的多播组中使用子树重传技术。这也可以通过使用传输层路由器<br />
的支持来帮助执行重传，尽管当前的路由器机制[FLST98]支持基于NACK的协议，而不支持<br />
基于ACK的协议。<br />
另外一个重要的问题是ACK树中间节点所做的联合操作的本质是什么。这些节点能够：<br />
1．	如果所有子节点都发送ACK，就把它们联合起来，发送一个单独的ACK<br />
2．	通过发送有ACK的子节点的列表，来进行ACK的联合操作<br />
3．	发送一个联合的ACK，外加一个NACK子节点列表<br />
对于数据包来说，第1种方法显然扩展性更好。然而，如果发送端需要确切知道哪些接<br />
收端收到了数据，第2，3种方法就提供了这些信息。幸运的是，一般说来并不需要对每个<br />
包做这样的操作，而只需要对每个ADU提供这样的信息就可以了。在数据包层用第1种方法，<br />
而在ADU层用第3种方法，这是对于需要这种信息的应用的扩展性最好的解决方案，与其它<br />
数据包层的解决方案相比实际上并没有带来多少开销。<br />
4.2.&nbsp;基于NACK的机制<br />
接收端可以不需要为每个收到的数据包都发送一个ACK，而是对每个检测到已经丢失的<br />
数据包发送一个反向确认（NACK）。这样一种机制相对于基于ACK的机制有以下的优点：<br />
?	发送端不需要知道接收端的确切数目，这样就可以将建立拓扑阶段从环状或树状的<br />
基于ACK的算法中去掉。<br />
?	由接收端来负责可靠性，容错措施就可以相对简单一些。<br />
?	发送端的状态可以大量减少，因为发送端不需要去跟踪接收端的状态。<br />
?	不管多少个接收端丢失了某个数据包，都只需要发送一个NACK给发送端就可以了。<br />
所以NACK抑制是完全可行的。<br />
不足之处在于发送端很难知道它何时可以释放发送缓冲区，并且需要有一些额外的会话<br />
层机制来通知发送端某个接收端已经收到了全部数据。对于大多数应用来说，这些问题都并<br />
不重要。<br />
4.2.1.&nbsp;NACK抑制<br />
基于NACK的协议之间的一个最大差别就在于NACK抑制是如何做的。NACK抑制的目标是<br />
当第一次发现某个包丢失之后，立刻发送一个并且只有一个NACK到发送端，然后丢失数据<br />
的唯一一份拷贝重新发送出来，并且被那些需要这个包的接收端接收下来。<br />
不同的协议用不同的方法来满足或接近满足这些目标。<br />
?	SRM[FJM95]中用发送端到丢失数据的节点之间的闭环传输时间（Round&nbsp;trip&nbsp;time,&nbsp;<br />
RTT）来对随机定时器进行加权。这种方法很有效，但是在NACK抑制开始之前需要<br />
计算每个节点的RTT。<br />
?	NTE[HC97]使用一个基于随机密钥和滑动窗口的发送端触发机制。这种方法不需要<br />
随机定时器，可以用于大型的会话，但是在进行拥塞控制的时候，很难提供一个稳<br />
定的底层反馈流。<br />
?	AAP[Ha99]用指数分布的随机定时器，不需要计算RTT，因此对于大型会话也很有效。<br />
?	PGM[FLST98]和LMS[PPV98]中在路由器中加入额外的算法来抑制重复的NACK。在<br />
PGM中，路由器可以与SRM中的随机定时器协同工作，并且使抑制局部化，从而不<br />
需要对整个多播组进行整体的NACK抑制。<br />
这些方法中最一般的可能是指数分布的随机定时器。尽管使用SRM中的定时器可以减少<br />
反馈延时，但是在RTT未知或接收端总数未知的情况下，它很难得到实际的应用。相比之下，<br />
指数分布的随机定时器对于一个大型的会话，不管其延时特性是好是坏，都可以很好地工作。<br />
只要有可能，任何一种形式的基于随机定时器的方法都可以与路由器的支持结合起来。<br />
发送端触发机制[HC97]就很难与路由器的相关支持结合起来。<br />
4.3.&nbsp;复制<br />
有些可靠多播协议设计时多数情况下并不需要有显式的可靠机制。比如说，在一个用多<br />
播实现的多人网络游戏中，将一个运动物体的位置不停地用多播发出去。这种位置流信息并<br />
不需要额外的可靠保证，因为在重传一个旧的位置之前，新的位置已经取代了旧的位置。然<br />
而，当运动物体与其它物体相交互或者停止移动的时候，就需要保证交互信息或者最终的位<br />
置信息的传送是完全可靠的。<br />
并不只是游戏需要考虑这类问题。NTE共享文本编辑器[HC97]使用同样的机制来处理一<br />
行文字的变化。对于每次更改，都重新发送整个行，那么这种情况下不需要有额外的可靠保<br />
证。复制的主要优势在于它不易收到空间上不相关的丢包的影响。对于传统的基于ACK或<br />
NACK的协议，任何一个包被一个很大的接收端集合中的所有接收端正确接收的概率相当低。<br />
这就导致重传的码率相当高。相比起来，复制流并不受接收端集合增长的影响，不同的接收<br />
端丢失的包通常不同，而这时并不会增加网络的流量。<br />
4.4.&nbsp;分组层前向纠错<br />
前向纠错是用来保护数据使之免受误码破坏的一项很成熟的计数。擦除码在可靠多播可<br />
以得到很好的应用。<br />
最简单的分组层的FEC就是将若干个将要发出的分组合起来对它们进行异或操作，生成<br />
一个新的分组，并将这个新的分组也发送出去。如果每三个原始分组生成一个新的异或分组，<br />
那么这三个分组中的任何一个丢失，而异或分组收到的话，丢失的原始分组可以重建出来。<br />
还有一些更为一般的擦除码[BKKKLZ95],[Ri97],[LMSSS97]可以用k个原始分组生成n<br />
个分组发送出去。这样，只要接收到n个分组中的任意k个分组，k个原始分组都可以完全<br />
重建出来。<br />
在应用FEC的时候，发送端将数据分组分成若干轮，每次对一轮中的分组进行编码并生<br />
成新的监督分组。某些情况下一轮中的所有分组就构成了一个ADU，而在另外一些情况下一<br />
轮中的分组只是ADU的一小部分。<br />
用擦除码来恢复丢包比起用重传机制有很大的进步，因为这时发送端并不需要知道哪些<br />
分组丢失了。因此，在恢复空间上无关的丢包的时候，重传流量就大大减少了。<br />
我们可以把分组层的FEC方案分成两类：主动FEC和被动FEC。这两者的区别在于：主<br />
动FEC中发送端先验地确定对于每一轮数据分组生成多少个监督分组；而在被动FEC中发送<br />
端最开始只发送原始分组，并不发送监督分组，然后，发送端根据接收端的反馈来计算出丢<br />
包最严重的接收端每一轮有多少个丢包，并以此来决定应当生成多少个监督分组。这些监督<br />
分组当然也可以用于丢包不太严重的接收端恢复丢包。接收端通过ACK和NACK来向发送端<br />
报告每一轮有多少个丢包。用NACK的时候，只有每一轮丢包最严重的接收端需要发送一个<br />
NACK，因此它的丢包数就被用来作为NACK中随机定时器的权重。<br />
主动FEC和被动FEC可以结合起来使用，例如，对每一轮发送都使用一定量的主动FEC，<br />
如果某个接收端丢包过于严重无法恢复时，它可以请求发送端对这几轮数据包增加FEC监督<br />
包的数量。<br />
FEC对于减少丢包所造成的重传流量是很有效的，然而，它要求数据分组分成轮来发送，<br />
这会增加端到端的延时。对于大数据量的应用来说这一般不成什么问题，但是对于交互式应<br />
用来说，这种方法可能就不如直接重复发送更为有效。<br />
4.5.&nbsp;分层FEC<br />
当数据被同时发往多个多播组的时候，可以应用另外一种分组层的<br />
FEC[RVC98][BLMR98]。在这种情况下，原始的k个分组经过FEC生成n个编码分组，n远远<br />
大于k。然后这n个编码分组被分别发往多个多播组。当某个接收端想要接收原始数据时，<br />
它可以加入一个或多个多播组，并接收编码分组。当它接收到k个不同的编码分组，它就可<br />
以退出这些多播组并重建出原始的k个分组。<br />
这样一种分层机制的最重要之处在于不同的接收端可以根据它们自己的容量、处理能力<br />
等以不同的速率来接收数据。这种机制中不需要接收端送回任何反馈信息，这样就可以保证<br />
较高的吞吐率，并且吞吐率并不因为接收端集合的大小而受影响。然而，接收端以这种方式<br />
来加入和离开多播组，会给拥塞控制机制带来一定的问题。同一个拥塞控制链上的接收端在<br />
加入和离开分组的时候需要相互协调一下。如下一节所述，[RVC98]中提出了一个分层的拥<br />
塞控制方案。<br />
5.&nbsp;拥塞控制机制<br />
Internet的基本传输模型是最大努力服务（best-effort&nbsp;service）。在这种模型中，<br />
不保证任何的吞吐率、延时和丢包率。终端系统被认为是自适应的，能够在网络拥塞的情况<br />
下把它们的传输率适当降低。尽管以后Internet会开始支持带宽预留并对一些特定应用支<br />
持不同的服务等级，但是除非终端系统明确知道它已经预留了带宽，否则它还是要进行拥塞<br />
控制。<br />
广义上讲，单发送端的多播拥塞控制解决方案有五类：<br />
?	发送端控制，单组&nbsp;<br />
只有一个多播组来做数据传输。用从接收端传回的反馈来控制这个组的发送速率。<br />
目标是按照最慢的接收端的速率来进行传输。<br />
?	发送端控制，多组&nbsp;<br />
把最初得一个多播组按照拥塞点自适应地划分成若干个子组。在应用层，数据首先<br />
发送到离发送端最近的子组，然后由这个子组将数据以更低的速率转发到更远的子<br />
组。用这样一种方式，不同的接收端可以以不同的速率来接收数据。在子组内仍然<br />
使用基于发送端的拥塞控制方案。<br />
?	接收端控制，单组&nbsp;<br />
只有一个多播组来做数据传输。由接收端来根据当前网络的拥塞状况决定是否发送<br />
端的速率过高，不能适应这个速率的接收端就自动离开多播组。<br />
?	接收端控制，分层组织&nbsp;<br />
[RVC98]中提出了一种不需要接收端反馈的分层的拥塞控制机制。发送端将数据同<br />
时分散的发往多个多播组，接收端根据它们自己的网络带宽及网络的拥塞状况来决<br />
定加入哪些多播组，使得接收的数据量能够适应网络的拥塞状况。然而，这种方案<br />
要求在一条瓶颈链路之后的若干个接收端能够相互协调地加入和离开不同的多播<br />
组。并且这种方法是否能够在实际的Internet上应用还未得到完全证实。因此，<br />
在拥塞控制方案上还需要有更深入的工作。<br />
?	基于路由器的拥塞控制&nbsp;<br />
可以在多播路由器中加入额外的机制来协助进行多播的拥塞控制。这些机制包括：<br />
?	条件性加入：某个接收端在加入多播组时设定一个丢包率，当高于这个丢包率<br />
时，允许路由器拒绝其加入。<br />
?	路由器过滤掉合理速率以上的流量。这也包括在网络的不同位置根据局部拥塞<br />
状况设定不同的合理速率[LVS99]。<br />
?	公平排队机制结合端到端速率自适应调整<br />
基于路由器的方案要求路由器比起传统的干线路由器有更多的状态。因此，在短期<br />
内，这类方案只能应用于内联网。<br />
对于可靠多播协议，必须把拥塞控制和可靠传输放在同等重要的位置来考虑。同样的机<br />
制有时在提供可靠传输的同时也实现了拥塞控制。<br />
在基于接收端的拥塞控制方案中，用FEC来做开环数据传送是一个很好的选择，对于大<br />
数据量传输能够达到较高的吞吐率。这是因为开环数据传送不需要接收端的反馈，而基于接<br />
收端的拥塞控制同样也不需要接收端反馈，因此它们是一个完美的配合。<br />
6.&nbsp;安全性问题<br />
一般说来，安全性方面的考虑不会对可靠多播协议的设计带来太大的影响。影响到协议<br />
设计的最主要问题在于接收端集合的扩展。对于数据源和数据完整性验证，接收端集合扩展<br />
并不是一个很大的问题。然而，对于数据加密，密钥分发，以及密钥的重生都会收到接收端<br />
集合扩展的严重影响。基于树和图的密钥重生解决方案[WHA98,WGL97]可能是一个合适的解<br />
决方案。然而这类密钥重生解决方案会如何影响可靠多播协议的数据传输部分的设计还不是<br />
很清楚。<br />
可靠多播协议的安全性中需要考虑的一个主要问题在于第三方的角色。如果除了原始数<br />
据源以外的节点可以被允许发送或转发分组，那么协议的安全模型就必须把这一点考虑进<br />
去。尤其是必须弄清楚这些第三方是否是受信任的。如果协议要求第三方必须是受信任的，<br />
那么这样一个协议就很难应用在Internet上。<br />
如果验证机制在设计上考虑到这一点的话，不受信任的第三方（比如重发数据的接收端）<br />
也是可以应用的。一个典型的做法就是由发送端对数据进行数字签名，并打上时间戳，第三<br />
方原样转发这些由数字签名和时间戳的载荷。<br />
与单播协议不同，多播协议如果在设计的时候不加以特别考虑，将很容易受到拒绝服务<br />
攻击。这时因为任何人都可以加入多播会话，并发送反馈信息来影响整个会话乃至其它接收<br />
端。因此必须仔细考虑怎样设计可靠多播协议保护它免受拒绝服务攻击。一个接收端可能会<br />
要求重发所有的包，或者在基于ACK的协议中拒绝发送ACK确认，这样就有可能会导致一个<br />
可靠多播会话陷入停顿。发送端必须采取相应的策略来处理这样的情况，并在必要的时候把<br />
这样的接收端从组中驱逐出去。一个单个的接收端有可能会伪装成一大群接收端，这在基于<br />
NACK的协议中仍然会是一个问题。在接收端第一次单播响应时为它们每个都分配一个单独<br />
的密钥也许可以避免这类攻击。<br />
由于流量泛滥引发的拒绝服务攻击相对起来比单播容易防范。不想要的发送端可以用<br />
IGMP&nbsp;v3[CDT99]中的机制将它们之间从树形拓扑中删掉。<br />
7.&nbsp;结论<br />
本文中我们纵览了一对多大量数据传输的可靠多播协议设计的概况。多播应用的其它特<br />
点本文中没有考虑。在回顾各种设计策略的过程中，我们重申了可靠多播协议的设计受到很<br />
多因素的影响，因此设计一个能够适用所有情况的解决方案是没有意义的。接着我们描述了<br />
这些影响可靠多播协议设计的因素，并借此说明了应用的需要是如何影响设计协议时各种技<br />
术的选用及组合。我们检查了一种基本的技术，并阐释了它们是如何满足特定应用的要求的。<br />
本文意图为将来IETF对大量数据的可靠多播协议标准化过程提供指导。鉴于各种应用<br />
对于可能解决方案的限制程度，以及需要支持的各种各样应用，可以预见将来的标准化将会<br />
在测试上做大量的工作。这也隐含着不是一次完成对可靠多播传输协议的标准化，而是将这<br />
些协议分解成功能模块，并在可能情况下最大程度上对这些功能模块分离进行标准化。这样<br />
一种方法可以允许协议进化，并使得有新要求的应用能够最大程度上重用已存在并经过测试<br />
的一些技术。<br />
8.&nbsp;致谢<br />
本文回顾了可靠多播设计的不同解决方案。文中介绍的各种思想并不属于作者，而是从<br />
IRTF的可靠多播研究组的各种文档中收集得来。尽管无法将他们的名字都列出来，我还是<br />
要谢谢那些在文档中做出贡献的参与者。<br />
9.&nbsp;作者地址<br />
&nbsp;&nbsp;&nbsp;Mark&nbsp;Handley<br />
&nbsp;&nbsp;&nbsp;ATT&nbsp;Center&nbsp;for&nbsp;Internet&nbsp;Research&nbsp;at&nbsp;ICSI,<br />
&nbsp;&nbsp;&nbsp;International&nbsp;Computer&nbsp;Science&nbsp;Institute,<br />
&nbsp;&nbsp;&nbsp;1947&nbsp;Center&nbsp;Street,&nbsp;Suite&nbsp;600,<br />
&nbsp;&nbsp;&nbsp;Berkeley,&nbsp;CA&nbsp;94704,&nbsp;USA<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;mjh@aciri.org<br />
<br />
&nbsp;&nbsp;&nbsp;Sally&nbsp;Floyd<br />
&nbsp;&nbsp;&nbsp;ATT&nbsp;Center&nbsp;for&nbsp;Internet&nbsp;Research&nbsp;at&nbsp;ICSI,<br />
&nbsp;&nbsp;&nbsp;International&nbsp;Computer&nbsp;Science&nbsp;Institute,<br />
&nbsp;&nbsp;&nbsp;1947&nbsp;Center&nbsp;Street,&nbsp;Suite&nbsp;600,<br />
&nbsp;&nbsp;&nbsp;Berkeley,&nbsp;CA&nbsp;94704,&nbsp;USA<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;floyd@aciri.org<br />
<br />
&nbsp;&nbsp;&nbsp;Brian&nbsp;Whetten<br />
&nbsp;&nbsp;&nbsp;Talarian&nbsp;Corporation,<br />
&nbsp;&nbsp;&nbsp;333&nbsp;Distel&nbsp;Circle,<br />
&nbsp;&nbsp;&nbsp;Los&nbsp;Altos,&nbsp;CA&nbsp;94022,&nbsp;USA<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;whetten@talarian.com<br />
<br />
&nbsp;&nbsp;&nbsp;Roger&nbsp;Kermode<br />
&nbsp;&nbsp;&nbsp;Motorola&nbsp;Australian&nbsp;Research&nbsp;Centre<br />
&nbsp;&nbsp;&nbsp;Level&nbsp;3,&nbsp;12&nbsp;Lord&nbsp;St,<br />
&nbsp;&nbsp;&nbsp;Botany&nbsp;&nbsp;NSW&nbsp;&nbsp;2019,<br />
&nbsp;&nbsp;&nbsp;Australia<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;Roger.Kermode@motorola.com<br />
<br />
&nbsp;&nbsp;&nbsp;Lorenzo&nbsp;Vicisano<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,<br />
&nbsp;&nbsp;&nbsp;170&nbsp;West&nbsp;Tasman&nbsp;Dr.<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Jose,&nbsp;CA&nbsp;95134,&nbsp;USA<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;lorenzo@cisco.com<br />
<br />
&nbsp;&nbsp;&nbsp;Michael&nbsp;Luby<br />
&nbsp;&nbsp;&nbsp;Digital&nbsp;Fountain,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;600&nbsp;Alabama&nbsp;Street<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Francisco,&nbsp;CA&nbsp;&nbsp;94110<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;luby@digitalfountain.com<br />
10.参考文献<br />
&nbsp;&nbsp;&nbsp;[BC94]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;K.&nbsp;Birman,&nbsp;T.&nbsp;Clark.&nbsp;&nbsp;"Performance&nbsp;of&nbsp;the&nbsp;Isis&nbsp;Distributed<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Computing&nbsp;Toolkit."&nbsp;Technical&nbsp;Report&nbsp;TR-94-1432,&nbsp;Dept.&nbsp;of<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Computer&nbsp;Science,&nbsp;Cornell&nbsp;University.<br />
<br />
&nbsp;&nbsp;&nbsp;[BKKKLZ95]&nbsp;J.&nbsp;Bloemer,&nbsp;M.&nbsp;Kalfane,&nbsp;M.&nbsp;Karpinski,&nbsp;R.&nbsp;Karp,&nbsp;M.&nbsp;Luby,&nbsp;D.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Zuckerman,&nbsp;"An&nbsp;XOR-based&nbsp;Erasure&nbsp;Resilient&nbsp;Coding&nbsp;Scheme",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ICSI&nbsp;Technical&nbsp;Report&nbsp;No.&nbsp;TR-95-048,&nbsp;August&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[BLMR98]&nbsp;&nbsp;&nbsp;J.&nbsp;Byers,&nbsp;M.&nbsp;Luby,&nbsp;M.&nbsp;Mitzenmacher,&nbsp;A.&nbsp;Rege,&nbsp;"A&nbsp;Digital<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Fountain&nbsp;Approach&nbsp;to&nbsp;Reliable&nbsp;Distribution&nbsp;of&nbsp;Bulk&nbsp;Data",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Proc&nbsp;ACM&nbsp;SIGCOMM&nbsp;98.<br />
<br />
&nbsp;&nbsp;&nbsp;[CDT99]&nbsp;&nbsp;&nbsp;&nbsp;Cain,&nbsp;B.,&nbsp;Deering,&nbsp;S.,&nbsp;and&nbsp;A.&nbsp;Thyagarajan,&nbsp;"Internet&nbsp;Group<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Management&nbsp;Protocol,&nbsp;Version&nbsp;3",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
<br />
&nbsp;&nbsp;&nbsp;[FLST98]&nbsp;&nbsp;&nbsp;Farinacci,&nbsp;D.,&nbsp;Lin,&nbsp;S.,&nbsp;Speakman,&nbsp;T.&nbsp;and&nbsp;A.&nbsp;Tweedly,&nbsp;"PGM<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reliable&nbsp;transport&nbsp;protocol&nbsp;specification",&nbsp;Work&nbsp;in<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Progress.<br />
<br />
&nbsp;&nbsp;&nbsp;[FJM95]&nbsp;&nbsp;&nbsp;&nbsp;S.&nbsp;Floyd,&nbsp;V.&nbsp;Jacobson,&nbsp;S.&nbsp;McCanne,&nbsp;"A&nbsp;Reliable&nbsp;Multicast<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Framework&nbsp;for&nbsp;Light-weight&nbsp;Sessions&nbsp;and&nbsp;Application&nbsp;Level<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Framing",&nbsp;Proc&nbsp;ACM&nbsp;SIGCOMM&nbsp;95,&nbsp;Aug&nbsp;1995&nbsp;pp.&nbsp;342-356.<br />
<br />
&nbsp;&nbsp;&nbsp;[Ha99]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Handley,&nbsp;M.,&nbsp;"Multicast&nbsp;address&nbsp;allocation&nbsp;protocol<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(AAP)",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
<br />
&nbsp;&nbsp;&nbsp;[HC97]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M.&nbsp;Handley&nbsp;and&nbsp;J.&nbsp;Crowcroft,&nbsp;"Network&nbsp;text&nbsp;editor&nbsp;(NTE)&nbsp;a<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;scalable&nbsp;shared&nbsp;text&nbsp;editor&nbsp;for&nbsp;MBone,"&nbsp;ACM&nbsp;Computer<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Communication&nbsp;Review,&nbsp;vol.&nbsp;27,&nbsp;pp.&nbsp;197-208,&nbsp;Oct.&nbsp;1997.&nbsp;ACM<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SIGCOMM'97,&nbsp;Sept.&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[KCW98]&nbsp;&nbsp;&nbsp;&nbsp;Kadansky,&nbsp;M.,&nbsp;Chiu,&nbsp;D.&nbsp;and&nbsp;J.&nbsp;Wesley,&nbsp;"Tree-based&nbsp;reliable<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;multicast&nbsp;(TRAM)",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
<br />
&nbsp;&nbsp;&nbsp;[LMSSS97]&nbsp;&nbsp;M.&nbsp;Luby,&nbsp;M.&nbsp;Mitzenmacher,&nbsp;A.&nbsp;Shokrollahi,&nbsp;D.&nbsp;Spielman,&nbsp;V.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stemann,&nbsp;"Practical&nbsp;Loss-Resilient&nbsp;Codes",&nbsp;Proc&nbsp;ACM<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Symposium&nbsp;on&nbsp;Theory&nbsp;of&nbsp;Computing,&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[MWB+98]&nbsp;&nbsp;&nbsp;Montgomery,&nbsp;T.,&nbsp;Whetten,&nbsp;B.,&nbsp;Basavaiah,&nbsp;M.,&nbsp;Paul,&nbsp;S.,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Rastogi,&nbsp;N.,&nbsp;Conlan,&nbsp;J.&nbsp;and&nbsp;T.&nbsp;Yeh,&nbsp;"THE&nbsp;RMTP-II<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PROTOCOL",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
<br />
&nbsp;&nbsp;&nbsp;[PPV98]&nbsp;&nbsp;&nbsp;&nbsp;C.&nbsp;Papadopoulos,&nbsp;G.&nbsp;Parulkar,&nbsp;and&nbsp;G.&nbsp;Varghese,&nbsp;"An&nbsp;error<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;control&nbsp;scheme&nbsp;for&nbsp;large-scale&nbsp;multicast&nbsp;applications,"&nbsp;in<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Proceedings&nbsp;of&nbsp;the&nbsp;Conference&nbsp;on&nbsp;Computer&nbsp;Communications<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(IEEE&nbsp;Infocom),&nbsp;(San&nbsp;Francisco,&nbsp;California),&nbsp;p.&nbsp;1188,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;March/April&nbsp;1998.<br />
<br />
&nbsp;&nbsp;&nbsp;[Ri97]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L.&nbsp;Rizzo,&nbsp;"Effective&nbsp;erasure&nbsp;codes&nbsp;for&nbsp;reliable&nbsp;computer<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;communication&nbsp;protocols,"&nbsp;ACM&nbsp;Computer&nbsp;Communication<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Review,&nbsp;vol.&nbsp;&nbsp;27,&nbsp;pp.&nbsp;24-36,&nbsp;Apr.&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[RV97]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L.&nbsp;Rizzo,&nbsp;L.&nbsp;Vicisano,&nbsp;"A&nbsp;Reliable&nbsp;Multicast&nbsp;data<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Distribution&nbsp;Protocol&nbsp;based&nbsp;on&nbsp;software&nbsp;FEC&nbsp;techniques",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Proc.&nbsp;of&nbsp;The&nbsp;Fourth&nbsp;IEEE&nbsp;Workshop&nbsp;on&nbsp;the&nbsp;Architecture&nbsp;and<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Implementation&nbsp;of&nbsp;High&nbsp;Performance&nbsp;Communication&nbsp;Systems<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(HPCS'97),&nbsp;Sani&nbsp;Beach,&nbsp;Chalkidiki,&nbsp;Greece&nbsp;June&nbsp;23-25,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[RVC98]&nbsp;&nbsp;&nbsp;&nbsp;L.&nbsp;Rizzo,&nbsp;L.&nbsp;Vicisano,&nbsp;J.&nbsp;Crowcroft,&nbsp;"The&nbsp;RLC&nbsp;multicast<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;congestion&nbsp;control&nbsp;algorithm",&nbsp;submitted&nbsp;to&nbsp;IEEE&nbsp;Network&nbsp;-<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;special&nbsp;issue&nbsp;multicast.<br />
<br />
&nbsp;&nbsp;&nbsp;[RMWT98]&nbsp;&nbsp;&nbsp;Robertson,&nbsp;K.,&nbsp;Miller,&nbsp;K.,&nbsp;White,&nbsp;M.&nbsp;and&nbsp;A.&nbsp;Tweedly,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"StarBurst&nbsp;multicast&nbsp;file&nbsp;transfer&nbsp;protocol&nbsp;(MFTP)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;specification",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
<br />
&nbsp;&nbsp;&nbsp;[WHA98]&nbsp;&nbsp;&nbsp;&nbsp;Wallner,&nbsp;D.,&nbsp;Hardler,&nbsp;E.&nbsp;and&nbsp;R.&nbsp;Agee,&nbsp;"Key&nbsp;Management&nbsp;for<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Multicast:&nbsp;Issues&nbsp;and&nbsp;Architectures",&nbsp;RFC&nbsp;2627,&nbsp;June&nbsp;1999.<br />
<br />
&nbsp;&nbsp;&nbsp;[WKM94]&nbsp;&nbsp;&nbsp;&nbsp;Brian&nbsp;Whetten,&nbsp;Simon&nbsp;Kaplan,&nbsp;and&nbsp;Todd&nbsp;Montgomery,&nbsp;"A&nbsp;high<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;performance&nbsp;totally&nbsp;ordered&nbsp;multicast&nbsp;protocol,"&nbsp;research<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;memorandum,&nbsp;Aug.&nbsp;1994.<br />
<br />
&nbsp;&nbsp;&nbsp;[WGL97]&nbsp;&nbsp;&nbsp;&nbsp;C.K.&nbsp;Wong,&nbsp;M.&nbsp;Gouda,&nbsp;S.&nbsp;Lam,&nbsp;"Secure&nbsp;Group&nbsp;Communications<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Using&nbsp;Key&nbsp;Graphs,"&nbsp;Technical&nbsp;Report&nbsp;TR&nbsp;97-23,&nbsp;Department<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of&nbsp;Computer&nbsp;Sciences,&nbsp;The&nbsp;University&nbsp;of&nbsp;Texas&nbsp;at&nbsp;Austin,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;July&nbsp;1997.<br />
11.&nbsp;版权声明<br />
&nbsp;&nbsp;&nbsp;版权归Internet协会所有（2000）。保留所有权利。<br />
&nbsp;&nbsp;&nbsp;本文及其译本可以提供给其他任何人，可以准备继续进行注释，可以继续拷贝、出版、<br />
发布，无论是全部还是部分，没有任何形式的限制，不过要在所有这样的拷贝和后续工作中<br />
提供上述声明和本段文字。无论如何，本文档本身不可以做任何的修改，比如删除版权声明<br />
或是关于Internet协会、其他的Internet组织的参考资料等。除了是为了开发Internet<br />
标准的需要，或是需要把它翻译成除英语外的其他语言的时候，在这种情况下，在Internet<br />
标准程序中的版权定义必须被附加其中。<br />
&nbsp;&nbsp;&nbsp;上面提到的有限授权允许永远不会被Internet协会或它的继承者或它的下属机构废除。<br />
&nbsp;&nbsp;&nbsp;本文档和包含在其中的信息以"As&nbsp;is"提供给读者，Internet社区和Internet工程任务<br />
组不做任何担保、解释和暗示，包括该信息使用不破坏任何权利或者任何可商用性担保或特<br />
定目的。<br />
致谢<br />
&nbsp;&nbsp;&nbsp;Internet协会当前为RFC编辑提供了资助，对此表示感谢。<br />
<br />
RFC2887—The&nbsp;Reliable&nbsp;Multicast&nbsp;Design&nbsp;Space&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;大量数据传输的可靠多播设计空间<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for&nbsp;Bulk&nbsp;Data&nbsp;Transfer<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />