IGM因特网组管理协议第3版.docx

IGM因特网组管理协议第3版.docx

《IGM因特网组管理协议第3版.docx》由会员分享，可在线阅读，更多相关《IGM因特网组管理协议第3版.docx（24页珍藏版）》请在冰点文库上搜索。

IGM因特网组管理协议第3版

摘要

   本文档说明了因特网组管理协议的第3版，IGMPv3。

IGMP协议被IPv4系统用于向邻接的多播路由器报告它们的组成员关系。

第3版的IGMP增加了对“源过滤”的支持，即系统能够报告它只对接收到的发往某一特定多播组的数据报中，某些来自特定源地址的数据感兴趣，或者是只对除了某些特定源地址之外的数据感兴趣。

这个信息能够被多播路由协议用于避免把某些来自特定源地址的多播数据报发往对它不感兴趣的网络。

1、简介

   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版的功能。

2、用于IP多播接收的服务接口

   在一个IP系统内，有一个（至少概念上有）服务接口，被上层协议或者应用程序用于打开或者关闭IP层对发往某一特定IP多播地址的数据报的接收。

为了充分利IGMPv3的能力，一个系统的IP服务接口必须支持以下操作：

   IPMulticastListen（socket,interface,multicast-address,filter-mode,source-list）

   这里：

   socket是一个实现相关的参数，用于区别系统中不同的请求实体（程序或者进程）；BSDunix系统的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，和multicastaddress的组合，在任一时刻，只能有一个filter-mode和source-list有效。

但是，filter-mode或者source-list，或者两者，可以被接下来的作用于同一socket，interface，和multicastaddress组合的IPMulticastListen操作修改。

每一个接下来的请求都会完全替换上一个请求。

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

在新的服务接口上的一个等效的操作如下：

   加入操作等效于：

   IPMulticastListen（socket，interface，multicast-address，EXCLUDE{}）;

   而离开操作等效于：

   IPMulticastListen（socket，interface，multicast-address，INCLUDE{}）;

   这里{}表示一个空的源列表。

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

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

3.1、Socket状态

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

   （interface，multicast-address，filter-mode，source-list）

   响应IPMulticastListen对该socket的每一次调用，socket的状态会变化。

如下：

   如果所请求的过滤模式是INCLUDE，并且所请求的源列表是空的。

那么跟所请求的接口和多播地址相关的入口如果存在就会被删除，如果不存在这样的入口，则忽略请求。

   如果所请求的过滤模式是EXCLUDE，并且所请求的源列表非空。

那么跟请求的接口和多播地址相关的入口如果存在，就修改成含有所请求的过滤模式和源列表。

如果这样的入口不存在，就需要使用参数指定的请求创建一个新的入口。

3.2、Interface的状态

   除了每一个socket的多播接收状态，系统同时也要为它的每一个接口维护或者计算一个多播接收状态。

这个状态概念上由如下形式的一组记录组成：

   （multicast-address，filter-mode，source-list）。

   对于一个给定的接口，每个多播地址至多存在一条记录。

这个interface状态是从socket状态继承过来的。

但是当不同的socket在同一个多播地址和接口上具有不同的mode和源列表时，两者可能就不同了。

比如，假设一个应用程序或进程在sockets1上作如下调用：

   IPMulticastListen（s1，i，m，INCLUDE{a，b，c}）

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

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

   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的，它会被传送给sockets1但不会给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记录如下：

   fromsockets1:

   （i,m,EXCLUDE,{a,b,c,d}）

   fromsockets2:

   （i,m,EXCLUDE,{b,c,d,e}）

   fromsockets3:

（i,m,INCLUDE,{d,e,f}）

   这样的话，相应的接口i上的interface记录就是：

   （m,EXCLUDE{a,b,c}）

   如果第4个socket被加入，比如：

   fromsockets4:

（i,m,EXCLUDE{}）

   那么interface记录就变成：

   （m,EXCLUDE{}）

   -如果所有的这样的记录的过滤模式都为INCLUDE，那么interface记录的过滤模式就是INCLUDE。

interface记录的源列表就是所有socket记录的源列表的合集。

比如，如果接口i上多播地址m的socket记录如下：

   fromsockets1：

（i,m,INCLUDE{a,b,c}）

   fromsockets2：

（i,m,INCLUDE{b,c,d}）

   fromsockets3：

（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.1、成员关系查询消息

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

   8bittype=0x11|8bitMaxRspCode|16bitchecksum

   32bitgroupaddress

   4bitResv|1bitS|3bitQRV|8bitQQIC|16bitNumberofSources（N）

   N个SourceAddress

4.1.1、MaxRspCode（最大响应代码）

   最大响应代码字段指定在发送一个响应报告之前所允许的最大时间。

实际允许的时间，被称为最大响应时间，其单位是1/10秒。

它跟最大响应代码的换算如下：

   ifMaxRspCode<128最大响应时间=MaxRspCode

   ifMaxRspCode>=128MaxRspCode其实是表示如下的一个浮点值：

   01234567

   1|exp |mant  |

   最大响应时间=（mant|0x10）<<（exp+3）

   最大响应时间的小值允许IGMPv3路由器调节“离开延迟”（最后一台主机离开组的那个时间点跟路由协议被通知到已经不存在成员的那个时间点，两者之间的时间差）。

更大的值，尤其在指数范围内的值，可以调节网络中IGMP流量的爆炸。

4.1.2、校验和

   校验和是对整个IGMP数据报以16位为一段进行取反求和。

为了计算校验和，校验和字段开始必须被设置成0。

当收到一个数据，在处理之前必须先对校验和进行验证。

4.1.3、组地址

   当发送一个普通查询的时候，组地址字段必须被置0。

当发送一个指定组查询或者发送一个指定组和源的查询（见4.1.9）时，必须被设置成要被查询的IP组地址。

4.1.4、Resv（保留）

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

4.1.5、S标志（禁止路由器处理）

   当被设置成1的时候，S标志表示任何接收路由器禁止更新它们在收到查询时要更新的那些定时器。

但它不禁止查询者选举或者普通的在路由器上执行的（当路由器作为一个组成员的时候）主机端的查询处理。

4.1.6、QRV（查询者的健壮变量）

   如果不为0，QRV中包含中一个被查询者使用的[健壮变量]的值，如果查询者的健壮变量的值超过7，即QRV字段的最大值，那么QRV被设成0。

路由器取最近收到的查询中的QRV值作为它们自己的健壮性变量的值，除非最近收到的QRV是0，在这种情况下，接收者使用缺省的健壮性变量值，或者是一个静态配置的值。

4.1.7、QQIC（查询者的查询间隔代码）

   查询者的查询间隔代码字段指定查询者使用的[查询间隔]。

实际的间隔，称为查询者的查询间隔（QQI），以秒为单位表示，从查询者的查询间隔代码进行换算的方法如下：

   ifQQIC<128   QQI=QQIC

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

   01234567

   1|exp |mant  |

   QQI=（mant|0x10）<<（exp+3）

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

4.1.8、NumberofSources（N）

   源数量（N）字段表明该查询中存在多少个源地址。

在普通查询或指定组查询中这个值是0，在指定组和源的查询中，这个值为非0值。

该数量受到查询所传输的网络上的MTU的限制。

比如，在1500字节MTU的以太网上，含有路由器警告选项的IP首部占去24字节，除源数量之外的IGMP字段占去12字节，还有1464字节用于源地址，这就限制了源地址的数量最多只能有366（1464/4）。

4.1.9、SourceAddress[i]

   SourceAddress[i]是n个IP单播地址的数组，n就是NumberofSources（N）字段的值。

4.1.10、附加数据

   如果收到的查询中的IP首部中数据报长度字段表明除了上述的字段之外，还有附加的数据存在，IGMPv3的实现在计算校验和的时候必须包含这些数据，但是在发送查询的时候，必须忽略这些数据，一个IGMPv3的实现在上述字段之外，不能再包含其它数据。

4.1.11、查询的变体

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

   1、“普通查询”由多播路由器发出，用于获知邻接接口（即查询所传输的网络中所相连的接口）的完整的多播接收状态。

在一个普通查询中，组地址字段和源数量（N）字段都为0。

   2、“指定组查询”由一台多播路由器发出，用于获知邻接接口中跟某一个IP地址相关的多播接收状态。

在指定组查询中，“组地址”字段含有需要查询的那个组地址，源数量（N）字段为0。

   3、“指定组和源查询”由一台多播路由器发出，用于获知邻接接口是否需要接收来自指定的这些源的，发往指定组的多播数据报。

在一个指定组和源的查询中，组地址字段含有要查询的多播地址,源地址[i]字段含有相关的源地址。

4.1.12、查询中的目的IP地址

   在IGMPv3中，普通查询的目的IP地址是224.0.0.1，即“所有主机”多播地址。

指定组和指定组和源的查询发往的目的IP地址就是要查询的那个多播地址。

但是一个系统必须接收和处理目的IP地址是收到查询的那个接口的某一个地址（单播或多播）的查询。

4.1、第3版成员关系报告

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

报告具有以下的格式：

   8bittype=0x22|8bitReserved|16bitchecksum

   16bitReserved             |16bitNumberofGroupRecords（M）

   GroupRecords[M]

   每一个GroupRecord的内部格式如下：

   8bitRecordType|8bitAuxDatatype|16bitNumberofSources（N）

   32bitMulticastAddress

   SourceAddress[N]

   AuxiliaryData

4.2.1、Reserved（保留）

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

4.2.2、校验和

   校验和是对整个IGMP消息以16位为一段进行取反求和。

为了计算校验和，校验和字段首先必须被置0。

当收到一个数据，在处理之前，必须先对校验和进行验证。

4.2.3、NumberofGroupRecords（M）

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

4.2.4、GroupRecord

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

4.2.5、RecordType

   见4.2.12。

4.2.6、AuxDataLen

   辅助数据长度含有在组记录中的辅助数据的实际长度，其单位是32bit字。

它有可能是0，这就表示辅助数据不存在。

4.2.7、NumberofSources（N）

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

4.2.8、MulticastAddress

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

4.2.9、SourceAddress[i]

   源地址[i]字段是一个数组，含有n个单播地址。

n就是该记录的源数量（N）字段的值。

4.2.10、AuxiliaryData

   辅助数据字段如果存在，它含有关于该组记录的一些附加信息。

本文档所描述的协议IGMPv3，没有定义任何辅助数据。

所以，IGMPv3的实现在任何传输的组记录中都不应该含有任何辅助数据（即必须把AuxDataLen字段置0）。

并且在收到的所有组记录中，必须忽略辅助数据的存在。

关于辅助数据的语法和内部编码会由将来版本的使用该字段的IGMP或其扩展定义。

4.2.11、附加数据

   如果收到的报告中的IP首部的数据报长度字段标明在最后一个组记录后面有附加的数据存在。

IGMPv3的实现必须在计算和验证校验和的时候包含这些附加数据，但是同时必须忽略这些附加数据。

当发送一个报告时，一个IGMPv3的实现在最后一个组记录后面不能包含附加数据。

4.2.12、组记录类型

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

   -“当前状态记录”由一个系统发出，用于响应在一个接口上收到的查询。

它报告了接口跟某一个多播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调用造成本地