Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Obsoletes: 2236                                               S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002
        
Network Working Group                                            B. Cain
Request for Comments: 3376                               Cereva Networks
Obsoletes: 2236                                               S. Deering
Category: Standards Track                                    I. Kouvelas
                                                           Cisco Systems
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                          A. Thyagarajan
                                                                Ericsson
                                                            October 2002
        

Internet Group Management Protocol, Version 3

Internet组管理协议,版本3

Status of this Memo

本备忘录的状况

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

Abstract

摘要

This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers.

本文档指定了Internet组管理协议IGMPv3的版本3。IGMP是IPv4系统用于向相邻多播路由器报告其IP多播组成员身份的协议。IGMP版本3增加了对“源过滤”的支持,即系统能够报告是否有兴趣从特定源地址或从发送到特定多播地址的*除*以外的*所有*特定源地址接收数据包。多播路由协议可以使用该信息来避免将多播分组从特定源传送到没有感兴趣的接收器的网络。

This document obsoletes RFC 2236.

本文件淘汰了RFC 2236。

Table of Contents

目录

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Service Interface for Requesting IP Multicast Reception .   3
   3.  Multicast Reception State Maintained by Systems . . . . . . .   5
   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Description of the Protocol for Group Members . . . . . . . .  19
   6.  Description of the Protocol for Multicast Routers . . . . . .  24
   7.  Interoperation with Older Versions of IGMP. . . . . . . . . .  35
   8.  List of Timers, Counters, and Their Default Values. . . . . .  40
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  43
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  47
   12. Normative References. . . . . . . . . . . . . . . . . . . . .  47
   13. Informative References. . . . . . . . . . . . . . . . . . . .  47
       Appendix A. Design Rationale. . . . . . . . . . . . . . . . .  49
       Appendix B. Summary of changes from IGMPv2. . . . . . . . . .  50
       Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  52
       Full Copyright Statement. . . . . . . . . . . . . . . . . . .  53
        
   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Service Interface for Requesting IP Multicast Reception .   3
   3.  Multicast Reception State Maintained by Systems . . . . . . .   5
   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Description of the Protocol for Group Members . . . . . . . .  19
   6.  Description of the Protocol for Multicast Routers . . . . . .  24
   7.  Interoperation with Older Versions of IGMP. . . . . . . . . .  35
   8.  List of Timers, Counters, and Their Default Values. . . . . .  40
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  43
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  47
   12. Normative References. . . . . . . . . . . . . . . . . . . . .  47
   13. Informative References. . . . . . . . . . . . . . . . . . . .  47
       Appendix A. Design Rationale. . . . . . . . . . . . . . . . .  49
       Appendix B. Summary of changes from IGMPv2. . . . . . . . . .  50
       Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  52
       Full Copyright Statement. . . . . . . . . . . . . . . . . . .  53
        
1. Introduction
1. 介绍

The Internet Group Management Protocol (IGMP) is used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to any neighboring multicast routers. Note that an IP multicast router may itself be a member of one or more multicast groups, in which case it performs both the "multicast router part" of the protocol (to collect the membership information needed by its multicast routing protocol) and the "group member part" of the protocol (to inform itself and other, neighboring multicast routers of its memberships).

IPv4系统(主机和路由器)使用Internet组管理协议(IGMP)向任何相邻的多播路由器报告其IP多播组成员身份。注意,IP多播路由器本身可以是一个或多个多播组的成员,在这种情况下,它执行协议的“多播路由器部分”(以收集其多播路由协议所需的成员信息)和协议的“组成员部分”(告知自身和其他相邻多播路由器其成员资格)。

IGMP is also used for other IP multicast management functions, using message types other than those used for group membership reporting. This document specifies only the group membership reporting functions and messages.

IGMP还用于其他IP多播管理功能,使用组成员身份报告以外的消息类型。本文档仅指定组成员资格报告功能和消息。

This document specifies Version 3 of IGMP. Version 1, specified in [RFC-1112], was the first widely-deployed version and the first version to become an Internet Standard. Version 2, specified in [RFC-2236], added support for "low leave latency", that is, a reduction in the time it takes for a multicast router to learn that there are no longer any members of a particular group present on an attached network. Version 3 adds support for "source filtering", that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, as required to support Source-Specific Multicast [SSM], or from *all but* specific source addresses, sent to a particular multicast address. Version 3 is designed to be interoperable with Versions 1 and 2.

本文件规定了IGMP的第3版。[RFC-1112]中指定的版本1是第一个广泛部署的版本,也是第一个成为互联网标准的版本。[RFC-2236]中指定的版本2增加了对“低离开延迟”的支持,即减少多播路由器了解到连接网络上不再存在特定组的任何成员所需的时间。版本3增加了对“源过滤”的支持,也就是说,系统能够根据支持源特定多播[SSM]的需要,报告是否有兴趣从特定源地址*仅*接收数据包,或者从*除*特定源地址以外的所有源地址接收发送到特定多播地址的数据包。版本3旨在与版本1和2互操作。

Multicast Listener Discovery (MLD) is used in a similar way by IPv6 systems. MLD version 1 [MLD] implements the functionality of IGMP version 2; MLD version 2 [MLDv2] implements the functionality of IGMP version 3.

IPv6系统以类似的方式使用多播侦听器发现(MLD)。MLD版本1[MLD]实现IGMP版本2的功能;MLD版本2[MLDv2]实现IGMP版本3的功能。

The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Due to the lack of italics, emphasis is indicated herein by bracketing a word or phrase in "*" characters.

本文件中大写的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。由于缺少斜体字,此处通过将单词或短语括在“*”字符中来表示重点。

2. The Service Interface for Requesting IP Multicast Reception
2. 用于请求IP多播接收的服务接口

Within an IP system, there is (at least conceptually) a service interface used by upper-layer protocols or application programs to ask the IP layer to enable and disable reception of packets sent to specific IP multicast addresses. In order to take full advantage of the capabilities of IGMPv3, a system's IP service interface must support the following operation:

在IP系统内,存在(至少在概念上)由上层协议或应用程序使用的服务接口,以请求IP层启用和禁用发送到特定IP多播地址的分组的接收。为了充分利用IGMPv3的功能,系统的IP服务接口必须支持以下操作:

IPMulticastListen ( socket, interface, multicast-address, filter-mode, source-list )

IPMulticastListen(套接字、接口、多播地址、筛选器模式、源列表)

where:

哪里:

o "socket" is an implementation-specific parameter used to distinguish among different requesting entities (e.g., programs or processes) within the system; the socket parameter of BSD Unix system calls is a specific example.

o “套接字”是一个特定于实现的参数,用于区分系统内的不同请求实体(例如,程序或进程);BSD Unix系统调用的套接字参数就是一个具体的例子。

o "interface" is a local identifier of the network interface on which reception of the specified multicast address is to be enabled or disabled. Interfaces may be physical (e.g., an Ethernet interface) or virtual (e.g., the endpoint of a Frame Relay virtual circuit or the endpoint of an IP-in-IP "tunnel"). An implementation may allow a special "unspecified" value to be passed as the interface parameter, in which case the request would apply to the "primary" or "default" interface of the system (perhaps established by system configuration). If reception of the same multicast address is desired on more than one interface, IPMulticastListen is invoked separately for each desired interface.

o “接口”是要启用或禁用接收指定多播地址的网络接口的本地标识符。接口可以是物理接口(例如,以太网接口)或虚拟接口(例如,帧中继虚拟电路的端点或IP-in-IP“隧道”的端点)。实现可能允许将特殊的“未指定”值作为接口参数传递,在这种情况下,请求将应用于系统的“主”或“默认”接口(可能由系统配置建立)。如果需要在多个接口上接收相同的多播地址,则会为每个所需接口分别调用IPMulticastListen。

o "multicast-address" is the IP multicast address, or group, to which the request pertains. If reception of more than one multicast address on a given interface is desired, IPMulticastListen is invoked separately for each desired multicast address.

o “多播地址”是请求所属的IP多播地址或组。如果需要在给定接口上接收多个多播地址,则会为每个需要的多播地址分别调用IPMulticastListen。

o "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to the specified multicast address is requested *only* from those IP source addresses listed in the source-list parameter. In EXCLUDE mode, reception of packets sent to the given multicast address is requested from all IP source addresses *except* those listed in the source-list parameter.

o “过滤模式”可以是包含或排除。在包括模式下,仅从源列表参数中列出的IP源地址请求*接收发送到指定多播地址的数据包。在排除模式下,从所有IP源地址*请求接收发送到给定多播地址的数据包,源列表参数中列出的除外*。

o "source-list" is an unordered list of zero or more IP unicast addresses from which multicast reception is desired or not desired, depending on the filter mode. An implementation MAY impose a limit on the size of source lists, but that limit MUST NOT be less than 64 addresses per list. When an operation causes the source list size limit to be exceeded, the service interface MUST return an error.

o “源列表”是零个或多个IP单播地址的无序列表,根据过滤模式,需要或不需要从中接收多播。实现可能会对源列表的大小施加限制,但该限制不得小于每个列表64个地址。当操作导致超过源列表大小限制时,服务接口必须返回错误。

For a given combination of socket, interface, and multicast address, only a single filter mode and source list can be in effect at any one time. However, either the filter mode or the source list, or both, may be changed by subsequent IPMulticastListen requests that specify the same socket, interface, and multicast address. Each subsequent request completely replaces any earlier request for the given socket, interface and multicast address.

对于套接字、接口和多播地址的给定组合,一次只能使用单个筛选器模式和源列表。但是,指定相同套接字、接口和多播地址的后续IPMulticastListen请求可能会更改筛选器模式或源列表,或同时更改两者。每个后续请求完全替换给定套接字、接口和多播地址的任何早期请求。

Previous versions of IGMP did not support source filters and had a simpler service interface consisting of Join and Leave operations to enable and disable reception of a given multicast address (from *all* sources) on a given interface. The equivalent operations in the new service interface follow:

IGMP的早期版本不支持源过滤器,并且有一个更简单的服务接口,包括加入和离开操作,用于在给定接口上启用和禁用对给定多播地址(来自*所有*源)的接收。新服务接口中的等效操作如下所示:

The Join operation is equivalent to

联接操作相当于

IPMulticastListen ( socket, interface, multicast-address, EXCLUDE, {} )

IPMulticastListen(套接字、接口、多播地址、排除、{})

and the Leave operation is equivalent to:

而休假操作相当于:

IPMulticastListen ( socket, interface, multicast-address, INCLUDE, {} )

IPMulticastListen(套接字、接口、多播地址,包括,{})

where {} is an empty source list.

其中{}是一个空的源列表。

An example of an API providing the capabilities outlined in this service interface is in [FILTER-API].

[FILTER-API]中提供了此服务接口中概述的功能的API示例。

3. Multicast Reception State Maintained by Systems
3. 由系统维护的多播接收状态
3.1. Socket State
3.1. 套接字状态

For each socket on which IPMulticastListen has been invoked, the system records the desired multicast reception state for that socket. That state conceptually consists of a set of records of the form:

对于已调用IPMulticastListen的每个套接字,系统记录该套接字所需的多播接收状态。该状态在概念上由以下形式的一组记录组成:

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

(接口、多播地址、筛选模式、源列表)

The socket state evolves in response to each invocation of IPMulticastListen on the socket, as follows:

套接字状态随套接字上IPMulticastListen的每次调用而变化,如下所示:

o If the requested filter mode is INCLUDE *and* the requested source list is empty, then the entry corresponding to the requested interface and multicast address is deleted if present. If no such entry is present, the request is ignored.

o 如果请求的过滤模式为INCLUDE*且*请求的源列表为空,则删除与请求的接口和多播地址对应的条目(如果存在)。如果不存在此类条目,则忽略该请求。

o If the requested filter mode is EXCLUDE *or* the requested source list is non-empty, then the entry corresponding to the requested interface and multicast address, if present, is changed to contain the requested filter mode and source list. If no such entry is present, a new entry is created, using the parameters specified in the request.

o 如果请求的筛选器模式为EXCLUDE*或*请求的源列表为非空,则与请求的接口和多播地址(如果存在)对应的条目将更改为包含请求的筛选器模式和源列表。如果不存在这样的条目,则使用请求中指定的参数创建一个新条目。

3.2. Interface State
3.2. 界面状态

In addition to the per-socket multicast reception state, a system must also maintain or compute multicast reception state for each of its interfaces. That state conceptually consists of a set of records of the form:

除了每个套接字的多播接收状态外,系统还必须维护或计算其每个接口的多播接收状态。该状态在概念上由以下形式的一组记录组成:

(multicast-address, filter-mode, source-list)

(多播地址、筛选器模式、源列表)

At most one record per multicast-address exists for a given interface. This per-interface state is derived from the per-socket state, but may differ from the per-socket state when different sockets have differing filter modes and/or source lists for the same multicast address and interface. For example, suppose one application or process invokes the following operation on socket s1:

对于给定接口,每个多播地址最多存在一条记录。此每个接口状态源自每个套接字状态,但当不同套接字对同一多播地址和接口具有不同的筛选模式和/或源列表时,可能不同于每个套接字状态。例如,假设一个应用程序或进程调用套接字s1上的以下操作:

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

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

requesting reception on interface i of packets sent to multicast address m, *only* if they come from source a, b, or c. Suppose another application or process invokes the following operation on socket s2:

请求在接口i上接收发送到多播地址m的数据包,*仅当数据包来自源a、b或c时*。假设另一个应用程序或进程调用套接字s2上的以下操作:

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

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

requesting reception on the same interface i of packets sent to the same multicast address m, *only* if they come from sources b, c, or d. In order to satisfy the reception requirements of both sockets, it is necessary for interface i to receive packets sent to m from any one of the sources a, b, c, or d. Thus, in this example, the reception state of interface i for multicast address m has filter mode INCLUDE and source list {a, b, c, d}.

请求在同一接口i上接收发送到同一多播地址m的数据包,*仅当它们来自源b、c或d时。为了满足两个插座的接收要求,接口i必须接收从源a、b、c或d中的任何一个发送到m的数据包。因此,在该示例中,多播地址m的接口i的接收状态具有过滤模式INCLUDE和源列表{a,b,c,d}。

After a multicast packet has been accepted from an interface by the IP layer, its subsequent delivery to the application or process listening on a particular socket depends on the multicast reception state of that socket [and possibly also on other conditions, such as what transport-layer port the socket is bound to]. So, in the above example, if a packet arrives on interface i, destined to multicast address m, with source address a, it will be delivered on socket s1 but not on socket s2. Note that IGMP Queries and Reports are not subject to source filtering and must always be processed by hosts and routers.

在IP层已从接口接受多播分组之后,其随后传送到在特定套接字上侦听的应用程序或进程取决于该套接字的多播接收状态[并且可能还取决于其他条件,例如套接字绑定到哪个传输层端口]。因此,在上面的示例中,如果包到达接口i,目的地为多播地址m,源地址为a,则它将在套接字s1上传递,而不是在套接字s2上传递。请注意,IGMP查询和报告不受源筛选的约束,必须始终由主机和路由器处理。

Filtering of packets based upon a socket's multicast reception state is a new feature of this service interface. The previous service interface [RFC1112] described no filtering based upon multicast join state; rather, a join on a socket simply caused the host to join a group on the given interface, and packets destined for that group could be delivered to all sockets whether they had joined or not.

根据套接字的多播接收状态过滤数据包是此服务接口的一个新功能。先前的服务接口[RFC1112]描述了没有基于多播加入状态的过滤;相反,套接字上的连接只会导致主机加入给定接口上的一个组,而发往该组的数据包可以传递到所有套接字,无论它们是否已加入。

The general rules for deriving the per-interface state from the per-socket state are as follows: For each distinct (interface, multicast-address) pair that appears in any socket state, a per-interface record is created for that multicast address on that interface. Considering all socket records containing the same (interface, multicast-address) pair,

从每个套接字状态派生每个接口状态的一般规则如下:对于任何套接字状态中出现的每个不同(接口,多播地址)对,将为该接口上的多播地址创建一个每个接口记录。考虑到所有包含相同(接口、多播地址)对的套接字记录,

o if *any* such record has a filter mode of EXCLUDE, then the filter mode of the interface record is EXCLUDE, and the source list of the interface record is the intersection of the source lists of all socket records in EXCLUDE mode, minus those source addresses that appear in any socket record in INCLUDE mode. For example, if the socket records for multicast address m on interface i are:

o 如果*any*此类记录的过滤模式为EXCLUDE,则接口记录的过滤模式为EXCLUDE,接口记录的源列表是EXCLUDE模式下所有套接字记录的源列表的交点,减去INCLUDE模式下任何套接字记录中出现的源地址。例如,如果接口i上多播地址m的套接字记录为:

        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} )
        
        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} )
        

then the corresponding interface record on interface i is:

则接口i上对应的接口记录为:

( m, EXCLUDE, {b, c} )

(m,排除,{b,c})

If a fourth socket is added, such as:

如果添加了第四个插座,例如:

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

then the interface record becomes:

然后,接口记录变为:

( m, EXCLUDE, {} )

(m,排除,{})

o if *all* such records have a filter mode of INCLUDE, then the filter mode of the interface record is INCLUDE, and the source list of the interface record is the union of the source lists of all the socket records. For example, if the socket records for multicast address m on interface i are:

o 如果*all*这样的记录具有INCLUDE的过滤模式,则接口记录的过滤模式为INCLUDE,并且接口记录的源列表是所有套接字记录的源列表的并集。例如,如果接口i上多播地址m的套接字记录为:

        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} )
        
        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} )
        

then the corresponding interface record on interface i is:

则接口i上对应的接口记录为:

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

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

An implementation MUST NOT use an EXCLUDE interface record to represent a group when all sockets for this group are in INCLUDE state. If system resource limits are reached when an interface state source list is calculated, an error MUST be returned to the application which requested the operation.

当组的所有套接字都处于包含状态时,实现不能使用排除接口记录来表示组。如果在计算接口状态源列表时达到系统资源限制,则必须向请求操作的应用程序返回错误。

The above rules for deriving the interface state are (re-)evaluated whenever an IPMulticastListen invocation modifies the socket state by adding, deleting, or modifying a per-socket state record. Note that a change of socket state does not necessarily result in a change of interface state.

每当IPMulticastListen调用通过添加、删除或修改每个套接字状态记录来修改套接字状态时,就会(重新)评估上述派生接口状态的规则。请注意,套接字状态的更改不一定会导致接口状态的更改。

4. Message Formats
4. 消息格式

IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2. Every IGMP message described in this document is sent with an IP Time-to-Live of 1, IP Precedence of Internetwork Control (e.g., Type of Service 0xc0), and carries an IP Router Alert option [RFC-2113] in its IP header. IGMP message types are registered by the IANA [IANA-REG] as described by [RFC-3228].

IGMP消息封装在IPv4数据报中,IP协议号为2。本文档中描述的每个IGMP消息发送时,IP生存时间为1,网络间控制的IP优先级(例如,服务类型0xc0),并在其IP报头中携带IP路由器警报选项[RFC-2113]。IGMP消息类型由IANA[IANA-REG]注册,如[RFC-3228]所述。

There are two IGMP message types of concern to the IGMPv3 protocol described in this document:

本文档中描述的IGMPv3协议涉及两种IGMP消息类型:

      Type Number (hex)   Message Name
      -----------------   ------------
        
      Type Number (hex)   Message Name
      -----------------   ------------
        

0x11 Membership Query

0x11成员资格查询

0x22 Version 3 Membership Report

0x22版本3成员报告

An implementation of IGMPv3 MUST also support the following three message types, for interoperation with previous versions of IGMP (see section 7):

IGMPv3的实现还必须支持以下三种消息类型,以便与以前版本的IGMP进行互操作(参见第7节):

0x12 Version 1 Membership Report [RFC-1112]

0x12第1版成员报告[RFC-1112]

0x16 Version 2 Membership Report [RFC-2236]

0x16第2版成员报告[RFC-2236]

0x17 Version 2 Leave Group [RFC-2236]

0x17版本2休假组[RFC-2236]

Unrecognized message types MUST be silently ignored. Other message types may be used by newer versions or extensions of IGMP, by multicast routing protocols, or for other uses.

无法识别的消息类型必须以静默方式忽略。其他消息类型可由IGMP的较新版本或扩展、多播路由协议或其他用途使用。

In this document, unless otherwise qualified, the capitalized words "Query" and "Report" refer to IGMP Membership Queries and IGMP Version 3 Membership Reports, respectively.

在本文件中,除非另有限定,大写的“查询”和“报告”分别指IGMP成员查询和IGMP第3版成员报告。

4.1. Membership Query Message
4.1. 会员查询消息

Membership Queries are sent by IP multicast routers to query the multicast reception state of neighboring interfaces. Queries have the following format:

成员查询由IP多播路由器发送,以查询相邻接口的多播接收状态。查询的格式如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x11  | Max Resp Code |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                              .                              -+
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x11  | Max Resp Code |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                              .                              -+
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
4.1.1. Max Resp Code
4.1.1. 最大响应码

The Max Resp Code field specifies the maximum time allowed before sending a responding report. The actual time allowed, called the Max Resp Time, is represented in units of 1/10 second and is derived from the Max Resp Code as follows:

Max Resp Code字段指定发送响应报告之前允许的最长时间。允许的实际时间(称为最大响应时间)以1/10秒为单位表示,并从最大响应代码中导出,如下所示:

If Max Resp Code < 128, Max Resp Time = Max Resp Code

如果最大响应代码<128,则最大响应时间=最大响应代码

If Max Resp Code >= 128, Max Resp Code represents a floating-point value as follows:

如果Max Resp Code>=128,则Max Resp Code表示浮点值,如下所示:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+
        
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+
        
   Max Resp Time = (mant | 0x10) << (exp + 3)
        
   Max Resp Time = (mant | 0x10) << (exp + 3)
        

Small values of Max Resp Time allow IGMPv3 routers to tune the "leave latency" (the time between the moment the last host leaves a group and the moment the routing protocol is notified that there are no more members). Larger values, especially in the exponential range, allow tuning of the burstiness of IGMP traffic on a network.

Max Resp Time的较小值允许IGMPv3路由器调整“离开延迟”(从最后一台主机离开组到路由协议被通知不再有成员之间的时间)。更大的值,特别是在指数范围内,允许调整网络上IGMP流量的突发性。

4.1.2. Checksum
4.1.2. 校验和

The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a packet. [RFC-1071]

校验和是整个IGMP消息(整个IP有效负载)的16位1的补码和。为了计算校验和,校验和字段设置为零。接收数据包时,必须在处理数据包之前验证校验和。[RFC-1071]

4.1.3. Group Address
4.1.3. 组地址

The Group Address field is set to zero when sending a General Query, and set to the IP multicast address being queried when sending a Group-Specific Query or Group-and-Source-Specific Query (see section 4.1.9, below).

发送常规查询时,Group Address(组地址)字段设置为零,发送特定于组的查询或特定于组和源的查询时,该字段设置为正在查询的IP多播地址(请参阅下面的第4.1.9节)。

4.1.4. Resv (Reserved)
4.1.4. Resv(保留)

The Resv field is set to zero on transmission, and ignored on reception.

Resv字段在传输时设置为零,在接收时忽略。

4.1.5. S Flag (Suppress Router-Side Processing)
4.1.5. S标志(抑制路由器端处理)

When set to one, the S Flag indicates to any receiving multicast routers that they are to suppress the normal timer updates they perform upon hearing a Query. It does not, however, suppress the querier election or the normal "host-side" processing of a Query that a router may be required to perform as a consequence of itself being a group member.

当设置为1时,S标志向任何接收多播路由器指示,它们将抑制在听到查询时执行的正常计时器更新。然而,它不会抑制查询器选择或路由器作为组成员可能需要执行的查询的正常“主机端”处理。

4.1.6. QRV (Querier's Robustness Variable)
4.1.6. QRV(Querier的稳健性变量)

If non-zero, the QRV field contains the [Robustness Variable] value used by the querier, i.e., the sender of the Query. If the querier's [Robustness Variable] exceeds 7, the maximum value of the QRV field, the QRV is set to zero. Routers adopt the QRV value from the most recently received Query as their own [Robustness Variable] value, unless that most recently received QRV was zero, in which case the receivers use the default [Robustness Variable] value specified in section 8.1 or a statically configured value.

如果非零,则QRV字段包含查询者(即查询的发送者)使用的[Robustness Variable]值。如果查询器的[稳健性变量]超过QRV字段的最大值7,则QRV设置为零。路由器采用来自最近接收的查询的QRV值作为其自己的[鲁棒性变量]值,除非最近接收的QRV为零,在这种情况下,接收器使用第8.1节中指定的默认[鲁棒性变量]值或静态配置值。

4.1.7. QQIC (Querier's Query Interval Code)
4.1.7. QQIC(查询器的查询间隔代码)

The Querier's Query Interval Code field specifies the [Query Interval] used by the querier. The actual interval, called the Querier's Query Interval (QQI), is represented in units of seconds and is derived from the Querier's Query Interval Code as follows:

查询器的查询间隔代码字段指定查询器使用的[Query Interval]。实际时间间隔称为查询器的查询时间间隔(QQI),以秒为单位表示,并从查询器的查询时间间隔代码中派生,如下所示:

If QQIC < 128, QQI = QQIC

如果QQIC<128,则QQI=QQIC

If QQIC >= 128, QQIC represents a floating-point value as follows:

如果QQIC>=128,则QQIC表示浮点值,如下所示:

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+
        
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |1| exp | mant  |
      +-+-+-+-+-+-+-+-+
        
   QQI = (mant | 0x10) << (exp + 3)
        
   QQI = (mant | 0x10) << (exp + 3)
        

Multicast routers that are not the current querier adopt the QQI value from the most recently received Query as their own [Query Interval] value, unless that most recently received QQI was zero, in which case the receiving routers use the default [Query Interval] value specified in section 8.2.

非当前查询者的多播路由器采用最近收到的查询中的QQI值作为其自己的[Query Interval]值,除非最近收到的QQI为零,在这种情况下,接收路由器使用第8.2节中指定的默认[Query Interval]值。

4.1.8. Number of Sources (N)
4.1.8. 来源数量(N)

The Number of Sources (N) field specifies how many source addresses are present in the Query. This number is zero in a General Query or a Group-Specific Query, and non-zero in a Group-and-Source-Specific Query. This number is limited by the MTU of the network over which the Query is transmitted. For example, on an Ethernet with an MTU of 1500 octets, the IP header including the Router Alert option consumes 24 octets, and the IGMP fields up to including the Number of Sources (N) field consume 12 octets, leaving 1464 octets for source addresses, which limits the number of source addresses to 366 (1464/4).

源数量(N)字段指定查询中存在多少个源地址。此数字在常规查询或特定于组的查询中为零,在特定于组和源的查询中为非零。该数字受传输查询的网络的MTU限制。例如,在MTU为1500个八位字节的以太网上,包括路由器警报选项的IP报头消耗24个八位字节,IGMP字段(最多包括源数量(N)字段)消耗12个八位字节,留下1464个八位字节作为源地址,这将源地址的数量限制为366(1464/4)。

4.1.9. Source Address [i]
4.1.9. 来源地址[i]

The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in the Number of Sources (N) field.

源地址[i]字段是n个IP单播地址的向量,其中n是源数量(n)字段中的值。

4.1.10. Additional Data
4.1.10. 附加数据

If the Packet Length field in the IP header of a received Query indicates that there are additional octets of data present, beyond the fields described here, IGMPv3 implementations MUST include those octets in the computation to verify the received IGMP Checksum, but MUST otherwise ignore those additional octets. When sending a Query, an IGMPv3 implementation MUST NOT include additional octets beyond the fields described here.

如果接收到的查询的IP报头中的数据包长度字段指示存在额外的八位字节数据,则除了此处描述的字段外,IGMPv3实现必须在计算中包括这些八位字节,以验证接收到的IGMP校验和,但必须忽略这些额外的八位字节。发送查询时,IGMPv3实现不得包含此处所述字段以外的其他八位字节。

4.1.11. Query Variants
4.1.11. 查询变量

There are three variants of the Query message:

查询消息有三种变体:

1. A "General Query" is sent by a multicast router to learn the complete multicast reception state of the neighboring interfaces (that is, the interfaces attached to the network on which the Query is transmitted). In a General Query, both the Group Address field and the Number of Sources (N) field are zero.

1. “一般查询”由多播路由器发送,以了解相邻接口(即连接到传输查询的网络的接口)的完整多播接收状态。在常规查询中,组地址字段和源数量(N)字段均为零。

2. A "Group-Specific Query" is sent by a multicast router to learn the reception state, with respect to a *single* multicast address, of the neighboring interfaces. In a Group-Specific Query, the Group Address field contains the multicast address of interest, and the Number of Sources (N) field contains zero.

2. “组特定查询”由多播路由器发送,以了解相邻接口的关于*单个*多播地址的接收状态。在特定于组的查询中,组地址字段包含感兴趣的多播地址,而源数(N)字段包含零。

3. A "Group-and-Source-Specific Query" is sent by a multicast router to learn if any neighboring interface desires reception of packets sent to a specified multicast address, from any of a specified list of sources. In a Group-and-Source-Specific Query, the Group Address field contains the multicast address of interest, and the Source Address [i] fields contain the source address(es) of interest.

3. “组和源特定查询”由多播路由器发送,以了解任何相邻接口是否希望接收从任何指定源列表发送到指定多播地址的数据包。在特定于组和源的查询中,组地址字段包含感兴趣的多播地址,源地址[i]字段包含感兴趣的源地址。

4.1.12. IP Destination Addresses for Queries
4.1.12. 查询的IP目标地址

In IGMPv3, General Queries are sent with an IP destination address of 224.0.0.1, the all-systems multicast address. Group-Specific and Group-and-Source-Specific Queries are sent with an IP destination address equal to the multicast address of interest. *However*, a system MUST accept and process any Query whose IP Destination Address field contains *any* of the addresses (unicast or multicast) assigned to the interface on which the Query arrives.

在IGMPv3中,发送一般查询时,IP目标地址为224.0.0.1,即所有系统的多播地址。发送特定于组以及特定于组和源的查询时,IP目标地址等于感兴趣的多播地址*但是*,系统必须接受并处理其IP目标地址字段包含*分配给查询到达接口的任何*地址(单播或多播)的任何查询。

4.2. Version 3 Membership Report Message
4.2. 第三版会员报告信息

Version 3 Membership Reports are sent by IP systems to report (to neighboring routers) the current multicast reception state, or changes in the multicast reception state, of their interfaces. Reports have the following format:

版本3成员报告由IP系统发送,以报告(相邻路由器)其接口的当前多播接收状态或多播接收状态的变化。报告的格式如下:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x22  |    Reserved   |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |  Number of Group Records (M)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [1]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [2]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      .                               .                               .
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [M]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = 0x22  |    Reserved   |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |  Number of Group Records (M)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [1]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [2]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      .                               .                               .
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                        Group Record [M]                       .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

where each Group Record has the following internal format:

其中每个组记录具有以下内部格式:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Multicast Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                                                             -+
      .                               .                               .
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                         Auxiliary Data                        .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Multicast Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                                                             -+
      .                               .                               .
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                         Auxiliary Data                        .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
4.2.1. Reserved
4.2.1. 含蓄的

The Reserved fields are set to zero on transmission, and ignored on reception.

保留字段在传输时设置为零,在接收时忽略。

4.2.2. Checksum
4.2.2. 校验和

The Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a message.

校验和是整个IGMP消息(整个IP有效负载)的16位1的补码和。为了计算校验和,校验和字段设置为零。接收数据包时,必须在处理消息之前验证校验和。

4.2.3. Number of Group Records (M)
4.2.3. 组记录数(M)

The Number of Group Records (M) field specifies how many Group Records are present in this Report.

组记录数(M)字段指定此报告中存在多少组记录。

4.2.4. Group Record
4.2.4. 团体记录

Each Group Record is a block of fields containing information pertaining to the sender's membership in a single multicast group on the interface from which the Report is sent.

每个组记录都是一个字段块,其中包含与发送方在发送报告的接口上的单个多播组中的成员资格相关的信息。

4.2.5. Record Type
4.2.5. 记录类型

See section 4.2.12, below.

见下文第4.2.12节。

4.2.6. Aux Data Len
4.2.6. 辅助数据透镜

The Aux Data Len field contains the length of the Auxiliary Data field in this Group Record, in units of 32-bit words. It may contain zero, to indicate the absence of any auxiliary data.

Aux Data Len字段包含此组记录中辅助数据字段的长度,以32位字为单位。它可能包含零,表示没有任何辅助数据。

4.2.7. Number of Sources (N)
4.2.7. 来源数量(N)

The Number of Sources (N) field specifies how many source addresses are present in this Group Record.

源数量(N)字段指定此组记录中存在多少个源地址。

4.2.8. Multicast Address
4.2.8. 多播地址

The Multicast Address field contains the IP multicast address to which this Group Record pertains.

多播地址字段包含此组记录所属的IP多播地址。

4.2.9. Source Address [i]
4.2.9. 来源地址[i]

The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in this record's Number of Sources (N) field.

源地址[i]字段是n个IP单播地址的向量,其中n是该记录的源数(n)字段中的值。

4.2.10. Auxiliary Data
4.2.10. 辅助数据

The Auxiliary Data field, if present, contains additional information pertaining to this Group Record. The protocol specified in this document, IGMPv3, does not define any auxiliary data. Therefore, implementations of IGMPv3 MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any transmitted Group Record, and MUST ignore any auxiliary data present in any received Group Record. The semantics and internal encoding of the Auxiliary Data field are to be defined by any future version or extension of IGMP that uses this field.

辅助数据字段(如果存在)包含与此组记录相关的附加信息。本文档中指定的协议IGMPv3未定义任何辅助数据。因此,IGMPv3的实现不得在任何传输的组记录中包括任何辅助数据(即,必须将Aux data Len字段设置为零),并且必须忽略任何接收的组记录中存在的任何辅助数据。辅助数据字段的语义和内部编码将由使用该字段的IGMP的任何未来版本或扩展定义。

4.2.11. Additional Data
4.2.11. 附加数据

If the Packet Length field in the IP header of a received Report indicates that there are additional octets of data present, beyond the last Group Record, IGMPv3 implementations MUST include those octets in the computation to verify the received IGMP Checksum, but MUST otherwise ignore those additional octets. When sending a Report, an IGMPv3 implementation MUST NOT include additional octets beyond the last Group Record.

如果接收到的报告的IP报头中的数据包长度字段指示除最后一组记录外,还存在其他八位字节的数据,则IGMPv3实现必须在计算中包括这些八位字节,以验证接收到的IGMP校验和,但必须忽略这些额外的八位字节。发送报告时,IGMPv3实现不得包含超出最后一组记录的额外八位字节。

4.2.12. Group Record Types
4.2.12. 组记录类型

There are a number of different types of Group Records that may be included in a Report message:

报告消息中可能包含许多不同类型的组记录:

o A "Current-State Record" is sent by a system in response to a Query received on an interface. It reports the current reception state of that interface, with respect to a single multicast address. The Record Type of a Current-State Record may be one of the following two values:

o “当前状态记录”由系统发送,以响应接口上接收到的查询。它报告该接口相对于单个多播地址的当前接收状态。当前状态记录的记录类型可以是以下两个值之一:

        Value  Name and Meaning
        -----  ----------------
        
        Value  Name and Meaning
        -----  ----------------
        

1 MODE_IS_INCLUDE - indicates that the interface has a filter mode of INCLUDE for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's source list for the specified multicast address, if it is non-empty.

1 MODE_IS_INCLUDE-表示接口对指定的多播地址具有包含的筛选模式。此组记录中的源地址[i]字段包含指定多播地址的接口源列表(如果该列表非空)。

2 MODE_IS_EXCLUDE - indicates that the interface has a filter mode of EXCLUDE for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's source list for the specified multicast address, if it is non-empty.

2模式_IS_EXCLUDE-表示接口对指定的多播地址具有排除的筛选模式。此组记录中的源地址[i]字段包含指定多播地址的接口源列表(如果该列表非空)。

o A "Filter-Mode-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of the filter mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), of the interface-level state entry for a particular multicast address. The Record is included in a Report sent from the interface on which the change occurred. The Record Type of a Filter-Mode-Change Record may be one of the following two values:

o 每当IPMulticastListen的本地调用导致特定多播地址的接口级状态条目的过滤模式(即从包含更改为排除,或从排除更改为包括)发生更改时,系统将发送“过滤模式更改记录”。该记录包含在从发生更改的接口发送的报告中。过滤器模式更改记录的记录类型可以是以下两个值之一:

3 CHANGE_TO_INCLUDE_MODE - indicates that the interface has changed to INCLUDE filter mode for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's new source list for the specified multicast address, if it is non-empty.

3 CHANGE_TO_INCLUDE_MODE-表示接口已更改为包含指定多播地址的筛选器模式。此组记录中的源地址[i]字段包含指定多播地址的接口新源列表(如果该列表非空)。

4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface has changed to EXCLUDE filter mode for the specified multicast address. The Source Address [i] fields in this Group Record contain the interface's new source list for the specified multicast address, if it is non-empty.

4 CHANGE_TO_EXCLUDE_MODE-表示接口已更改为排除指定多播地址的筛选器模式。此组记录中的源地址[i]字段包含指定多播地址的接口新源列表(如果该列表非空)。

o A "Source-List-Change Record" is sent by a system whenever a local invocation of IPMulticastListen causes a change of source list that is *not* coincident with a change of filter mode, of the interface-level state entry for a particular multicast address. The Record is included in a Report sent from the interface on which the change occurred. The Record Type of a Source-List-Change Record may be one of the following two values:

o 每当IPMulticastListen的本地调用导致源列表的更改与特定多播地址的接口级状态条目的过滤器模式的更改*不*一致时,系统就会发送“源列表更改记录”。该记录包含在从发生更改的接口发送的报告中。源列表更改记录的记录类型可以是以下两个值之一:

5 ALLOW_NEW_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the additional sources that the system wishes to hear from, for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were added to the list; if the change was to an EXCLUDE source list, these are the addresses that were deleted from the list.

5 ALLOW_NEW_SOURCES-表示此组记录中的Source Address[i]字段包含系统希望听到的附加源列表,用于发送到指定多播地址的数据包。如果更改是包含源列表,则这些是添加到列表中的地址;如果更改为排除源列表,则这些是从列表中删除的地址。

6 BLOCK_OLD_SOURCES - indicates that the Source Address [i] fields in this Group Record contain a list of the sources that the system no longer wishes to hear from, for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were deleted from the list; if the change was to an EXCLUDE source list, these are the addresses that were added to the list.

6 BLOCK_OLD_SOURCES-表示此组记录中的Source Address[i]字段包含系统不再希望听到的源列表,用于发送到指定多播地址的数据包。如果更改为包含源列表,则这些是从列表中删除的地址;如果更改为排除源列表,则这些是添加到列表中的地址。

If a change of source list results in both allowing new sources and blocking old sources, then two Group Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES.

如果源列表的更改导致同时允许新源和阻止旧源,那么将为同一多播地址发送两个组记录,一个为ALLOW_new_sources类型,另一个为BLOCK_old_sources类型。

We use the term "State-Change Record" to refer to either a Filter-Mode-Change Record or a Source-List-Change Record.

我们使用术语“状态更改记录”来指过滤模式更改记录或源列表更改记录。

Unrecognized Record Type values MUST be silently ignored.

无法识别的记录类型值必须以静默方式忽略。

4.2.13. IP Source Addresses for Reports
4.2.13. 报表的IP源地址

An IGMP report is sent with a valid IP source address for the destination subnet. The 0.0.0.0 source address may be used by a system that has not yet acquired an IP address. Note that the 0.0.0.0 source address may simultaneously be used by multiple systems on a LAN. Routers MUST accept a report with a source address of 0.0.0.0.

IGMP报告随目标子网的有效IP源地址一起发送。0.0.0.0源地址可由尚未获取IP地址的系统使用。请注意,0.0.0.0源地址可由LAN上的多个系统同时使用。路由器必须接受源地址为0.0.0.0的报告。

4.2.14. IP Destination Addresses for Reports
4.2.14. 报表的IP目标地址

Version 3 Reports are sent with an IP destination address of 224.0.0.22, to which all IGMPv3-capable multicast routers listen. A system that is operating in version 1 or version 2 compatibility modes sends version 1 or version 2 Reports to the multicast group specified in the Group Address field of the Report. In addition, a system MUST accept and process any version 1 or version 2 Report whose IP Destination Address field contains *any* of the addresses (unicast or multicast) assigned to the interface on which the Report arrives.

发送版本3报告时,IP目标地址为224.0.0.22,所有支持IGMPv3的多播路由器都会侦听该地址。在版本1或版本2兼容模式下运行的系统将向报告的组地址字段中指定的多播组发送版本1或版本2报告。此外,系统必须接受并处理任何版本1或版本2报告,其IP目标地址字段包含分配给报告到达接口的*任何*地址(单播或多播)。

4.2.15. Notation for Group Records
4.2.15. 组记录的符号

In the rest of this document, we use the following notation to describe the contents of a Group Record pertaining to a particular multicast address:

在本文档的其余部分中,我们使用以下符号来描述与特定多播地址相关的组记录的内容:

IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x

在(x)-类型模式中,源地址x是包含的,源地址x是包含的(x)-类型模式中,源地址x到包含的,源地址x到包含的,源地址x到排除的,源地址x到排除的,源地址x允许(x)-类型允许新源,源地址x块(x)-类型块旧源,源地址x

where x is either:

其中x为:

o a capital letter (e.g., "A") to represent the set of source addresses, or

o 表示源地址集的大写字母(如“a”),或

o a set expression (e.g., "A+B"), where "A+B" means the union of sets A and B, "A*B" means the intersection of sets A and B, and "A-B" means the removal of all elements of set B from set A.

o 集合表达式(例如,“a+B”),其中“a+B”表示集合a和B的并集,“a*B”表示集合a和B的交集,“a-B”表示从集合a中删除集合B的所有元素。

4.2.16. Membership Report Size
4.2.16. 成员报告大小

If the set of Group Records required in a Report does not fit within the size limit of a single Report message (as determined by the MTU of the network on which it will be sent), the Group Records are sent in as many Report messages as needed to report the entire set.

如果报告中所需的组记录集不符合单个报告消息的大小限制(由发送组记录的网络的MTU确定),则将以报告整个组所需的报告消息数发送组记录。

If a single Group Record contains so many source addresses that it does not fit within the size limit of a single Report message, if its Type is not MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, it is split into multiple Group Records, each containing a different subset of the source addresses and each sent in a separate Report message. If its Type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, a single Group Record is sent, containing as many source addresses as can fit, and

如果单个组记录包含的源地址太多,不符合单个报表消息的大小限制,如果其类型不是MODE_is_EXCLUDE或将_更改为_EXCLUDE_MODE,则会将其拆分为多个组记录,每个组记录包含源地址的不同子集,并在单独的报表消息中发送。如果其类型为MODE_is_EXCLUDE或将_更改为_EXCLUDE_MODE,则发送单个组记录,其中包含尽可能多的源地址,并且

the remaining source addresses are not reported; though the choice of which sources to report is arbitrary, it is preferable to report the same set of sources in each subsequent report, rather than reporting different sources each time.

未报告剩余的源地址;尽管报告来源的选择是任意的,但最好在后续报告中报告同一组来源,而不是每次报告不同的来源。

5. Description of the Protocol for Group Members
5. 组成员的协议说明

IGMP is an asymmetric protocol, specifying separate behaviors for group members -- that is, hosts or routers that wish to receive multicast packets -- and multicast routers. This section describes the part of IGMPv3 that applies to all group members. (Note that a multicast router that is also a group member performs both parts of IGMPv3, receiving and responding to its own IGMP message transmissions as well as those of its neighbors. The multicast router part of IGMPv3 is described in section 6.)

IGMP是一种非对称协议,为组成员(即希望接收多播数据包的主机或路由器)和多播路由器指定单独的行为。本节介绍适用于所有集团成员的IGMPv3部分。(请注意,同时也是组成员的多播路由器执行IGMPv3的两个部分,接收和响应其自身的IGMP消息传输以及其邻居的IGMP消息传输。第6节介绍了IGMPv3的多播路由器部分。)

A system performs the protocol described in this section over all interfaces on which multicast reception is supported, even if more than one of those interfaces is connected to the same network.

系统在支持多播接收的所有接口上执行本节所述的协议,即使这些接口中有多个连接到同一网络。

For interoperability with multicast routers running older versions of IGMP, systems maintain a MulticastRouterVersion variable for each interface on which multicast reception is supported. This section describes the behavior of group member systems on interfaces for which MulticastRouterVersion = 3. The algorithm for determining MulticastRouterVersion, and the behavior for versions other than 3, are described in section 7.

为了与运行旧版本IGMP的多播路由器进行互操作,系统为支持多播接收的每个接口维护一个MulticastroutVersion变量。本节描述MulticastroutVersion=3的接口上的组成员系统的行为。第7节描述了确定多计算机版本的算法,以及3以外版本的行为。

The all-systems multicast address, 224.0.0.1, is handled as a special case. On all systems -- that is all hosts and routers, including multicast routers -- reception of packets destined to the all-systems multicast address, from all sources, is permanently enabled on all interfaces on which multicast reception is supported. No IGMP messages are ever sent regarding the all-systems multicast address.

所有系统多播地址224.0.0.1作为特例处理。在所有系统(即所有主机和路由器,包括多播路由器)上,在支持多播接收的所有接口上永久启用从所有源接收到所有系统多播地址的数据包。从未发送关于所有系统多播地址的IGMP消息。

There are two types of events that trigger IGMPv3 protocol actions on an interface:

有两种类型的事件触发接口上的IGMPv3协议操作:

o a change of the interface reception state, caused by a local invocation of IPMulticastListen.

o 由本地调用IPMulticastListen引起的接口接收状态的变化。

o reception of a Query.

o 接受询问。

(Received IGMP messages of types other than Query are silently ignored, except as required for interoperation with earlier versions of IGMP.)

(接收到的非查询类型的IGMP消息将被静默忽略,除非需要与早期版本的IGMP进行互操作。)

The following subsections describe the actions to be taken for each of these two cases. In those descriptions, timer and counter names appear in square brackets. The default values for those timers and counters are specified in section 8.

以下小节描述了针对这两种情况采取的措施。在这些描述中,计时器和计数器名称显示在方括号中。第8节规定了这些计时器和计数器的默认值。

5.1. Action on Change of Interface State
5.1. 更改接口状态时的操作

An invocation of IPMulticastListen may cause the multicast reception state of an interface to change, according to the rules in section 3.2. Each such change affects the per-interface entry for a single multicast address.

根据第3.2节中的规则,调用IPMulticastListen可能会导致接口的多播接收状态发生变化。每个这样的更改都会影响单个多播地址的每个接口条目。

A change of interface state causes the system to immediately transmit a State-Change Report from that interface. The type and contents of the Group Record(s) in that Report are determined by comparing the filter mode and source list for the affected multicast address before and after the change, according to the table below. If no interface state existed for that multicast address before the change (i.e., the change consisted of creating a new per-interface record), or if no state exists after the change (i.e., the change consisted of deleting a per-interface record), then the "non-existent" state is considered to have a filter mode of INCLUDE and an empty source list.

接口状态的更改会导致系统立即从该接口发送状态更改报告。根据下表,通过比较更改前后受影响多播地址的筛选器模式和源列表,确定该报告中组记录的类型和内容。如果更改前该多播地址不存在接口状态(即,更改包括创建新的每个接口记录),或者更改后不存在任何状态(即,更改包括删除每个接口记录),则“不存在”状态被认为具有包含的筛选器模式和空源列表。

     Old State         New State         State-Change Record Sent
     ---------         ---------         ------------------------
        
     Old State         New State         State-Change Record Sent
     ---------         ---------         ------------------------
        

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

包括(A)包括(B)允许(B-A),块(A-B)

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

排除(A)排除(B)允许(A-B),块(B-A)

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

包括(A)排除(B)至_EX(B)

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

排除(A)在(B)中包括(B)至

If the computed source list for either an ALLOW or a BLOCK State-Change Record is empty, that record is omitted from the Report message.

如果“允许”或“块状态更改”记录的计算源列表为空,则报告消息中将忽略该记录。

To cover the possibility of the State-Change Report being missed by one or more multicast routers, it is retransmitted [Robustness Variable] - 1 more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]).

为了覆盖状态更改报告被一个或多个多播路由器丢失的可能性,以从范围(0,[未经请求的报告间隔])中随机选择的间隔将其重新传输[鲁棒性变量]-1次以上。

If more changes to the same interface state entry occur before all the retransmissions of the State-Change Report for the first change have been completed, each such additional change triggers the immediate transmission of a new State-Change Report.

如果在完成第一次更改的状态更改报告的所有重新传输之前,对同一接口状态条目进行了更多更改,则每次此类额外更改都会触发新状态更改报告的立即传输。

The contents of the new transmitted report are calculated as follows. As was done with the first report, the interface state for the affected group before and after the latest change is compared. The report records expressing the difference are built according to the table above. However these records are not transmitted in a message but instead merged with the contents of the pending report, to create the new State-Change report. The rules for merging the difference report resulting from the state change and the pending report are described below.

新传输报告的内容计算如下。与第一份报告一样,比较了受影响组在最新更改前后的界面状态。表示差异的报告记录根据上表构建。但是,这些记录不会在消息中传输,而是与挂起报告的内容合并,以创建新的状态更改报告。合并状态更改产生的差异报告和挂起报告的规则如下所述。

The transmission of the merged State-Change Report terminates retransmissions of the earlier State-Change Reports for the same multicast address, and becomes the first of [Robustness Variable] transmissions of State-Change Reports.

合并状态更改报告的传输终止了对相同多播地址的先前状态更改报告的重新传输,并成为状态更改报告的第一个[鲁棒性变量]传输。

Each time a source is included in the difference report calculated above, retransmission state for that source needs to be maintained until [Robustness Variable] State-Change reports have been sent by the host. This is done in order to ensure that a series of successive state changes do not break the protocol robustness.

每次在上面计算的差异报告中包含一个源时,都需要保持该源的重传状态,直到主机发送[鲁棒性变量]状态更改报告。这样做是为了确保一系列连续的状态更改不会破坏协议的健壮性。

If the interface reception-state change that triggers the new report is a filter-mode change, then the next [Robustness Variable] State-Change Reports will include a Filter-Mode-Change record. This applies even if any number of source-list changes occur in that period. The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent. When [Robustness Variable] State-Change reports with Filter-Mode-Change records have been transmitted after the last filter-mode change, and if source-list changes to the interface reception have scheduled additional reports, then the next State-Change report will include Source-List-Change records.

如果触发新报告的接口接收状态更改是过滤器模式更改,则下一个[稳健性变量]状态更改报告将包括过滤器模式更改记录。即使在此期间发生了任意数量的源列表更改,这也适用。主机必须保持组的重新传输状态,直到发送[鲁棒性变量]状态更改报告。在上一次过滤器模式更改后,如果发送了带有过滤器模式更改记录的[鲁棒性变量]状态更改报告,并且如果接口接收的源列表更改计划了其他报告,则下一个状态更改报告将包括源列表更改记录。

Each time a State-Change Report is transmitted, the contents are determined as follows. If the report should contain a Filter-Mode-Change record, then if the current filter-mode of the interface is INCLUDE, a TO_IN record is included in the report, otherwise a TO_EX record is included. If instead the report should contain Source-List-Change records, an ALLOW and a BLOCK record are included. The contents of these records are built according to the table below.

每次传输状态更改报告时,内容确定如下。如果报表应包含过滤模式更改记录,则如果接口的当前过滤模式为INCLUDE,则报表中包含TO_IN记录,否则包含TO_EX记录。如果报告应包含源列表更改记录,则包括允许和块记录。这些记录的内容是根据下表建立的。

      Record   Sources included
      ------   ----------------
      TO_IN    All in the current interface state that must be forwarded
      TO_EX    All in the current interface state that must be blocked
      ALLOW    All with retransmission state that must be forwarded
      BLOCK    All with retransmission state that must be blocked
        
      Record   Sources included
      ------   ----------------
      TO_IN    All in the current interface state that must be forwarded
      TO_EX    All in the current interface state that must be blocked
      ALLOW    All with retransmission state that must be forwarded
      BLOCK    All with retransmission state that must be blocked
        

If the computed source list for either an ALLOW or a BLOCK record is empty, that record is omitted from the State-Change report.

如果ALLOW或BLOCK记录的计算源列表为空,则状态更改报告中将忽略该记录。

Note: When the first State-Change report is sent, the non-existent pending report to merge with, can be treated as a source-change report with empty ALLOW and BLOCK records (no sources have retransmission state).

注意:发送第一个状态更改报告时,不存在的要合并的挂起报告可以被视为具有空允许和块记录的源更改报告(没有源具有重传状态)。

5.2. Action on Reception of a Query
5.2. 收到询问时采取的行动

When a system receives a Query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message. A system may receive a variety of Queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response.

当系统收到查询时,它不会立即响应。相反,它将其响应延迟随机的时间量,以从接收到的查询消息中的Max Resp代码派生的Max Resp time值为界。系统可以在不同的接口上接收各种不同类型的查询(例如,一般查询、特定于组的查询以及特定于组和源的查询),每个查询都可能需要自己的延迟响应。

Before scheduling a response to a Query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the system must be able to maintain the following state:

在调度对查询的响应之前,系统必须首先考虑预先调度的待决响应,并且在许多情况下调度组合响应。因此,系统必须能够保持以下状态:

o A timer per interface for scheduling responses to General Queries.

o 每个接口都有一个计时器,用于调度对常规查询的响应。

o A per-group and interface timer for scheduling responses to Group-Specific and Group-and-Source-Specific Queries.

o 每个组和接口计时器,用于调度对特定于组以及特定于组和源的查询的响应。

o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query.

o 在对组和源特定查询的响应中报告的每个组和接口源列表。

When a new Query with the Router-Alert option arrives on an interface, provided the system has state to report, a delay for a response is randomly selected in the range (0, [Max Resp Time]) where Max Resp Time is derived from Max Resp Code in the received Query message. The following rules are then used to determine if a Report needs to be scheduled and the type of Report to schedule. The rules are considered in order and only the first matching rule is applied.

当带有路由器警报选项的新查询到达接口时,如果系统具有要报告的状态,则响应的延迟将在范围(0,[Max Resp Time])内随机选择,其中Max Resp Time从接收到的查询消息中的Max Resp Code中派生。然后使用以下规则确定是否需要计划报表以及要计划的报表类型。规则按顺序考虑,仅应用第一个匹配规则。

1. If there is a pending response to a previous General Query scheduled sooner than the selected delay, no additional response needs to be scheduled.

1. 如果对上一个常规查询的挂起响应比所选延迟早,则无需计划其他响应。

2. If the received Query is a General Query, the interface timer is used to schedule a response to the General Query after the selected delay. Any previously pending response to a General Query is canceled.

2. 如果接收到的查询是一般查询,则使用接口计时器在所选延迟后安排对一般查询的响应。任何以前挂起的对常规查询的响应都将被取消。

3. If the received Query is a Group-Specific Query or a Group-and-Source-Specific Query and there is no pending response to a previous Query for this group, then the group timer is used to schedule a report. If the received Query is a Group-and-Source-Specific Query, the list of queried sources is recorded to be used when generating a response.

3. 如果收到的查询是特定于组的查询或特定于组和源的查询,并且没有对此组的上一个查询的挂起响应,则使用组计时器计划报告。如果收到的查询是组和源特定的查询,则记录查询的源列表,以便在生成响应时使用。

4. If there already is a pending response to a previous Query scheduled for this group, and either the new Query is a Group-Specific Query or the recorded source-list associated with the group is empty, then the group source-list is cleared and a single response is scheduled using the group timer. The new response is scheduled to be sent at the earliest of the remaining time for the pending report and the selected delay.

4. 如果已为该组安排了对以前查询的挂起响应,并且新查询是特定于组的查询,或者与该组关联的记录源列表为空,则清除组源列表,并使用组计时器安排单个响应。新的响应计划在挂起报告和所选延迟的剩余时间中最早的时间发送。

5. If the received Query is a Group-and-Source-Specific Query and there is a pending response for this group with a non-empty source-list, then the group source list is augmented to contain the list of sources in the new Query and a single response is scheduled using the group timer. The new response is scheduled to be sent at the earliest of the remaining time for the pending report and the selected delay.

5. 如果收到的查询是组和源特定的查询,并且此组有一个具有非空源列表的挂起响应,则组源列表将被扩充以包含新查询中的源列表,并使用组计时器计划单个响应。新的响应计划在挂起报告和所选延迟的剩余时间中最早的时间发送。

When the timer in a pending response record expires, the system transmits, on the associated interface, one or more Report messages carrying one or more Current-State Records (see section 4.2.12), as follows:

当挂起响应记录中的计时器过期时,系统在相关接口上传输一条或多条报告消息,其中包含一条或多条当前状态记录(见第4.2.12节),如下所示:

1. If the expired timer is the interface timer (i.e., it is a pending response to a General Query), then one Current-State Record is sent for each multicast address for which the specified interface has reception state, as described in section 3.2. The Current-State Record carries the multicast address and its associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list. Multiple Current-State Records are packed into individual Report messages, to the extent possible.

1. 如果过期计时器是接口计时器(即,它是对一般查询的挂起响应),则为指定接口具有接收状态的每个多播地址发送一条当前状态记录,如第3.2节所述。当前状态记录包含多播地址及其关联的筛选模式(模式为“包含”或“模式为“排除”)和源列表。多个当前状态记录尽可能打包到单个报告消息中。

This naive algorithm may result in bursts of packets when a system is a member of a large number of groups. Instead of using a single interface timer, implementations are recommended to spread transmission of such Report messages over the interval (0, [Max Resp Time]). Note that any such implementation MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a Report immediately on reception of a General Query.

当系统是大量组的成员时,这种幼稚的算法可能会导致数据包突发。建议实现在间隔(0,[Max Resp Time])上分散此类报告消息的传输,而不是使用单个接口计时器。请注意,任何此类实现都必须避免“ack内爆”问题,即,在收到一般查询时不得立即发送报告。

2. If the expired timer is a group timer and the list of recorded sources for the that group is empty (i.e., it is a pending response to a Group-Specific Query), then if and only if the interface has reception state for that group address, a single Current-State Record is sent for that address. The Current-State Record carries the multicast address and its associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list.

2. 如果过期计时器是组计时器,且该组的记录源列表为空(即,它是对特定于组的查询的挂起响应),则当且仅当接口具有该组地址的接收状态时,才会为该地址发送单个当前状态记录。当前状态记录包含多播地址及其关联的筛选模式(模式为“包含”或“模式为“排除”)和源列表。

3. If the expired timer is a group timer and the list of recorded sources for that group is non-empty (i.e., it is a pending response to a Group-and-Source-Specific Query), then if and only if the interface has reception state for that group address, the contents of the responding Current-State Record is determined from the interface state and the pending response record, as specified in the following table:

3. 如果过期计时器是组计时器,且该组的记录源列表为非空(即,它是对组和源特定查询的挂起响应),则当且仅当接口具有该组地址的接收状态时,响应当前状态记录的内容由接口状态和挂起响应记录确定,如下表所示:

                         set of sources in the
      interface state   pending response record   Current-State Record
      ---------------   -----------------------   --------------------
        
                         set of sources in the
      interface state   pending response record   Current-State Record
      ---------------   -----------------------   --------------------
        

INCLUDE (A) B IS_IN (A*B)

包括(A)B在(A*B)中

EXCLUDE (A) B IS_IN (B-A)

排除(A)B在(B-A)中

If the resulting Current-State Record has an empty set of source addresses, then no response is sent.

如果生成的当前状态记录的源地址集为空,则不会发送响应。

Finally, after any required Report messages have been generated, the source lists associated with any reported groups are cleared.

最后,生成任何必需的报告消息后,将清除与任何报告组关联的源列表。

6. Description of the Protocol for Multicast Routers
6. 多播路由器协议描述

The purpose of IGMP is to enable each multicast router to learn, for each of its directly attached networks, which multicast addresses are of interest to the systems attached to those networks. IGMP version 3 adds the capability for a multicast router to also learn which *sources* are of interest to neighboring systems, for packets sent to any particular multicast address. The information gathered by IGMP is provided to whichever multicast routing protocol is being used by the router, in order to ensure that multicast packets are delivered to all networks where there are interested receivers.

IGMP的目的是使每个多播路由器能够为其每个直接连接的网络学习连接到这些网络的系统感兴趣的多播地址。IGMP版本3增加了多播路由器的功能,使其能够了解发送到任何特定多播地址的数据包对相邻系统感兴趣的*源*。IGMP收集的信息被提供给路由器正在使用的任何一个多播路由协议,以确保多播数据包被传送到有感兴趣的接收器的所有网络。

This section describes the part of IGMPv3 that is performed by multicast routers. Multicast routers may also themselves become members of multicast groups, and therefore also perform the group member part of IGMPv3, described in section 5.

本节描述由多播路由器执行的IGMPv3部分。多播路由器本身也可以成为多播组的成员,因此也可以执行第5节中描述的IGMPv3的组成员部分。

A multicast router performs the protocol described in this section over each of its directly-attached networks. If a multicast router has more than one interface to the same network, it only needs to operate this protocol over one of those interfaces. On each interface over which this protocol is being run, the router MUST enable reception of multicast address 224.0.0.22, from all sources (and MUST perform the group member part of IGMPv3 for that address on that interface).

多播路由器在其每个直接连接的网络上执行本节所述的协议。如果多播路由器与同一网络有多个接口,它只需要在其中一个接口上运行该协议。在运行此协议的每个接口上,路由器必须能够从所有源接收多播地址224.0.0.22(并且必须对该接口上的地址执行IGMPv3的组成员部分)。

Multicast routers need to know only that *at least one* system on an attached network is interested in packets to a particular multicast address from a particular source; a multicast router is not required to keep track of the interests of each individual neighboring system. (However, see Appendix A.2 point 1 for discussion.)

多播路由器只需要知道连接网络上的*至少一个*系统对来自特定源的特定多播地址的分组感兴趣;多播路由器不需要跟踪每个相邻系统的兴趣。(但是,有关讨论,请参见附录A.2第1点。)

IGMPv3 is backward compatible with previous versions of the IGMP protocol. In order to remain backward compatible with older IGMP systems, IGMPv3 multicast routers MUST also implement versions 1 and 2 of the protocol (see section 7).

IGMPv3与以前版本的IGMP协议向后兼容。为了与旧的IGMP系统保持向后兼容,IGMPv3多播路由器还必须实现协议的版本1和版本2(参见第7节)。

6.1. Conditions for IGMP Queries
6.1. IGMP查询的条件

Multicast routers send General Queries periodically to request group membership information from an attached network. These queries are used to build and refresh the group membership state of systems on attached networks. Systems respond to these queries by reporting their group membership state (and their desired set of sources) with Current-State Group Records in IGMPv3 Membership Reports.

多播路由器定期发送常规查询,以从连接的网络请求组成员信息。这些查询用于构建和刷新连接网络上系统的组成员状态。系统通过在IGMPv3成员报告中使用当前状态组记录报告其组成员状态(以及所需的源集)来响应这些查询。

As a member of a multicast group, a system may express interest in receiving or not receiving traffic from particular sources. As the desired reception state of a system changes, it reports these changes using Filter-Mode-Change Records or Source-List-Change Records. These records indicate an explicit state change in a group at a system in either the group record's source list or its filter-mode. When a group membership is terminated at a system or traffic from a particular source is no longer desired, a multicast router must query for other members of the group or listeners of the source before deleting the group (or source) and pruning its traffic.

作为多播组的成员,系统可能对接收或不接收来自特定源的流量表示兴趣。当系统的期望接收状态发生变化时,它会使用过滤器模式变化记录或源列表变化记录报告这些变化。这些记录表示系统中某个组在该组记录的源列表或其筛选模式下的显式状态更改。当组成员资格在系统中终止或不再需要来自特定源的流量时,多播路由器必须在删除组(或源)并修剪其流量之前查询组的其他成员或源的侦听器。

To enable all systems on a network to respond to changes in group membership, multicast routers send specific queries. A Group-Specific Query is sent to verify there are no systems that desire reception of the specified group or to "rebuild" the desired reception state for a particular group. Group-Specific Queries are sent when a router receives a State-Change record indicating a system is leaving a group.

为了使网络上的所有系统能够响应组成员资格的更改,多播路由器发送特定的查询。发送特定于组的查询,以验证没有系统希望接收指定组或“重建”特定组的所需接收状态。当路由器接收到表示系统正在离开组的状态更改记录时,将发送特定于组的查询。

A Group-and-Source Specific Query is used to verify there are no systems on a network which desire to receive traffic from a set of sources. Group-and-Source Specific Queries list sources for a particular group which have been requested to no longer be forwarded. This query is sent by a multicast router to learn if any systems desire reception of packets to the specified group address from the specified source addresses. Group-and-Source Specific Queries are only sent in response to State-Change Records and never in response to Current-State Records. Section 4.1.11 describes each query in more detail.

特定于组和源的查询用于验证网络上没有希望从一组源接收流量的系统。组和源特定查询列出了已请求不再转发的特定组的源。此查询由多播路由器发送,以了解是否有任何系统希望从指定源地址接收到指定组地址的数据包。组和源特定的查询仅在响应状态更改记录时发送,而从不响应当前状态记录。第4.1.11节更详细地描述了每个查询。

6.2. IGMP State Maintained by Multicast Routers
6.2. 由多播路由器维护的IGMP状态

Multicast routers implementing IGMPv3 keep state per group per attached network. This group state consists of a filter-mode, a list of sources, and various timers. For each attached network running IGMP, a multicast router records the desired reception state for that network. That state conceptually consists of a set of records of the form:

实现IGMPv3的多播路由器在每个连接的网络上保持每个组的状态。此组状态由筛选模式、源列表和各种计时器组成。对于运行IGMP的每个连接网络,多播路由器记录该网络所需的接收状态。该状态在概念上由以下形式的一组记录组成:

(multicast address, group timer, filter-mode, (source records))

(多播地址、组计时器、筛选模式(源记录))

Each source record is of the form:

每个源记录的格式如下:

(source address, source timer)

(源地址、源计时器)

If all sources within a given group are desired, an empty source record list is kept with filter-mode set to EXCLUDE. This means hosts on this network want all sources for this group to be forwarded. This is the IGMPv3 equivalent to a IGMPv1 or IGMPv2 group join.

如果需要给定组中的所有源,则保留空源记录列表,并将筛选模式设置为排除。这意味着此网络上的主机希望转发此组的所有源。这是相当于IGMPv1或IGMPv2组联接的IGMPv3。

6.2.1. Definition of Router Filter-Mode
6.2.1. 路由器过滤模式的定义

To reduce internal state, IGMPv3 routers keep a filter-mode per group per attached network. This filter-mode is used to condense the total desired reception state of a group to a minimum set such that all systems' memberships are satisfied. This filter-mode may change in response to the reception of particular types of group records or when certain timer conditions occur. In the following sections, we use the term "router filter-mode" to refer to the filter-mode of a particular group within a router. Section 6.4 describes the changes of a router filter-mode per group record received.

为了减少内部状态,IGMPv3路由器在每个连接的网络上保持每个组的过滤模式。此过滤模式用于将组的总期望接收状态压缩到最小集合,以便满足所有系统的成员资格。此过滤模式可能会随着接收到特定类型的组记录或出现某些计时器条件而改变。在以下部分中,我们使用术语“路由器过滤模式”来指代路由器内特定组的过滤模式。第6.4节描述了收到的每个组记录的路由器过滤模式的变化。

Conceptually, when a group record is received, the router filter-mode for that group is updated to cover all the requested sources using the least amount of state. As a rule, once a group record with a filter-mode of EXCLUDE is received, the router filter-mode for that group will be EXCLUDE.

从概念上讲,当接收到组记录时,该组的路由器过滤器模式将更新,以使用最少的状态覆盖所有请求的源。通常,一旦收到过滤模式为EXCLUDE的组记录,该组的路由器过滤模式将为EXCLUDE。

When a router filter-mode for a group is EXCLUDE, the source record list contains two types of sources. The first type is the set which represents conflicts in the desired reception state; this set must be forwarded by some router on the network. The second type is the set of sources which hosts have requested to not be forwarded. Appendix A describes the reasons for keeping this second set when in EXCLUDE mode.

当组的路由器筛选器模式为“排除”时,源记录列表包含两种类型的源。第一类型是表示期望接收状态中的冲突的集合;此集合必须由网络上的某个路由器转发。第二种类型是主机请求不转发的源集合。附录A描述了在排除模式下保持第二组的原因。

When a router filter-mode for a group is INCLUDE, the source record list is the list of sources desired for the group. This is the total desired set of sources for that group. Each source in the source record list must be forwarded by some router on the network.

当组的路由器筛选器模式为“包括”时,源记录列表是该组所需的源列表。这是该组所需的全部源集。源记录列表中的每个源都必须由网络上的某个路由器转发。

Because a reported group record with a filter-mode of EXCLUDE will cause a router to transition its filter-mode for that group to EXCLUDE, a mechanism for transitioning a router's filter-mode back to INCLUDE must exist. If all systems with a group record in EXCLUDE filter-mode cease reporting, it is desirable for the router filter-mode for that group to transition back to INCLUDE mode. This transition occurs when the group timer expires and is explained in detail in section 6.5.

由于过滤模式为EXCLUDE的报告组记录将导致路由器转换其过滤模式以排除该组,因此必须存在将路由器的过滤模式转换回INCLUDE的机制。如果组记录处于排除筛选模式的所有系统都停止报告,则该组的路由器筛选模式最好转换回包括模式。当组计时器过期时发生此转换,并在第6.5节中详细说明。

6.2.2. Definition of Group Timers
6.2.2. 分组计时器的定义

The group timer is only used when a group is in EXCLUDE mode and it represents the time for the *filter-mode* of the group to expire and switch to INCLUDE mode. We define a group timer as a decrementing timer with a lower bound of zero kept per group per attached network. Group timers are updated according to the types of group records received.

组计时器仅在组处于排除模式时使用,它表示组的*筛选模式*过期并切换到包括模式的时间。我们将组计时器定义为递减计时器,每个连接的网络中每个组的下限为零。根据收到的组记录类型更新组计时器。

A group timer expiring when a router filter-mode for the group is EXCLUDE means there are no listeners on the attached network in EXCLUDE mode. At this point, a router will transition to INCLUDE filter-mode. Section 6.5 describes the actions taken when a group timer expires while in EXCLUDE mode.

当组的路由器筛选器模式为EXCLUDE时,组计时器过期意味着连接的网络上没有处于EXCLUDE模式的侦听器。此时,路由器将转换为包含过滤器模式。第6.5节描述了在排除模式下组计时器过期时采取的措施。

The following table summarizes the role of the group timer. Section 6.4 describes the details of setting the group timer per type of group record received.

下表总结了组计时器的作用。第6.4节描述了根据接收到的组记录类型设置组计时器的详细信息。

      Group
      Filter-Mode      Group Timer Value      Actions/Comments
      -----------      -----------------      ----------------
        
      Group
      Filter-Mode      Group Timer Value      Actions/Comments
      -----------      -----------------      ----------------
        

INCLUDE Timer >= 0 All members in INCLUDE mode.

包含计时器>=0包含模式中的所有成员。

EXCLUDE Timer > 0 At least one member in EXCLUDE mode.

排除计时器>0至少有一个成员处于排除模式。

EXCLUDE Timer == 0 No more listeners to group. If all source timers have expired then delete Group Record. If there are still source record timers running, switch to INCLUDE filter-mode using those source records with running timers as the INCLUDE source record state.

排除计时器==0组中不再有侦听器。如果所有源计时器都已过期,则删除组记录。如果仍有源记录计时器在运行,请切换到包含筛选模式,使用那些具有运行计时器的源记录作为包含源记录状态。

6.2.3. Definition of Source Timers
6.2.3. 源定时器的定义

A source timer is kept per source record and is a decrementing timer with a lower bound of zero. Source timers are updated according to the type and filter-mode of the group record received. Source timers are always updated (for a particular group) whenever the source is present in a received record for that group. Section 6.4 describes the setting of source timers per type of group records received.

每个源记录保留一个源计时器,它是一个下限为零的递减计时器。源计时器根据接收到的组记录的类型和过滤模式进行更新。每当源出现在该组的接收记录中时,源计时器总是会更新(针对特定组)。第6.4节描述了接收到的每种组记录类型的源计时器设置。

A source record with a running timer with a router filter-mode for the group of INCLUDE means that there is currently one or more systems (in INCLUDE filter-mode) which desire to receive that source. If a source timer expires with a router filter-mode for the group of INCLUDE, the router concludes that traffic from this particular source is no longer desired on the attached network, and deletes the associated source record.

对于包含组,带有运行计时器和路由器过滤模式的源记录意味着当前有一个或多个系统(在包含过滤模式下)希望接收该源。如果源计时器因包含组的路由器筛选器模式而过期,路由器会得出结论,即连接的网络不再需要来自该特定源的通信量,并删除关联的源记录。

Source timers are treated differently when a router filter-mode for a group is EXCLUDE. If a source record has a running timer with a router filter-mode for the group of EXCLUDE, it means that at least one system desires the source. It should therefore be forwarded by a router on the network. Appendix A describes the reasons for keeping state for sources that have been requested to be forwarded while in EXCLUDE state.

当组的路由器筛选器模式被排除时,源计时器的处理方式不同。如果源记录有一个运行计时器,该计时器具有一组排除的路由器过滤模式,则表示至少有一个系统需要该源。因此,它应该由网络上的路由器转发。附录A描述了在处于排除状态时保持已请求转发的源状态的原因。

If a source timer expires with a router filter-mode for the group of EXCLUDE, the router informs the routing protocol that there is no longer a receiver on the network interested in traffic from this source.

如果源计时器因排除组的路由器过滤模式而过期,路由器将通知路由协议,网络上不再有对来自该源的流量感兴趣的接收器。

When a router filter-mode for a group is EXCLUDE, source records are only deleted when the group timer expires. Section 6.3 describes the actions that should be taken dependent upon the value of a source timer.

当组的路由器筛选模式为“排除”时,仅当组计时器过期时才删除源记录。第6.3节描述了根据源定时器的值应采取的措施。

6.3. IGMPv3 Source-Specific Forwarding Rules
6.3. IGMPv3源特定转发规则

When a multicast router receives a datagram from a source destined to a particular group, a decision has to be made whether to forward the datagram onto an attached network or not. The multicast routing protocol in use is in charge of this decision, and should use the IGMPv3 information to ensure that all sources/groups desired on a subnetwork are forwarded to that subnetwork. IGMPv3 information does not override multicast routing information; for example, if the IGMPv3 filter-mode group for G is EXCLUDE, a router may still forward packets for excluded sources to a transit subnet.

当多播路由器从目的地为特定组的源接收到数据报时,必须决定是否将数据报转发到连接的网络上。正在使用的多播路由协议负责此决策,并应使用IGMPv3信息确保子网上所需的所有源/组都转发到该子网。IGMPv3信息不覆盖多播路由信息;例如,如果G的IGMPv3过滤模式组为EXCLUDE,则路由器仍然可以将被排除源的分组转发到传输子网。

To summarize, the following table describes the forwarding suggestions made by IGMP to the routing protocol for traffic originating from a source destined to a group. It also summarizes the actions taken upon the expiration of a source timer based on the router filter-mode of the group.

总而言之,下表描述了IGMP对路由协议提出的转发建议,这些建议适用于来自目的地为组的源的流量。它还根据组的路由器筛选器模式总结了源计时器过期时采取的操作。

      Group
      Filter-Mode    Source Timer Value    Action
      -----------    ------------------    ------
        
      Group
      Filter-Mode    Source Timer Value    Action
      -----------    ------------------    ------
        

INCLUDE TIMER > 0 Suggest to forward traffic from source

包含计时器>0建议转发来自源的流量

INCLUDE TIMER == 0 Suggest to stop forwarding traffic from source and remove source record. If there are no more source records for the group, delete group record.

INCLUDE TIMER==0建议停止从源转发流量并删除源记录。如果组没有更多的源记录,请删除组记录。

INCLUDE No Source Elements Suggest to not forward source

包含无源元素建议不转发源

EXCLUDE TIMER > 0 Suggest to forward traffic from source

排除计时器>0建议转发来自源的流量

EXCLUDE TIMER == 0 Suggest to not forward traffic from source (DO NOT remove record)

排除计时器==0建议不转发来自源的流量(不删除记录)

EXCLUDE No Source Elements Suggest to forward traffic from source

排除不建议从源转发流量的源元素

6.4. Action on Reception of Reports
6.4. 关于接收报告的行动
6.4.1. Reception of Current-State Records
6.4.1. 接收当前状态记录

When receiving Current-State Records, a router updates both its group and source timers. In some circumstances, the reception of a type of group record will cause the router filter-mode for that group to change. The table below describes the actions, with respect to state and timers that occur to a router's state upon reception of Current-State Records.

当接收到当前状态记录时,路由器更新其组和源计时器。在某些情况下,接收一类组记录会导致该组的路由器过滤模式发生变化。下表描述了在接收到当前状态记录时路由器状态发生的状态和计时器相关的操作。

The following notation is used to describe the updating of source timers. The notation ( A, B ) will be used to represent the total number of sources for a particular group, where

以下符号用于描述源计时器的更新。符号(A,B)将用于表示特定组的源总数,其中

A = set of source records whose source timers > 0 (Sources that at least one host has requested to be forwarded) B = set of source records whose source timers = 0 (Sources that IGMP will suggest to the routing protocol not to forward)

A=源计时器大于0的源记录集(至少有一个主机请求转发的源)B=源计时器为0的源记录集(IGMP将建议路由协议不要转发的源)

Note that there will only be two sets when a router's filter-mode for a group is EXCLUDE. When a router's filter-mode for a group is INCLUDE, a single set is used to describe the set of sources requested to be forwarded (e.g., simply (A)).

请注意,当路由器的组过滤模式为“排除”时,将只有两组。当路由器对组的过滤模式为INCLUDE时,单个集合用于描述请求转发的源集合(例如,简单地说(a))。

In the following tables, abbreviations are used for several variables (all of which are described in detail in section 8). The variable GMI is an abbreviation for the Group Membership Interval, which is the time in which group memberships will time out. The variable LMQT is an abbreviation for the Last Member Query Time, which is the total time spent after Last Member Query Count retransmissions. LMQT represents the "leave latency", or the difference between the transmission of a membership change and the change in the information given to the routing protocol.

在下表中,多个变量使用缩写(第8节详细介绍了所有这些变量)。变量GMI是组成员资格间隔的缩写,即组成员资格将超时的时间。变量LMQT是最后一个成员查询时间的缩写,它是最后一个成员查询计数重新传输后花费的总时间。LMQT表示“离开延迟”,即成员身份更改的传输与给路由协议的信息更改之间的差异。

Within the "Actions" section of the router state tables, we use the notation 'A=J', which means that the set A of source records should have their source timers set to value J. 'Delete A' means that the set A of source records should be deleted. 'Group Timer=J' means that the Group Timer for the group should be set to value J.

在路由器状态表的“操作”部分中,我们使用符号“A=J”,这意味着源记录集A的源计时器应设置为值J。“删除A”意味着应删除源记录集A。”Group Timer=J'表示组的组计时器应设置为值J。

   Router State   Report Rec'd  New Router State         Actions
   ------------   ------------  ----------------         -------
        
   Router State   Report Rec'd  New Router State         Actions
   ------------   ------------  ----------------         -------
        

INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=GMI

包括(A)是(B)中的_,包括(A+B)(B)=GMI

INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0 Delete (A-B) Group Timer=GMI

包括(A)是排除(A*B,B-A)(B-A)=0删除(A-B)组计时器=GMI

EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI

排除(X,Y)是(A)中的_排除(X+A,Y-A)(A)=GMI

EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=GMI Delete (X-A) Delete (Y-A) Group Timer=GMI

EXCLUDE(X,Y)是_EX(A)EXCLUDE(A-Y,Y*A)(A-X-Y)=GMI Delete(X-A)Delete(Y-A)Group Timer=GMI

6.4.2. Reception of Filter-Mode-Change and Source-List-Change Records
6.4.2. 接收过滤器模式更改和源列表更改记录

When a change in the global state of a group occurs in a system, the system sends either a Source-List-Change Record or a Filter-Mode-Change Record for that group. As with Current-State Records, routers must act upon these records and possibly change their own state to reflect the new desired membership state of the network.

当系统中某个组的全局状态发生更改时,系统会发送该组的源列表更改记录或筛选器模式更改记录。与当前状态记录一样,路由器必须对这些记录进行操作,并可能更改其自身的状态以反映网络的新的期望成员状态。

Routers must query sources that are requested to be no longer forwarded to a group. When a router queries or receives a query for a specific set of sources, it lowers its source timers for those sources to a small interval of Last Member Query Time seconds. If group records are received in response to the queries which express interest in receiving traffic from the queried sources, the corresponding timers are updated.

路由器必须查询请求不再转发到组的源。当路由器查询或接收到一组特定源的查询时,它会将这些源的源计时器降低到最后一个成员查询时间秒的小间隔。如果接收到组记录以响应表示有兴趣从查询源接收流量的查询,则会更新相应的计时器。

Similarly, when a router queries a specific group, it lowers its group timer for that group to a small interval of Last Member Query Time seconds. If any group records expressing EXCLUDE mode interest in the group are received within the interval, the group timer for the group is updated and the suggestion to the routing protocol to forward the group stands without any interruption.

类似地,当路由器查询特定组时,它会将该组的组计时器降低到最后一个成员查询时间秒的小间隔。如果在该时间间隔内收到任何表示排除模式对该组感兴趣的组记录,则更新该组的组计时器,并向路由协议建议在不中断的情况下转发该组。

During a query period (i.e., Last Member Query Time seconds), the IGMP component in the router continues to suggest to the routing protocol that it forwards traffic from the groups or sources that it is querying. It is not until after Last Member Query Time seconds without receiving a record expressing interest in the queried group or sources that the router may prune the group or sources from the network.

在查询期间(即,最后一个成员查询时间秒),路由器中的IGMP组件继续向路由协议建议它转发来自其正在查询的组或源的流量。直到最后一个成员查询时间秒后,没有收到表示对查询的组或源感兴趣的记录,路由器才可以从网络中删除组或源。

The following table describes the changes in group state and the action(s) taken when receiving either Filter-Mode-Change or Source-List-Change Records. This table also describes the queries which are sent by the querier when a particular report is received.

下表描述了组状态的更改以及在接收筛选器模式更改或源列表更改记录时采取的操作。此表还描述了查询者在收到特定报告时发送的查询。

We use the following notation for describing the queries which are sent. We use the notation 'Q(G)' to describe a Group-Specific Query to G. We use the notation 'Q(G,A)' to describe a Group-and-Source Specific Query to G with source-list A. If source-list A is null as a result of the action (e.g., A*B) then no query is sent as a result of the operation.

我们使用以下符号来描述发送的查询。我们使用符号‘Q(G)’来描述对G的特定于组的查询。我们使用符号‘Q(G,a)’来描述对G的特定于组和源的查询,以及源列表a。如果源列表a由于操作(例如a*B)而为空,则操作的结果不会发送任何查询。

In order to maintain protocol robustness, queries sent by actions in the table below need to be transmitted [Last Member Query Count] times, once every [Last Member Query Interval].

为了保持协议的健壮性,下表中的操作发送的查询需要传输[Last Member Query Count]次,每[Last Member Query Interval]一次。

If while scheduling new queries, there are already pending queries to be retransmitted for the same group, the new and pending queries have to be merged. In addition, received host reports for a group with pending queries may affect the contents of those queries. Section 6.6.3 describes the process of building and maintaining the state of pending queries.

如果在调度新查询时,同一组中已存在要重新传输的挂起查询,则必须合并新查询和挂起查询。此外,收到的具有挂起查询的组的主机报告可能会影响这些查询的内容。第6.6.3节描述了建立和维护未决查询状态的过程。

Router State   Report Rec'd New Router State        Actions
------------   ------------ ----------------        -------
        
Router State   Report Rec'd New Router State        Actions
------------   ------------ ----------------        -------
        

INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=GMI

包括(A)允许(B)包括(A+B)(B)=GMI

INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(G,A*B)

包括(A)块(B)包括(A)发送Q(G,A*B)

INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A)=0 Delete (A-B) Send Q(G,A*B) Group Timer=GMI

INCLUDE(A)TO_EX(B)EXCLUDE(A*B,B-A)(B-A)=0 Delete(A-B)Send Q(G,A*B)Group Timer=GMI

INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=GMI Send Q(G,A-B)

包括(A)至(B)中的_包括(A+B)(B)=GMI发送Q(G,A-B)

EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=GMI

排除(X,Y)允许(A)排除(X+A,Y-A)(A)=GMI

EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y)=Group Timer Send Q(G,A-Y)

排除(X,Y)块(A)排除(X+(A-Y),Y)(A-X-Y)=组定时器发送Q(G,A-Y)

EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer Delete (X-A) Delete (Y-A) Send Q(G,A-Y) Group Timer=GMI

排除(X,Y)到排除(A)排除(A-Y,Y*A)(A-X-Y)=组计时器删除(X-A)删除(Y-A)发送Q(G,A-Y)组计时器=GMI

EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI Send Q(G,X-A) Send Q(G)

排除(X,Y)到(A)中的_排除(X+A,Y-A)(A)=GMI发送Q(G,X-A)发送Q(G)

6.5. Switching Router Filter-Modes
6.5. 交换路由器滤波器模式

The group timer is used as a mechanism for transitioning the router filter-mode from EXCLUDE to INCLUDE.

组计时器用作将路由器筛选器模式从排除转换为包括的机制。

When a group timer expires with a router filter-mode of EXCLUDE, a router assumes that there are no systems with a *filter-mode* of EXCLUDE present on the attached network. When a router's filter-mode for a group is EXCLUDE and the group timer expires, the router filter-mode for the group transitions to INCLUDE.

当组计时器在路由器过滤模式为EXCLUDE的情况下过期时,路由器会假定连接的网络上不存在*过滤模式*为EXCLUDE的系统。当路由器对组的筛选模式为“排除”且组计时器过期时,组的路由器筛选模式将转换为“包括”。

A router uses source records with running source timers as its state for the switch to a filter-mode of INCLUDE. If there are any source records with source timers greater than zero (i.e., requested to be forwarded), a router switches to filter-mode of INCLUDE using those source records. Source records whose timers are zero (from the previous EXCLUDE mode) are deleted.

路由器使用源记录和正在运行的源计时器作为其状态,以切换到包含的过滤模式。如果有任何源记录的源计时器大于零(即,请求转发),路由器将使用这些源记录切换到包含过滤模式。将删除计时器为零的源记录(从以前的排除模式)。

For example, if a router's state for a group is EXCLUDE(X,Y) and the group timer expires for that group, the router switches to filter-mode of INCLUDE with state INCLUDE(X).

例如,如果一个组的路由器状态为EXCLUDE(X,Y),并且该组的组计时器过期,路由器将切换到包含状态为INCLUDE(X)的过滤模式。

6.6. Action on Reception of Queries
6.6. 接受查询的行动
6.6.1. Timer Updates
6.6.1. 计时器更新

When a router sends or receives a query with a clear Suppress Router-Side Processing flag, it must update its timers to reflect the correct timeout values for the group or sources being queried. The following table describes the timer actions when sending or receiving a Group-Specific or Group-and-Source Specific Query with the Suppress Router-Side Processing flag not set.

当路由器发送或接收带有清除禁止路由器端处理标志的查询时,它必须更新其计时器,以反映所查询的组或源的正确超时值。下表描述了发送或接收特定于组或特定于组和源的查询时未设置抑制路由器端处理标志的计时器操作。

      Query      Action
      -----      ------
      Q(G,A)     Source Timer for sources in A are lowered to LMQT
      Q(G)       Group Timer is lowered to LMQT
        
      Query      Action
      -----      ------
      Q(G,A)     Source Timer for sources in A are lowered to LMQT
      Q(G)       Group Timer is lowered to LMQT
        

When a router sends or receives a query with the Suppress Router-Side Processing flag set, it will not update its timers.

当路由器发送或接收设置了抑制路由器端处理标志的查询时,它不会更新其计时器。

6.6.2. Querier Election
6.6.2. 质询者选举

IGMPv3 elects a single querier per subnet using the same querier election mechanism as IGMPv2, namely by IP address. When a router receives a query with a lower IP address, it sets the Other-Querier-Present timer to Other Querier Present Interval and ceases to send queries on the network if it was the previously elected querier. After its Other-Querier Present timer expires, it should begin sending General Queries.

IGMPv3使用与IGMPv2相同的查询器选择机制,即按IP地址,为每个子网选择一个查询器。当路由器接收到具有较低IP地址的查询时,它会将另一个查询器当前计时器设置为另一个查询器当前间隔,并停止在网络上发送查询(如果它是先前选择的查询器)。在它的另一个查询器Present计时器过期后,它应该开始发送常规查询。

If a router receives an older version query, it MUST use the oldest version of IGMP on the network. For a detailed description of compatibility issues between IGMP versions see section 7.

如果路由器接收到较旧版本的查询,它必须使用网络上最旧版本的IGMP。有关IGMP版本之间兼容性问题的详细说明,请参阅第7节。

6.6.3. Building and Sending Specific Queries
6.6.3. 生成和发送特定查询
6.6.3.1. Building and Sending Group Specific Queries
6.6.3.1. 生成和发送特定于组的查询

When a table action "Send Q(G)" is encountered, then the group timer must be lowered to LMQT. The router must then immediately send a group specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time].

当遇到表操作“发送Q(G)”时,必须将组计时器降低到LMQT。然后,路由器必须立即发送特定于组的查询,并在[上一个成员查询时间]内安排[上一个成员查询计数-1]查询重传,以便每[上一个成员查询间隔]发送一次。

When transmitting a group specific query, if the group timer is larger than LMQT, the "Suppress Router-Side Processing" bit is set in the query message.

传输特定于组的查询时,如果组计时器大于LMQT,则在查询消息中设置“抑制路由器端处理”位。

6.6.3.2. Building and Sending Group and Source Specific Queries
6.6.3.2. 生成和发送特定于组和源的查询

When a table action "Send Q(G,X)" is encountered by a querier in the table in section 6.4.2, the following actions must be performed for each of the sources in X of group G, with source timer larger than LMQT:

当第6.4.2节表格中的查询者遇到表格操作“发送Q(G,X)”时,必须对G组X中的每个震源执行以下操作,震源计时器大于LMQT:

o Set number of retransmissions for each source to [Last Member Query Count].

o 将每个源的重新传输次数设置为[上次成员查询计数]。

o Lower source timer to LMQT.

o 将源定时器降低到LMQT。

The router must then immediately send a group and source specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. The contents of these queries are calculated as follows.

然后,路由器必须立即发送特定于组和源的查询,并在[Last Member query Time]期间安排每[Last Member query Interval]发送一次[Last Member query Count-1]查询重传。这些查询的内容计算如下。

When building a group and source specific query for a group G, two separate query messages are sent for the group. The first one has the "Suppress Router-Side Processing" bit set and contains all the sources with retransmission state and timers greater than LMQT. The second has the "Suppress Router-Side Processing" bit clear and contains all the sources with retransmission state and timers lower or equal to LMQT. If either of the two calculated messages does not contain any sources, then its transmission is suppressed.

为组G构建组和源特定查询时,会为该组发送两条单独的查询消息。第一个具有“抑制路由器端处理”位集,并包含重传状态和定时器大于LMQT的所有源。第二个具有“抑制路由器端处理”位清除,并包含重传状态和定时器低于或等于LMQT的所有源。如果两条计算出的消息中的任何一条不包含任何源,则其传输将被抑制。

Note: If a group specific query is scheduled to be transmitted at the same time as a group and source specific query for the same group, then transmission of the group and source specific message with the "Suppress Router-Side Processing" bit set may be suppressed.

注意:如果一个特定于组的查询计划与同一组的特定于组和源的查询同时发送,则可能会抑制具有“抑制路由器端处理”位集的特定于组和源的消息的发送。

7. Interoperation With Older Versions of IGMP
7. 与旧版IGMP的互操作

IGMP version 3 hosts and routers interoperate with hosts and routers that have not yet been upgraded to IGMPv3. This compatibility is maintained by hosts and routers taking appropriate actions depending on the versions of IGMP operating on hosts and routers within a network.

IGMP版本3主机和路由器与尚未升级到IGMPv3的主机和路由器互操作。这种兼容性是由主机和路由器根据网络中主机和路由器上运行的IGMP版本采取适当措施来维护的。

7.1. Query Version Distinctions
7.1. 查询版本差异

The IGMP version of a Membership Query message is determined as follows:

成员资格查询消息的IGMP版本确定如下:

IGMPv1 Query: length = 8 octets AND Max Resp Code field is zero

IGMPv1查询:长度=8个八位字节,最大响应代码字段为零

IGMPv2 Query: length = 8 octets AND Max Resp Code field is non-zero

IGMPv2查询:长度=8个八位字节,最大响应代码字段为非零

      IGMPv3 Query: length >= 12 octets
        
      IGMPv3 Query: length >= 12 octets
        

Query messages that do not match any of the above conditions (e.g., a Query of length 10 octets) MUST be silently ignored.

不符合上述任何条件的查询消息(例如,长度为10个八位字节的查询)必须以静默方式忽略。

7.2. Group Member Behavior
7.2. 群体成员行为
7.2.1. In the Presence of Older Version Queriers
7.2.1. 在旧版本的查询者面前

In order to be compatible with older version routers, IGMPv3 hosts MUST operate in version 1 and version 2 compatibility modes. IGMPv3 hosts MUST keep state per local interface regarding the compatibility mode of each attached network. A host's compatibility mode is

为了与旧版本路由器兼容,IGMPv3主机必须在版本1和版本2兼容模式下运行。IGMPv3主机必须保持每个本地接口关于每个连接网络的兼容性模式的状态。主机的兼容模式是

determined from the Host Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per interface and is dependent on the version of General Queries heard on that interface as well as the Older Version Querier Present timers for the interface.

根据主机兼容模式变量确定,该变量可以处于三种状态之一:IGMPv1、IGMPv2或IGMPv3。此变量保留在每个接口上,并取决于该接口上听到的常规查询的版本以及该接口的较旧版本查询器当前计时器。

In order to switch gracefully between versions of IGMP, hosts keep both an IGMPv1 Querier Present timer and an IGMPv2 Querier Present timer per interface. IGMPv1 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv1 Membership Query is received. IGMPv2 Querier Present is set to Older Version Querier Present Timeout seconds whenever an IGMPv2 General Query is received.

为了在IGMP版本之间优雅地切换,主机在每个接口上同时保留一个IGMPv1查询器呈现计时器和一个IGMPv2查询器呈现计时器。每当收到IGMPv1成员资格查询时,IGMPv1 Querier Present设置为旧版本Querier Present超时秒。每当接收到IGMPv2常规查询时,IGMPv2查询器显示将设置为旧版本查询器显示超时秒。

The Host Compatibility Mode of an interface changes whenever an older version query (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv2 if it has a running IGMPv2 Querier Present timer. If it does not have a running IGMPv2 Querier Present timer then it switches to Host Compatibility of IGMPv3. When the IGMPv2 Querier Present timer expires, a host switches to Host Compatibility mode of IGMPv3.

每当听到较旧版本的查询(而不是当前的兼容模式)或出现某些计时器条件时,接口的主机兼容模式就会更改。当IGMPv1查询器当前计时器过期时,如果主机有正在运行的IGMPv2查询器当前计时器,则会切换到IGMPv2的主机兼容模式。如果它没有正在运行的IGMPv2查询器呈现计时器,那么它将切换到IGMPv3的主机兼容性。当IGMPv2查询器呈现计时器过期时,主机切换到IGMPv3的主机兼容模式。

The Host Compatibility Mode variable is based on whether an older version General query was heard in the last Older Version Querier Present Timeout seconds. The Host Compatibility Mode is set depending on the following:

Host Compatibility Mode变量基于上一个旧版本查询器Present Timeout seconds中是否听到旧版本常规查询。主机兼容性模式的设置取决于以下内容:

   Host Compatibility Mode       Timer State
   -----------------------       -----------
        
   Host Compatibility Mode       Timer State
   -----------------------       -----------
        

IGMPv3 (default) IGMPv2 Querier Present not running and IGMPv1 Querier Present not running

IGMPv3(默认)IGMPv2查询器存在未运行和IGMPv1查询器存在未运行

IGMPv2 IGMPv2 Querier Present running and IGMPv1 Querier Present not running

IGMPv2 IGMPv2查询器存在正在运行,IGMPv1查询器存在未运行

IGMPv1 IGMPv1 Querier Present running

IGMPv1 IGMPv1查询器当前正在运行

If a host receives a query which causes its Querier Present timers to be updated and correspondingly its compatibility mode, it should switch compatibility modes immediately.

如果主机收到一个导致其查询器当前计时器更新的查询,并相应地更新其兼容模式,则应立即切换兼容模式。

When Host Compatibility Mode is IGMPv3, a host acts using the IGMPv3 protocol on that interface. When Host Compatibility Mode is IGMPv2, a host acts in IGMPv2 compatibility mode, using only the IGMPv2 protocol, on that interface. When Host Compatibility Mode is IGMPv1, a host acts in IGMPv1 compatibility mode, using only the IGMPv1 protocol on that interface.

当主机兼容模式为IGMPv3时,主机在该接口上使用IGMPv3协议进行操作。当主机兼容模式为IGMPv2时,主机在该接口上以IGMPv2兼容模式运行,仅使用IGMPv2协议。当主机兼容模式为IGMPv1时,主机在IGMPv1兼容模式下运行,仅在该接口上使用IGMPv1协议。

An IGMPv1 router will send General Queries with the Max Resp Code set to 0. This MUST be interpreted as a value of 100 (10 seconds).

IGMPv1路由器将发送Max Resp Code设置为0的常规查询。这必须解释为100(10秒)的值。

An IGMPv2 router will send General Queries with the Max Resp Code set to the desired Max Resp Time, i.e., the full range of this field is linear and the exponential algorithm described in section 4.1.1 is not used.

IGMPv2路由器将发送一般查询,并将Max Resp代码设置为所需的Max Resp时间,即该字段的整个范围是线性的,不使用第4.1.1节中描述的指数算法。

Whenever a host changes its compatibility mode, it cancels all its pending response and retransmission timers.

每当主机更改其兼容模式时,它都会取消所有挂起的响应和重传计时器。

7.2.2. In the Presence of Older Version Group Members
7.2.2. 在旧版本组成员在场的情况下

An IGMPv3 host may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. A host MAY allow its IGMPv3 Membership Record to be suppressed by either a Version 1 Membership Report, or a Version 2 Membership Report.

IGMPv3主机可以放置在有尚未升级到IGMPv3的主机的网络上。主机可能允许其IGMPv3成员记录被版本1成员报告或版本2成员报告抑制。

7.3. Multicast Router Behavior
7.3. 多播路由器行为
7.3.1. In the Presence of Older Version Queriers
7.3.1. 在旧版本的查询者面前

IGMPv3 routers may be placed on a network where at least one router on the network has not yet been upgraded to IGMPv3. The following requirements apply:

IGMPv3路由器可放置在网络上,其中网络上至少一个路由器尚未升级到IGMPv3。以下要求适用:

o If any older versions of IGMP are present on routers, the querier MUST use the lowest version of IGMP present on the network. This must be administratively assured; routers that desire to be compatible with IGMPv1 and IGMPv2 MUST have a configuration option to act in IGMPv1 or IGMPv2 compatibility modes. When in IGMPv1 mode, routers MUST send Periodic Queries with a Max Resp Code of 0 and truncated at the Group Address field (i.e., 8 bytes long), and MUST ignore Leave Group messages. They SHOULD also warn about receiving an IGMPv2 or IGMPv3 query, although such warnings MUST be rate-limited. When in IGMPv2 mode, routers MUST send Periodic Queries truncated at the Group Address field (i.e., 8 bytes long), and SHOULD also warn about receiving an IGMPv3 query (such warnings MUST be rate-limited). They also MUST fill in the Max Resp Time in the Max Resp Code field, i.e., the exponential algorithm described in section 4.1.1 is not used.

o 如果路由器上存在任何较早版本的IGMP,则查询者必须使用网络上存在的最低版本的IGMP。这必须在行政上得到保证;希望与IGMPv1和IGMPv2兼容的路由器必须具有配置选项,以在IGMPv1或IGMPv2兼容模式下运行。当处于IGMPv1模式时,路由器必须发送Max Resp Code为0且在组地址字段处截断的定期查询(即8字节长),并且必须忽略离开组消息。他们还应该就接收IGMPv2或IGMPv3查询发出警告,尽管此类警告必须有速率限制。当处于IGMPv2模式时,路由器必须发送在组地址字段截断的定期查询(即8字节长),并且还应就接收IGMPv3查询发出警告(此类警告必须是速率限制的)。他们还必须在最大响应代码字段中填写最大响应时间,即不使用第4.1.1节中描述的指数算法。

o If a router is not explicitly configured to use IGMPv1 or IGMPv2 and hears an IGMPv1 Query or IGMPv2 General Query, it SHOULD log a warning. These warnings MUST be rate-limited.

o 如果路由器未明确配置为使用IGMPv1或IGMPv2,并听到IGMPv1查询或IGMPv2常规查询,则应记录警告。这些警告必须是有限制的。

7.3.2. In the Presence of Older Version Group Members
7.3.2. 在旧版本组成员在场的情况下

IGMPv3 routers may be placed on a network where there are hosts that have not yet been upgraded to IGMPv3. In order to be compatible with older version hosts, IGMPv3 routers MUST operate in version 1 and version 2 compatibility modes. IGMPv3 routers keep a compatibility mode per group record. A group's compatibility mode is determined from the Group Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per group record and is dependent on the version of Membership Reports heard for that group as well as the Older Version Host Present timer for the group.

IGMPv3路由器可以放置在有尚未升级到IGMPv3的主机的网络上。为了与旧版本主机兼容,IGMPv3路由器必须在版本1和版本2兼容模式下运行。IGMPv3路由器保持每个组记录的兼容模式。组的兼容模式由组兼容模式变量确定,该变量可以处于三种状态之一:IGMPv1、IGMPv2或IGMPv3。此变量按组记录保存,并取决于为该组听到的成员资格报告的版本以及该组的旧版本主机当前计时器。

In order to switch gracefully between versions of IGMP, routers keep an IGMPv1 Host Present timer and an IGMPv2 Host Present timer per group record. The IGMPv1 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv1 Membership Report is received. The IGMPv2 Host Present timer is set to Older Version Host Present Timeout seconds whenever an IGMPv2 Membership Report is received.

为了在IGMP版本之间优雅地切换,路由器为每个组记录保留一个IGMPv1主机当前计时器和一个IGMPv2主机当前计时器。每当收到IGMPv1成员资格报告时,IGMPv1主机呈现计时器设置为旧版本主机呈现超时秒。每当收到IGMPv2成员资格报告时,IGMPv2主机呈现计时器设置为旧版本主机呈现超时秒。

The Group Compatibility Mode of a group record changes whenever an older version report (than the current compatibility mode) is heard or when certain timer conditions occur. When the IGMPv1 Host Present timer expires, a router switches to Group Compatibility mode of IGMPv2 if it has a running IGMPv2 Host Present timer. If it does not have a running IGMPv2 Host Present timer then it switches to Group Compatibility of IGMPv3. When the IGMPv2 Host Present timer expires and the IGMPv1 Host Present timer is not running, a router switches to Group Compatibility mode of IGMPv3. Note that when a group switches back to IGMPv3 mode, it takes some time to regain source-specific state information. Source-specific information will be learned during the next General Query, but sources that should be blocked will not be blocked until [Group Membership Interval] after that.

每当听到较旧版本的报告(而不是当前兼容模式)或出现某些计时器条件时,组记录的组兼容模式都会更改。当IGMPv1主机呈现计时器过期时,如果路由器有一个正在运行的IGMPv2主机呈现计时器,则路由器将切换到IGMPv2的组兼容模式。如果它没有正在运行的IGMPv2主机当前计时器,则会切换到IGMPv3的组兼容性。当IGMPv2主机存在计时器到期且IGMPv1主机存在计时器未运行时,路由器切换到IGMPv3的组兼容模式。请注意,当组切换回IGMPv3模式时,需要一些时间才能恢复源特定的状态信息。源特定信息将在下一次常规查询中学习,但应阻止的源将不会被阻止,直到在此之后的[组成员资格间隔]。

The Group Compatibility Mode variable is based on whether an older version report was heard in the last Older Version Host Present Timeout seconds. The Group Compatibility Mode is set depending on the following:

Group Compatibility Mode变量基于上一个旧版本主机当前超时秒中是否听到旧版本报告。根据以下内容设置组兼容性模式:

   Group Compatibility Mode      Timer State
   ------------------------      -----------
        
   Group Compatibility Mode      Timer State
   ------------------------      -----------
        

IGMPv3 (default) IGMPv2 Host Present not running and IGMPv1 Host Present not running

IGMPv3(默认)IGMPv2主机不在运行,IGMPv1主机不在运行

IGMPv2 IGMPv2 Host Present running and IGMPv1 Host Present not running

IGMPv2 IGMPv2主机存在正在运行,IGMPv1主机存在未运行

IGMPv1 IGMPv1 Host Present running

IGMPv1 IGMPv1主机当前正在运行

If a router receives a report which causes its older Host Present timers to be updated and correspondingly its compatibility mode, it SHOULD switch compatibility modes immediately.

如果路由器收到一个报告,该报告导致其较旧的主机当前计时器更新,并相应地更新其兼容模式,则它应立即切换兼容模式。

When Group Compatibility Mode is IGMPv3, a router acts using the IGMPv3 protocol for that group.

当组兼容模式为IGMPv3时,路由器使用该组的IGMPv3协议进行操作。

When Group Compatibility Mode is IGMPv2, a router internally translates the following IGMPv2 messages for that group to their IGMPv3 equivalents:

当组兼容模式为IGMPv2时,路由器会在内部将该组的以下IGMPv2消息转换为其IGMPv3等价物:

       IGMPv2 Message                IGMPv3 Equivalent
       --------------                -----------------
        
       IGMPv2 Message                IGMPv3 Equivalent
       --------------                -----------------
        
         Report                        IS_EX( {} )
        
         Report                        IS_EX( {} )
        
         Leave                         TO_IN( {} )
        
         Leave                         TO_IN( {} )
        

IGMPv3 BLOCK messages are ignored, as are source-lists in TO_EX() messages (i.e., any TO_EX() message is treated as TO_EX( {} )).

IGMPv3块消息被忽略,TO_EX()消息中的源列表也被忽略(即,任何TO_EX()消息都被视为TO_EX({}))。

When Group Compatibility Mode is IGMPv1, a router internally translates the following IGMPv1 and IGMPv2 messages for that group to their IGMPv3 equivalents:

当组兼容模式为IGMPv1时,路由器会在内部将该组的以下IGMPv1和IGMPv2消息转换为其IGMPv3等价物:

       IGMP Message                  IGMPv3 Equivalent
       ------------                  -----------------
        
       IGMP Message                  IGMPv3 Equivalent
       ------------                  -----------------
        
         v1 Report                      IS_EX( {} )
        
         v1 Report                      IS_EX( {} )
        
         v2 Report                      IS_EX( {} )
        
         v2 Report                      IS_EX( {} )
        

In addition to ignoring IGMPv3 BLOCK messages and source-lists in TO_EX() messages as in IGMPv2 Group Compatibility Mode, IGMPv2 Leave messages and IGMPv3 TO_IN() messages are also ignored.

除了在IGMPv2组兼容模式中忽略to_EX()消息中的IGMPv3阻止消息和源列表外,IGMPv2 Leave消息和IGMPv3 to_In()消息也被忽略。

8. List of Timers, Counters and Their Default Values
8. 计时器、计数器及其默认值的列表

Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all systems on a single link. Note that parentheses are used to group expressions to make the algebra clear.

大多数定时器都是可配置的。如果使用非默认设置,则它们必须在单个链路上的所有系统之间保持一致。请注意,括号用于对表达式进行分组,以使代数更加清晰。

8.1. Robustness Variable
8.1. 稳健性变量

The Robustness Variable allows tuning for the expected packet loss on a network. If a network is expected to be lossy, the Robustness Variable may be increased. IGMP is robust to (Robustness Variable - 1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2

鲁棒性变量允许调整网络上的预期数据包丢失。如果预期网络有损,则可增加鲁棒性变量。IGMP对(鲁棒性变量-1)数据包丢失具有鲁棒性。稳健性变量不得为零,也不应为一。默认值:2

8.2. Query Interval
8.2. 查询间隔

The Query Interval is the interval between General Queries sent by the Querier. Default: 125 seconds.

查询间隔是查询者发送的常规查询之间的间隔。默认值:125秒。

By varying the [Query Interval], an administrator may tune the number of IGMP messages on the network; larger values cause IGMP Queries to be sent less often.

通过改变[查询间隔],管理员可以调整网络上IGMP消息的数量;值越大,发送IGMP查询的频率越低。

8.3. Query Response Interval
8.3. 查询响应间隔

The Max Response Time used to calculate the Max Resp Code inserted into the periodic General Queries. Default: 100 (10 seconds)

用于计算插入定期常规查询的Max Resp代码的最大响应时间。默认值:100(10秒)

By varying the [Query Response Interval], an administrator may tune the burstiness of IGMP messages on the network; larger values make the traffic less bursty, as host responses are spread out over a larger interval. The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval].

通过改变[查询响应间隔],管理员可以调整网络上IGMP消息的突发性;值越大,流量的突发性就越小,因为主机响应分布的时间间隔越大。[Query Response Interval]表示的秒数必须小于[Query Interval]。

8.4. Group Membership Interval
8.4. 组成员间隔

The Group Membership Interval is the amount of time that must pass before a multicast router decides there are no more members of a group or a particular source on a network.

组成员资格间隔是多播路由器确定网络上没有组成员或特定源之前必须经过的时间量。

This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).

该值必须是((稳健性变量)乘以(查询间隔))加上(一个查询响应间隔)。

8.5. Other Querier Present Interval
8.5. 其他查询当前间隔

The Other Querier Present Interval is the length of time that must pass before a multicast router decides that there is no longer another multicast router which should be the querier. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval).

另一个查询器当前间隔是一个多播路由器决定不再存在另一个应作为查询器的多播路由器之前必须经过的时间长度。该值必须是((稳健性变量)乘以(查询间隔))加上(一个查询响应间隔的一半)。

8.6. Startup Query Interval
8.6. 启动查询间隔

The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default: 1/4 the Query Interval.

启动查询间隔是查询器在启动时发送的常规查询之间的间隔。默认值:查询间隔的1/4。

8.7. Startup Query Count
8.7. 启动查询计数

The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default: the Robustness Variable.

Startup Query Count是启动时发送的查询数,以启动查询间隔分隔。默认值:稳健性变量。

8.8. Last Member Query Interval
8.8. 最后成员查询间隔

The Last Member Query Interval is the Max Response Time used to calculate the Max Resp Code inserted into Group-Specific Queries sent in response to Leave Group messages. It is also the Max Response Time used in calculating the Max Resp Code for Group-and-Source-Specific Query messages. Default: 10 (1 second)

最后一个成员查询间隔是最大响应时间,用于计算为响应离开组消息而发送的组特定查询中插入的最大响应代码。它也是用于计算组和源特定查询消息的最大响应代码的最大响应时间。默认值:10(1秒)

Note that for values of LMQI greater than 12.8 seconds, a limited set of values can be represented, corresponding to sequential values of Max Resp Code. When converting a configured time to a Max Resp Code value, it is recommended to use the exact value if possible, or the next lower value if the requested value is not exactly representable.

请注意,对于大于12.8秒的LMQI值,可以表示一组有限的值,对应于Max Resp Code的顺序值。将配置的时间转换为最大响应代码值时,如果可能,建议使用准确的值,如果请求的值不能准确表示,建议使用下一个较低的值。

This value may be tuned to modify the "leave latency" of the network. A reduced value results in reduced time to detect the loss of the last member of a group or source.

可以调整此值以修改网络的“离开延迟”。减少的值会减少检测组或源的最后一个成员丢失的时间。

8.9. Last Member Query Count
8.9. 上次成员查询计数

The Last Member Query Count is the number of Group-Specific Queries sent before the router assumes there are no local members. The Last Member Query Count is also the number of Group-and-Source-Specific Queries sent before the router assumes there are no listeners for a particular source. Default: the Robustness Variable.

Last Member Query Count是路由器假定没有本地成员之前发送的特定于组的查询数。最后一个成员查询计数也是在路由器假定特定源没有侦听器之前发送的组和源特定查询数。默认值:稳健性变量。

8.10. Last Member Query Time
8.10. 上次成员查询时间

The Last Member Query Time is the time value represented by the Last Member Query Interval, multiplied by the Last Member Query Count. It is not a tunable value, but may be tuned by changing its components.

最后一个成员查询时间是由最后一个成员查询间隔乘以最后一个成员查询计数表示的时间值。它不是一个可调值,但可以通过更改其组件进行调整。

8.11. Unsolicited Report Interval
8.11. 主动报告间隔

The Unsolicited Report Interval is the time between repetitions of a host's initial report of membership in a group. Default: 1 second.

主动报告时间间隔是指主机重复首次报告组成员资格之间的时间间隔。默认值:1秒。

8.12. Older Version Querier Present Timeout
8.12. 旧版本查询器当前超时

The Older Version Querier Interval is the time-out for transitioning a host back to IGMPv3 mode once an older version query is heard. When an older version query is received, hosts set their Older Version Querier Present Timer to Older Version Querier Interval.

旧版本查询器间隔是在听到旧版本查询后将主机转换回IGMPv3模式的超时时间。收到旧版本查询时,主机将其旧版本查询器当前计时器设置为旧版本查询器间隔。

This value MUST be ((the Robustness Variable) times (the Query Interval in the last Query received)) plus (one Query Response Interval).

此值必须是((稳健性变量)乘以(上次收到的查询中的查询间隔))加上(一个查询响应间隔)。

8.13. Older Host Present Interval
8.13. 较老的宿主出现间隔

The Older Host Present Interval is the time-out for transitioning a group back to IGMPv3 mode once an older version report is sent for that group. When an older version report is received, routers set their Older Host Present Timer to Older Host Present Interval.

较旧的主机存在时间间隔是为组发送较旧版本报告后,将组转换回IGMPv3模式的超时时间。当收到旧版本报告时,路由器将其旧主机呈现计时器设置为旧主机呈现间隔。

This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).

该值必须是((稳健性变量)乘以(查询间隔))加上(一个查询响应间隔)。

8.14. Configuring Timers
8.14. 配置计时器

This section is meant to provide advice to network administrators on how to tune these settings to their network. Ambitious router implementations might tune these settings dynamically based upon changing characteristics of the network.

本节旨在向网络管理员提供有关如何将这些设置调整到其网络的建议。雄心勃勃的路由器实现可能会根据不断变化的网络特征动态调整这些设置。

8.14.1. Robustness Variable
8.14.1. 稳健性变量

The Robustness Variable tunes IGMP to expected losses on a link. IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if the Robustness Variable is set to the default value of 2, IGMPv3 is robust to a single packet loss but may operate imperfectly if more

鲁棒性变量将IGMP调整为链路上的预期损耗。IGMPv3对(稳健性变量-1)数据包丢失具有稳健性,例如,如果稳健性变量设置为默认值2,则IGMPv3对单个数据包丢失具有稳健性,但如果超过该值,则IGMPv3可能运行不完全

losses occur. On lossy subnetworks, the Robustness Variable should be increased to allow for the expected level of packet loss. However, increasing the Robustness Variable increases the leave latency of the subnetwork. (The leave latency is the time between when the last member stops listening to a source or group and when the traffic stops flowing.)

发生损失。在有损子网上,应增加稳健性变量,以考虑预期的数据包丢失水平。但是,增加鲁棒性变量会增加子网络的离开延迟。(离开延迟是最后一个成员停止侦听源或组与流量停止流动之间的时间。)

8.14.2. Query Interval
8.14.2. 查询间隔

The overall level of periodic IGMP traffic is inversely proportional to the Query Interval. A longer Query Interval results in a lower overall level of IGMP traffic. The Query Interval MUST be equal to or longer than the Max Response Time inserted in General Query messages.

周期性IGMP流量的总体水平与查询间隔成反比。查询间隔越长,IGMP流量的总体水平越低。查询间隔必须等于或大于在常规查询消息中插入的最大响应时间。

8.14.3. Max Response Time
8.14.3. 最大响应时间

The burstiness of IGMP traffic is inversely proportional to the Max Response Time. A longer Max Response Time will spread Report messages over a longer interval. However, a longer Max Response Time in Group-Specific and Source-and-Group-Specific Queries extends the leave latency. (The leave latency is the time between when the last member stops listening to a source or group and when the traffic stops flowing.) The expected rate of Report messages can be calculated by dividing the expected number of Reporters by the Max Response Time. The Max Response Time may be dynamically calculated per Query by using the expected number of Reporters for that Query as follows:

IGMP流量的突发性与最大响应时间成反比。较长的最大响应时间将在较长的时间间隔内传播报告消息。但是,特定于组以及特定于源和组的查询中较长的最大响应时间会延长离开延迟。(离开延迟是最后一个成员停止收听源或组与流量停止流动之间的时间。)报告消息的预期速率可以通过将预期报告者数量除以最大响应时间来计算。每个查询的最大响应时间可通过使用该查询的预期报告者数量动态计算,如下所示:

      Query Type            Expected number of Reporters
      ----------            ----------------------------
        
      Query Type            Expected number of Reporters
      ----------            ----------------------------
        

General Query All systems on subnetwork

通用查询子网上的所有系统

Group-Specific Query All systems that had expressed interest in the group on the subnetwork

特定于组的查询表示对子网络上的组感兴趣的所有系统

Source-and-Group- All systems on the subnetwork that had Specific Query expressed interest in the source and group

源和组-子网络上具有特定查询的所有系统都表示对源和组感兴趣

A router is not required to calculate these populations or tune the Max Response Time dynamically; these are simply guidelines.

路由器不需要计算这些总体或动态调整最大响应时间;这些只是指导方针。

9. Security Considerations
9. 安全考虑

We consider the ramifications of a forged message of each type, and describe the usage of IPSEC AH to authenticate messages if desired.

我们考虑每种类型的伪造消息的后果,并描述IPSec AH在需要时对消息进行认证的用法。

9.1. Query Message
9.1. 查询消息

A forged Query message from a machine with a lower IP address than the current Querier will cause Querier duties to be assigned to the forger. If the forger then sends no more Query messages, other routers' Other Querier Present timer will time out and one will resume the role of Querier. During this time, if the forger ignores Leave Messages, traffic might flow to groups with no members for up to [Group Membership Interval].

来自IP地址低于当前查询者的计算机的伪造查询消息将导致将查询者职责分配给伪造者。如果伪造者不再发送查询消息,其他路由器的其他查询器当前计时器将超时,其中一个将恢复查询器的角色。在此期间,如果伪造者忽略离开消息,流量可能会流向在[Group Membership Interval]内没有成员的组。

A DoS attack on a host could be staged through forged Group-and-Source-Specific Queries. The attacker can find out about membership of a specific host with a general query. After that it could send a large number of Group-and-Source-Specific queries, each with a large source list and the Maximum Response Time set to a large value. The host will have to store and maintain the sources specified in all of those queries for as long as it takes to send the delayed response. This would consume both memory and CPU cycles in order to augment the recorded sources with the source lists included in the successive queries.

对主机的DoS攻击可以通过伪造的组和源特定查询进行。攻击者可以通过常规查询了解特定主机的成员资格。之后,它可以发送大量特定于组和源的查询,每个查询都有一个较大的源列表,并且最大响应时间设置为一个较大的值。只要发送延迟响应,主机就必须存储和维护所有这些查询中指定的源。这将消耗内存和CPU周期,以便使用后续查询中包含的源列表来增加记录的源。

To protect against such a DoS attack, a host stack implementation could restrict the number of Group-and-Source-Specific Queries per group membership within this interval, and/or record only a limited number of sources.

为了防止此类DoS攻击,主机堆栈实现可以在此间隔内限制每个组成员的组和源特定查询的数量,和/或只记录有限数量的源。

Forged Query messages from the local network can be easily traced. There are three measures necessary to defend against externally forged Queries:

可以很容易地追踪来自本地网络的伪造查询消息。针对外部伪造的查询,需要采取三种措施:

o Routers SHOULD NOT forward Queries. This is easier for a router to accomplish if the Query carries the Router-Alert option.

o 路由器不应转发查询。如果查询带有路由器警报选项,则路由器更容易完成此操作。

o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert option.

o 主机应忽略没有路由器警报选项的v2或v3查询。

o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a multicast address other than 224.0.0.1, the all-systems address.

o 主机应忽略发送到除224.0.0.1(所有系统地址)之外的多播地址的v1、v2或v3常规查询。

9.2. Current-State Report messages
9.2. 当前状态报告消息

A forged Report message may cause multicast routers to think there are members of a group on a network when there are not. Forged Report messages from the local network are meaningless, since joining a group on a host is generally an unprivileged operation, so a local user may trivially gain the same result without forging any messages. Forged Report messages from external sources are more troublesome; there are two defenses against externally forged Reports:

伪造的报告消息可能会导致多播路由器认为网络上有组成员,而实际上没有。来自本地网络的伪造报告消息是没有意义的,因为加入主机上的组通常是一种不受限制的操作,因此本地用户可能在不伪造任何消息的情况下获得相同的结果。来自外部来源的伪造报告消息更麻烦;针对外部伪造的报告,有两种防御措施:

o Ignore the Report if you cannot identify the source address of the packet as belonging to a network assigned to the interface on which the packet was received. This solution means that Reports sent by mobile hosts without addresses on the local network will be ignored. Report messages with a source address of 0.0.0.0 SHOULD be accepted on any interface.

o 如果无法将数据包的源地址标识为属于分配给接收数据包的接口的网络,请忽略该报告。此解决方案意味着本地网络上没有地址的移动主机发送的报告将被忽略。应在任何接口上接受源地址为0.0.0.0的报告消息。

o Ignore Report messages without Router Alert options [RFC-2113], and require that routers not forward Report messages. (The requirement is not a requirement of generalized filtering in the forwarding path, since the packets already have Router Alert options in them.) This solution breaks backwards compatibility with implementations of IGMPv1 or earlier versions of IGMPv2 which did not require Router Alert.

o 忽略没有路由器警报选项的报告消息[RFC-2113],并要求路由器不转发报告消息。(该要求不是转发路径中的通用过滤要求,因为数据包中已经有路由器警报选项。)该解决方案打破了与IGMPv1或IGMPv2早期版本(不需要路由器警报)实现的向后兼容性。

A forged Version 1 Report Message may put a router into "version 1 members present" state for a particular group, meaning that the router will ignore Leave messages. This can cause traffic to flow to groups with no members for up to [Group Membership Interval]. This can be solved by providing routers with a configuration switch to ignore Version 1 messages completely. This breaks automatic compatibility with Version 1 hosts, so should only be used in situations where "fast leave" is critical.

伪造的版本1报告消息可能会将路由器置于特定组的“版本1成员存在”状态,这意味着路由器将忽略离开消息。这可能会导致流量流向在[Group Membership Interval]内没有成员的组。这可以通过为路由器提供配置开关来完全忽略版本1消息来解决。这会破坏与版本1主机的自动兼容性,因此仅应在“快速离开”至关重要的情况下使用。

A forged Version 2 Report Message may put a router into "version 2 members present" state for a particular group, meaning that the router will ignore IGMPv3 source-specific state messages. This can cause traffic to flow from unwanted sources for up to [Group Membership Interval]. This can be solved by providing routers with a configuration switch to ignore Version 2 messages completely. This breaks automatic compatibility with Version 2 hosts, so should only be used in situations where source include and exclude is critical.

伪造的版本2报告消息可能会将路由器置于特定组的“版本2成员存在”状态,这意味着路由器将忽略IGMPv3源特定状态消息。这会导致流量从不需要的源流出,持续时间可达[组成员资格间隔]。这可以通过为路由器提供配置开关来完全忽略版本2消息来解决。这破坏了与版本2主机的自动兼容性,因此仅应在源包含和排除非常重要的情况下使用。

9.3. State-Change Report Messages
9.3. 状态更改报告消息

A forged State-Change Report message will cause the Querier to send out Group-Specific or Source-and-Group-Specific Queries for the group in question. This causes extra processing on each router and on each member of the group, but can not cause loss of desired traffic. There are two defenses against externally forged State-Change Report messages:

伪造的状态更改报告消息将导致查询者发送有关组的特定于组或特定于源和组的查询。这会在每个路由器和组的每个成员上造成额外的处理,但不会造成所需流量的丢失。针对外部伪造的状态更改报告消息,有两种防御措施:

o Ignore the State-Change Report message if you cannot identify the source address of the packet as belonging to a subnet assigned to the interface on which the packet was received. This solution means that State-Change Report messages sent by mobile hosts without addresses on the local subnet will be ignored. State-Change Report messages with a source address of 0.0.0.0 SHOULD be accepted on any interface.

o 如果无法将数据包的源地址标识为属于分配给接收数据包的接口的子网,请忽略状态更改报告消息。此解决方案意味着将忽略本地子网上没有地址的移动主机发送的状态更改报告消息。应在任何接口上接受源地址为0.0.0.0的状态更改报告消息。

o Ignore State-Change Report messages without Router Alert options [RFC-2113], and require that routers not forward State-Change Report messages. (The requirement is not a requirement of generalized filtering in the forwarding path, since the packets already have Router Alert options in them.)

o 忽略没有路由器警报选项的状态更改报告消息[RFC-2113],并要求路由器不转发状态更改报告消息。(该要求不是转发路径中的通用过滤要求,因为数据包中已经有路由器警报选项。)

9.4. IPSEC Usage
9.4. IPSEC使用

In addition to these measures, IPSEC in Authentication Header mode [AH] may be used to protect against remote attacks by ensuring that IGMPv3 messages came from a system on the LAN (or, more specifically, a system with the proper key). When using IPSEC, the messages sent to 224.0.0.1 and 224.0.0.22 should be authenticated using AH. When keying, there are two possibilities:

除了这些措施外,身份验证头模式[AH]中的IPSEC还可用于通过确保IGMPv3消息来自LAN上的系统(或者更具体地说,来自具有适当密钥的系统)来防止远程攻击。使用IPSEC时,发送到224.0.0.1和224.0.0.22的消息应使用AH进行身份验证。设置关键帧时,有两种可能:

1. Use a symmetric signature algorithm with a single key for the LAN (or a key for each group). This allows validation that a packet was sent by a system with the key. This has the limitation that any system with the key can forge a message; it is not possible to authenticate the individual sender precisely. It also requires disabling IPSec's Replay Protection.

1. 使用对称签名算法,为LAN使用一个密钥(或为每个组使用一个密钥)。这允许验证数据包是由具有密钥的系统发送的。这有一个限制,即任何具有密钥的系统都可以伪造消息;不可能精确地对单个发送者进行身份验证。它还需要禁用IPSec的重播保护。

2. When appropriate key management standards have been developed, use an asymmetric signature algorithm. All systems need to know the public key of all routers, and all routers need to know the public key of all systems. This requires a large amount of key management but has the advantage that senders can be authenticated individually so e.g., a host cannot forge a message that only routers should be allowed to send.

2. 制定了适当的密钥管理标准后,使用非对称签名算法。所有系统都需要知道所有路由器的公钥,所有路由器都需要知道所有系统的公钥。这需要大量的密钥管理,但其优点是发送者可以单独进行身份验证,例如,主机不能伪造只允许路由器发送的消息。

This solution only directly applies to Query and Leave messages in IGMPv1 and IGMPv2, since Reports are sent to the group being reported and it is not feasible to agree on a key for host-to-router communication for arbitrary multicast groups.

此解决方案仅直接适用于IGMPv1和IGMPv2中的查询和留言,因为报告会发送到被报告的组,并且不可能为任意多播组商定主机到路由器通信的密钥。

10. IANA Considerations
10. IANA考虑

All IGMP types described in this document are already assigned in [IANA-REG].

本文件中描述的所有IGMP类型已在[IANA-REG]中分配。

11. Acknowledgments
11. 致谢

We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert, Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark Handley, Bob Quinn, Michael Speer, Dave Thaler and Rolland Vida for comments and suggestions on this document.

我们要感谢Ran Atkinson、Luis Costa、Toerless Eckert、Dino Farinaci、Serge Fdida、Wilbert de Graaf、Sumit Gupta、Mark Handley、Bob Quinn、Michael Speer、Dave Thaler和Rolland Vida对本文件的评论和建议。

Portions of the text of this document were copied from [RFC-1112] and [RFC-2236].

本文件部分文本抄袭自[RFC-1112]和[RFC-2236]。

12. Normative References
12. 规范性引用文件

[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[AH]Kent,S.和R.Atkinson,“IP认证头”,RFC 2402,1998年11月。

   [IANA-REG]   http://www.iana.org/assignments/igmp-type-numbers
        
   [IANA-REG]   http://www.iana.org/assignments/igmp-type-numbers
        

[RFC-1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

[RFC-1112]Deering,S.,“IP多播的主机扩展”,STD 5,RFC 1112,1989年8月。

[RFC-2113] Katz, D., "IP Router Alert Option," RFC 2113, February, 1997.

[RFC-2113]Katz,D.,“IP路由器警报选项”,RFC 21131997年2月。

[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC-2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.

[RFC-2236]Fenner,W.,“互联网组管理协议,第2版”,RFC 2236,1997年11月。

[RFC-3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, February 2002.

[RFC-3228]Fenner,B.,“IPv4互联网组管理协议(IGMP)的IANA注意事项”,BCP 57,RFC 3228,2002年2月。

13. Informative References
13. 资料性引用

[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.

[RFC-1071]Braden,R.,Borman,D.和C.Partridge,“计算互联网校验和”,RFC 10711988年9月。

[FILTER-API] Thaler, D., B. Fenner, and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress.

[FILTER-API]Thaler,D.,B.Fenner和B.Quinn,“多播源过滤器的套接字接口扩展”,正在进行中。

[SSM] Bhattacharyya, S., et. al., "An Overview of Source-Specific Multicast (SSM)", Work in Progress.

[SSM]Bhattacharyya,S.,等人,“源特定多播(SSM)概述”,正在进行的工作。

[MLD] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

[MLD]Deering,S.,Fenner,W.和B.Haberman,“IPv6的多播侦听器发现(MLD)”,RFC 2710,1999年10月。

[MLDV2] Vida, R., L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, and B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Work in Progress.

[MLDV2]Vida,R.,L.Costa,S.Fdida,S.Deering,B.Fenner,I.Kouvelas和B.Haberman,“IPv6多播侦听器发现版本2(MLDV2)”,正在进行中。

Appendix A. Design Rationale
附录A.设计原理
A.1 The Need for State-Change Messages
A.1状态更改消息的需要

IGMPv3 specifies two types of Membership Reports: Current-State and State Change. This section describes the rationale for the need for both these types of Reports.

IGMPv3指定两种类型的成员资格报告:当前状态和状态更改。本节描述了需要这两种类型报告的理由。

Routers need to distinguish Membership Reports that were sent in response to Queries from those that were sent as a result of a change in interface state. Membership reports that are sent in response to Membership Queries are used mainly to refresh the existing state at the router; they typically do not cause transitions in state at the router. Membership Reports that are sent in response to changes in interface state require the router to take some action in response to the received report (see Section 6.4).

路由器需要区分响应查询而发送的成员资格报告和由于接口状态更改而发送的成员资格报告。响应成员资格查询而发送的成员资格报告主要用于刷新路由器上的现有状态;它们通常不会导致路由器的状态转换。为响应接口状态的变化而发送的成员资格报告要求路由器对收到的报告采取一些措施(参见第6.4节)。

The inability to distinguish between the two types of reports would force a router to treat all Membership Reports as potential changes in state and could result in increased processing at the router as well as an increase in IGMP traffic on the network.

无法区分这两种类型的报告将迫使路由器将所有成员资格报告视为状态的潜在变化,并可能导致路由器的处理增加以及网络上IGMP流量的增加。

A.2 Host Suppression
A.2主机抑制

In IGMPv1 and IGMPv2, a host would cancel sending a pending membership reports if a similar report was observed from another member on the network. In IGMPv3, this suppression of host membership reports has been removed. The following points explain the reasons behind this decision.

在IGMPv1和IGMPv2中,如果从网络上的另一个成员处观察到类似的报告,主机将取消发送挂起的成员报告。在IGMPv3中,已删除对主机成员资格报告的这种抑制。以下几点解释了这一决定背后的原因。

1. Routers may want to track per-host membership status on an interface. This allows routers to implement fast leaves (e.g., for layered multicast congestion control schemes) as well as track membership status for possible accounting purposes.

1. 路由器可能希望跟踪接口上每台主机的成员身份状态。这允许路由器实现快速离开(例如,对于分层多播拥塞控制方案)以及跟踪成员状态,以实现可能的计费目的。

2. Membership Report suppression does not work well on bridged LANs. Many bridges and Layer2/Layer3 switches that implement IGMP snooping do not forward IGMP messages across LAN segments in order to prevent membership report suppression. Removing membership report suppression eases the job of these IGMP snooping devices.

2. 成员报告抑制在桥接LAN上无法正常工作。许多实现IGMP窥探的网桥和第二层/第三层交换机不会跨LAN网段转发IGMP消息,以防止成员报告被抑制。删除成员报告抑制可简化这些IGMP窥探设备的工作。

3. By eliminating membership report suppression, hosts have fewer messages to process; this leads to a simpler state machine implementation.

3. 通过消除成员报告抑制,主机要处理的消息更少;这将导致更简单的状态机实现。

4. In IGMPv3, a single membership report now bundles multiple multicast group records to decrease the number of packets sent. In comparison, the previous versions of IGMP required that each multicast group be reported in a separate message.

4. 在IGMPv3中,单个成员报告现在捆绑多个多播组记录以减少发送的数据包数量。相比之下,以前版本的IGMP要求在单独的消息中报告每个多播组。

A.3 Switching Router Filter Modes from EXCLUDE to INCLUDE
A.3将路由器过滤模式从排除切换到包括

If there exist hosts in both EXCLUDE and INCLUDE modes for a single multicast group in a network, the router must be in EXCLUDE mode as well (see section 6.2.1). In EXCLUDE mode, a router forwards traffic from all sources unless that source exists in the exclusion source list. If all hosts in EXCLUDE mode cease to exist, it would be desirable for the router to switch back to INCLUDE mode seamlessly without interrupting the flow of traffic to existing receivers.

如果网络中的单个多播组存在处于排除模式和包括模式的主机,则路由器也必须处于排除模式(参见第6.2.1节)。在排除模式下,路由器转发来自所有源的流量,除非该源存在于排除源列表中。如果所有处于排除模式的主机都不存在,那么路由器最好无缝地切换回包括模式,而不中断到现有接收机的通信流。

One of the ways to accomplish this is for routers to keep track of all sources desired by hosts that are in INCLUDE mode even though the router itself is in EXCLUDE mode. If the group timer now expires in EXCLUDE mode, it implies that there are no hosts in EXCLUDE mode on the network (otherwise a membership report from that host would have refreshed the group timer). The router can then switch to INCLUDE mode seamlessly with the list of sources currently being forwarded in its source list.

实现这一点的方法之一是,路由器跟踪处于包含模式的主机所需的所有源,即使路由器本身处于排除模式。如果组计时器现在在排除模式下过期,则表示网络上没有处于排除模式的主机(否则来自该主机的成员资格报告将刷新组计时器)。然后路由器可以切换到包含模式,与当前在其源列表中转发的源列表无缝连接。

Appendix B. Summary of Changes from IGMPv2
附录B.IGMPv2变更汇总

While the main additional feature of IGMPv3 is the addition of source filtering, the following is a summary of other changes from RFC 2236.

虽然IGMPv3的主要附加功能是添加源过滤,但以下是RFC 2236的其他更改摘要。

o State is maintained as Group + List-of-Sources, not simply Group as in IGMPv2.

o 状态维护为组+源列表,而不是像IGMPv2中那样简单的组。

o Interoperability with IGMPv1 and IGMPv2 systems is defined as operations on the IGMPv3 state.

o 与IGMPv1和IGMPv2系统的互操作性定义为在IGMPv3状态下的操作。

o The IP Service Interface has changed to allow specification of source-lists.

o IP服务接口已更改,以允许指定源列表。

o The Querier includes its Robustness Variable and Query Interval in Query packets to allow synchronization of these variables on non-Queriers.

o 查询器在查询包中包含其健壮性变量和查询间隔,以允许在非查询器上同步这些变量。

o The Max Response Time in Query messages has an exponential range, changing the maximum from 25.5 seconds to about 53 minutes, for use on links with huge numbers of systems.

o 查询消息中的最大响应时间具有指数范围,最大响应时间从25.5秒更改为约53分钟,用于具有大量系统的链接。

o Hosts retransmit state-change messages for increased robustness.

o 主机重新传输状态更改消息以增强健壮性。

o Additional data sections are defined to allow later extensions.

o 定义了其他数据节以允许以后的扩展。

o Report packets are sent to 224.0.0.22, to assist layer-2 switches in "snooping".

o 报告数据包被发送到224.0.0.22,以帮助第二层交换机进行“窥探”。

o Report packets can contain multiple group records, to allow reporting of full current state using fewer packets.

o 报告数据包可以包含多个组记录,以允许使用较少的数据包报告完整的当前状态。

o Hosts no longer perform suppression, to simplify implementations and permit explicit membership tracking.

o 主机不再执行抑制,以简化实现并允许显式成员身份跟踪。

o New Suppress Router-Side Processing (S) flag in Query messages fixes robustness issues which were also present in IGMPv2.

o 查询消息中新的抑制路由器端处理标志修复了IGMPv2中也存在的健壮性问题。

Authors' Addresses

作者地址

Brad Cain Cereva Networks

布拉德·凯恩·塞雷瓦网络公司

Steve Deering Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134-1706

Steve Deering Cisco Systems,Inc.位于加利福尼亚州圣何塞塔斯曼大道170号,邮编95134-1706

   Phone: +1-408-527-8213
   EMail: deering@cisco.com
        
   Phone: +1-408-527-8213
   EMail: deering@cisco.com
        

Bill Fenner AT&T Labs - Research 75 Willow Rd. Menlo Park, CA 94025

比尔·芬纳AT&T实验室-加利福尼亚州门罗公园威洛路75号研究室,邮编94025

   Phone: +1-650-330-7893
   EMail: fenner@research.att.com
        
   Phone: +1-650-330-7893
   EMail: fenner@research.att.com
        

Isidor Kouvelas Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134-1706

伊西多·库维拉斯思科系统公司,位于加利福尼亚州圣何塞塔斯曼大道170号,邮编95134-1706

   Phone: +1-408-525-0727
   EMail: kouvelas@cisco.com
        
   Phone: +1-408-525-0727
   EMail: kouvelas@cisco.com
        

Ajit Thyagarajan Ericsson IP Infrastructure

Ajit Thyagarajan Ericsson IP基础设施

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。