Internet Engineering Task Force (IETF) J. Asghar
Request for Comments: 7891 IJ. Wijnands, Ed.
Category: Standards Track S. Krishnaswamy
ISSN: 2070-1721 A. Karan
Cisco Systems
V. Arya
DIRECTV Inc.
June 2016
Internet Engineering Task Force (IETF) J. Asghar
Request for Comments: 7891 IJ. Wijnands, Ed.
Category: Standards Track S. Krishnaswamy
ISSN: 2070-1721 A. Karan
Cisco Systems
V. Arya
DIRECTV Inc.
June 2016
Explicit Reverse Path Forwarding (RPF) Vector
显式反向路径转发（RPF）向量
Abstract
摘要
The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.
RFC 5496中定义的PIM反向路径转发（RPF）向量TLV可以包括在PIM连接属性中，使得基于RPF向量的单播可达性而不是与多播树相关联的源或集合点来选择RPF邻居。
This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.
本文档定义了一种新的RPF矢量属性类型，这样就可以在PIM Join属性中对显式RPF邻居列表进行编码，从而绕过单播路由查找。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7891.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7891.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use of the PIM Explicit RPF Vector . . . . . . . . . . . . . 4
5. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5
6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 5
7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5
8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 6
10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use of the PIM Explicit RPF Vector . . . . . . . . . . . . . 4
5. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5
6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 5
7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5
8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 6
10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
The procedures in [RFC5496] define how an RPF Vector can be used to influence the path selection in the absence of a route to the source. The same procedures can be used to override a route to the source when it exists. It is possible to include multiple RPF Vectors in the list where each router along the path will perform a unicast route lookup on the first Vector in the attribute list. Once the router owning the address of the RPF Vector is reached, following the procedures in [RFC5496], the RPF Vector will be removed from the attribute list. This will result in a 'loosely' routed path that still depends on unicast reachability to the RPF Vector(s).
[RFC5496]中的程序定义了在没有到源的路由的情况下，如何使用RPF向量来影响路径选择。当存在到源的路由时，可以使用相同的过程覆盖该路由。可以在列表中包括多个RPF向量，其中路径上的每个路由器将对属性列表中的第一个向量执行单播路由查找。一旦到达拥有RPF向量地址的路由器，按照[RFC5496]中的步骤，RPF向量将从属性列表中删除。这将导致“松散”路由路径仍然依赖于RPF向量的单播可达性。
In some scenarios, the network administrators don't want to rely on the unicast reachability to the RPF Vector address and want to build a path strictly based on the RPF Vectors. In that case, the RPF Vectors represent a list of directly connected PIM neighbors along the path. For these Vectors, the router would not do a route lookup in the unicast routing table. These Vectors are referred to as 'Explicit' RPF Vector addresses. If a router receiving an Explicit RPF Vector does not have a PIM neighbor matching the Explicit RPF Vector address, it does not fall back to loosely routing the Join. Instead, it could process the packet and store the RPF Vector list so that the PIM Join can be sent out as soon as the neighbor comes up. Since the behavior of the Explicit RPF Vector differs from the 'loose' RPF Vector as defined in [RFC5496], a new attribute called the Explicit RPF Vector is defined.
在某些场景中，网络管理员不希望依赖于RPF向量地址的单播可达性，而是希望严格基于RPF向量构建路径。在这种情况下，RPF向量表示沿路径直接连接的PIM邻居的列表。对于这些向量，路由器不会在单播路由表中进行路由查找。这些向量称为“显式”RPF向量地址。如果接收显式RPF向量的路由器没有与显式RPF向量地址匹配的PIM邻居，则不会退回到松散地路由联接。相反，它可以处理数据包并存储RPF向量列表，以便在邻居出现时立即发送PIM连接。由于显式RPF向量的行为不同于[RFC5496]中定义的“松散”RPF向量，因此定义了一个称为显式RPF向量的新属性。
This document defines a new TLV in the PIM Join Attribute message [RFC5384] for specifying the explicit path.
本文档在PIM连接属性消息[RFC5384]中定义了一个新的TLV，用于指定显式路径。
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]中所述进行解释。
Some broadcast video transport networks use a multicast PIM Live-Live resiliency model for video delivery based on PIM Source-Specific Multicast (PIM-SSM) or PIM Any-Source Multicast (PIM-ASM). Live-Live implies using two active, spatially diverse multicast trees to transport video flows from root to leaf multicast routers. The leaf multicast router receives two copies from the PIM multicast core and will replicate one copy towards the receivers [RFC7431].
一些广播视频传输网络使用基于PIM源特定多播（PIM-SSM）或PIM任意源多播（PIM-ASM）的多播PIM实时弹性模型进行视频传输。Live-Live意味着使用两个活动的、空间上不同的多播树将视频流从根多播路由器传输到叶多播路由器。叶子多播路由器从PIM多播核心接收两个副本，并向接收器复制一个副本[RFC7431]。
One of the requirements of the PIM Live-Live resiliency model is to ensure path diversity of the two active PIM trees in the core such that they do not intersect to avoid a single point of failure. IGP-routed RPF paths of two PIM trees could be routed over the same transit router and create a single point of failure. It is useful to have a way to specify the explicit path along which the PIM Join is propagated.
PIM实时弹性模型的要求之一是确保核心中两个活动PIM树的路径多样性，以确保它们不相交，从而避免单点故障。两个PIM树的IGP路由RPF路径可以路由到同一个传输路由器上，并产生单点故障。有一种方法可以指定PIM联接传播的显式路径，这很有用。
How the Explicit RPF Vector list is determined is outside the scope of this document. For example, it may either be manually configured by the network operator or procedures may be implemented on the egress router to dynamically calculate the Vector list based on a link-state database protocol, like OSPF or IS-IS.
如何确定显式RPF向量列表超出了本文档的范围。例如，它可以由网络运营商手动配置，或者可以在出口路由器上实现基于链路状态数据库协议（如OSPF或IS-IS）动态计算向量列表的过程。
Due to the fact that the leaf router receives two copies of the multicast stream via two diverse paths, there is no need for PIM to repair the broken path immediately. It is up to the egress router to either wait for the broken path to be repaired or build a new explicit path using a new RPF Vector list. Which method is applied depends very much on how the Vector list was determined initially. Double failures are not considered and are outside the scope of this document.
由于叶路由器通过两条不同的路径接收多播流的两个副本，因此PIM不需要立即修复断开的路径。由出口路由器等待修复断开的路径，或者使用新的RPF向量列表构建新的显式路径。采用哪种方法在很大程度上取决于向量列表最初是如何确定的。不考虑双重故障，不在本文件范围内。
This document describes the procedures to carry Explicit RPF Vectors in PIM. It is up to the mechanism(s) that produce the Explicit RPF Vectors to ensure they are correct. Existing mechanisms like [MTRACE-V2] may be used to verify how the PIM tree was built.
本文档描述了在PIM中携带显式RPF向量的过程。由生成显式RPF向量的机制来确保它们是正确的。[MTRACE-V2]等现有机制可用于验证PIM树是如何构建的。
Figure 1 provides an example multicast join path R4->R3->R6->R5->R2->R1, where the multicast join is explicitly routed to the source hop by hop using the Explicit RPF Vector list. When the R5-R6 link fails, the Join will NOT take an alternate path.
图1提供了一个示例多播连接路径R4->R3->R6->R5->R2->R1，其中多播连接使用显式RPF向量列表显式地逐跳路由到源。当R5-R6链路失败时，连接将不会采用备用路径。
[S]---(R1)--(R2)---(R3)--(R4)---[R]
<--- | | ---
| | | |
| (R5)---(R6) |
- (S,G) Join -
| |
| |
(R7)---(R8)
[S]---(R1)--(R2)---(R3)--(R4)---[R]
<--- | | ---
| | | |
| (R5)---(R6) |
- (S,G) Join -
| |
| |
(R7)---(R8)
Figure 1
图1
In comparison, when the procedures specified in [RFC5496] are used, if the R5-R6 link fails, then the Join may be rerouted using the R6-R8-R7 path to reach R5.
相比之下，当使用[RFC5496]中规定的程序时，如果R5-R6链路失败，则可以使用R6-R8-R7路径重新路由连接，以到达R5。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
Figure 2
图2
F bit: 'Transitive Attribute' bit. The F bit MUST be set to 0. Otherwise, there could be loops.
F位：“可传递属性”位。F位必须设置为0。否则，可能会出现循环。
E bit: 'End of Attributes' bit. If the E bit is set, then this is the last TLV specified in the list.
E位：“属性结束”位。如果设置了E位，则这是列表中指定的最后一个TLV。
Type: 4 (Explicit RPF Vector)
类型：4（显式RPF向量）
Length: The length depending on the Address Family (IPv4 or IPv6) of the Encoded-Unicast address.
长度：长度取决于编码单播地址的地址族（IPv4或IPv6）。
Value: Encoded-Unicast address. This SHOULD be a valid IPv4 or IPv6 address of an upstream router.
值：编码的单播地址。这应该是上游路由器的有效IPv4或IPv6地址。
The Explicit RPF Vector Attribute does not impact or restrict the functionality of other RPF Vector Attributes in a PIM Join. It is possible to mix Vectors of different types such that some part of the tree is explicit and other parts are loosely routed. RPF Vectors are processed in the order in which they are specified.
显式RPF向量属性不会影响或限制PIM联接中其他RPF向量属性的功能。可以混合不同类型的向量，以便树的某些部分是显式的，而其他部分是松散路由的。RPF向量按照指定的顺序进行处理。
It is possible that a PIM router has multiple downstream neighbors. If for the same multicast route there is an inconsistency between the Explicit RPF Vector lists provided by the downstream PIM neighbor, the procedures as documented in Section 3.3.3 of [RFC5384] apply.
PIM路由器可能有多个下游邻居。如果对于相同的多播路由，下游PIM邻居提供的显式RPF向量列表之间存在不一致，则[RFC5384]第3.3.3节中记录的程序适用。
The conflict resolution procedures in Section 3.3.3 of [RFC5384] only apply to attributes of the same Join Attribute type. Join Attributes that have a different type can't be compared because the content of the Join Attribute may have a totally different meaning and/or encoding. This may cause a problem if a mix of Explicit RPF Vectors
[RFC5384]第3.3.3节中的冲突解决程序仅适用于相同连接属性类型的属性。无法比较具有不同类型的联接属性，因为联接属性的内容可能具有完全不同的含义和/或编码。如果混合使用显式RPF向量，则可能会导致问题
(this document) and 'loose' RPF Vectors [RFC5496] is received from two or more downstream routers. The order in which the RPF Vectors are encoded may be different, and/or the combination of RPF Vectors may be inconsistent. The procedures in Section 3.3.3 of [RFC5384] would not resolve the conflict. The following procedures MUST be applied to deal with this scenario.
（本文件）和“松散”RPF向量[RFC5496]从两个或多个下游路由器接收。RPF向量的编码顺序可能不同，和/或RPF向量的组合可能不一致。[RFC5384]第3.3.3节中的程序无法解决冲突。必须应用以下程序来处理此场景。
When a PIM Join with a Join Attribute list is received from a downstream neighbor, the router MUST verify that the order in which the RPF Vector types appear in the PIM Join Attribute list matches what is stored as the Join Attribute list for reaching the source or Rendezvous Point listed in the PIM Join. Once it is determined that the RPF Vector types on the stack are equal, the content of the RPF Vectors MUST be compared ([RFC5384]). If it is determined that there is either a conflict with RPF Vector types or the RPF Vector content, the router uses the RPF Vector stack from the PIM adjacency with the numerically smallest IP address. In the case of IPv6, the link-local address will be used. When two neighbors have the same IP address, either for IPv4 or IPv6, the interface index MUST be used as a tie breaker. It's RECOMMENDED that the router doing the conflict resolution log a message.
当从下游邻居接收到具有连接属性列表的PIM连接时，路由器必须验证RPF向量类型在PIM连接属性列表中出现的顺序是否与存储为连接属性列表的顺序相匹配，以便到达PIM连接中列出的源或集合点。一旦确定堆栈上的RPF向量类型相等，就必须比较RPF向量的内容（[RFC5384]）。如果确定与RPF向量类型或RPF向量内容存在冲突，则路由器使用PIM邻接处的RPF向量堆栈和数字上最小的IP地址。在IPv6的情况下，将使用链路本地地址。如果两个邻居具有相同的IP地址（IPv4或IPv6），则必须将接口索引用作连接断开器。建议执行冲突解决的路由器记录一条消息。
Section 3.3.3 of [RFC5496] specifies the procedures for how to deal with PIM Asserts when RPF Vectors are used. The same procedures apply to the Explicit RPF Vector. There is a minor behavioral difference: the route 'metric' that is included in the PIM Assert should be the route metric of the first Explicit RPF Vector address in the list. However, the first Explicit Vector should always be directly connected, so the metric may likely be zero. The metric will therefore not be a tie breaker in the PIM Assert selection procedure.
[RFC5496]第3.3.3节规定了使用RPF向量时如何处理PIM断言的程序。同样的过程也适用于显式RPF向量。有一个较小的行为差异：PIM断言中包含的路由“metric”应该是列表中第一个显式RPF向量地址的路由度量。但是，第一个显式向量应始终直接连接，因此度量可能为零。因此，在PIM断言选择程序中，该指标将不会成为一个平局断路器。
Section 3.3.4 of [RFC5496] specifies the procedures for how to apply Join Suppression when an RPF Vector Attribute is included in the PIM Join. The same procedure applies to the Explicit RPF Vector Attribute. The procedure MUST match against all the Explicit RPF Vectors in the PIM Join before a PIM Join can be suppressed.
[RFC5496]第3.3.4节规定了当RPF向量属性包含在PIM连接中时，如何应用连接抑制的程序。同样的过程也适用于显式RPF向量属性。该过程必须与PIM联接中的所有显式RPF向量匹配，才能抑制PIM联接。
The F bit MUST be set to 0 in all Explicit RPF Vectors in case the upstream router receiving the Join does not support the TLV. As described in Section 3.3.2 of [RFC5384], routers that do not understand the type of a particular attribute that has the F bit clear will discard it and continue to process the Join.
如果接收连接的上游路由器不支持TLV，则在所有显式RPF向量中，F位必须设置为0。如[RFC5384]第3.3.2节所述，不了解具有F位清除的特定属性类型的路由器将丢弃该属性并继续处理连接。
This processing is particularly important when the routers that do not support the Explicit RPF TLV are identified as hops in the Explicit RPF list because failing to remove the RPF Vectors could cause upstream routers to send the Join back toward these routers causing loops.
当不支持显式RPF TLV的路由器被标识为显式RPF列表中的跳时，此处理尤其重要，因为未能移除RPF向量可能导致上游路由器将连接发送回这些路由器，从而导致循环。
As the administrator is manually specifying the path that the Joins need to be sent on, it is recommended that the administrator computes the path to include routers that support the Explicit Vector and check that the state is created correctly on each router along the path. Tools like mtrace can be used for debugging and to ensure that the Join state is setup correctly.
由于管理员正在手动指定连接需要发送的路径，建议管理员计算该路径以包括支持显式向量的路由器，并检查沿该路径的每个路由器上是否正确创建了状态。mtrace等工具可用于调试和确保正确设置联接状态。
In the "PIM Join Attribute Types" registry, IANA has assigned the value 4 to the Explicit RPF Vector Attribute.
在“PIM连接属性类型”注册表中，IANA已将值4指定给显式RPF向量属性。
Security of the Explicit RPF Vector Attribute is only guaranteed by the security of the PIM packet, so the security considerations for PIM Join packets as described in PIM-SM [RFC7761] apply here. A malicious downstream node can attempt a denial-of-service attack by sending PIM Join packets with invalid addresses listed in the RPF Vector stack with an intent to stop the propagation of the Joins to the correct upstream node. Another denial-of-service attack would be a malicious downstream node targeting all Joins to a specific node with an intent to overload the bandwidth on that node by making it responsible for forwarding multicast traffic for more streams that it can handle. In order to minimize the risk of a denial-of-service attack from forged PIM Join packets with Explicit RPF Vector stack, it should be used within a single trusted management domain.
显式RPF向量属性的安全性仅由PIM数据包的安全性保证，因此PIM-SM[RFC7761]中描述的PIM连接数据包的安全注意事项适用于此处。恶意下游节点可以通过发送RPF向量堆栈中列出的地址无效的PIM连接数据包来尝试拒绝服务攻击，目的是阻止连接传播到正确的上游节点。另一种拒绝服务攻击是恶意下游节点，其目标是指向特定节点的所有连接，目的是通过使该节点负责转发其可以处理的更多流的多播流量，从而使该节点上的带宽过载。为了最大限度地降低伪造的具有显式RPF向量堆栈的PIM连接数据包的拒绝服务攻击风险，应在单个可信管理域内使用该数据包。
If a router finds that it cannot use the Vector list due to the next hop router not being a PIM neighbor, it may log an error. Also, if a router is receiving two conflicting Vectors, it may log an error. It is up to the mechanisms that produced the Explicit RPF Vector to ensure that the PIM tree is built correctly and to monitor any error logs.
如果路由器发现由于下一跳路由器不是PIM邻居而无法使用向量列表，它可能会记录错误。此外，如果路由器接收到两个冲突向量，它可能会记录错误。由生成显式RPF向量的机制来确保正确构建PIM树并监视任何错误日志。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, DOI 10.17487/RFC5384, November 2008, <http://www.rfc-editor.org/info/rfc5384>.
[RFC5384]Boers，A.，Wijnands，I.，和E.Rosen，“协议独立多播（PIM）连接属性格式”，RFC 5384，DOI 10.17487/RFC5384，2008年11月<http://www.rfc-editor.org/info/rfc5384>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, <http://www.rfc-editor.org/info/rfc5496>.
[RFC5496]Wijnands，IJ.，Boers，A.，和E.Rosen，“反向路径转发（RPF）向量TLV”，RFC 5496，DOI 10.17487/RFC5496，2009年3月<http://www.rfc-editor.org/info/rfc5496>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.
[RFC7761]Fenner，B.，Handley，M.，Holbrook，H.，Kouvelas，I.，Parekh，R.，Zhang，Z.，和L.Zheng，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，STD 83，RFC 7761，DOI 10.17487/RFC7761，2016年3月<http://www.rfc-editor.org/info/rfc7761>.
[MTRACE-V2] Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, draft-ietf-mboned-mtrace-v2-13, June 2016.
[MTRACE-V2]Asaeda，H.，Meyer，K.，和W.Lee，“MTRACE版本2：IP多播跟踪路由设施”，正在进行的工作，草案-ietf-mboned-MTRACE-V2-132016年6月。
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, <http://www.rfc-editor.org/info/rfc7431>.
[RFC7431]Karan，A.，Filsfils，C.，Wijnands，IJ.，Ed.，和B.Decraene，“仅组播快速重路由”，RFC 7431，DOI 10.17487/RFC74312015年8月<http://www.rfc-editor.org/info/rfc7431>.
Acknowledgements
致谢
The authors would like to thank Vatsa Kumar, Nagendra Kumar, and Bharat Joshi for their comments on the document.
作者感谢Vatsa Kumar、Nagendra Kumar和Bharat Joshi对该文件的评论。
Authors' Addresses
作者地址
Javed Asghar Cisco Systems 725, Alder Drive Milpitas, CA 95035 United States
Javed Asghar Cisco Systems 725，加利福尼亚州米尔皮塔斯阿尔德大道，邮编95035
Email: jasghar@cisco.com
Email: jasghar@cisco.com
IJsbrand Wijnands (editor) Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（编辑）Cisco Systems De Kleetlaan 6a Diegem 1831比利时
Email: ice@cisco.com
Email: ice@cisco.com
Sowmya Krishnaswamy Cisco Systems 3750 Cisco Way San Jose, CA 95134 United States
美国加利福尼亚州圣何塞市思科路3750号，邮编95134
Email: sowkrish@cisco.com
Email: sowkrish@cisco.com
Apoorva Karan Cisco Systems 3750 Cisco Way San Jose, CA 95134 United States
美国加利福尼亚州圣何塞市思科路3750号，邮编95134
Email: apoorva@cisco.com
Email: apoorva@cisco.com
Vishal Arya DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 United States
Vishal Arya DIRECTV Inc.美国加利福尼亚州塞贡多帝国大道东2230号，邮编90245
Email: varya@directv.com
Email: varya@directv.com