Network Working Group IJ. Wijnands
Request for Comments: 5496 A. Boers
Category: Standards Track E. Rosen
Cisco Systems, Inc.
March 2009
Network Working Group IJ. Wijnands
Request for Comments: 5496 A. Boers
Category: Standards Track E. Rosen
Cisco Systems, Inc.
March 2009
The Reverse Path Forwarding (RPF) Vector TLV
反向路径转发（RPF）向量TLV
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree.
本文档描述了RFC 5384中定义的协议独立多播（PIM）连接属性的使用，该属性使PIM能够通过启用MPLS的网络构建多播树，即使该网络的IGP没有到树源的路由。
Table of Contents
目录
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Use of the RPF Vector TLV .......................................3
3.1. Attribute and Shared Tree Joins ............................4
3.2. Attribute and Bootstrap Messages ...........................4
3.3. The Vector Attribute .......................................4
3.3.1. Inserting a Vector Attribute in a Join ..............4
3.3.2. Processing a Received Vector Attribute ..............5
3.3.3. Vector Attribute and Asserts ........................5
3.3.4. Vector Attribute and Join Suppression ...............6
4. Vector Attribute TLV Format .....................................6
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................7
8. Normative References ............................................7
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Use of the RPF Vector TLV .......................................3
3.1. Attribute and Shared Tree Joins ............................4
3.2. Attribute and Bootstrap Messages ...........................4
3.3. The Vector Attribute .......................................4
3.3.1. Inserting a Vector Attribute in a Join ..............4
3.3.2. Processing a Received Vector Attribute ..............5
3.3.3. Vector Attribute and Asserts ........................5
3.3.4. Vector Attribute and Join Suppression ...............6
4. Vector Attribute TLV Format .....................................6
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................7
8. Normative References ............................................7
It is sometimes convenient to distinguish the routers of a particular network into two categories: "edge routers" and "core routers". The edge routers attach directly to users or to other networks, but the core routers attach only to other routers of the same network. If the network is MPLS-enabled, then any unicast packet that needs to travel outside the network can be "tunneled" via MPLS from one edge router to another. To handle a unicast packet that must travel outside the network, an edge router needs to know which of the other edge routers is the best exit point from the network for that packet's destination IP address. The core routers, however, do not need to have any knowledge of routes that lead outside the network; as they handle only tunneled packets, they only need to know how to reach the edge routers and the other core routers.
有时可以方便地将特定网络的路由器分为两类：“边缘路由器”和“核心路由器”。边缘路由器直接连接到用户或其他网络，但核心路由器仅连接到同一网络的其他路由器。如果网络启用MPLS，则需要在网络外部传输的任何单播数据包都可以通过MPLS从一个边缘路由器“隧道”到另一个边缘路由器。要处理必须在网络外传输的单播数据包，边缘路由器需要知道其他边缘路由器中的哪一个是该数据包目标IP地址的最佳网络出口点。然而，核心路由器不需要知道通向网络外部的路由；由于他们只处理隧道数据包，他们只需要知道如何到达边缘路由器和其他核心路由器。
Consider, for example, the case where the network is an Autonomous System (AS), the edge routers are External Border Gateway Protocol (EBGP) speakers, the core routers may be said to constitute a "BGP-free core". The edge routers distribute BGP routes to each other, but not to the core routers.
例如，考虑网络是自治系统（AS）的情况，边缘路由器是外部边界网关协议（EBGP）扬声器，核心路由器可以被称为构成“BGP自由核心”。边缘路由器将BGP路由分配给彼此，但不分配给核心路由器。
However, when multicast packets are considered, the strategy of keeping the core routers free of "external" routes is more problematic. When using PIM Sparse-Mode (PIM-SM) [RFC4601], PIM Source-Specific Mode (PIM-SSM) [RFC4607], or Bidirectional PIM (BIDIR-PIM) [RFC5015] to create a multicast distribution tree for a particular multicast group, one wants the core routers to be full participants in the PIM protocol, so that multicasting can be done efficiently in the core. This means that the core routers must be
然而，当考虑多播数据包时，保持核心路由器不受“外部”路由影响的策略问题更大。当使用PIM稀疏模式（PIM-SM）[RFC4601]、PIM源特定模式（PIM-SSM）[RFC4607]或双向PIM（BIDIR-PIM）[RFC5015]为特定多播组创建多播分发树时，人们希望核心路由器成为PIM协议的完全参与者，以便可以在核心中高效地进行多播。这意味着核心路由器必须
able to correctly process PIM Join messages for the group, which in turn means that the core routers must be able to send the Join messages towards the root of the distribution tree. If the root of the tree lies outside the network's borders (e.g., is in a different AS), and the core routers do not maintain routes to external destinations, then the PIM Join messages cannot be processed, and the multicast distribution tree cannot be created.
能够正确处理组的PIM连接消息，这反过来意味着核心路由器必须能够向分发树的根发送连接消息。如果树的根位于网络边界之外（例如，位于不同的AS中），并且核心路由器不维护到外部目的地的路由，则无法处理PIM连接消息，并且无法创建多播分发树。
In order to allow PIM to work properly in an environment where the core routers do not maintain external routes, a PIM extension is needed. When an edge router sends a PIM Join message into the core, it MUST include in that message a "Vector" that specifies the IP address of the next edge router along the path to the root of the multicast distribution tree. The core routers can then process the Join message by sending it towards the specified edge router (i.e., toward the Vector). In effect, the Vector serves as an attribute, within a particular network, for the root of the tree.
为了使PIM在核心路由器不维护外部路由的环境中正常工作，需要PIM扩展。当边缘路由器向核心发送PIM连接消息时，它必须在该消息中包含一个“向量”，该向量指定沿多播分发树根路径的下一个边缘路由器的IP地址。然后，核心路由器可以通过向指定的边缘路由器（即，向向量）发送连接消息来处理连接消息。实际上，向量在特定网络中充当树根的属性。
This document defines a new TLV in the PIM Join Attribute message [RFC5384]. It consists of a single Vector that identifies the exit point of the network.
本文档在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]中所述进行解释。
Before a router can start forwarding multicast packets, it is necessary to build a forwarding tree by sending PIM Joins hop-by-hop. Each router in the path creates a forwarding state and propagates the Join towards the root of the forwarding tree. The building of this tree is receiver driven. See Figure 1.
在路由器开始转发多播数据包之前，必须通过逐跳发送PIM连接来构建转发树。路径中的每个路由器创建一个转发状态，并将连接传播到转发树的根。这棵树是由接收器驱动的。参见图1。
------------------ BGP -----------------
| |
[S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R]
<--- (S,G) Join
------------------ BGP -----------------
| |
[S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R]
<--- (S,G) Join
Figure 1
图1
In this example, the two edge routers are BGP speakers. The core routers are not BGP speakers and do not have any BGP distributed routes. The route to S is a BGP distributed route; hence, it is known to the edge but not to the core. The Edge 2 router determines the interface leading to S, and sends a PIM Join to the upstream
在本例中，两个边缘路由器是BGP扬声器。核心路由器不是BGP扬声器，也没有任何BGP分布式路由。到S的路由为BGP分布式路由；因此，边缘已知，但核心不知道。Edge 2路由器确定通向S的接口，并向上游发送PIM连接
router. In this example, though, the upstream router is a core router, with no route to S. Without the PIM extensions specified in this document, the core router cannot determine where the send the Join, so the tree cannot be constructed.
路由器。然而，在本例中，上游路由器是一个核心路由器，没有到S的路由。没有本文档中指定的PIM扩展，核心路由器无法确定发送连接的位置，因此无法构建树。
To allow the core router to participate in the construction of the tree, the Edge 2 router includes an "RPF (Reverse Path Forwarding) Vector" TLV in the PIM Join Attribute [RFC5384] of the PIM Join. In this example, the RPF Vector TLV will contain the IP address of Edge 1. Edge 2 forwards the PIM Join towards Edge 1. Each intermediate core router does its RPF check [RFC4601] on the address contained in the RPF Vector TLV (i.e., on the IP address of Edge 1), instead of doing the RPF check on the address S. This allows the tree to be constructed.
为了允许核心路由器参与树的构建，边缘2路由器在PIM连接的PIM连接属性[RFC5384]中包括“RPF（反向路径转发）向量”TLV。在本例中，RPF向量TLV将包含边缘1的IP地址。边缘2将PIM连接向前移动至边缘1。每个中间核心路由器对RPF向量TLV中包含的地址（即边缘1的IP地址）进行RPF检查[RFC4601]，而不是对地址S进行RPF检查。这允许构建树。
In the example above, we build a source tree to illustrate the attribute behavior. Use of the attribute is, however, not restricted to the construction of source trees. It may also be used to construct a shared tree. In this case, the RPF Vector TLV contains the IP address of a Rendezvous Point (RP). Procedures defined in this document for (S,G) Joins are equally applicable to (*,G) and (*,*,RP) Joins unless otherwise noted.
在上面的示例中，我们构建了一个源树来说明属性行为。但是，该属性的使用不限于构建源树。它还可用于构造共享树。在这种情况下，RPF向量TLV包含集合点（RP）的IP地址。除非另有说明，本文件中定义的（S，G）连接程序同样适用于（*，G）和（*，*，RP）连接。
There is no way to carry an RPF Vector TLV in a Bootstrap Router (BSR) bootstrap message. The procedures in this document do not define a way for BSR messages to be forwarded across a core in which the BSP IP address is not routable.
在引导路由器（BSR）引导消息中无法携带RPF向量TLV。本文档中的过程未定义BSR消息在BSP IP地址不可路由的核心间转发的方式。
In the example of Figure 1, when the Edge 2 router looks up the route to the source of the multicast distribution tree, it will find a BGP-distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks up the route to Edge 1 to find the next hop to the source, namely Core 2.
在图1的示例中，当Edge 2路由器查找到多播分发树源的路由时，它将找到一个“BGP下一跳”为Edge 1的BGP分布式路由。然后，边缘2查找到边缘1的路由，以查找到源的下一个跃点，即核心2。
When Edge 2 sends a PIM Join to Core 2, it includes a Vector Attribute specifying the address of Edge 1. Core 2, and subsequent core routers, will forwarding the Join along the Vector (i.e., towards Edge 1) instead of trying to forward it towards S.
当边缘2向核心2发送PIM连接时，它包含一个向量属性，指定边缘1的地址。核心2和后续的核心路由器将沿着向量（即，向边缘1）转发连接，而不是尝试向S转发连接。
Whether an attribute is actually needed depends on whether the Core routers have a route to the source of the multicast tree. How the Edge router knows whether or not this is the case (and thus how the Edge router determines whether or not to insert an attribute field) is outside the scope of this document.
是否实际需要属性取决于核心路由器是否有到多播树源的路由。边缘路由器如何知道是否存在这种情况（以及边缘路由器如何确定是否插入属性字段）超出了本文档的范围。
When processing a received PIM Join that contains a Vector Attribute, a router MUST first check to see if the Vector IP address is one of its own IP addresses. If so, the Vector Attribute is discarded, and not passed further upstream. Otherwise, the Vector Attribute is used to find the route to the source, and is passed along when a PIM Join is sent upstream. Note that a router that receives a Vector Attribute MUST use it, even if that router happens to have a route to the source. A router that discards a Vector Attribute MAY of course insert a new Vector Attribute. This would typically happen if a PIM Join needed to pass through a sequence of Edge routers, each pair of which is separated by a core that does not have external routes. In the absence of periodic refreshment, Vectors expire along with the corresponding (S,G) state.
当处理接收到的包含向量属性的PIM连接时，路由器必须首先检查向量IP地址是否是其自己的IP地址之一。如果是这样，向量属性将被丢弃，并且不会进一步向上游传递。否则，Vector属性用于查找到源的路由，并在向上游发送PIM连接时传递。请注意，接收向量属性的路由器必须使用它，即使该路由器碰巧有到源的路由。丢弃向量属性的路由器当然可以插入新的向量属性。如果PIM连接需要通过一系列边缘路由器（每对路由器由一个没有外部路由的核心分隔），则通常会发生这种情况。在没有定期刷新的情况下，向量将随着相应的（S，G）状态一起过期。
A PIM Assert message includes the routing protocol's "metric" to the source of the tree. This information is used in the selection of the Assert winner. If a PIM Join is being sent towards a Vector, rather than towards the source, the Assert message MUST have the metric to the Vector instead of the metric to the source. The Assert message however does not have an attribute field and does not mention the Vector.
PIM断言消息包括路由协议到树源的“度量”。此信息用于选择断言获胜者。如果PIM联接是向向量而不是向源发送的，则断言消息必须具有指向向量的度量，而不是指向源的度量。但是，断言消息没有属性字段，也没有提到向量。
A router may change its upstream neighbor on a particular multicast tree as the result of receiving Assert messages. However, a Vector Attribute MUST NOT be sent in a PIM Join to an upstream neighbor that is chosen as the result of Assert processing, if that neighbor is different than the original upstream neighbor. Reachability of the Vector is only guaranteed by the router that advertises reachability to the Vector in its IGP. If the Assert winner upstream is not the real preferred next-hop, it is possible that the Assert winner does not know the path to the Vector. In the worst case the Assert winner has a route to the Vector that is on the same interface where the Assert was won. That will point the RPF interface to that interface and will result in the O-list being NULL. The Vector Attribute therefore MUST NOT be inserted if the RPF neighbor was chosen via an Assert process and the RPF neighbor is different from the RPF neighbor that would have been selected via the local routing table. In all other cases, the Vector MUST be included in the Join message.
路由器接收断言消息后，可能会改变其在特定多播树上的上游邻居。但是，如果作为断言处理结果选择的上游邻居与原始上游邻居不同，则不得在PIM联接中向该邻居发送向量属性。矢量的可达性仅由在其IGP中宣传矢量可达性的路由器来保证。如果断言优胜者上游不是真正的首选下一跳，则断言优胜者可能不知道向量的路径。在最坏的情况下，断言获胜者有一条到向量的路由，该向量位于断言获胜者所在的同一接口上。这将使RPF接口指向该接口，并将导致O-list为NULL。因此，如果RPF邻居是通过断言过程选择的，并且RPF邻居与通过本地路由表选择的RPF邻居不同，则不得插入Vector属性。在所有其他情况下，向量必须包含在连接消息中。
If a router receives a PIM Join on the upstream LAN interface for a particular multicast state, Join suppression may be applied if that PIM Join is targeted to the same upstream neighbor. Which router(s) will suppress their PIM Join is dependent on timing and is unpredictable. Downstream routers on a LAN MAY include different RPF Vectors in the PIM Joins. Therefore, an upstream router on that LAN may receive and use different RPF Vectors over time to reach the destination (depending on which downstream router(s) suppressed their Join). To make the upstream router behavior more predictable, the RPF Vector address MUST be used as additional condition to the Join suppression logic. Only if the RPF Vector in the PIM Join matches the RPF Vector in the multicast state, the suppression logic is applied. It is also possible to disable Join suppression on that LAN.
如果路由器在特定多播状态的上游LAN接口上接收到PIM连接，则如果该PIM连接针对同一上游邻居，则可以应用连接抑制。哪些路由器将抑制其PIM连接取决于时间，并且不可预测。LAN上的下游路由器可以在PIM连接中包括不同的RPF向量。因此，该LAN上的上游路由器可以随时间接收并使用不同的RPF向量来到达目的地（取决于哪个下游路由器抑制了它们的加入）。为了使上游路由器的行为更加可预测，必须将RPF向量地址用作连接抑制逻辑的附加条件。仅当PIM连接中的RPF向量与多播状态中的RPF向量匹配时，才会应用抑制逻辑。也可以在该LAN上禁用连接抑制。
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|S| 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|S| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
F bit Forward Unknown TLV. If this bit is set, the TLV is forwarded regardless of whether the router understands the Type. If the TLV is known, the F bit is ignored.
F位前向未知TLV。如果设置了该位，则无论路由器是否理解该类型，TLV都会被转发。如果TLV已知，则忽略F位。
S bit Bottom of Stack. If this bit is set, then this is the last TLV in the stack.
在堆栈的底部有位。如果设置了该位，则这是堆栈中的最后一个TLV。
Type The Vector Attribute type is 0.
类型向量属性类型为0。
Length Length depending on Address Family of Encoded-Unicast address.
长度取决于编码单播地址的地址族。
Value Encoded-Unicast address.
值编码单播地址。
IANA has assigned the value 0 to the RPF Vector in the "PIM Join Attribute Types" registry.
IANA已将值0分配给“PIM连接属性类型”注册表中的RPF向量。
Security of the 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 [RFC4601] apply here.
RPF向量属性的安全性仅由PIM数据包的安全性保证，因此PIM-SM[RFC4601]中描述的PIM连接数据包的安全注意事项适用于此处。
The authors would like to thank Yakov Rekhter and Dino Farinacci for their initial ideas on this topic and Su Haiyang for the comments on the document.
作者要感谢雅科夫·雷克特和迪诺·法里纳奇对此主题的初步想法，并感谢苏海阳对该文件的评论。
[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月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[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月。
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[RFC5384]Boers，A.，Wijnands，I.，和E.Rosen，“协议独立多播（PIM）连接属性格式”，RFC 5384，2008年11月。
Authors' Addresses
作者地址
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijlands Cisco Systems，Inc.De kleetlaan 6a Diegem 1831比利时
EMail: ice@cisco.com
EMail: ice@cisco.com
Arjen Boers Cisco Systems, Inc. Avda. Diagonal, 682 Barcelona 08034 Spain
Arjen Boers思科系统公司Avda。对角线，682巴塞罗那08034西班牙
EMail: aboers@cisco.com
EMail: aboers@cisco.com
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, Ma 01719
Eric Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com