Network Working Group I. Wu
Request for Comments: 3488 T. Eckert
Category: Informational Cisco Systems
February 2003
Network Working Group I. Wu
Request for Comments: 3488 T. Eckert
Category: Informational Cisco Systems
February 2003
Cisco Systems Router-port Group Management Protocol (RGMP)
思科系统路由器端口组管理协议（RGMP）
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.
本文档介绍路由器端口组管理协议（RGMP）。此协议由Cisco Systems开发，用于多播路由器和交换机之间，以限制交换机中的多播数据包转发到可能需要数据包的路由器。
RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.
RGMP设计用于多个高速路由器互连的主干交换网络。
The 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 BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
IGMP Snooping is a popular, but not well documented mechanism to restrict multicast traffic, in switched networks, to those ports that want to receive the multicast traffic. It dynamically establishes and terminates multicast group specific forwarding in switches that support this feature.
IGMP窥探是一种流行但没有很好文档记录的机制，用于将交换网络中的多播流量限制为希望接收多播流量的端口。它在支持此功能的交换机中动态建立和终止特定于多播组的转发。
The main limitation of IGMP Snooping is that it can only restrict multicast traffic onto switch ports where receiving hosts are connected directly or indirectly via other switches. IGMP Snooping can not restrict multicast traffic to ports where at least one multicast router is connected. It must instead flood multicast traffic to these ports. Snooping on IGMP messages alone is an intrinsic limitation. Through it, a switch can only learn which multicast flows are being requested by hosts. A switch can not learn through IGMP which traffic flows need to be received by router ports to be routed because routers do not report these flows via IGMP.
IGMP窥探的主要限制是，它只能将多播流量限制在接收主机通过其他交换机直接或间接连接的交换机端口上。IGMP侦听不能将多播流量限制到至少连接了一个多播路由器的端口。相反，它必须向这些端口发送大量多播通信。单独窥探IGMP消息是一个固有的限制。通过它，交换机只能了解主机正在请求哪些多播流。交换机无法通过IGMP了解路由路由器端口需要接收哪些流量，因为路由器不会通过IGMP报告这些流量。
In situations where multiple multicast routers are connected to a switched backbone, IGMP Snooping will not reduce multicast traffic load. Nor will it assist in increasing internal bandwidth through the use of switches in the network.
在多个多播路由器连接到交换主干网的情况下，IGMP侦听不会减少多播流量负载。它也不会通过在网络中使用交换机来帮助增加内部带宽。
In switched backbone networks or exchange points, where predominantly routers are connected with each other, a large amount of multicast traffic may lead to unexpected congestion. It also leads to more resource consumption in the routers because they must discard the unwanted multicast traffic.
在交换主干网或交换点中，主要路由器相互连接，大量多播流量可能导致意外拥塞。这也会导致路由器中更多的资源消耗，因为它们必须丢弃不需要的多播流量。
The RGMP protocol described in this document restricts multicast traffic to router ports. To effectively restrict traffic, it must be supported by both the switches and the routers in the network.
本文档中描述的RGMP协议将多播通信限制到路由器端口。为了有效地限制流量，网络中的交换机和路由器都必须支持它。
The RGMP message format resembles the IGMPv2 message format so that existing switches, capable of IGMP Snooping, can easily be enhanced with this feature. Its messages are encapsulated in IPv4 datagrams, with a protocol number of 2, the same as that of IGMP. All RGMP messages are sent with TTL 1, to destination address 224.0.0.25. This address has been assigned by IANA to carry messages from routers to switches [3].
RGMP消息格式类似于IGMPv2消息格式，因此可以使用此功能轻松增强能够进行IGMP侦听的现有交换机。其消息封装在IPv4数据报中，协议号为2，与IGMP相同。所有RGMP消息都使用TTL 1发送到目标地址224.0.0.25。IANA已分配此地址，用于将消息从路由器传送到交换机[3]。
RGMP is designed to work in conjunction with multicast routing protocols where explicit join/prune to the distribution tree is performed. PIM-SM [4] is an example of such a protocol.
RGMP设计用于与多播路由协议协同工作，其中对分发树执行显式连接/修剪。PIM-SM[4]就是这种协议的一个例子。
The RGMP protocol specifies operations only for IP version 4 multicast routing. IP version 6 is not considered.
RGMP协议仅为IP版本4多播路由指定操作。不考虑IP版本6。
To keep RGMP simple, efficient and easy to implement, it is designed for switches to expect RGMP messages from only one source per port. For this reason, RGMP only supports a single RGMP enabled router to be connected directly to a port of an RGMP enabled switch. Such a topology should be customary when connecting routers to backbone switches and thus not pose a limitation on the deployment of RGMP.
为了使RGMP保持简单、高效和易于实现，它设计用于交换机，使每个端口仅从一个源接收RGMP消息。因此，RGMP仅支持单个启用RGMP的路由器直接连接到启用RGMP的交换机的端口。当将路由器连接到主干交换机时，这种拓扑应该是习惯的，因此不会对RGMP的部署造成限制。
All RGMP messages have the following format:
所有RGMP消息的格式如下：
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The reserved field in the message MUST be transmitted as zeros and ignored on receipt.
消息中的保留字段必须作为零传输，并在收到时忽略。
There are four types of RGMP messages of concern to the router-switch interaction. The type codes are defined to be the highest values in an octet to avoid the re-use of already assigned IGMP type codes.
路由器-交换机交互涉及四种类型的RGMP消息。类型代码定义为八位字节中的最高值，以避免重复使用已分配的IGMP类型代码。
0xFF = Hello 0xFE = Bye 0xFD = Join a group 0xFC = Leave a group
0xFF=你好0xFE=再见0xFD=加入组0xFC=离开组
Unrecognized message types should be silently ignored.
无法识别的消息类型应被静默忽略。
Note:
注:
RGMP and the IANA assignment of address 224.0.0.25 for it predates RFC 3228 [9]. RGMP defines Type values which in RFC 3228 are assigned to protocol testing and experimentation. This is not an operational issue for RGMP itself because only RGMP packets use the IPv4 destination address 224.0.0.25. The Type values defined above are thus ONLY valid in conjunction with the RGMP destination address.
RGMP和地址224.0.0.25的IANA分配早于RFC 3228[9]。RGMP定义RFC 3228中分配给协议测试和实验的类型值。这不是RGMP本身的操作问题，因为只有RGMP数据包使用IPv4目标地址224.0.0.25。因此，上面定义的类型值仅与RGMP目标地址一起有效。
Checksum covers the RGMP message (the entire IPv4 payload). The algorithm and handling of checksum are the same as those for IGMP messages as described in RFC 3376 [5].
校验和覆盖RGMP消息（整个IPv4负载）。校验和的算法和处理与RFC 3376[5]中描述的IGMP消息的算法和处理相同。
In an RGMP Hello or Bye message, the group address field is set to zero.
在RGMP Hello或Bye消息中，组地址字段设置为零。
In an RGMP Join or Leave message, the group address field holds the IPv4 multicast group address of the group being joined or left.
在RGMP加入或离开消息中，组地址字段保存正在加入或离开的组的IPv4多播组地址。
RGMP messages are sent by routers to switches. The source IPv4 address of an RGMP packet is the sending interface IPv4 address of the originating router. The destination IPv4 address of an RGMP packet is 224.0.0.25. Switches supporting RGMP need to listen to packets to this group.
RGMP消息由路由器发送到交换机。RGMP数据包的源IPv4地址是发起路由器的发送接口IPv4地址。RGMP数据包的目标IPv4地址为224.0.0.25。支持RGMP的交换机需要侦听发送到此组的数据包。
Backbone switches use RGMP to learn which groups are desired at each of their ports. Multicast routers use RGMP to pass such information to the switches. Only routers send RGMP messages. They ignore received RGMP messages.
主干交换机使用RGMP来了解每个端口需要哪些组。多播路由器使用RGMP将这些信息传递给交换机。只有路由器发送RGMP消息。它们忽略收到的RGMP消息。
A Router enabled for RGMP on an interface periodically [Hello Interval] sends an RGMP Hello message to the attached network to indicate that it is RGMP enabled. When RGMP is disabled on a routers interface, it will send out an RGMP Bye message on that interface, indicating that it again wishes to receive IPv4 multicast traffic promiscuously from that interface.
在接口上为RGMP启用的路由器定期[Hello Interval]向连接的网络发送RGMP Hello消息，以指示其已启用RGMP。当在路由器接口上禁用RGMP时，它将在该接口上发送一条RGMP Bye消息，指示它再次希望从该接口杂乱无章地接收IPv4多播流量。
When an interface is RGMP enabled, a router sends an RGMP Join message out through this interface to each group that it wants to receive traffic for from the interface. The router needs to periodically [Join Interval] re-send an RGMP Join for a group to indicate its continued desire to receive multicast traffic.
当接口启用RGMP时，路由器通过该接口向它希望从接口接收流量的每个组发送RGMP加入消息。路由器需要周期性地[Join Interval]重新发送组的RGMP连接，以表明其继续希望接收多播流量。
Routers supporting RGMP MUST NOT send RGMP Join or Leave messages for groups 224.0.0.x (x=0...255), 224.0.1.39 and 224.0.1.40. The latter two are known as cisco-rp-announce and cisco-rp-discovery [3].
支持RGMP的路由器不得向组224.0.0.x（x=0…255）、224.0.1.39和224.0.1.40发送RGMP加入或离开消息。后两种被称为cisco rp公告和cisco rp发现[3]。
When a router no longer needs to receive traffic for a particular group, it sends an RGMP Leave message for the group. For robustness, the router MAY send more than one such message.
当路由器不再需要接收特定组的通信量时，它会为该组发送RGMP LEVE消息。为了健壮性，路由器可以发送多个这样的消息。
If IPv4 multicast packets for an undesired group are received at a router from a switch, the router MAY send a RGMP Leave message for that group to the switch. These messages are called data-triggered RGMP Leave messages and the router SHOULD rate-limit them. The router MAY suppress sending a data triggered RGMP Leave message if it has a desired group that has the same MAC destination address as the undesired group. (See RFC 1112 [6] for MAC ambiguity.) Such suppression of data triggered RGMP Leave messages SHOULD be configurable if supported.
如果路由器从交换机接收到不需要的组的IPv4多播数据包，路由器可能会向交换机发送该组的RGMP LEVE消息。这些消息称为数据触发的RGMP离开消息，路由器应该对它们进行速率限制。如果路由器具有与非期望组具有相同MAC目的地地址的期望组，则路由器可以抑制发送数据触发的RGMP离开消息。（参见RFC 1112[6]了解MAC模糊性。）如果支持，应可配置对数据触发的RGMP离开消息的抑制。
A switch enabled for RGMP on a network consumes RGMP messages received from ports of the network and processes them as described below. If enabled for RGMP, the switch must NOT forward/flood received RGMP messages out to other ports of the network.
为网络上的RGMP启用的交换机使用从网络端口接收的RGMP消息，并按如下所述进行处理。如果为RGMP启用，交换机不得将接收到的RGMP消息转发/泛洪发送到网络的其他端口。
RGMP on a switch operates on a per port basis, establishing per-group forwarding state on RGMP enabled ports. A port reverts into an RGMP enabled port upon receipt of an RGMP Hello message on the port, and a timer [5 * Hello Interval] is started. This timer is restarted by each RGMP Hello message arriving on the port. If this timer expires or if it is removed by the arrival of an RGMP Bye message, then the port reverts to its prior state of multicast traffic forwarding.
交换机上的RGMP基于每个端口运行，在启用RGMP的端口上建立每个组的转发状态。在端口上接收到RGMP Hello消息后，端口将恢复为启用RGMP的端口，并启动计时器[5*Hello Interval]。每个到达端口的RGMP Hello消息都会重新启动此计时器。如果此计时器过期或RGMP Bye消息到达时将其删除，则端口将恢复到其先前的多播流量转发状态。
Correct deployment of RGMP is one RGMP enabled router directly connected to a port on a switch that supports RGMP. The port on the switch MAY want to keep track of the IPv4 originator address of the RGMP Hello and Bye messages it receives on that port. In the event it receives multiple IPv4 originating addresses in RGMP messages on one port, the switch MAY generate an alert to notify the administrator. The switch MAY also have a configuration option that will allow for the operator to disable RGMP and have the switch fall back to flooding IPv4 multicast on that port, although this is a potentially dangerous option.
正确部署RGMP是指一个支持RGMP的路由器直接连接到支持RGMP的交换机上的端口。交换机上的端口可能希望跟踪它在该端口上接收的RGMP Hello和Bye消息的IPv4发起方地址。如果交换机在一个端口上的RGMP消息中接收到多个IPv4原始地址，则交换机可能会生成警报以通知管理员。交换机还可能有一个配置选项，允许操作员禁用RGMP，并使交换机退回到该端口上的泛洪IPv4多播，尽管这是一个潜在的危险选项。
By default, connecting two or more RGMP enabled routers to a switch port will cause intermittent black holing of IPv4 multicast traffic towards these routers. Black holing occurs when a RGMP Leave is received from one router while the other router is still joined.
默认情况下，将两个或多个启用RGMP的路由器连接到交换机端口将导致IPv4多播流量向这些路由器间歇性黑洞。当从一个路由器接收到RGMP离开，而另一个路由器仍然加入时，就会发生黑洞。
This malfunction is not only easily recognized by the actual users connected through the routers, but it also adheres to the principle that a failure situation causes less traffic than more. Reverting to flooding easily maintains the illusion that everything is working perfectly. The exception is that the traffic constraining benefits
这种故障不仅很容易被通过路由器连接的实际用户识别，而且还遵循了故障情况导致的流量小于流量的原则。回归洪水很容易保持一切都完美运转的错觉。例外情况是，流量限制带来的好处
of RGMP are not realized. This suggests that congestion happens at a much later time than the misconfiguration and can then not easily be correlated with the cause anymore.
没有实现RGMP的功能。这表明阻塞发生的时间比错误配置晚得多，因此不容易再与原因联系起来。
Because routers supporting RGMP are not required to send RGMP Join or Leave messages for groups 224.0.0.x (x=0...255), 224.0.1.39 and 224.0.1.40, RGMP enabled ports always need to receive traffic for these groups. Traffic for other groups is initially not forwarded to an RGMP enabled port.
由于支持RGMP的路由器不需要为组224.0.0.x（x=0…255）、224.0.1.39和224.0.1.40发送RGMP加入或离开消息，因此启用RGMP的端口始终需要接收这些组的流量。其他组的通信最初不会转发到启用RGMP的端口。
RGMP Join and Leave messages are accepted if they arrive on an RGMP enabled port, otherwise they will be discarded. Upon acceptance of an RGMP Join message, the switch MUST start forwarding traffic for the group to the port. Upon acceptance of an RGMP Leave message, the switch SHOULD stop forwarding traffic for the group to that port. The switch's ability to stop forwarding traffic for a group may be limited, for example, because of destination MAC based forwarding in the switch. Therefore, it is necessary for the switch to always forward traffic for all MAC-ambiguous IPv4 multicast groups (see [6] for MAC-ambiguity).
如果RGMP加入和离开消息到达启用RGMP的端口，则它们将被接受，否则它们将被丢弃。在接受RGMP加入消息后，交换机必须开始将组的流量转发到端口。在接受RGMP离开消息后，交换机应停止将组的流量转发到该端口。例如，由于交换机中基于目的地MAC的转发，交换机停止为组转发业务的能力可能受到限制。因此，交换机必须始终转发所有MAC不明确IPv4多播组的流量（有关MAC不明确性，请参阅[6]）。
To stop forwarding of traffic to a group in the event of lost RGMP Leave message(s), a switch MAY time out RGMP forwarding state on a port for a group [5 * Join Interval] after the last RGMP Join for that group has been received on the port.
若要在丢失RGMP离开消息的情况下停止向组转发通信量，交换机可在端口上接收到该组的最后一次RGMP加入后，将端口上的RGMP转发状态超时[5*加入间隔]。
Without any layer 2 IPv4 multicast filtering methods running, a switch needs to flood multicast traffic to all ports. If a switch does actually run one or more mechanisms beside RGMP to filter IPv4 multicast traffic, such as IGMP snooping [10], then by default it will not flood IPv4 multicast traffic to all ports anymore. Instead, the switch will try to determine which ports still needs to receive all IPv4 multicast traffic by default, and which ports do not.
如果不运行任何第2层IPv4多播过滤方法，交换机需要将多播流量大量传输到所有端口。如果交换机确实运行RGMP旁边的一个或多个机制来过滤IPv4多播流量，例如IGMP侦听[10]，那么默认情况下，它将不再向所有端口大量发送IPv4多播流量。相反，交换机将尝试确定默认情况下哪些端口仍然需要接收所有IPv4多播流量，哪些端口不需要。
Compliance with this specification requires that a switch MUST be able to elect a port for flooding through the presence of PIM Hello messages [4] arriving from the port and also through a manual configuration option. In addition, the switch SHOULD recognize a port connected to a router by other appropriate protocol packets or dedicated IPv4 multicast router discovery mechanisms such as MRDISC [11]. The manual configuration is required to support routers not supporting PIM or other methods recognized by the switch.
符合本规范要求交换机必须能够通过存在从端口到达的PIM Hello消息[4]以及手动配置选项来选择用于泛洪的端口。此外，交换机应识别通过其他适当的协议包或专用IPv4多播路由器发现机制（如MRDISC）连接到路由器的端口[11]。需要手动配置来支持不支持PIM或交换机识别的其他方法的路由器。
Further mechanisms for IPv4 multicast traffic restriction may also be used on RGMP enabled ports. In this case, forwarding for a group on the port must be established if either mechanism requires it, and it must only be removed if no mechanism requires it anymore.
还可以在启用RGMP的端口上使用IPv4多播流量限制的其他机制。在这种情况下，如果任何一种机制需要，则必须为端口上的组建立转发，并且只有当不再有任何机制需要时，才必须将其删除。
To be simple to implement on switches and resilient in face of potential layer 2 network topology changes, RGMP does not specify how to restrict multicast traffic on links connecting switches amongst each other. With just RGMP being used, multicast traffic will thus be flooded on inter-switch links within a network if at least one router is connected to each of the switches.
为了在交换机上实现简单，并且在面对潜在的第2层网络拓扑变化时具有弹性，RGMP没有指定如何限制连接交换机之间的链路上的多播流量。只要使用RGMP，如果至少有一个路由器连接到每个交换机，则网络内的交换机间链路上的多播流量就会被淹没。
This happens implicitly because the switch will not flood/forward received RGMP messages out to the inter-switch link and thus the switch on the other end will only recognize the port as a router port via the PIM Hello messages flooded by the switches. Manual configuration for inter-switch links may be required if non-PIM routers are being used, depending on the other capabilities of the switch.
这是因为交换机不会将接收到的RGMP消息泛洪/转发到交换机间链路，因此另一端的交换机只能通过交换机泛洪的PIM Hello消息将端口识别为路由器端口。如果正在使用非PIM路由器，则可能需要手动配置交换机间链路，具体取决于交换机的其他功能。
If appropriate, a switch can send out RGMP messages on ports to make it look like an RGMP enabled router to a potential switch at the other end of the link. This would constrain IPv4 multicast traffic between switches, but this type of "RGMP Spoofing" by the switch is outside the scope of this specification.
如果合适，交换机可以在端口上发送RGMP消息，使其看起来像是链路另一端的潜在交换机的启用RGMP的路由器。这将限制交换机之间的IPv4多播通信，但交换机的这种类型的“RGMP欺骗”超出了本规范的范围。
Since RGMP messages received at a switch only affect the state of their ingress ports, the traffic restriction is applied there only. RGMP-incapable routers will receive multicast traffic for all multicast groups.
由于在交换机上接收的RGMP消息仅影响其入口端口的状态，因此仅在那里应用流量限制。RGMP路由器将接收所有多播组的多播流量。
One result of the simplicity of RGMP are its restrictions in supporting specific routing protocols. The following paragraphs list a few known restrictions.
RGMP简单的一个结果是它在支持特定路由协议方面的限制。以下段落列出了一些已知的限制。
A router running RGMP on a switched network will not receive traffic for a multicast group unless it explicitly requests it via RGMP Join messages (besides those group ranges specified to be flooded in 3.1). For this reason, it is not possible to run a protocol like PIM Dense-Mode or DVMRP across an RGMP enabled network with RGMP enabled routers.
在交换网络上运行RGMP的路由器将不会接收多播组的流量，除非它通过RGMP连接消息明确请求它（除了3.1中指定的组范围）。因此，不可能通过支持RGMP的路由器在支持RGMP的网络上运行PIM密集模式或DVMRP等协议。
In Bidir-PIM, a router elected to be the DF must not be enabled for RGMP on the network, because it unconditionally needs to forward traffic received from the network towards the RP. If a router is not the DF for any group on the network, it can be enabled for RGMP on that network.
在Bidir PIM中，选择为DF的路由器不得为网络上的RGMP启用，因为它无条件地需要将从网络接收的流量转发到RP。如果路由器不是网络上任何组的DF，则可以为该网络上的RGMP启用该路由器。
In PIM-SM, directly connected sources on the network can not be supported if the elected DR is running RGMP, because this DR needs to unconditionally receive traffic from directly connected sources to trigger the PIM-SM registering process on the DR. In PIM-SSM, directly connected sources can be supported with RGMP enabled routers.
在PIM-SM中，如果选定的DR运行RGMP，则网络上的直连源不受支持，因为此DR需要无条件地接收来自直连源的流量，以触发DR上的PIM-SM注册过程。在PIM-SSM中，启用RGMP的路由器可支持直连源。
Both in PIM-SM and PIM-SSM, upstream routers forwarding traffic into the switched network need to send RGMP Joins for the group in support of the PIM assert process.
在PIM-SM和PIM-SSM中，向交换网络转发流量的上游路由器都需要为组发送RGMP加入，以支持PIM断言过程。
The Hello Interval is the interval between RGMP Hello messages sent by an RGMP-enabled router to an RGMP-enabled switch. Default: 60 seconds.
Hello Interval是由启用RGMP的路由器发送到启用RGMP的交换机的RGMP Hello消息之间的间隔。默认值：60秒。
The Join Interval is the interval between periodic RGMP Join messages sent by an RGMP-enabled router to an RGMP-enabled switch for a given group address. Default: 60 seconds.
Join Interval是由启用RGMP的路由器为给定组地址向启用RGMP的交换机发送的周期性RGMP Join消息之间的间隔。默认值：60秒。
The RGMP protocol assumes that physical port security can be guaranteed for switch ports from which RGMP messages are accepted. Physical port security for RGMP means that physical measures will ensure that such ports are dedicatedly connected to one system which acts as an RGMP capable router. This is also the recommended configuration to best leverage the benefits of the RGMP protocol (e.g., avoiding unwanted third-party IPv4 multicast traffic arriving on said ports).
RGMP协议假定可以为接收RGMP消息的交换机端口保证物理端口安全。RGMP的物理端口安全性意味着物理措施将确保这些端口专用于连接到一个系统，该系统充当支持RGMP的路由器。这也是最佳利用RGMP协议优点的推荐配置（例如，避免不必要的第三方IPv4多播流量到达所述端口）。
RGMP specific DoS attacks arise from forged RGMP messages. If more than one system is connected to a port of the RGMP switch, then one system may forge RGMP messages and affect the operations of the other system(s) on the same port. This is a potential security risk.
RGMP特定的DoS攻击来自伪造的RGMP消息。如果多个系统连接到RGMP交换机的端口，则一个系统可能伪造RGMP消息并影响同一端口上其他系统的操作。这是一个潜在的安全风险。
When physical security ensures that only one system is connected to a RGMP capable port on a switch, then forged messages from this system itself can take effect. Such forged messages can always be avoided by system local measures.
当物理安全性确保只有一个系统连接到交换机上支持RGMP的端口时，来自该系统本身的伪造消息就会生效。系统本地措施始终可以避免此类伪造消息。
We consider the ramifications of a forged message of each type:
我们考虑每种类型的伪造消息的后果：
Hello Message:
你好，留言：
A forged RGMP Hello message can restrict multicast data towards a non-RGMP enabled router on the same port. This effectively introduces a blackholing DoS attack.
伪造的RGMP Hello消息可以将多播数据限制在同一端口上未启用RGMP的路由器上。这有效地引入了黑洞DoS攻击。
Leave Message:
留言：
A forged RGMP Leave message can restrict IPv4 multicast traffic for individual groups toward the port. The effect is a possible blackholing DoS attack similar to an RGMP Hello Message except that it does not affect all IPv4 multicast traffic but only that of the groups indicated in the forged messages. It will also only affect a port if there officially is only one RGMP enabled router connected to it (i.e., if the port is RGMP enabled).
伪造的RGMP离开消息可以限制单个组朝向端口的IPv4多播流量。其影响可能是一种类似于RGMP Hello消息的黑洞DoS攻击，只是它不会影响所有IPv4多播流量，而只影响伪造消息中指示的组的流量。它还将仅在只有一个支持RGMP的路由器连接到端口时（即，如果端口支持RGMP）才会影响端口。
Bye Message:
再见：
A forged RGMP Bye message can turn the port into being RGMP-disabled. This could, indirectly, cause a DoS attack based on the port getting overloaded with IPv4 multicast traffic if the network bandwidth of the port was provisioned with the expectation that RGMP will suppress unwanted IPv4 multicast messages.
伪造的RGMP Bye消息可将端口变为禁用RGMP。如果端口的网络带宽是在预期RGMP将抑制不需要的IPv4多播消息的情况下配置的，则这可能会间接导致基于端口的DoS攻击因IPv4多播流量过载。
This type of DoS attack simply re-establishes a port behavior as if RGMP was not configured and invalidates the benefit of RGMP. This, however, does not introduce an issue that would not have been there without RGMP in the first place.
这种类型的DoS攻击只是重新建立端口行为，就好像没有配置RGMP一样，并使RGMP的好处无效。然而，这并不会带来一个没有RGMP就不会出现的问题。
Join Message:
加入消息：
A forged RGMP Join message could attract undesired multicast packets to the port where it is received from. The effect is similar to an RGMP Bye Message except that it does not affect all IPv4 multicast traffic only the groups indicated in the forged messages. The message will affect a port only if there officially is only one RGMP enabled router connected to it (i.e., if the port is RGMP enabled).
伪造的RGMP连接消息可能会将不需要的多播数据包吸引到接收它的端口。该效果类似于RGMP Bye消息，只是它不会影响所有IPv4多播流量，只影响伪造消息中指示的组。只有当只有一个支持RGMP的路由器连接到某个端口时（即，如果端口支持RGMP），该消息才会影响该端口。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[4] Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[5] Cain, B., Deering, S., Kouvelas, I., Fenner, W. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[5] Cain，B.，Deering，S.，Kouvelas，I.，Fenner，W.和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[6] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[6] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[7] ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC) Bridges", 1998.
[7] ANSI/IEEE标准802.1D 1998版，“媒体访问控制（MAC）网桥”，1998年。
[3] Internet Multicast Addresses,
http://www.iana.org/assignments/multicast-addresses
[3] Internet Multicast Addresses,
http://www.iana.org/assignments/multicast-addresses
[8] Farinacci D., Tweedly D., Speakman T., "Cisco Group Management
Protocol (CGMP)", 1996/1997
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[8] Farinacci D., Tweedly D., Speakman T., "Cisco Group Management
Protocol (CGMP)", 1996/1997
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[9] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", RFC 3228, February 2002.
[9] Fenner，B.，“IPv4互联网组管理协议（IGMP）的IANA考虑因素”，RFC3228，2002年2月。
[10] Christensen, M. and F. Solensky, "IGMP and MLD snooping switches", Work In Progress.
[10] Christensen，M.和F.Solensky，“IGMP和MLD窥探开关”，正在进行中。
[11] Biswas, S., Cain, B. and B. Haberman, "IGMP Multicast Router Discovery", Work In Progress.
[11] Biswas，S.，Cain，B.和B.Haberman，“IGMP多播路由器发现”，工作正在进行中。
The authors would like to thank Gorry Fairhurst, Bill Fenner, Giovanni Meo, Mike Norton, Pavlin Radoslavov and Alex Zinin for their review of the document and their suggestions.
作者要感谢Gorry Fairhurst、Bill Fenner、Giovanni Meo、Mike Norton、Pavlin Radoslavov和Alex Zinin对文件的审查和他们的建议。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
Appendix B. Comparison with GARP/GMRP
附录B.与GARP/GMRP的比较
This appendix is not part of the RGMP specification but is provided for information only.
本附录不是RGMP规范的一部分，但仅供参考。
GARP/GMRP (defined in IEEE 802.1D [7]) is the ANSI/ISO/IEC/IEEE protocol suite to constrain ethernet multicast traffic in bridged ethernet networks. As such it is also a possible alternative to RGMP for the purpose of constraining multicast traffic towards router ports. This appendix will explain the motivation not to rely on GARP/GMRP and how GARP/GMRP and RGMP differ.
GARP/GMRP（在IEEE 802.1D[7]中定义）是ANSI/ISO/IEC/IEEE协议套件，用于限制桥接以太网中的以太网多播流量。因此，它也是RGMP的一种可能替代方案，用于限制朝向路由器端口的多播流量。本附录将解释不依赖GARP/GMRP的动机以及GARP/GMRP和RGMP的区别。
The key factor in rolling out GARP/GMRP would have been to completely replace IGMP Snooping. This was the design goal of GARP/GMRP. For efficient operations, IGMP Snooping requires hardware filtering support in the switch (to differentiate between hosts membership reports and actual IPv4 multicast traffic). Especially in many older switches this support does not exist. Vendors tried to find a way around this issue to provide the benefit of constraining IPv4 multicast traffic in a switched LAN without having to build more expensive switch hardware. GARP/GMRP is one protocol resulting from this. CGMP from Cisco is another one. While CGMP solves the problem without requiring changes to the host stack software, GARP/GMRP requires support for it by the host stack.
推广GARP/GMRP的关键因素是完全取代IGMP窥探。这是GARP/GMRP的设计目标。为了实现高效操作，IGMP侦听需要交换机中的硬件过滤支持（以区分主机成员资格报告和实际IPv4多播流量）。尤其是在许多较旧的交换机中，这种支持并不存在。供应商试图找到一种解决此问题的方法，以提供在交换LAN中限制IPv4多播流量的好处，而无需构建更昂贵的交换机硬件。GARP/GMRP是由此产生的一个协议。思科的CGMP是另一个。虽然CGMP在不需要更改主机堆栈软件的情况下解决了这个问题，但是GARP/GMRP需要主机堆栈对它的支持。
Up to date GARP/GMRP has so far not made significant inroads into deployed solutions. IGMP Snooping (and CGMP) are the norm for this environment. In result, GARP/GMRP can not necessarily be expected to be supported by layer 2 switches. In addition, GARP/GMRP does not address clearly the issues RGMP tries to solve. On one hand, GARP/GMRP provides much more functionality and as such complexity as immediately required. On the other hand, GARP/GMRP is limited by being a standard predominantly for the Ethernet scope.
迄今为止，GARP/GMRP尚未对已部署的解决方案取得重大进展。IGMP窥探（和CGMP）是这种环境的标准。因此，第2层交换机不一定支持GARP/GMRP。此外，GARP/GMRP没有明确解决RGMP试图解决的问题。一方面，GARP/GMRP提供了更多的功能，因此具有即时所需的复杂性。另一方面，GARP/GMRP是一个主要用于以太网范围的标准，因此受到限制。
Beyond the process and applicability reasons, the main differences between GARP/GMRP and RGMP are as follows:
除工艺和适用性原因外，GARP/GMRP和RGMP之间的主要区别如下：
o GARP/GMRP switches/systems need to send and listen/react to GARP/GMRP messages. In RGMP, routers only need to send RGMP messages and switches only need to listen to them. This protocol approach is meant to simplify implementation, operations and troubleshooting.
o GARP/GMRP交换机/系统需要发送并侦听/响应GARP/GMRP消息。在RGMP中，路由器只需要发送RGMP消息，交换机只需要监听它们。此协议方法旨在简化实现、操作和故障排除。
o The same switch running RGMP in a backbone network will likely see more states then running on the edge only doing IGMP Snooping, making it preferable to keep the amount of per group processing and memory requirements in RGMP more in bounds than possible in IGMP Snooping and GARP/GMRP: In GARP/GMRP, a (multiple) timer based state-machines needs to be maintained on a per ethernet group address, in RGMP timer maintenance is completely optional and there are only two states per group (joined or not joined).
o 在主干网中运行RGMP的同一交换机可能会看到更多的状态，然后仅在边缘上运行IGMP侦听，因此，最好将RGMP中的每组处理量和内存需求保持在比IGMP侦听和GARP/GMRP中可能的范围内：在GARP/GMRP中，a（多个）基于计时器的状态机需要在每个以太网组地址上维护，在RGMP中，计时器维护是完全可选的，每个组只有两个状态（已加入或未加入）。
o GARP/GMRP is an ethernet level protocol from the IEEE. It supports to constrain traffic for ethernet addresses (groups). RGMP does constrain traffic for IPv4 multicast groups. Today this is even beyond the capabilities of typical switch platforms used as layer2 switches. Extensions to support further entities are likely easier to come by through extensions to RGMP than to GARP/GMRP.
o GARP/GMRP是来自IEEE的以太网级协议。它支持限制以太网地址（组）的通信量。RGMP不限制IPv4多播组的通信量。如今，这甚至超出了用作第二层交换机的典型交换机平台的能力。通过对RGMP的扩展比对GARP/GMRP的扩展更容易获得支持更多实体的扩展。
o RGMP shares the basic packet format with IGMP (version 2) and is as such easy to add to router and switch platforms that already support IGMP and IGMP Snooping respectively. This is especially true for switches that in hardware can differentiate between IGMP protocol type packets and other IPv4 multicast traffic sent to the same (or a MAC ambiguous) group. In addition, due to the state simplicity of RGMP it is easy to integrate IGMP Snooping and RGMP operations in the IPv4 multicast control and forwarding plane of a switch.
o RGMP与IGMP（版本2）共享基本数据包格式，因此易于添加到已分别支持IGMP和IGMP侦听的路由器和交换机平台。对于在硬件中可以区分IGMP协议类型数据包和发送到相同（或MAC不明确）组的其他IPv4多播流量的交换机，尤其如此。此外，由于RGMP的状态简单，很容易将IGMP侦听和RGMP操作集成到交换机的IPv4多播控制和转发平面中。
o GARP/GMRP supports more than one system (host/router) on a switch port which is one reason for its complexity. In RGMP, this configuration is explicitly not supported: More than one router per switched port is not only not a common scenario in today's switches layer 2 networks, it is also an undesired configuration when unwanted IPv4 multicast traffic is to be kept away from routers.
o GARP/GMRP在交换机端口上支持多个系统（主机/路由器），这是其复杂性的一个原因。在RGMP中，明确不支持这种配置：每个交换端口有一个以上的路由器不仅在今天的交换机第2层网络中不常见，而且在不需要的IPv4多播流量远离路由器时，这种配置也是不需要的。
o GARP/GMRP defines how to constrain multicast traffic between switches, another reason for its complexity. RGMP does not explicitly support this as part of the protocol because of the following reasons:
o GARP/GMRP定义了如何约束交换机之间的多播流量，这也是其复杂性的另一个原因。由于以下原因，RGMP不明确支持将其作为协议的一部分：
o It is not necessary to include this function as part of the RGMP protocol description because switch implementations can transparently decide to support this function (see 4.1 about this "RGMP Spoofing").
o 没有必要将此功能作为RGMP协议描述的一部分，因为交换机实现可以透明地决定支持此功能（有关此“RGMP欺骗”，请参阅4.1）。
o Important deployments through which large amounts of IPv4 multicast are moved today are typically single switch MIX - Multicast Internet eXchange points.
o 如今，移动大量IPv4多播的重要部署通常是单交换机混合多播Internet交换点。
o Avoiding congestion on inter-switch links in general is more complex than simply constraining IPv4 multicast traffic to paths where it is needed. With or without IPv4 multicast, the aggregate bandwidth needed between switches can easily be the aggregate required bandwidth to routers on either sides. For this reason, inter-switch bandwidth is most often appropriately over provisioned. In addition, the likelihood for receiving routers to be only on the sources side of an inter-switch link is in general deployments rather low. The cases where traffic constrainment on inter-switch links is required and helpful is thus limited and can in most cases be avoided or worked around. Moving the network to a layer 3 routed network is often the best solution, supporting RGMP-Spoofing (see section 4.1) is another one.
o 避免交换机间链路上的拥塞通常比简单地将IPv4多播流量限制到需要的路径更复杂。无论是否使用IPv4多播，交换机之间所需的聚合带宽都可以很容易地成为路由器两侧所需的聚合带宽。由于这个原因，交换机间带宽通常是过度配置的。此外，接收路由器仅位于交换机间链路的源端的可能性通常相当低。因此，需要在交换机间链路上进行流量限制并对其有帮助的情况是有限的，在大多数情况下可以避免或解决。将网络移动到第3层路由网络通常是最佳解决方案，支持RGMP欺骗（见第4.1节）是另一种解决方案。
Appendix C. Possible future extensions / comparison to PIM Snooping
附录C.未来可能的PIM窥探扩展/比较
This appendix is not part of the RGMP specification but is provided for information only.
本附录不是RGMP规范的一部分，但仅供参考。
This appendix presents a discussion of possible extensions to RGMP. Included are points on why the extensions are not included and in addition a motivation for RGMP in comparison to (PIM) snooping.
本附录讨论了RGMP的可能扩展。包括关于为什么不包括扩展的观点，以及与（PIM）窥探相比，RGMP的动机。
o Support for multiple switches
o 支持多个交换机
As discussed in "RGMP Spoofing", chapter 4.1 and GARP/GMRP comparison in Appendix B.
如附录B第4.1章“RGMP欺骗”和GARP/GMRP比较中所述。
o Support for SSM
o 支持SSM
While RGMP works with PIM-SSM, it does not have explicit messages for the router to selectively join to (S,G) channels individually. Instead the router must RGMP join to all (Si,G) channels by
虽然RGMP与PIM-SSM一起工作，但它没有明确的消息供路由器选择性地单独加入（S，G）通道。相反，路由器必须通过以下方式将RGMP连接到所有（Si，G）通道：
joining to G. Extending RGMP to include (S,G) Join/Leaves is feasible. However, currently the majority of switches do not support actual traffic constraining on a per channel basis. In addition, the likelihood for actual channel collision (two SSM channels using the same group) will only become an issue when SSM is fully deployed.
连接到G。扩展RGMP以包括（S，G）连接/离开是可行的。然而，目前大多数交换机不支持基于每个信道的实际流量约束。此外，只有在SSM完全部署时，实际信道冲突（两个SSM信道使用同一组）的可能性才会成为一个问题。
o Support for IPv6
o 支持IPv6
RGMP could easily be extended to support IPv6 by mapping the RGMP packet format into the MLD/IPv6 packet format. This was not done for this specification because most switches today do not even support MLD snooping.
通过将RGMP数据包格式映射到MLD/IPv6数据包格式，可以轻松地扩展RGMP以支持IPv6。这不是针对本规范的，因为今天的大多数交换机甚至不支持MLD窥探。
o Support for multiple routers per port
o 支持每个端口有多个路由器
As discussed in Appendix B. This is probably one extension that should be avoided. Multiple RGMP router per port are inappropriate for efficient multicast traffic constrainment.
如附录B所述。这可能是一个应该避免的扩展。每个端口有多个RGMP路由器不适合有效的多播流量约束。
o Support for non-join based protocols / protocol elements
o 支持基于非连接的协议/协议元素
For protocols like PIM dense-mode, DVMRP or Bidir-PIM DF routers, additional RGMP messages may be added to allow routers to indicate that certain group (ranges) traffic need to be flooded from (dense-mode) or to (Bidir-PIM) them.
对于PIM密集模式、DVMRP或Bidir PIM DF路由器等协议，可以添加额外的RGMP消息，以允许路由器指示某些组（范围）流量需要从（密集模式）或（Bidir PIM）它们淹没。
o Support for multi-policy switching
o 支持多策略切换
In Multicast Exchange Points (MIXes) environments situations exist where different downstream routers for policy reasons need to receive the same traffic flow from different upstream routers.
在多播交换点（MIXes）环境中，存在这样的情况：出于策略原因，不同的下游路由器需要从不同的上游路由器接收相同的流量。
This problem could be solved by actually providing an upstream neighbor field in RGMP Join/Leave messages. The RGMP switch would then forward traffic from one upstream router only to those downstream routers who want to have the traffic from exactly this upstream router. This extension would best go in hand with changes to the layer 3 routing protocol run between the routers.
这个问题可以通过在RGMP加入/离开消息中实际提供一个上游邻居字段来解决。然后，RGMP交换机将只将来自一个上游路由器的流量转发给那些希望正好来自该上游路由器的流量的下游路由器。此扩展最好与路由器之间运行的第3层路由协议的更改同时进行。
As previously mentioned, RGMP was designed to be easy to implement and to support simple layer2 switches. Implementations could also be applied to switches beyond layer 2. If all the above possible future extensions were to be supported by an evolution of RGMP, it would be questionable whether such a protocol could be any less complex than actually snooping into the layer3 IPv4 routing protocol run between routers in a switched LAN.
如前所述，RGMP设计为易于实现并支持简单的layer2交换机。实现也可以应用于第2层以外的交换机。如果上述所有可能的未来扩展都由RGMP的演进提供支持，那么这种协议是否比窥探交换LAN中路由器之间运行的第3层IPv4路由协议的复杂程度要低，这将是一个疑问。
From the perspective of protocol architecture it is certainly more appropriate to have a separate protocol like RGMP or GARP/GMRP for this purpose. Then again, the more complex the requirements are, the more duplication of effort is involved and snooping seems to become a more attractive option.
从协议体系结构的角度来看，使用单独的协议（如RGMP或GARP/GMRP）显然更合适。再说一次，需求越复杂，所涉及的重复工作就越多，窥探似乎成为一种更具吸引力的选择。
Even though there exists one predominant routing Protocol, PIM, in IPv4 multicast, routing with PIM in itself is extremely complex for a switch to snoop into. PIM has two main versions, different modes - sparse, dense, bidir, ssm, join / prune / graft messages (depending on the mode of the group), various PIM Hello options, different versions of asserts, two dynamic mode announcement protocols (BSR, AutoRP), and finally supports both IPv4 and IPv6.
尽管在IPv4多播中存在一种主要的路由协议PIM，但对于窥探到的交换机来说，使用PIM本身的路由是极其复杂的。PIM有两个主要版本，不同的模式-稀疏、密集、bidir、ssm、加入/删减/嫁接消息（取决于组的模式）、各种PIM Hello选项、不同版本的断言、两个动态模式公告协议（BSR、AutoRP），最后支持IPv4和IPv6。
A switch snooping into PIM is very likely to implement just a subset of this feature set, making it very hard for the user to determine what level of actual traffic constrainment is achieved unless a clear specification exists for the implementation (or better the method per se.). In addition, there is always the danger that such a snooping implementation may break newer features of the routing protocol that it was not designed to handle (likely because they could not have been predicted). For example, this can happen with switches using IGMP (v2) snooping implementations that are being subjected to IGMP version 3 messages - they break IGMPv3.
窥探PIM的交换机很可能只实现此功能集的一个子集，这使得用户很难确定实现的实际流量限制级别，除非存在明确的实现规范（或更好的方法本身）。此外，这种窥探实现可能会破坏路由协议的新功能，而这些新功能不是设计用来处理的（可能是因为无法预测）。例如，这可能发生在使用IGMP（v2）侦听实现的交换机上，这些交换机受到IGMP版本3消息的影响-它们破坏了IGMPv3。
In summary, with PIM still evolving, the approach taken by RGMP is the safest one for the immediate problems at hand, and extensions like those listed should be considered in time for actual demand. (PIM) snooping is a valid alternative once the total amount of features that need to be supported makes it an equally attractive solution (with respect to complexity) to a dedicated protocol and if its functions are well defined to allow predicting its effects - but always at the price of possible incompatibilities with upcoming PIM protocol extensions unless support for layer 2 switches is explicitly considered in moving PIM protocols forward.
总之，随着PIM的不断发展，RGMP采取的方法是解决眼前问题的最安全的方法，并且应根据实际需求及时考虑所列的扩展。（PIM）窥探是一个有效的替代方案，只要需要支持的功能总量使其成为一个同样具有吸引力的解决方案（就复杂性而言）对于专用协议，如果其功能定义良好，允许预测其影响，但总是以可能与即将到来的PIM协议扩展不兼容为代价，除非在推进PIM协议时明确考虑对第2层交换机的支持。
Authors' Addresses
作者地址
Ishan Wu cisco Systems 170 West Tasman Drive San Jose, CA 95134
Ishan Wu cisco Systems 170西塔斯曼大道圣何塞，加利福尼亚州95134
Phone: (408) 526-5673 EMail: iwu@cisco.com
电话：（408）526-5673电子邮件：iwu@cisco.com
Toerless Eckert cisco Systems 170 West Tasman Drive San Jose, CA 95134
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: (408) 853-5856 Email: eckert@cisco.com
电话：（408）853-5856电子邮件：eckert@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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编辑功能的资金目前由互联网协会提供。