rfc3048.txt

很多RFC的中文文档

   o  放弃从前的工作成果。设计可靠的传输协议是耗时费力的过程。在过去的5年中，人
们已经在这方面做了很多工作，例如RMTP-II，SRM，PGM。要大规模的重新设计这些部
件的风险之一就是不能利用这些从前的工作成果。

2.3.	对构件模块的要求
基于以上这些考虑,我们建议一个构件模块必须满足以下的要求：
o广泛的实用性。  为了保证部件能够被重复利用，应该能够在协议族间通用，并能够
升级。
o简明性。  为了保证对部件API所做的限制不会明显的减缓标准的处理过程，API要
简单，定义直接。在定义这些API时，不需要作相应的基础性的研究。
o 高效性。  构件模块要尽可能的避免破坏“较快的轨迹”，就是那些通常的包处理过
程。


3．协议部件
    这一部分从一个协议为应用程序所提供的功能部件的角度提出了对于大数据可靠多播
协议的功能分解的方法。这也包括一些虽然不是传输协议中必要的部分但直接受可靠多播协
议某些要求影响的部分。下一节描述的是能够实现这些部件的构件模块。
    尽管以下列举的内容试图囊括所有与一到多大数据传输应用有关的共同的需求，但是在
标准化的过程中还是有可能产生新的要求,因此以下列举的内容不能理解为对传输层协议应
当提供什么、不能做什么的一种指定。不过，需要指出的是，有些功能部件被故意的省略掉
了，这是我们认为它们与所考虑的应用的类型无关（如一到多的大数据传输）。这当中包括
有高级信息排序（这些工作仅依靠简单的序列号是无法实现的），原子传输等。另一点值得
一提的是下面列出的功能部件可能是其他功能部件所要求的而非应用本身直接要求的（如通
常是实现基于ACK的可靠性时需要有关身份的知识）。
以下的列表覆盖了各种传输功能部件，并把它们划分为子部件。
# 数据可靠性（保证良好的吞吐率）
			|-丢失检测/通知
			|-丢失恢复
			|-丢失保护
# 冲突控制
			|-冲突反馈
			|-速率调整
			|-接收方控制
# 安全性
# 组成员身份
			|-身份通知
			|-身份管理
# 会话管理
			|-组成员跟踪
			|-会话公告
			|-会话开始/结束
			|-会话构造（建立）/检测
# 树的构造
    注意，不是所有的协议都需要所有的部件，这取决于协议提供的功能是如何定义的。特
别是有些最小的服务模型对于很多的功能都不需要，它们可以不需要丢失通知，丢失恢复，
组成员身份等。

3.1 子部件定义
* 丢失检测/通知。这包括在传输过程中如何检测丢失的包，以及这些事件的信息如何传递
到一个或多个代理（这些代理负责从传输错误中恢复传送）。这个任务牵涉到扩展性的问题，
有可能导致反馈信息的内爆，如果处理不当会导致很差的吞吐率。通常使用基于TRACK（基
于树的正确认机制）或NACK（负确认）的机制实现这一功能。同样基于这两者组合的机
制也是可能的。
* 丢失恢复。该功能要求在传输其他包时对事件通知做出响应，形式可以是复制丢失的包，
也可以是使用FEC包。该功能实现的方式将极大的影响协议的可扩展性。
* 丢失保护。该功能是要掩盖包丢失，使其不产生丢失通知事件。该功能可以通过使用预先
激活方式传输FEC包。每个FEC包可以从一个整的或部分的应用数据单元产生，这一事实
使得接收方能够在不需要进一步重传的条件下恢复某些丢失的包。在不重传时所能恢复的包
的数目取决于在第一方发送的FEC包的数目。当没有丢失检测/通知和丢失恢复功能的条件
下实现了很好的吞吐率时，丢失保护在上面定义的ALC协议族中被使用到了极限。
* 冲突反馈。对于发送方驱动的冲突控制协议，接收方必须在冲突时提供某种反馈给发送方。
通常包括丢失率和对往返时间的测量。
* 速率调整。如果有冲突反馈，发送方必须调整速率以适应网络。[Whetten99]定义了这种
适应性以及其他的冲突控制要求。
* 接收方控制。为了避免在单速率机制中因为允许接收者和发送者之间有一个很慢的连接而
停止所有进程，冲突控制算法通常要求接收者离开组。对于多速率的方法，发送方对不同连
接速率的接收者可以根据它们连接的速率发送数据，而不会减慢其他接收者的接收速度。
* 安全性。可靠多播的安全性继承了IP多播服务模型中很多复杂棘手的内容。在这个服务
模型中，主机不向其他主机发送信息（流），而是从一个组中通过选举来接收信息（流）。这
意味着每个主机可以加入一个组接收信息。另一方面，主机可以在任何时刻离开组。因此协
议必须指出其对于以下安全性方面因素的影响：
# 发送者认证（因为每个主机可以向组发送）
# 数据加密（因为每个主机都可以加入组接收）
# 传输保护（通过中断传输状态的拒绝服务攻击，或请求未授权资源）
# 组钥匙管理（因为每个主机可以在任何时刻加入或离开组）
    特别指出的是，传输协议应特别注意协议如何在遇到拒绝服务攻击时，通过对控制包的
轻量认证（HW99）机制保护自己。
    对于指定资源的多播服务模型，主机加入指定的发送方和组。因此，如果有武断（仲裁）
的发送者向没有指定接收数据的主机发送数据时，此时对于通过拒绝服务接收数据的主机，
SSM提供了更多的安全性。不过，在使用SSM时，建议使用其它的针对这些攻击的保护措
施，因为SSM针对这些攻击的保护可能仍不够。
    发送者身份认证，数据加密，和组钥匙管理。 尽管这些功能通常在本质上不是传输层
的内容，协议需要了解它在数据安全方面可能有的影响分枝，以及为了处理这些分支影响而
与安全层之间采用的特殊的接口。
* 传输保护。	对于传输层最重要的安全任务是保护传输层本身免受攻击。对于这一点最重
要的功能就是为了防范状态中断以及拒绝服务攻击所采用的典型的对控制包的轻量认证。
* 身份通知。通过该功能数据源或在某个层次结构中的某个代理可以学习接收者或者是低级
的代理的身份或数目。为了是可扩展的，通常典型的情况不需要提供关于每个接收者的身份
的知识。
* 身份管理。 该机制的实现使得成员能够加入、离开组，接收、拒绝新成员，或中断现有
成员的身份。
* 组成员身份跟踪。这是一个可以选择的特性，协议可以与某个能跟踪一个大的组中每个接
收者身份的部件相连接。如果这样的话，该特性可以跨段实现，可以通过更高层的协议实现。
这对于某些要求跟踪使用的系统，以及记账，使用报告等有用。
* 会话广告。该功能公布会话名称内容，以及接收所需的参数。该功能通常通过高层的协议
（HPW99），[HJ98]）来实现。
* 会话开始/结束。这些功能决定了接收和发送者开始和结束的时间。在很多情况下是隐式
的或通过高层的应用程序或协议实现。不过在某些协议中，由于可扩展性的要求，这一任务
最好通过传输层实现。
* 会话建立/监测。考虑到多播会话广泛的程度，对于一个协议而言拥有对协议的各种操作
建立和监测的工具是特别重要的。
* 树的建立。对于包括了层次结构元素的协议如PGM，RMTP-II，能够以某种近似多播路
由拓扑的方式配置这些元素是很重要的。当然，尽管树型配置可以作为会话建立工具的一部
分，但是如果这种配置可以自动运行的话将会更好。


4	对构建模块的建议
在1.1节中介绍的协议族通常使用了不同的机制来实现在第3节中描述的功能部件。这
一节的目的是按照定义构件模块的宏部件对这些机制分组。一个构建模块定义为“一个
能够产生明确的API供其他构建模块或其他协议客户端使用的协议逻辑部件。构建模块
通常是由实现协议功能部件的算法集和包的格式来定义的。一个构建模块可以通过其
API与应用程序或者其他构建模块通信。大多数的构建模块都有管理API，通过它与
SNMP（简单网络管理协议）或其他管理协议通信。在下面一节中，我们将列出一些构
建模块，它们在目前而言，能够覆盖实现1.1中所列协议中需要的绝大多数功能部件。
不过这些列出的只是目前所作的最好的猜测，因此它也不一定是完整的。实际的构建模
块分解，也就是将功能部件划分为构建模块，在今后有可能被修改。
4.1	基于NACK的可靠性模块
该模块定义了基于NACK的丢失检测/通知和恢复功能。它的主要内容是防止（压制）
内爆以及NACK语义。（例如在选择性修复和FEC丢失修复的情况下如何指定要重发的
包）。压制机制包括：
#NACK多播
#NACK单播和多播确认
这些压制机制要能使延时最小同时使冗余信息最少。同时他们对于处理冲突反馈要有特
别的处理权限。
4.2	FEC编码
该构建模块关注的是在为了防止错误或对于丢失包后做出修复响应的情况下包一级的
FEC信息,.它确定了在这两种使用情况下如何对FEC编码做出选择以及如何命名或索引
FEC包。
4.3	冲突控制
该构建模块根据处理冲突控制时不同的政策可能有多个版本。目前主要考虑的有两种方
法：在对会话中所有接收者都提供统一速率的条件下基于源的速率调整和在同一会话中
不同接收者有不同接收速率的条件下多速率的由接收方驱动的方法。多速率方法可能使
用多层多播的流[VRC98]或者是单层的路由过滤[LVS99]。两种方法目前都处在研究状
态，不过第一种方法已经相当成熟使我们能够进行标准化的过程。在写该文档之时，另
外一种基于路由支持的冲突控制算法开始在IRTF RMRG[LVS99]中出现。这些工作可能
会使得将来有一个或多个针对冲突控制的构建模块标准化。
4.4	通用路由支持
在路由器的某些支持的出现使得设计可靠多播协议的工作变得简单了。在某些应用中，
虽然这些额外的支持增加了复杂性和花费，但其带来的好处要更大些[FLST98]。可以利
用路由支持的功能部件包括反馈聚集/压制（对于丢失通知和冲突控制），以及强制重传
修复包。另一个能利用路由支持的部件是互连网包过滤功能，该功能可以为不同的接收
者提供对同一个多播流的不同的传输速率。当这一点与ALC协议结合时尤为有益
[LVS99]。
设计使用这些路由器内部的机制的过程比设计一个只需要端到主机的协议机制要简单。
因此，如果能够用某种通用的方式定义这些机制，使得多个协议能够使用他们但并不需
要依赖他们的话，将会是很有好处的。这个部件有两个部分，一个信号协议和实际的路
由算法。信号协议允许传输协议向路由器请求它希望的功能，而路由算法实际执行这些
功能。由于信号协议可能影响通用协议头，因此定义信号协议的工作更为紧急。信号协
议一个重要的部分就是多个协议包头某种程度的通用性，这一点保证了路由器能够辨识
解析包头。
4.5	树的建立
前面已经说了通过在源和接收方间增加某种对于重传和反馈的集中代理能大大增加可
靠多播协议的可扩展性。使用这些代理可以形成一棵树，源端是树的根，而接收端就是
树的叶子，集中式/本地修复节点处在中间。中间的节点可以是指定这一任务的软件也
可以是执行判决任务的接收者。
这些代理对于数据传输的作用取决于使用的逻辑树是否很好的与实际的路由协议相匹
配。该构建模块的意图是构建管理连接代理的逻辑树。理想的情况是，该模块完成这些
功能时能够根据会话身份，路由拓扑，网络可用性变化的情况做出相应的调整。
4.6	数据安全性
安全性问题是IRTF 安全多播组(SmuG)的研究内容.当条件成熟时IETF将对这些安全性
的要求标准化。
4.7通用包头。
在通用路由支持一节中已经指出在不同的包头中有某些程度的通用性是非常重要的。由
于一些其他的原因，使用相同的数据头也是很有用的。该构建模块包括对协议包头中某
些位的建议，这些包头应当相互之间通用。
4.8	协议核心
以上的构建模块包括了第3节中所列的功能部件，这些功能部件看起来可以满足实现第
2节中所列构建模块的要求。第三节中其他的没有被包括的功能可以通过每个标准化的
协议指定作为协议核心的一部分来实现。

5	安全考虑
RFC2357特别指出TRANSPORT AREA DIRECTORS评审的可靠多播INTERNET草案
必须明确的研究了其所提协议的安全方面的因素。特别是RMT构建模块必须检测拒绝
服务攻击，Specifically, RMT building block works in progress must examine the 
denial-of-service attacks that can be made upon building blocks and affected by building 
blocks   upon the Internet at large。关于数据安全的讨论，也就是对于非授权用户控制会
话信息或显露会话信息的讨论有这么一点要求。读者如果要更详细的细节的话可以参考
RFC2357的第5节。

6	IANA考虑
由于可能有多个构建模块，并且由于设计的限制单个构建模块可能有多个版本。基于这
些原因，创建新的构建模块或者新的版本的构建模块要通过一个由IANA管理的构建模
块注册机构。最开始时，由于4.1到4.3中描述的构建模块都是根据例子或设 计要求提
出的，因此这个注册表是空的。如果被允许作为RFC公开发布的话(使用“请求规范”
政策，在RFC2434中有介绍)，被请求的IANA构建模块注册项将作为规范公布。一个
注册项包括构建模块名称，版本号，简单的文字描述，RFC编号，责任人，IANA对其
分配一个类型号。

7	结论
在本文档中，我们简要的描述了一些构建模块，这些模块可能对于产生适用于一到多可
靠的大数据传输应用范围的可靠多播协议有帮助。前面所示的构建模块列表是根据对于
这一范围内的协议必须实现的功能以及如何将这些功能分组的考虑而得来的。这个列表
并不试图做到包罗所有的内容，只不过是充当指导的角色指明在标准化可靠多播传输
WG的过程中要考虑那些构建模块。

8	致谢