Internet Engineering Task Force (IETF) Y. Cai
Request for Comments: 6754 Microsoft
Category: Standards Track L. Wei
ISSN: 2070-1721 H. Ou
Cisco Systems, Inc.
V. Arya
S. Jethwani
DIRECTV Inc.
October 2012
Internet Engineering Task Force (IETF) Y. Cai
Request for Comments: 6754 Microsoft
Category: Standards Track L. Wei
ISSN: 2070-1721 H. Ou
Cisco Systems, Inc.
V. Arya
S. Jethwani
DIRECTV Inc.
October 2012
Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
协议无关多播等代价多路径（ECMP）重定向
Abstract
摘要
A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal-cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics.
协议独立多播（PIM）路由器使用反向路径转发（RPF）过程选择上游接口和路由器以建立转发状态。当存在等成本多路径（ECMP）时，现有实现通常使用哈希算法来选择路径。此类算法不允许根据管理度量在ECMP之间传播流量。这通常会导致网络资源使用效率低下或无效。本文档介绍了ECMP重定向，这是一种在ECMPs上改进RPF过程的机制。它允许ECMP选择基于管理选择的度量，例如数据传输延迟、路径首选项和路由度量。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6754.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6754.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
5.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6
5.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 7
5.3. Transient State . . . . . . . . . . . . . . . . . . . . . 7
5.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 8
5.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8
5.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8
5.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
5.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6
5.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 7
5.3. Transient State . . . . . . . . . . . . . . . . . . . . . 7
5.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 8
5.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8
5.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8
5.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
A PIM router uses the RPF procedure to select an upstream interface and a PIM neighbor on that interface to build forwarding state. When there are equal-cost multipaths (ECMPs) upstream, existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMP according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMP. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics, or a combination of metrics.
PIM路由器使用RPF过程选择上游接口和该接口上的PIM邻居以建立转发状态。当上游存在等成本多路径（ECMP）时，现有实现通常使用哈希算法来选择路径。此类算法不允许根据管理度量在ECMP之间传播流量。这通常会导致网络资源使用效率低下或无效。本文档介绍了ECMP重定向，这是一种在ECMP上改进RPF过程的机制。它允许ECMP选择基于管理选择的度量，例如数据传输延迟、路径首选项和路由度量，或度量的组合。
ECMPs are frequently used in networks to provide redundancy and to increase available bandwidth. A PIM router selects a path in the ECMP based on its own implementation-specific choice. The selection is a local decision. One way is to choose the PIM neighbor with the highest IP address; another is to pick the PIM neighbor with the best hash value over the destination and source addresses.
ECMP经常用于网络中以提供冗余和增加可用带宽。PIM路由器根据其自身特定于实现的选择在ECMP中选择路径。选择是当地的决定。一种方法是选择IP地址最高的PIM邻居；另一种方法是选择目标地址和源地址上具有最佳哈希值的PIM邻居。
While implementations supporting ECMP have been deployed widely, the existing RPF selection methods have weaknesses. The lack of administratively effective ways to allocate traffic over alternative paths is a major issue. For example, there is no straightforward way to tell two downstream routers to select either the same or different RPF neighbor routers for the same traffic flows.
虽然支持ECMP的实现已经被广泛部署，但现有的RPF选择方法存在弱点。缺乏管理上有效的方法在备选路径上分配流量是一个主要问题。例如，没有直接的方法告诉两个下游路由器为相同的流量选择相同或不同的RPF邻居路由器。
With the ECMP Redirect mechanism introduced here, the upstream routers use a PIM ECMP Redirect message to instruct the downstream routers on how to tiebreak among the upstream neighbors. The PIM ECMP Redirect message conveys the tiebreak information based on metrics selected administratively.
通过这里介绍的ECMP重定向机制，上游路由器使用PIM ECMP重定向消息来指示下游路由器如何在上游邻居之间进行分段。PIM ECMP重定向消息根据管理上选择的度量传递中断信息。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses terms defined in [RFC4601] to describe actions taken by PIM routers.
本文件使用[RFC4601]中定义的术语描述PIM路由器采取的行动。
The following terms have special significance for ECMP Redirect:
以下术语对ECMP重定向具有特殊意义：
o Equal-Cost Multipath (ECMP). In this document, the term "ECMP" refers to parallel, single-hop, equal-cost links between adjacent nodes.
o 等成本多路径（ECMP）。在本文档中，术语“ECMP”指相邻节点之间的并行、单跳、等成本链路。
o ECMP Bundle. An ECMP bundle is a set of PIM-enabled interfaces on a router, where all interfaces belonging to the same bundle share the same routing metric. The next hops for the ECMP are all one hop away.
o ECMP包。ECMP包是路由器上一组启用PIM的接口，其中属于同一包的所有接口共享相同的路由度量。ECMP的下一个跃点都是一个跃点。
There can be one or more ECMP bundles on any router, while one individual interface can only belong to a single bundle. ECMP bundles are created on a router via configuration.
任何路由器上都可以有一个或多个ECMP包，而一个单独的接口只能属于一个包。ECMP包通过配置在路由器上创建。
o RPF. RPF stands for Reverse Path Forwarding.
o RPF。RPF代表反向路径转发。
o Upstream. Towards the root of the multicast forwarding tree. An upstream router refers to a router that is forwarding, or potentially capable of forwarding, data packets onto interfaces in an ECMP bundle.
o 上游指向多播转发树的根。上游路由器是指正在将数据包转发或可能能够将数据包转发到ECMP包中的接口上的路由器。
When there are multiple routers forwarding packets onto interfaces in the ECMP bundle, all these routers are called upstream routers.
当有多个路由器将数据包转发到ECMP包中的接口上时，所有这些路由器都称为上游路由器。
o Downstream. Away from the root of the multicast forwarding tree. A downstream router is a router that uses an interface in the ECMP bundle as an RPF interface for a multicast forwarding entry.
o 下游的远离多播转发树的根。下游路由器是使用ECMP包中的接口作为多播转发条目的RPF接口的路由器。
The existing PIM Assert mechanism allows the upstream router to detect the existence of multiple forwarders for the same multicast flow onto the same downstream interface. The upstream router sends a PIM Assert message containing a routing metric for the downstream routers to use for tiebreaking among the multiple upstream forwarders on the same RPF interface.
现有的PIM断言机制允许上游路由器检测同一下游接口上相同多播流的多个转发器的存在。上游路由器发送一条PIM Assert消息，其中包含下游路由器的路由度量，用于在同一RPF接口上的多个上游转发器之间进行分接。
With ECMP interfaces between the downstream and upstream routers, the PIM ECMP Redirect mechanism works in a similar way, but extends the ability to resolve the selection of forwarders among different interfaces in the ECMP.
通过下游和上游路由器之间的ECMP接口，PIM ECMP重定向机制以类似的方式工作，但扩展了解决ECMP中不同接口之间转发器选择的能力。
When a PIM router downstream of the ECMP interfaces creates a new (*,G) or (S,G) entry, it will populate the RPF interface and RPF neighbor information according to the rules specified by [RFC4601]. This router will send its initial PIM Joins to that RPF neighbor.
当ECMP接口下游的PIM路由器创建新的（*，G）或（S，G）条目时，它将根据[RFC4601]指定的规则填充RPF接口和RPF邻居信息。此路由器将向该RPF邻居发送其初始PIM连接。
When the RPF neighbor router receives the Join message and finds that the receiving interface is one of the ECMP interfaces, it will check if the same flow is already being forwarded out of another ECMP interface. If so, this RPF neighbor router will send a PIM ECMP Redirect message onto the interface the Join was received on. The PIM ECMP Redirect message contains the address of the desired RPF
当RPF邻居路由器接收到加入消息并发现接收接口是ECMP接口之一时，它将检查是否已从另一个ECMP接口转发相同的流。如果是这样，该RPF邻居路由器将向接收加入的接口发送PIM ECMP重定向消息。PIM ECMP重定向消息包含所需RPF的地址
neighbor, an Interface ID [RFC6395], and the other parameters used as tiebreakers. In essence, a PIM ECMP Redirect message is sent by an upstream router to notify downstream routers to redirect PIM Joins to the new RPF neighbor via a different interface. When the downstream routers receive this message, they SHOULD trigger PIM Joins toward the new RPF neighbor specified in the packet.
邻居、接口ID[RFC6395]和其他用作断开连接的参数。本质上，PIM ECMP重定向消息由上游路由器发送，以通知下游路由器通过不同的接口将PIM连接重定向到新的RPF邻居。当下游路由器接收到该消息时，它们应该触发PIM加入到数据包中指定的新RPF邻居。
This PIM ECMP Redirect message has similar functions as the existing PIM Assert message:
此PIM ECMP重定向消息具有与现有PIM Assert消息类似的功能：
1. It is sent by an upstream router.
1. 它由上游路由器发送。
2. It is used to influence the RPF selection by downstream routers.
2. 它用于影响下游路由器的RPF选择。
3. A tiebreaker metric is used.
3. 使用了一个tiebreaker度量。
However, the existing Assert message is used to select an upstream router within the same multi-access network (such as a LAN), while the Redirect message is used to select both a network and an upstream router.
然而，现有断言消息用于选择同一多址网络（如LAN）内的上游路由器，而重定向消息用于选择网络和上游路由器。
One advantage of this design is that the control messages are only sent when there is a need to "rebalance" the traffic. This reduces the amount of control traffic.
这种设计的一个优点是，只有在需要“重新平衡”流量时才发送控制消息。这减少了控制通信量。
The use of ECMP Redirect applies to shared trees or source trees built with procedures described in [RFC4601]. The use of ECMP Redirect in PIM Dense Mode [RFC3973] or in Bidirectional PIM [RFC5015] is not considered in this document.
ECMP重定向的使用适用于使用[RFC4601]中描述的过程构建的共享树或源树。本文件不考虑在PIM密集模式[RFC3973]或双向PIM[RFC5015]中使用ECMP重定向。
The enhancement described in this document can be applicable to a number of scenarios. For example, it allows a network operator to use ECMPs and have the ability to perform load splitting based on bandwidth. To do this, the downstream routers perform RPF selection with bandwidth, instead of IP addresses, as a tiebreaker. The ECMP Redirect mechanism assures that all downstream routers select the desired network link and upstream router whenever possible. Another example is for a network operator to impose a transmission delay limit on certain links. The ECMP Redirect mechanism provides a means for an upstream router to instruct a downstream router to choose a different RPF path.
本文档中描述的增强功能可适用于许多场景。例如，它允许网络运营商使用ECMPs，并能够根据带宽执行负载拆分。为了做到这一点，下游路由器使用带宽（而不是IP地址）来执行RPF选择，作为分接器。ECMP重定向机制确保所有下游路由器尽可能选择所需的网络链路和上游路由器。另一个例子是网络运营商对某些链路施加传输延迟限制。ECMP重定向机制为上游路由器提供了一种方法，以指示下游路由器选择不同的RPF路径。
This specification does not dictate the scope of applications of this mechanism.
本规范不规定该机制的应用范围。
ECMP Redirects are sent by an upstream router in a rate-limited fashion, under either of the following conditions:
在以下任一情况下，ECMP重定向由上行路由器以速率受限的方式发送：
o It detects a PIM Join on a non-desired outgoing interface.
o 它在一个不需要的输出接口上检测PIM连接。
o It detects multicast traffic on a non-desired outgoing interface.
o 它检测非期望的传出接口上的多播流量。
In both cases, an ECMP Redirect is sent to the non-desired interface. An outgoing interface is considered "non-desired" when:
在这两种情况下，ECMP重定向都被发送到不需要的接口。当出现以下情况时，传出接口被视为“不需要”：
o The upstream router is already forwarding the same flow out of another interface belonging to the same ECMP bundle.
o 上游路由器已经从属于同一ECMP包的另一个接口转发相同的流。
o The upstream router is not yet forwarding the flow out any interfaces of the ECMP bundle, but there is another interface with more desired attributes.
o 上游路由器尚未将流转发出ECMP包的任何接口，但还有另一个具有更多所需属性的接口。
An upstream router MAY choose not to send ECMP Redirects if it becomes aware that some of the downstream routers are unreachable via some links in ECMP bundle.
如果上游路由器意识到某些下游路由器无法通过ECMP包中的某些链路访问，则可以选择不发送ECMP重定向。
An upstream router uses the Neighbor Address or the Interface ID field in the ECMP Redirect message to indicate the interface it wants traffic to be directed to. This Neighbor Address MUST be associated with an interface in the same ECMP bundle as the ECMP Redirect message's outgoing interface. If the Interface ID field is ignored, this Neighbor Address field uniquely identifies a LAN and an upstream router to which a downstream router SHOULD redirect its Join messages, and an ECMP Redirect message MUST be discarded if the Neighbor Address field in the message does not match the cached neighbor address.
上游路由器使用ECMP重定向消息中的邻居地址或接口ID字段来指示它希望将流量定向到的接口。此邻居地址必须与ECMP重定向消息的传出接口所在的ECMP捆绑包中的接口相关联。如果忽略接口ID字段，则此邻居地址字段唯一标识LAN和上游路由器，下游路由器应将其加入消息重定向到该路由器，如果消息中的邻居地址字段与缓存的邻居地址不匹配，则必须丢弃ECMP重定向消息。
The Interface ID field is used in IPv4 when one or more RPF neighbors in the ECMP bundle are unnumbered, or in IPv6 where link-local addresses are in use. For other IPv4 usage, this field is zeroed when sent, and ignored when received. If the Router ID part of the Interface ID is zero, the field MUST be ignored. See [RFC6395] for details of its assignment and usage in PIM Hellos. If the Interface ID is not ignored, the receiving router of this message MUST use the Interface ID, instead of Neighbor Address, to identify the new RPF neighbor. Additionally, an ECMP Redirect message MUST be discarded if the Interface ID field in the message does not match the cached Interface ID.
当ECMP包中的一个或多个RPF邻居未编号时，在IPv4中使用Interface ID字段，或者在使用链路本地地址的IPv6中使用Interface ID字段。对于其他IPv4使用，此字段在发送时为零，在接收时被忽略。如果接口ID的路由器ID部分为零，则必须忽略该字段。请参阅[RFC6395]，了解其在PIM Hellos中的分配和使用的详细信息。如果未忽略接口ID，则此消息的接收路由器必须使用接口ID而不是邻居地址来标识新的RPF邻居。此外，如果消息中的接口ID字段与缓存的接口ID不匹配，则必须丢弃ECMP重定向消息。
When a downstream router receives an ECMP Redirect, and detects that the desired RPF path from its upstream router's point of view is different from its current one, it should choose to join the newly suggested path and prune from the current path. The exact order of such actions is implementation specific.
当下游路由器接收到ECMP重定向，并且从其上游路由器的角度检测到所需的RPF路径与其当前路径不同时，它应该选择加入新建议的路径并从当前路径修剪。此类行动的确切顺序取决于具体实施情况。
If a downstream router receives multiple ECMP Redirects sent by different upstream routers, it SHOULD use the Preference, Metric, or other fields as specified below as the tiebreakers to choose the most preferred RPF interface and neighbor. The tiebreak procedure is the same as that used in PIM Assert processing described by [RFC4601].
如果下游路由器接收到由不同上游路由器发送的多个ECMP重定向，则应使用首选项、度量或以下指定的其他字段作为分接器来选择最首选的RPF接口和邻居。tiebreak过程与[RFC4601]描述的PIM断言处理中使用的过程相同。
If an upstream router receives an ECMP Redirect, it SHOULD NOT change its forwarding behavior even if the ECMP Redirect makes it a less preferred RPF neighbor on the receiving interface.
如果上游路由器接收到ECMP重定向，则即使ECMP重定向使其成为接收接口上不太首选的RPF邻居，也不应更改其转发行为。
During a transient network outage with a single link cut in an ECMP bundle, a downstream router may lose connection to its RPF neighbor and the normal ECMP Redirect operation may be interrupted temporarily. In such an event, the following actions are RECOMMENDED.
在ECMP包中单个链路中断的瞬时网络中断期间，下游路由器可能会失去与其RPF邻居的连接，并且正常的ECMP重定向操作可能会暂时中断。在这种情况下，建议采取以下措施。
The downstream router SHOULD select a new RPF neighbor. Among all ECMP upstream routers, the preferred selection is the one on the LAN that the previous RPF neighbor resided on.
下游路由器应选择一个新的RPF邻居。在所有ECMP上游路由器中，首选的选择是前一个RPF邻居所在的LAN上的路由器。
If there is no upstream router reachable on the LAN that the previous RPF neighbor resided on, the downstream router will select a new RPF neighbor on a different LAN. Among all ECMP upstream routers, the one that served as RPF neighbor before the link failure is preferred. Such a router can be identified by the Router ID, which is part of the Interface ID in the PIM ECMP Redirect Hello option.
如果上一个RPF邻居所在的LAN上没有可访问的上游路由器，则下游路由器将选择另一个LAN上的新RPF邻居。在所有ECMP上游路由器中，优先选择在链路故障前充当RPF邻居的路由器。这样的路由器可以通过路由器ID识别，路由器ID是PIM ECMP Redirect Hello选项中接口ID的一部分。
During normal ECMP Redirect operations, when PIM Joins for the same (*,G) or (S,G) are received on a different LAN, an upstream router will send ECMP Redirect to prune the non-preferred LAN. Such ECMP Redirects during partial network outage can be suppressed if the upstream router decides that the non-preferred PIM Join is from a router that is not reachable via the preferred LAN. This check can be performed by retrieving the downstream router's Router ID, using the source address in the PIM Join, and searching neighbors on the preferred LAN for one with the same Router ID.
在正常的ECMP重定向操作期间，当在不同的LAN上接收到相同（*，G）或（S，G）的PIM连接时，上游路由器将发送ECMP重定向以删除非首选LAN。如果上游路由器确定非首选PIM连接来自无法通过首选LAN访问的路由器，则可以抑制部分网络中断期间的此类ECMP重定向。通过检索下游路由器的路由器ID，使用PIM连接中的源地址，并在首选LAN上搜索具有相同路由器ID的邻居，可以执行此检查。
If a PIM router supports this specification, it MUST send the PIM ECMP Redirect Hello Option in its PIM Hello messages.
如果PIM路由器支持此规范，则必须在其PIM Hello消息中发送PIM ECMP重定向Hello选项。
A PIM router sends ECMP Redirects on an interface only when it detects that all neighbors on that interface have sent this Hello option. If a PIM router detects that any of its neighbors on an ECMP bundle does not support this Hello option, it SHOULD NOT send ECMP Redirects to interfaces in that bundle; however, it SHOULD still process any ECMP Redirects received from interfaces in that same bundle.
PIM路由器只有在检测到接口上的所有邻居都发送了此Hello选项时，才会在该接口上发送ECMP重定向。如果PIM路由器检测到ECMP捆绑包上的任何邻居不支持此Hello选项，则不应向该捆绑包中的接口发送ECMP重定向；但是，它仍然应该处理从同一捆绑包中的接口接收到的任何ECMP重定向。
If a PIM router does not support this specification, it will ignore the PIM ECMP Redirect Hello Options and ECMP Redirects in the PIM packets that it receives.
如果PIM路由器不支持此规范，它将忽略它接收的PIM数据包中的PIM ECMP重定向Hello选项和ECMP重定向。
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 = 32 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 32 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ECMP Redirect Hello Option
图1:ECMP重定向Hello选项
Type: 32
类型：32
Length: 0
长度：0
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+- ............ Interface ID ........... -+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+
| |
+- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+- ............ Interface ID ........... -+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+
| |
+- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 2: ECMP Redirect Message Format
图2:ECMP重定向消息格式
PIM Ver: See Section 4.9 in [RFC4601].
PIM版本：参见[RFC4601]中的第4.9节。
Type: 11
类型：11
Reserved: See Section 4.9 in [RFC4601].
保留：参见[RFC4601]中的第4.9节。
Checksum: See Section 4.9 in [RFC4601].
校验和：见[RFC4601]中的第4.9节。
Group Address (64 or 160 bits): Encoded-Group address as specified in Section 4.9.1 of [RFC4601].
组地址（64或160位）：按照[RFC4601]第4.9.1节的规定编码的组地址。
Source Address (48 or 144 bits): Encoded-Unicast address as specified in Section 4.9.1 of [RFC4601].
源地址（48或144位）：按照[RFC4601]第4.9.1节规定的编码单播地址。
Neighbor Address (32 or 128 bits): Address of desired upstream neighbor where the downstream receiver redirects PIM Joins.
邻居地址（32或128位）：下游接收器重定向PIM连接的所需上游邻居的地址。
Interface ID (64 bits): See [RFC6395] for details.
接口ID（64位）：详见[RFC6395]。
Preference (8 bits): The first tiebreaker when ECMP Redirects from multiple upstream routers are compared against each other. A numerically smaller value is preferred. A reserved value (15) is used to indicate the metric value following the Preference field is a Network Time Protocol (NTP) timestamp, encoded in the format specified in [RFC5905], taken at the moment the sending router started to forward out of this interface.
首选项（8位）：比较来自多个上游路由器的ECMP重定向时的第一个分界线。首选数值较小的值。保留值（15）用于指示首选字段后面的度量值是网络时间协议（NTP）时间戳，以[RFC5905]中指定的格式编码，在发送路由器开始从该接口转发时获取。
Metric (64 bits): The second tiebreaker if the Preference values are the same. A numerically smaller value is preferred. This Metric can contain path parameters defined by users. When the Preference and Metric values are the same, the Neighbor Address or Interface ID field is used as the third tiebreaker, depending on which field is used to identify the RPF neighbor; the bigger value wins.
公制（64位）：如果首选项值相同，则为第二个tiebreaker。首选数值较小的值。此度量可以包含用户定义的路径参数。当首选项和度量值相同时，邻居地址或接口ID字段用作第三个分接器，具体取决于用于标识RPF邻居的字段；价值越大，赢家就越多。
A PIM-Hello Option Type (32) has been assigned to the PIM ECMP Redirect Hello Option.
PIM Hello选项类型（32）已分配给PIM ECMP重定向Hello选项。
In the PIM Message Types registry created by [RFC6166], a PIM Message Type (11) has been assigned to the ECMP Redirect message.
在[RFC6166]创建的PIM消息类型注册表中，已将PIM消息类型（11）分配给ECMP重定向消息。
Security of the ECMP Redirect is only guaranteed by the security of the PIM packet; the security considerations for PIM Assert packets as described in [RFC4601] apply here. Spoofed ECMP Redirect packets may cause the downstream routers to send PIM Joins to an undesired upstream router and trigger more ECMP Redirect messages. Security considerations for PIM packets described in [RFC4601] also apply to the new Hello option defined here.
ECMP重定向的安全性仅由PIM数据包的安全性保证；[RFC4601]中描述的PIM断言数据包的安全注意事项适用于此处。伪造的ECMP重定向数据包可能导致下游路由器向不希望的上游路由器发送PIM连接，并触发更多ECMP重定向消息。[RFC4601]中描述的PIM数据包的安全注意事项也适用于此处定义的新Hello选项。
The authors would like to thank Apoorva Karan for helping with the original idea, and Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig Venaas, Jeffrey Zhang, Bill Atwood, and Adrian Farrel for their review comments.
作者要感谢Aporva Karan对原始想法的帮助，以及Eric Rosen、Isidor Kouvelas、Toerless Eckert、Stig Venaas、Jeffrey Zhang、Bill Atwood和Adrian Farrel的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166, April 2011.
[RFC6166]Venaas，S.，“PIM消息类型的注册表”，RFC6166，2011年4月。
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC 6395, October 2011.
[RFC6395]Gullajani，S.和S.Venaas，“PIM的接口标识符（ID）Hello选项”，RFC 63952011年10月。
Authors' Addresses
作者地址
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
美国加利福尼亚州拉阿维尼达山景大道1065号益群蔡微软公司，邮编94043
EMail: yiqunc@microsoft.com
EMail: yiqunc@microsoft.com
Liming Wei Cisco Systems, Inc. Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道（邮编：95134）利明伟思科系统有限公司
EMail: lwei@cisco.com
EMail: lwei@cisco.com
Heidi Ou Cisco Systems, Inc. Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道海蒂欧思科系统有限公司，邮编95134
EMail: hou@cisco.com
EMail: hou@cisco.com
Vishal Arya DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 USA
Vishal Arya DIRECTV Inc.美国加利福尼亚州塞贡多帝国大道东2230号，邮编90245
EMail: varya@directv.com
EMail: varya@directv.com
Sunil Jethwani DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 USA
Sunil Jethwani DIRECTV Inc.美国加利福尼亚州塞贡多帝国大道东2230号，邮编90245
EMail: sjethwani@directv.com
EMail: sjethwani@directv.com