rfc1112.txt

来自「283个中文RFC文档」· 文本 代码 · 共 406 行 · 第 1/3 页

要注意的是，多播路由器接收所有IP多播数据报，因此不需要明确的指明它的地址。还要
注意的是，路由器不需知道哪些主机属于一个组，而仅需知道是否至少有一个主机属于在特
定网络上的一个组。
对以上描述的特性有两个例外。第一，如果在请求收到以前，已经有一个报告延时定
时器在为一个组成员运行，则该定时器不会重置为一个新的随机值，而允许以它的当前值运
行。第二，报告定时器不会因为主机是所有主机组（224.0.0.1）的成员而生成，这个成员关
系不会被报告。
如果主机使用伪随机数生成器计算报告延迟时间，主机的单个IP地址之一应用作生成
器种子的一部分，以减少多宿主机生成相同的延迟序列的可能性。
主机应该确保接收到的报告的IP目的地址字段和IGMP组地址字段有相同的IP组地
址。以保证主机自己的报告不会因为错误的接收报告而取消。主机应该丢弃除了主机成员请
求或主机成员报告类型以外的任何IGMP报文。
多播路由器周期性地发送请求，以更新它所知的，在特定网络上目前的成员关系情况。
如果在几次请求之后，没有接收到特定组的报告，则路由器假设这个组已经没有本地成员，
它们就不需转发从远端传来的那个组的多播数据报到本地网络上。正常情况下，请求被发送
的频率很低（每分钟不超过一次），因此IGMP对主机和网络的开销非常小。然而，当多播
路由器启动时，它可以发出几个时间间隔很小的请求，以便尽快获知本地成员的情况。
当主机加入一个新的组时，它应该立即发送一个那个组的报告，而不是等待一个请求，
以防万一它是这个网络上该组的第一个成员。考虑到初始的报告可能丢失或损坏，建议在一
个短的延迟后重复报告一到两次。（达到这一目的的一种简单的方式是好像仅仅那个组的请
求被接收，设置组随机报告延迟定时器。以下的状态变换图解释了这种方法。）
要注意的是，在一个没有多播路由器的网络上，当有主机加入一个新组时，唯一的IGMP
通信量是一个或多个报告的传送。

状态变换图
通过下面的状态转换图，将更加正式地说明IGMP特性。每个主机可能处于三种可能
的状态中的一种，这与在任意的单个网络接口上的一个单独的IP主机组有关。
—非成员状态，当主机不属于这个接口上的组时。这是所有网络接口上所有成员的初
始状态；它不需要主机的存储空间。
—延时成员状态，当主机属于那个接口上的组时，需要为这个成员关系运行一个报告
延时定时器。
—空闲成员状态，当主机属于那个接口上的组时，不需要为这个成员关系运行一个报
告延时定时器。
有五种重大的事件能使IGMP状态变换：
  —当主机决定加入这个接口的组时，出现“加入组”事件。这只能出现在非成员状态。
  —当主机决定离开这个接口的组时，出现“离开组”事件。这只能出现在延迟成员和
空闲成员状态。
  —当主机收到一个有效的IGMP主机成员请求报文时，出现“请求收到”事件。要达
到有效状态，请求报文必须至少有8字节长，有一个正确的IGMP校验和和地址为224.0.0.1
的IP目的地址。单一的请求适合于收到请求的接口的所有成员关系。这里不考虑非成员状
态或延迟成员状态的情况。
—当主机接收到一个有效的IGMP主机成员报告报文时，出现“报告收到”状态。要达
到有效状态，报告报文必须至少有8字节长，有一个正确的IGMP校验和，而且在它的IP
目的地址字段和IGMP组地址字段有相同的IP组地址。报告仅用于在接收到报告的接口上，
由报告标识的组组成员。这里不考虑非成员状态或空闲成员状态的情况。
—当接口上的组的报告延迟定时器超时时，出现“定时器超时”事件。它只出现在延迟
成员状态。
所有其它的事件，如收到无效的IGMP报文，或收到除请求或报告之外的IGMP报文，
被忽略了。
有三种可能的动作，可以用来响应以上事件：
—为那个接口上的组“发送报告”。
—为那个接口上的组“打开定时器”，使用在0到D秒之间的随机延时值。
—为那个接口上的组“停止定时器”。
在下面的图表中，每个状态转换弧由促使转换的事件标记，在圆括号中的是在转换过程
中所执行的动作。















                              ________________
                             |                |
                             |                |
                             |                |
                             |                |
                   --------->|     非成员     |<---------
                  |          |                |          |
                  |          |                |          |
                  |          |                |          |
                  |          |________________|          |
                  |                   |                  |
                  |   离开组          |     加入组       | 离开组
                  | (停止定时器)      |  (发送报告，     |
                  |                   |  打开定时器)     |
          ________|________           |          ________|________
         |                 |<---------          |                 |
         |                 |                    |                 |
         |                 |<-------------------|                 |
         |                 |    接收到请求      |                 |
         | 延迟成员        |    (开始定时器)    |     空闲成员    |
         |                 |------------------->|                 |
         |                 |    接收到报告      |                 |
         |                 |    (停止定时器)    |                 |
         |_________________|------------------->|_________________|
                                定时器超时
                                (发送报告)
	所有主机组（地址为224.0.0.1）的处理属于特殊情况。主机开始时是每个接口上的那个
组的空闲成员状态，不会变换到其它状态，也不会为那个组发送报告。

协议参数
最大报告延时D为10秒。
附录2  主机组地址问题
本附录不是IP多播规范的一部分，但提供了有关IP主机组地址的一些问题的背景讨论。

组地址绑定
    IP主机组地址到物理主机地址的绑定可以被认为是IP单播地址绑定的推广。一个IP单
播地址静态地绑定到一个单一的IP网络上的一个单一的本地网络地址接口上。一个IP主机
组地址动态地绑定到一个IP网络集合上的本地网络接口集合上。
IP主机组地址不会绑定到IP单播地址集合上，理解这一点很重要。多播路由器不会维
持每个主机组的单个成员的列表。例如，属于一个以太网的多播路由器仅需有一个与有本地
成员的每个主机组对应的单一的以太网多播地址，而不是那些成员的单个IP或以太网地址
列表。     
临时主机组地址的分配
    本备忘录没有说明暂时的组地址是如何分配的。预期是IP暂时主机组地址空间的不同
部分的分配使用不同的技术。例如，可能有许多服务器联系在一起获得一个新的暂时组地址。
一些高层协议（比如VMTP，在RFC-1045中说明）可以生成高层暂时“进程组”或“实体
组”地址，这些地址会在算法中映射到IP暂时主机组地址的子集中，这与IP主机组地址映
射到以太网多播地址上类似。IP组地址空间的一部分可以留给一些应用程序随机分配，这
些应用程序能容忍和其它多播用户偶尔冲突，在发现一个合适的“安静”地址之前，一直生
成新的地址。
一般来说，主机不能假设被送到主机组地址的数据报将仅仅到达目的主机，或作为暂时
主机组的一个成员接收数据报的目的就是为了接受。在IP层以上，使用高层标识符或认证
标志来检测错误投递。如果发送者不想让不必要的用户收到，则传递给主机组地址的信息应
该被加密或用路由管理控制方法进行控制。

作者地址
   Steve Deering
   Stanford University
   Computer Science Department
   Stanford, CA 94305-2140 
Phone: [phone]
   EMail: [e-mail]
RFC1112  Host Extensions for IP Multicasting                         RFC 主机扩展用于IP多点传送