⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1112.txt

📁 RFC规范的翻译稿
💻 TXT
📖 第 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: (415) 723-9427
   EMail: deering@PESCADERO.STANFORD.EDU
RFC1112  Host Extensions for IP Multicasting                         RFC 主机扩展用于IP多点传送

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -