RFC3376_中文版

摘要

本文档说明了因特网组治理协议的第3版，IGMPv3。IGMP协议被IPv4系统用于向邻接的多播路由器报告它们的组成员关系。第3版的IGMP增加了对“源过滤”的支持，即系统能够报告它只对接收到的发往某一特定多播组的数据报中，某些来自特定源地址的数据感爱好，或是只对除某些特定源地址之外的数据感爱好。那个信息能够被多播路由协议用于幸免把某些来自特定源地址的多播数据报发往对它不感爱好的网络。 一、简介

IGMP协议被IPv4系统(主机或路由器)用于向邻接的多播路由器报告它们的组成员关系。需要注意的是IP多播路由器本身也可能是一个或多个多播组的成员。在这种情形下，它会既执行协议的“多播路由器部份”(为它的多播路由协议搜集成员信息)，又执行协议的“组成员部份”(把自己的成员关系通知自己，其它主机，还有邻接的多播路由器)。

IGMP协议还用于其它的IP多播治理功能，这通过利用组成员报告之外的其它的消息类型来实现。这份文档只描述组成员关系报告功能和消息。

这份文档说明IGMP第3版。第1版在RFC1112中说明，是第1个被普遍利用的版本，也是第1个成为因特网标准的版本。第2版在RFC2236中说明，增加了对“低离开延迟”的支持，即多播路由器获知相连的网络中的某一个组中已经没有组成员所花费的时刻大大减少。而第3版增加了对“源过滤”的支持，即系统有能力报告对发往某个特定多播地址的数据报，只希望接收某些特定源的，以支持特定源多播[SSM]，或只希望接收除

某些特定源的。第3版被设计为能够跟第1版，第2版互操作的。

多播侦听者发觉(MLD)是IPv6系统采纳的一种相似的方式，MLD第1版实现了IGMP第2版的功能，MLD第2版实现了IGMP第3版的功能。

二、用于IP多播接收的效劳接口

在一个IP系统内，有一个(至少概念上有)效劳接口，被上层协议或应用程序用于打开或关闭IP层对发往某一特定IP多播地址的数据报的接收。为了充分利IGMPv3的能力，一个系统的IP效劳接口必需支持以下操作：

IPMulticastListen( source-list )

socket, interface, multicast-address, filter-mode,

那个地址：

socket是一个实现相关的参数，用于区别系统中不同的请求实体(程序或进程)；BSD unix系统的socket参数确实是一个例子。

interface是网络接口的一个本地标识，是打开或关闭那个接口对特定多播地址的接收。接口必需是物理上的(比如说以太网接口)或是虚拟的(比如侦中继虚拟电路的端点，或IP-in-IP遂道的端点)。具体的实现必需许诺向interface参数传递一个未指定值，在这种情形下，请求就会被作用于系统的主接口或缺省接口(可能是由系统配置成立的)。若是需要在多个接口上接收同一个多播地址，IPMulticastListen需要为每一个接口单独挪用。

multicast-address是该请求所属的那个IP多播地址，或说是组。若是一个接口上需

要接收多个组地址，IPMulticastListen需要为每一个组地址单独挪用。

filter-mode能够是INCLUDE或是EXCLUDE。在INCLUDE模式下，只有来自source-list参数中列出的那些IP源地址的并发往指定多播地址的数据报才会被接收。在EXCLUDE模式下，只有来自除source-list参数中列出的那些IP源地址之外的源地址，并发往指定多播地址的数据才会被接收。

source-list是0个或多个未排序的IP多播地址的列表。这些地址是希望接收的或是不希望接收的，这具体取决于filter-mode参数。一个具体的实现可能会对源列表的大小强加一个限制，可是那个限制不能小于每一个列表64个地址。当一个操作引发源列表大小的限制被超出，效劳接口必需返回一个错误。

关于一个给定的socket，interface，和multicast address的组合，在任一时刻，只能有一个filter-mode和source-list有效。可是，filter-mode或source-list，或二者，能够被接下来的作用于同一socket，interface，和multicast address组合的IPMulticastListen操作修改。每一个接下来的请求都会完全替换上一个请求。

以前版本的IGMP不支持源过滤，只有一个简单的效劳接口，通过加入和离开操作来打开和关闭给定接口上给定多播地址的接收。在新的效劳接口上的一个等效的操作如下：

加入操作等效于：

IPMulticastListen( socket，interface，multicast-address，EXCLUDE {} );

而离开操作等效于：

IPMulticastListen( socket，interface，multicast-address，INCLUDE {} );

那个地址{}表示一个空的源列表。

一个关于在该效劳接口上提供兼容性的API的例子在[FILTER-API]中。

3、系统保护的多播接收状态

3.一、Socket状态

IPMulticastListen挪用过的每一个Socket，系统为那个Socket记录期望的组播接收状态，那个状态概念上由如下形式的一组记录组成：

(interface，multicast-address，filter-mode，source-list)

响应IPMulticastListen对该socket的每一次挪用，socket的状态会转变。如下：

若是所请求的过滤模式是INCLUDE，而且所请求的源列表是空的。那么跟所请求的接口和多播地址相关的入口若是存在就会被删除，若是不存在如此的入口，那么忽略请求。

若是所请求的过滤模式是EXCLUDE，而且所请求的源列表非空。那么跟请求的接口和多播地址相关的入口若是存在，就修改成含有所请求的过滤模式和源列表。若是如此的入口不存在，就需要利用参数指定的请求创建一个新的入口。

3.二、Interface的状态

除每一个socket的多播接收状态，系统同时也要为它的每一个接口保护或计算一个多播接收状态。那个状态概念上由如下形式的一组记录组成：

(multicast-address，filter-mode， source-list)。

关于一个给定的接口，每一个多播地址最多存在一条记录。那个interface状态是从socket状态继承过来的。可是当不同的socket在同一个多播地址和接口上具有不同的mode和源列表时，二者可能就不同了。比如，假设一个应用程序或进程在socket s1上作如下挪用：

IPMulticastListen( s1，i，m，INCLUDE {a，b，c} )

请求接收来自源地址a,b和c的接口i上发往多播地址m的数据报。

假设同时有另一个程序或进程在socket s2上作了如下挪用：

IPMulticastListen( s2, i, m, INCLUDE {b, c, d} )

请求接收同一个接口i上发往同一个多播地址m的来自源地址b,c,d的数据报。为了同时知足两个socket的接收需求，必需让接口i接收来自源地址a,b,c,d的发往多播地址m的所有数据报。如此的话，在那个例子中，接口i关于多播地址m的接收状态确实是mode为INCLUDE，源地址列表为{a,b,c,d}。

当IP层收到一个来自一个接口的IP多播数据报后，它接下来如何发往正在某个socket上侦听的程序或进程，取决于socket的多播接收状态[而且可能还跟其它条件相关，比如socket绑定在哪个传输层端口上]。因此，在上面的例子中，若是数据报抵达了接口i，而

且它是来自源地址a发往多播地址m的，它会被传送给socket s1但可不能给s2。需要注意的是IGMP查询和报告不属于源过滤的范围，必需老是被主机和路由器处置。

数据报的过滤基于socket的多播接收状态，这是该效劳接口上的一个新特性。前一版本的效劳接口[RFC1112]基于多播加入状态，没有过滤机制。而是，socket上的一个加入仅仅简单地使主机加入接口上的一个组，而且发往那个组的数据报能够被传送给所有的socket，不管它们有无加入。

从socket状态继承接口状态的的大体规那么如下：关于出此刻socket状态中的每一个不同的(interface, multicast-address)对，为接口interface上的那个多播地址multicast-address创建一个interface记录，就像所有的socket记录都含有相同的(interface，multicast-address)对。

-若是任何一个如此的socket记录含有EXCLUDE模式，那么interface记录的过滤模式确实是EXCLUDE。而且interface记录的源列表是所有EXCLUDE模式的socket记录的源列表减去在INCLUDE模式的socket中显现的源列表后的交集。比如接口i上，多播地址m的socket记录如下：

from socket s1: ( i, m, EXCLUDE, {a,b,c,d} )

from socket s2: ( i, m, EXCLUDE, {b,c,d,e} )

from socket s3: ( i, m, INCLUDE, {d,e,f} )

如此的话，相应的接口i上的interface记录确实是：

（m, EXCLUDE {b,c} )

若是第4个socket被加入，比如：

from socket s4: ( i, m, EXCLUDE {} )

那么interface记录就变成：

（m, EXCLUDE {} )

-若是所有的如此的记录的过滤模式都为INCLUDE，那么interface记录的过滤模式确实是INCLUDE。interface记录的源列表确实是所有socket记录的源列表的合集。比如，若是接口i上多播地址m的socket记录如下：

from socket s1：(i, m, INCLUDE {a,b,c} )

from socket s2：(i, m, INCLUDE {b,c,d} )

from socket s3：(i, m, INCLUDE {e,f} )

那么接口i上的相应的interface记录确实是：

(m, INCLUDE, {a,b,c,d,e,f})

若是一个组的所有的socket都在INCLUDE状态，那么具体的实现中，就不能把表示那个组的interface记录表示为EXCLUDE模式。若是在计算一个接口的interface记录时

受到了系统资源的限制，那么应当当即向请求那个操作的应用程序返回一个错误。

当一个IPMulticastListen挪用通过增，删或修改socket状态记录来修改socket状态时，上述的接收接口状态规那么要马上被执行或从头执行。可是注意的是socket状态的修改不必然会致使interface状态的修改。

4、消息格式

IGMP消息用IPv4数据报进行封装，IP协议号是2。本文档所描述的每一个IGMP消息的IP生存时刻都是1。因特网操纵的IP优先组(比如效劳类型0xC0)和IP路由器警告选项的负载会在它的IP首部中。IGMP消息的类型通过[RFC3228]描述的IANA[IANA-REG]来注册。

本文档所描述的IGMPv3协议关注两种类型的IGMP消息类型：

类型号(hex) 消息名称

0x11 成员关系查询

0x22 第3版成员关系报告

IGMPv3的一个具体实现必需同时支持以下的三种消息类型，以能跟初期版本的IGMP互操作(见第7节)。

0x12 第一版成员关系报告 RFC1112

0x16 第二版成员关系报告 RFC2236

0x17 第二版离开组 RFC2236

不能识别的消息类型必需被抛弃，其它的消息类型可能会出此刻更新的IGMP版本中，或IGMP的扩展中，或多播路由协议，或其它。

在本文档中，除非存在其它限制，关键词“查询”和“报告”别离指IGMP成员关系查询和IGMP第3版成员关系报告。

4.一、成员关系查询消息

查员关系查询由IP多播路由器发出，用于查询邻接接口的多播接收状态，查询具有如下的格式：

8bit type=0x11|8bit Max Rsp Code|16bit checksum

32bit group address

4bit Resv|1bit S|3bit QRV|8bit QQIC|16bit Number of Sources(N)

N个Source Address

4.1.一、Max Rsp Code(最大响应代码)

最大响应代码字段指定在发送一个响应报告之前所许诺的最大时刻。实际许诺的时刻，

被称为最大响应时刻，其单位是1/10秒。它跟最大响应代码的换算如下：

if Max Rsp Code < 128 最大响应时刻=Max Rsp Code

if Max Rsp Code >= 128 Max Rsp Code实际上是表示如下的一个浮点值：

0 1 2 3 4 5 6 7

1|exp |mant |

最大响应时刻= (mant | 0x10) << (exp + 3)

最大响应时刻的小值许诺IGMPv3路由器调剂“离开延迟”(最后一台主机离开组的那个时刻点跟路由协议被通知到已经不存在成员的那个时刻点，二者之间的时刻差)。更大的值，尤其在指数范围内的值，能够调剂网络中IGMP流量的爆炸。

4.1.二、校验和

校验和是对整个IGMP数据报以16位为一段进行取反求和。为了计算校验和，校验和字段开始必需被设置成0。当收到一个数据，在处置之前必需先对校验和进行验证。

4.1.3、组地址

当发送一个一般查询的时候，组地址字段必需被置0。当发送一个指定组查询或发送一个指定组和源的查询(见4.1.9)时，必需被设置成要被查询的IP组地址。

4.1.4、Resv(保留)

Resv字段在传输时必需被置0，在接收时必需被忽略。

4.1.五、S标志(禁止路由器处置)

当被设置成1的时候，S标志表示任何接收路由器禁止更新它们在收到查询时要更新的那些按时器。但它不由止查询者选举或一般的在路由器上执行的(当路由器作为一个组成员的时候)主机端的查询处置。

4.1.六、QRV(查询者的健壮变量)

若是不为0，QRV中包括中一个被查询者利用的[健壮变量]的值，若是查询者的健壮变量的值超过7，即QRV字段的最大值，那么QRV被设成0。路由器取最近收到的查询中的QRV值作为它们自己的健壮性变量的值，除非最近收到的QRV是0，在这种情形下，接收者利用缺省的健壮性变量值，或是一个静态配置的值。

4.1.7、QQIC(查询者的查询距离代码)

查询者的查询距离代码字段指定查询者利用的[查询距离]。实际的距离，称为查询者的查询距离(QQI)，以秒为单位表示，从查询者的查询距离代码进行换算的方式如下：

if QQIC < 128 QQI=QQIC

if QQIC >= 128 QQI代表如下的一个浮点值：

0 1 2 3 4 5 6 7

1|exp |mant |

QQI = (mant | 0x10 ) << (exp + 3)

当前为非查询者的多播路由器从最近收到的查询中取QQI值作为自己的[查询距离]值，除非最近收到QQI是0，在这种情形下，接收路由器利用缺省的[查询距离]值。

4.1.八、Number of Sources(N)

源数量(N)字段说明该查询中存在多少个源地址。在一般查询或指定组查询中那个值是0，在指定组和源的查询中，那个值为非0值。该数量受到查询所传输的网络上的MTU的限制。比如，在1500字节MTU的以太网上，含有路由器警告选项的IP首部占去24字节，除源数量之外的IGMP字段占去12字节，还有1464字节用于源地址，这就限制了源地址的数量最多只能有366(1464/4)。

4.1.九、Source Address[i]

Source Address[i]是n个IP单播地址的数组，n确实是Number of Sources(N)字段的值。

4.1.10、附加数据

若是收到的查询中的IP首部中数据报长度字段说明除上述的字段之外，还有附加的数据存在，IGMPv3的实此刻计算校验和的时候必需包括这些数据，可是在发送查询的时候，

必需忽略这些数据，一个IGMPv3的实此刻上述字段之外，不能再包括其它数据。

4.1.1一、查询的变体

查询消息有三种类型的变体：

一、“一般查询”由多播路由器发出，用于获知邻接接口(即查询所传输的网络中所相连的接口)的完整的多播接收状态。在一个一般查询中，组地址字段和源数量(N)字段都为0。

二、“指定组查询”由一台多播路由器发出，用于获知邻接接口中跟某一个IP地址相关的多播接收状态。在指定组查询中，“组地址”字段含有需要查询的那个组地址，源数量(N)字段为0。

3、“指定组和源查询”由一台多播路由器发出，用于获知邻接接口是不是需要接收来自指定的这些源的，发往指定组的多播数据报。在一个指定组和源的查询中，组地址字段含有要查询的多播地址,源地址[i]字段含有相关的源地址。

4.1.1二、查询中的目的IP地址

在IGMPv3中，一般查询的目的IP地址是224.0.0.1，即“所有主机”多播地址。指定组和指定组和源的查询发往的目的IP地址确实是要查询的那个多播地址。可是一个系统必需接收和处置目的IP地址是收到查询的那个接口的某一个地址(单播或多播)的查询。

4.2、第3版成员关系报告

第3版成员关系报告由IP系统发出，用于向邻接路由器报告当前的多播接收状态，或

修改它们的接口的多播接收状态。报告具有以下的格式：

8bit type=0x22|8bit Reserved|16bit checksum

16bit Reserved |16bit Number of Group Records(M)

Group Records[M]

每一个Group Record的内部格式如下：

8bit Record Type |8bit Aux Data type|16bit Number of Sources(N)

32bit Multicast Address

Source Address[N]

Auxiliary Data

4.2.一、Reserved(保留)

保留字段在传输时被设为0，接收时被忽略。

4.2.二、校验和

校验和是对整个IGMP消息以16位为一段进行取反求和。为了计算校验和，校验和字段第一必需被置0。当收到一个数据，在处置之前，必需先对校验和进行验证。

4.2.3、Number of Group Records(M)

组记录数量(M)字段标明在报告存在多个少组记录。

4.2.4、Group Record

每一个组记录字段是一整块数据，其含有的信息是关于发送者在报告发送接口上的某一个多播组的成员关系。

4.2.五、Record Type

见4.2.12。

4.2.六、Aux Data Len

辅助数据长度含有在组记录中的辅助数据的实际长度，其单位是32bit字。它有可能是0，这就表示辅助数据不存在。

4.2.7、Number of Sources(N)

源数量(N)字段标明在组记录中存在多少源地址。

4.2.八、Multicast Address

多播地址字段标明该组记录从属的多播IP地址。

4.2.九、Source Address[i]

源地址[i]字段是一个数组，含有n个单播地址。n确实是该记录的源数量(N)字段的值。

4.2.10、Auxiliary Data

辅助数据字段若是存在，它含有关于该组记录的一些附加信息。本文档所描述的协议IGMPv3，没有概念任何辅助数据。因此，IGMPv3的实此刻任何传输的组记录中都不该该含有任何辅助数据(即必需把Aux Data Len字段置0)。而且在收到的所有组记录中，必需忽略辅助数据的存在。关于辅助数据的语法和内部编码会由以后版本的利用该字段的IGMP或其扩展概念。

4.2.1一、附加数据

若是收到的报告中的IP首部的数据报长度字段标明在最后一个组记录后面有附加的数据存在。IGMPv3的实现必需在计算和验证校验和的时候包括这些附加数据，可是同时必需忽略这些附加数据。当发送一个报告时，一个IGMPv3的实此刻最后一个组记录后面不能包括附加数据。

4.2.1二、组记录类型

在一个报告消息中，有必然数量的不同类型的组记录：

-“当前状态记录”由一个系统发出，用于响应在一个接口上收到的查询。它报告了接口跟某一个多播IP地址相关的当前的接收状态。当前状态记录的记录类型能够是下面两个值中的一个：

值 名字和含义

1 MODE_IS_INCLUDE-标明接口相关于某一指定多播地址的过滤模式为INCLUDE。该组记录中的源地址[i]字段含有该接口的相关于该多播地址的源列表(若是非空的话)。

2 MODE_IS_EXCLUDE-标明接口相关于某一指定多播地址的过滤模式为EXCLUDE。该组记录中的源地址[i]字段含有该接口的相关于该多播地址的源列表(若是非空的话)。

-“过滤模式改变记录”是当本地的IPMulticastListen挪用造本钱地的接口层相关于某一特定多播IP地址的过滤模式的改变的时候(即从INCLUDE变到EXCLUDE，或从EXCLUDE变到INCLUDE)，由系统发出。那个记录包括在一个报告中，而该报告是从发生改变的那个接口上发出来的。过滤模式改变记录的记录类型是以下两个值中的一个：

值 名字和含义

3 CHANGE_TO_INCLUDE_MODE，标明接口相关于某一指定的多播地址的过滤模式改变到INCLUDE。该组记录中的源地址[i]字段含有该指定多播地址相关的新的源列表(若是非空的话)。

4 CHANGE_TO_EXCLUDE_MODE，标明接口相关于某一指定的多播地址的过滤模式改变到EXCLUDE。该组记录中的源地址[i]字段含有该指定多播地址相关的新的源列表(若是非空的话)。

-“源列表改变记录”是当本地的IPMulticastListen挪用造本钱地的接口层相关于某一特定多播IP地址的源列表发生改变，而且该改变不跟过滤模式的改变产生冲突时，由系统发出。该记录包括在一个报告中，而该报告是从发生改变的那个接口上发出来的。源列表改变记录的记录类型是以下两个值中的一个：

值 名字和含义

5 ALLOW_NEW_SOURCE，标明组记录中的源地址[i]字段含有系统希望接收的发往某一多播地址的，新的源的列表。若是这是对一个INCLUDE列表的改变，那么这些地址会被添加到列表中，若是这是对一个EXCLUDE列表的改变，那么这些地址会被从列表中删除。

6 BLOCK_OLD_SOURCE，标明组记录中的源地址[i]字段含有系统不希望再接收的发往某一多播地址的源的列表。若是这是对一个INCLUDE列表的改变，那么这些地址会被从列表中删除，若是这是对一个EXCLUDE列表的改变，那么这些地址会被添加到列表中。

若是源列表的改变是同时添加新的源和阻止旧的源，这两种组记录会同时发往一个多播地址，一个是ALLOW_NEW_SOURCE，另一个是BLOCK_OLD_SOURCE。

咱们把过滤模式改变记录和源列表改变记录都统一称作状态改变记录。

不能识别的记录类型值必需被抛弃。

4.2.13、报告的IP源地址

一个发往目的子网的IGMP报告应当有一个有效的IP源地址。当一个系统尚未取得一个IP地址时，它能够临时利用0.0.0.0。需要注意的是在一个LAN中，源地址0.0.0.0可能同时被多台主机利用。路由器必需接收源地址为0.0.0.0的报告。

4.2.14、报告的IP目的地址

第3版报告在发送时，目的IP地址为224.0.0.22，所有的IGMPv3路由器都在那个地址上侦听。以第1版和第2版兼容模式运行的系统向报告的组地址字段指定的组地址发送v1和v2报告。另外，一个系统必需接收和处置第1版和第2版的报告，它的目的IP地址字段是报告抵达的接口上的某一个IP地址(单播或多播)。

4.2.1五、组记录的表示法

在文档的接下来部份，咱们利用下面的表示法来描述属于某个特定多播组的组记录的内容：

IS_IN(x)-类型INCLUDE，源地址x。

IS_EX(x)-类型EXCLUDE，源地址x。

TO_IN(x)-类型CHANGE_TO_INCLUDE_MODE，源地址x。

TO_EX(x)-类型CHANGE_TO_EXCLUDE_MODE，源地址x。

ALLOW(x)-类型ALLOW_NEW_SOURCE，源地址x。

BLOCK(x)-类型BLOCK_OLD_SOURCE，源地址x。

那个地址x是：

一个大写的字母(如“A”)代表一组源地址，或：

一个表达式(如A+B)，那个地址“A+B”表示A和B的合集，“A*B”表示A和B的交集，“A-B”表示从集合A中拿掉所有集合B的元素。

4.2.16 成员关系报告的大小

若是包括在一个报告中的一组组记录，其大小超出了单个报告消息的大小限制(由它所发送的网络的MTU来决定)，组记录会被分散到多个报告中。

若是单个组记录含有太多的源地址，以致于它超出了报告消息的大小限制，若是它的类型不是MODE_IN_EXCLUDE或CHANGE_TO_EXCLUDE_MODE，它会被拆分成多个组记录，每一个都含有源地址的一个子集并在单个的报告消息中发送。若是它的类型是MODE_IN_EXCLUDE或CHANGE_TO_EXCLUDE_MODE，只会发送单个组记录，组记录尽可能包括多的源地址，但会抛弃一部份，被抛弃的源地址可不能再被报告，要被报告的源地址的选取也是任意的。它偏向于在接下来的每一个报告中，都报告同一组源，而不是每次都报告不同的源。

五、组成员协议的描述

IGMP是一个非对称的协议，别离指定组成员(即那些希望接收多播数据报的主机和路由器)和多播路由器的行为。本节要紧描述IGMPv3运用于所有组成员 的那部份(需要注意

的是，一个同时是组成员的多播路由器会同时执行IGMPv3的两部份，对来自自己的和邻居的IGMP消息，它都会接收和报告。 IGMPv3的多播路由器部份在第6节描述)。

一个系统在所有支持多播接收的接口上执行本节所描述的协议，即便有多个接口连接在同一网络上也是如此。

为了能跟运行旧版本IGMP协议的多播路由器互操作，系统在支持多播接收的每一个接口上保护了一个MulticastRouterVersion=3

MulticastRouterVersion

变量。本节描述在

的接口上组成员系统的行为。关于确信

MulticastRouterVersion变量的值的算法和非第3版的行为，在第7节描述。

“所有系统”多播地址224.0.0.1作为一个特殊的情形处置。所有的系统(包括主机和路由器，多播路由器)接收发往“所有系统”多播地址的来自所有源的数据报。关于这一点，在所有支持多播的接口上都是永久被打开着的。

有两种类型的事件能够触发接口上的IGMPv3协议的行为：

-由本地的IPMulticastListen挪用引发的接口接收状态的修改。

-收到一个查询。

(除要跟初期版本的IGMP进行互操作的请求，接收到的非查询类型的IGMP消息都会被忽略)。

接下来的章节描述这两种情形下所发生的行为。在这些描述中，按时器和计数器的名字出此刻方括号中，这些按时器和计数器的缺省值将在第8节描述。

5.一、接口状态改变时发生的行为

一个IPMulticastListen挪用会引发接口上的多播接收状态的改变，改变规那么见3.2节。每一个如此的改变只作用在单个接口上的单个多播地址。

接口状态的改变引发系统当即从该接口发送一个状态改变报告。该报告的组记录的类型和内容取决于针对该IP多播地址的改变前后，过滤模式和源列表的比较。若是改变前，关于该多播地址不存在接口状态(即那个改变是创建一个新的接口记录)，或改变后，不存在接口状态(即该改变是删除一个接口记录)。那么就涉及 到一个“不存在”状态，该状态被看做拥有一个INCLUDE过滤模式和一个空的源列表。

旧的状态 新的状态 发送的状态改变记录

INCLUDE(A) INCLUDE(B) ALLOW(B-A) BLOCK(A-B)

EXLUCDE(A) EXCLUDE(B) ALLOW(A-B) BLOCK(B-A)

INCLUDE(A) EXCLUDE(B) TO_EX(B)

EXCLUDE(A) INCLUDE(B) TO_IN(B)

若是计算取得的源列表中，ALLOW状态改变记录为空，或BLOCK为空，那么在报告消息中那个记录就被省略。

考虑到状态改变报告消息可能错过一个或多个路由器的可能性，它会被重传[健壮性变量]-1次，时刻距离是从范围(0，[主动报告距离])中随机选取的一个值。

若是前一个改变的状态改变报告尚未被重传完，同一个接口上就发生了新的改变。那么那个新的改变会造成当即对新的状态改变报告进行重传。

新传送的报告的内容通过如下的方式计算取得：第一个报告完成后，相关的组在上一次改变前和改变后的接口状态被进行比较。然后依照上述的表格，报告的记录中表达了二者的不同。可是这些记录不在一条消息中进行传输，而是跟上一次未传送完的的报告的内容合在一路，产生一条新的状态改变报告。把状态改变报告和未传送完的报告进行归并，产生不同报告的规那么描述如下。

归并的状态改变报告在被传输之前，同一个多播地址上的前一个状态改变报告会被中止，然后，新的状态改变报告进行[健壮性变量]次数的重传。

每一次被包括到不同报告中的一个源以上述的方式计算取得，关于该源的重传状态需要被保护到主机对状态改变报告已经传送了[健壮性变量]次数。这是为了保证接下来的一系例状态改变可不能破坏协议的健壮性。

若是接口的接收状态改变，并触发了新的过滤模式改变的状态报告，那么，下一轮[健壮性变量]次数的状态改变报告会包括过滤模式改变记录。若是在此期间，有 任何数量的源列表改变发生，该规那么都适用。主机必需为该组保护重传状态，直到有[健壮性变量]次数的状态改变报告被发送出去了。当在上一次过滤模式改变之 后，已经有[健壮性变量]次数的含有过滤模式改变记录的状态报告被发送出去了，而且接口接收的源列表改变已经启动了下一轮的报告，那么下一轮的状态改变报 告只含有源列表改变记录。

每一次被传送的状态改变报告，其内容以如下的方式确信：若是报告应当含有一个过滤模式改变记录，而且接口的当前过滤模式是INCLUDE，那么报告中就会含有一个TO_IN

记录，不然就会含有一个TO_EX记录。或，若是报告中应当含有源列表改变记录，那就会有一个ALLOW和一个BLOCK记录。这些记录的内容依据以下的表格成立：

记录 包括的源

TO_IN 所有在当前接口状态中必需被转发的

TO_EX 所有在当前接口状态中必需被阻止的

ALLOW 所有在重传状态中必需被转发的

BLOCK 所有在重传状态中必需被阻止的

若是计算出的ALLOW的源列表，或BLOCK的源列表是空的，在状态报告中的记录就会被省略。

注意：当第一个状态改变报告被发出去，会归并进一个不存在的未完成的状态报告。能够被看做是一个拥有空的ALLOW或BLOCK记录的源改变报告(这种重传状态下没有源)。

5.二、接收到一个查询时的行为

当系统接收到一个查询，它可不能当即响应。它会把那个响应延迟一个随机时刻，那个时刻就在接收到的查询消息的最大响应代码中计算取得的最大响应时刻的范围 内。一个系统可能在不同的接口上接收到多个查询，而且是不同类型的(比如一般查询，指定组查询，指定组和源的查询)，每一个查询都需要相应的延迟响应。

在调度一个查询的响应之前，系统必需考虑到前一次调度的还未完成的响应，大多数情形下，会从头调度一个组合的响应。因此，系统必需能够保护以下的状态：

-每一个接口上都有一个按时器，用于调度一般查询的响应。

-每一个接口和特定组相关的按时器，用于调度对指定组查询和指定组和源的查询的响应。

-每一个接口和特定组相关的源列表，被放置在指定组和源查询的响应中。

当一个带有路由器警告选项的查询抵达接口上时，那么系统的状态确实是要报告，报告的延迟时刻从范围(0，[最大响应时刻])中获取，那个地址，最大响应时刻是从接收到的查询中的最大响应代码计算取得的。下面的规那么用于确信一个报告是不是需要被调度和被调度的报告的类型。这些规那么依次被考虑，当发觉第一个匹配规那么 时，即被应用：

一、若是还存在对前一个一般查询的未完成响应，它在被选择的延迟之前被调度，就不需要再调度额外的响应。

二、若是收到的查询是一个一般查询，接口的按时器在选定的延迟以后，必需调度一个一般查询的响应。

3、若是收到的查询是一个指定组查询，或是一个指定组和源的查询，而且不存在该组的前一个查询的未完成的响应，那么组按时器就用于调度一个报告。若是收到的查询是一个指定组和源的查询，那么被查询的源列表必需被记录下来，用于生成响应。

4、若是对该组的前一个查询已经存在未完成的响应，而且新的查询是一个指定组的查

询，或已经被记录下来的该组的源列表是空的，那么那个组的源列表被清空，并利用组按时器调度单个的响应。新的响应在未完成报告的剩余时刻和选定的延迟两个时刻中的较早那个时刻被发送出去。

五、若是收到的查询是一个指定组和源的查询，而且该组存在一个拥有非空源列表的未完成响应。那么组的源列表被增加以含有新的查询的源列表，而且利用组的按时器调度一个单个的响应。新的响应在未完成报告的剩余时刻和选定的延迟两个时刻中的较早的那个时刻被发送出去。

当未完成报告相关的按时器超时，系统在相关的接口上传送一个或多个报告消息，消息中含有一个或多个当前状态记录，如下：

一、若是超时的按时器是接口按时器(即它是一个响应一般查询的报告)，那么为指定的拥有接收状态的接口上的每一个多播地址发送一个当前状态记录。当前状态记录含有该多播地址和相关的过滤模式(MODE_IS_INCLUDE或MODE_IS_EXCLUDE)，和源列表。多个当前状态记录被尽可能地打 到一个报告消息中。

当系统是大量的组的成员的时候，不成熟的算法会致使数据报的爆炸。不要利用单个的按时器，建议实现把如此的报告消息的传输分散到距离(0，[最大响应时 间])中。需要注意的是，任何如此的实现，必需幸免“ask-implosion”问题，即不能收到一个一般查询后当即发送报告。

二、若是超时的按时器是组按时器，而且该组的记录下来的源列表是空的(即它是一个未完成的指定组的查询的响应)，那么，当且仅当接口对该组地址有一个接收 状态时，为该地址发送一个当前状态记录。当前状态记录含有该多播地址，它相关的过滤模式

(MODE_IS_INCLUDE或 MODE_IS_EXCLUDE)和源列表。

3、若是超时的按时器是组按时器，而且该组的记录下来的源列表是非空的(即它是一个未完成的指定组和源的查询的响应)，那么，当且仅当接口对该组地址有一个接收状态时，用于响应的当前状态记录的内容由接口的状态和未完成响应记录来决定，如下表所述：

接口状态 未完成响应记录中的源集 当前状态记录

INCLUDE(A) B IS_IN(A*B)

EXCLUDE(A) B IS_IN(B-A)

若是结果的当前状态记录有一个空的源地址集，就可不能发送响应。

最后，在需要的报告消息被产生以后，跟所有被报告组相关的源列表都会被清除。

六、多播路由器的协议描述

由于当前重点关注主机的实现，该部份略。

7、跟旧版本的IGMP之间的互操作

IGMPv3的主机和路由器跟未升级到IGMPv3的主机和路由器要能互操作。这种兼容性由主机和路由器依照同一网络中其它主机和路由器的IGMP版本采取相应的行为来完成。

7.一、查询版本的不同

成员关系查询消息的IGMP版本以如下方式确信：

IGMPv1查询：长度=8字节，最大响应代码字段为0。

IGMPv2查询：长度=8字节，最大响应代码字段非0。

IGMPv3查询：长度>12字节。

不符合上述情形的查询消息(比如说一个10字节长的查询)必需被抛弃。

7.二、组成员行为

7.2.一、当有旧版本查询者存在的时候

为了跟旧版本的路由器兼容，IGMPv3的主机必需能够在第1版和第2版兼容模式下操作。IGMPv3主机必需为每一个本地接口保护一个跟相连网络的兼容 模式相关的状态。一台主机的兼容模式由主机的兼容模式变量来决定。兼容模式变量有三种可能的状态：IGMPv1，IGMPv2和IGMPv3，该变量在每 一个接口上都保护一个，其值取决于接口接收到的一般查询的版本，还有接口上的旧版本的查询者存在按时器。

为了能更优雅地在IGMP各版本间进行切换，主机在每一个接口上保护了一个IGMPv1查询者存在按时器和一个IGMPv2查询者存在按时器。任何时候， 当一个IGMPv1成员关系查询被收到时，IGMPv1查询者存在按时器被设置成旧版本查询者存在超时的时刻。当一个IGMPv2一般查询被收到后， IGMPv2查询者存在按时器被设置成

旧版本查询者存在超时的时刻。

当一个更旧版本的查询被收到(比当前的兼容模式还旧)，或特定的按时器条件发生时，主机某个接口上的兼容模式就会发生转变。当一个IGMPv1查询者存 在按时器超时，若是当前还有一个IGMPv2查询者存在按时器在运行，那主机就切换到IGMPv2的兼容模式。若是当前没有IGMPv2查询者存在按时器 在运行，主机就直接切换到IGMPv3兼容模式。当IGMPv2查询者存在按时器超时后，主机直接切换到IGMPv3兼容模式。

主机的兼容模式变量的取值取决于在前一个旧版本查询者存在超不时刻内，是不是收到旧版本的一般查询。主机的兼容模式的确信如下：

主机兼容模式 按时器状态

IGMPv3(缺省) IGMPv2查询者存在没有在运行

IGMPv1查询者存在也没有在运行

IGMPv2 IGMPv2查询者存在正在运行

IGMPv1查询者存在不在运行

IGMPv1 IGMPv1查询者存在正在运行

当主机收到一个查询，该查询会造成它的查询者存在按时器被更新，而且需要相应地调整它的兼容模式，它应当当即调整兼容模式。

当主机的兼容模式是IGMPv3，主机就在该接口上利用IGMPv3协议。当主机的兼容模式是IGMPv2，主机就在该接口上利用IGMPv2协议。当主机的兼容模式是IGMPv1，主机就在该接口上利用IGMPv1协议。

一台IGMPv1路由器会发送最大响应代码为0的一般查询，这时，最大响应时刻必需被说明为100(10秒)。

一台IGMPv2路由器发送的一般查询，其最大响应代码被说明为最大响应时刻。即，该字段的全范围段是线性的，不存在指数表示法。

任何时候主机改变了它的兼容模式，会终止掉所有的未完成的响应和重传按时器。

7.2.二、旧版本的组成员的存在

一台IGMPv3的主机可能被放置在某一个网络中，该网络中还有主机未升级到IGMPv3。一台主机的IGMPv3成员关系记录要能够被一个第1版成员报告或第2版成员报告禁止。

7.3、多播路由器的行为

7.3.一、存在旧版本的查询者

IGMPv3路由器可能被放置在一个网络中，该网络中至少还有一台路由器没有被升级到IGMPv3。这就产生了以下需求：

-若是路由器上存在更旧版本的IGMP，查询者必需利用网络中最低版本的IGMP。这

必需通过治理系统来确保；希望跟IGMPv1和IGMPv2兼容的路 由器必需有一个配置选项以运行在IGMPv1或IGMPv2兼容模式下。当在IGMPv1模式下，路由器必需周期性地出最大响应代码为0的查询，而且查询 会在组地址字段被截取掉(即8字节长度)，而且必需忽略离开组消息。它们应当在收到IGMPv2和IGMPv3查询时发出警告，可是如此的警告必需受到一 定的频率限制。若是运行在IGMPv2模式，路由器必需周期性地发出查询，该查询也要在组地址字段被截取(即8字节长度)，在收到IGMPv3查询时，也 要发出警告(如此的警告的频率必需受到限制)。它还要在最大响应代码字段填入最大响应时刻。

-若是路由器没有被显示地配置为利用IGMPv1或IGMPv2，并接收到了一个IGMPv1或IGMPv2的一般查询，它应当写下一个警告日记，这种警告必需受到频率限制。

7.3.二、存在旧版本的组成员

IGMPv3路由器可能被放置在一个网络中，该网络中还有主机没有被升级到IGMPv3。为了跟旧版本的主机兼容，IGMPv3路由器必需在IGMPv1 或IGMPv2兼容模式下运行。IGMPv3为每一个组记录保护一个兼容模式。组的兼容模式由组的兼容模式变量来决定，该变量可能是以下中个值中的一个： IGMPv1,IGMPv2和IGMPv3。每条组记录都有这么一个变量，它的值取决于该组所接收到的成员报告的版本，和该组的旧版本主机存在按时器。

为了更优雅地在不同版本的IGMP间进行切换，路由器为每一个组保护了一个IGMPv1主机存在按时器和一个IGMPv2主机存在按时器。当收到一个 IGMPv1成员关系报告时，IGMPv1主机存在按时器会被设置为旧版本主机存在超不时刻。当收到一个IGMPv2成员关系报告时，IGMPv2主机存 在按时器会被设置为旧版本主机存在超不时刻。

当收到一个更旧版本的报告(比当前兼容模式的版本更旧),或特定的按时器事件发生，组记录的组兼容模式就要发生改变。当IGMPv1主机存在按时器超 时，若是当前正在运行IGMPv2主机存在按时器就切换到IGMPv2的兼容模式。若是没有IGMPv2主机存在按时器在运行，就直接切换到IGMPv3 兼容模式。当一个IGMPv2主机存在按时器超时而且IGMPv1主机存在按时器不在运行，就切换到IGMPv3兼容模式。需要注意的是，当一个组切换回 IGMPv3模式，它需要一些时刻去从头获取指定源的状态信息。指定源的信息通过下一个一般查询获取，可是应当被阻止的源尚未被阻止，直到下一个[组成 员关系距离]后。

组兼容模式变量的值取决于在上一个旧版本主机存在超不时刻内，是不是收到一个更旧版本的报告。组兼容模式的设置依据以下规那么：

组兼容模式 按时器状态

IGMPv3(缺省) IGMPv2主机存在没有运行

IGMPv1主机存在也没有运行

IGMPv2 IGMPv2主机存在正运行

IGMPv1主机存在没有运行

IGMPv1 IGMPv1主机存在正运行

若是一台路由器收到一个报告，该报告造成该路由器的旧版本主机存在按时器被更新而且其兼容模式也要发生相应的转变，它应当当即切换其兼容模式。

当组兼容模式是IGMPv3，路由器为该组利用IGMPv3协议。当组兼容模式是IGMPv2，路由器在内部把下面的IGMPv2消息转化为它们等价的IGMPv3模式：

IGMPv2消息 IGMPv3等价形式

报告 IS_EX({})

离开 TO_IN({})

IGMPv3的阻止消息被忽略，在TO_EX()消息中，源列表也被忽略，即任何TO_EX()消息被处置为TO_EX({})。

当组兼容模式是IGMPv1，路由器在内部把下面的该组的IGMPv1，IGMPv2消息转化为它们的等价的IGMPv3形式：

IGMP消息 IGMPv3等价形式

v1报告 IS_EX({})

v2报告 IS_EX({})

除忽略IGMPv3阻止消息，和IGMPv2兼容模式下的TO_EX()消息的源列表，IGMPv2离开消息，IGMPv3的TO_IN消息也要被忽略。

八、按时器，计数器列表和它们的缺省值

略。

九、平安性方面的考虑

略