The Reverse Path Forwarding (RPF) Vector TLV
Lets PIM build a multicast tree across a core of routers that hold no routes to the multicast source.
Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, <https://www.rfc-editor.org/info/rfc5496>.
@misc{rfc5496,
series = {Request for Comments},
number = 5496,
howpublished = {RFC 5496},
publisher = {RFC Editor},
doi = {10.17487/RFC5496},
url = {https://www.rfc-editor.org/info/rfc5496},
author = {IJ. Wijnands and A. Boers and E. Rosen},
title = {{The Reverse Path Forwarding (RPF) Vector TLV}},
pagetotal = 8,
year = 2009,
month = mar,
} RFC text
Contents
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
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.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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.
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
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.
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.
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
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.
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.
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.
2. Specification of Requirements
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].
3. Use of the RPF Vector TLV
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.
------------------ BGP -----------------
| |
[S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R]
<--- (S,G) Join
Figure 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
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.
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.
3.1. Attribute and Shared Tree Joins
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.
3.2. Attribute and Bootstrap Messages
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.
3.3. The Vector Attribute
3.3.1. Inserting a Vector Attribute in a Join
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.
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.
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.
3.3.2. Processing a Received Vector Attribute
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.
3.3.3. Vector Attribute and Asserts
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.
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.
3.3.4. Vector Attribute and Join Suppression
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.
4. Vector Attribute TLV Format
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.
S bit
Bottom of Stack. If this bit is set, then this is the last TLV in
the stack.
Type
The Vector Attribute type is 0.
Length
Length depending on Address Family of Encoded-Unicast address.
Value
Encoded-Unicast address.
5. IANA Considerations
IANA has assigned the value 0 to the RPF Vector in the "PIM Join
Attribute Types" registry.
6. Security Considerations
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.
7. Acknowledgments
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.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format", RFC
5384, November 2008.
Authors' Addresses
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
EMail: ice@cisco.com
Arjen Boers
Cisco Systems, Inc.
Avda. Diagonal, 682
Barcelona 08034
Spain
EMail: aboers@cisco.com
Eric Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, Ma 01719
EMail: erosen@cisco.com
ISO Plain Language
On this page
§1The Problem With a Core That Holds No External Routes
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, any unicast packet that needs to travel outside the network can be tunnelled 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 for that packet's destination IP address. The core routers, however, do not need any knowledge of routes that lead outside the network: as they handle only tunnelled packets, they only need to know how to reach the edge routers and the other core routers.
Consider the case where the network is an Autonomous System, the edge routers are External Border Gateway Protocol speakers, and the core routers constitute a BGP-free core. The edge routers distribute BGP routes to each other, but not to the core routers.
With multicast the strategy is more problematic. When using PIM Sparse-Mode, PIM Source-Specific Mode or Bidirectional PIM 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. That means the core routers must be able to correctly process PIM Join messages for the group, which in turn means they must be able to send the Join messages towards the root of the distribution tree. If the root lies outside the network's borders and the core routers do not maintain routes to external destinations, the Join messages cannot be processed and the multicast distribution tree cannot be created.
The fix is a PIM extension. 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 by sending it towards the specified edge router, that is, towards the Vector. In effect, the Vector serves as an attribute, within a particular network, for the root of the tree. This document defines a new TLV in the PIM Join Attribute message of RFC 5384, consisting of a single Vector that identifies the exit point of the network.
Some networks deliberately keep their core routers ignorant of routes outside the network. Only the edge routers know the way out. That is fine for ordinary traffic, which is tunnelled from edge to edge.
Multicast is different. Every router along the path has to send a Join message towards the source, and a core router that has never heard of the source has no way to choose a direction. This document gives the core routers a name to aim at.
§3Building the Tree with a Vector
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 forwarding state and propagates the Join towards the root of the forwarding tree. The building of the tree is receiver driven.
In the RFC's example, a source S sits behind edge router Edge 1 and a receiver R sits behind edge router Edge 2, with core routers between them. The two edge routers are BGP speakers, and the core routers are not BGP speakers and have no BGP-distributed routes. The route to S is a BGP-distributed route, so it is known to the edge but not to the core.
Edge 2 determines the interface leading to S and sends a PIM Join to the upstream router. In this example the upstream router is a core router with no route to S, so without the extensions in this document the core router cannot determine where to send the Join and the tree cannot be constructed. To let the core router take part, Edge 2 includes an RPF Vector TLV in the PIM Join Attribute of the PIM Join, and the TLV contains the IP address of Edge 1. Edge 2 forwards the PIM Join towards Edge 1, and each intermediate core router does its reverse path forwarding check on the address contained in the RPF Vector TLV, that is, on the IP address of Edge 1, instead of doing the check on the address S. That is what allows the tree to be constructed.
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 that is the case, and therefore how it decides whether to insert an attribute field, is outside the scope of this document.
A receiver asks to join a multicast group, and the request travels hop by hop towards the source. Each router that handles it creates forwarding state and passes it on. The core routers can pass it on only if they know which neighbour leads towards the source, and the vector tells them exactly that.
- PIM JOIN WITH RPF VECTORThe vector names Edge 1 as the exit point.
- JOIN CONTINUES TOWARDS THE VECTORThe core router does its RPF check on the vector address, not on the source address S.
§3.1Shared Trees and What the Extension Does Not Cover
The example above builds a source tree, to illustrate the attribute behaviour. The use of the attribute is not restricted to the construction of source trees. It may also be used to construct a shared tree, in which case the RPF Vector TLV contains the IP address of a Rendezvous Point. The procedures defined in this document for (S,G) Joins are equally applicable to (*,G) and (*,*,RP) Joins unless otherwise noted.
There is one thing the extension does not cover. There is no way to carry an RPF Vector TLV in a Bootstrap Router bootstrap message, and the procedures in this document do not define a way for BSR messages to be forwarded across a core in which the bootstrap router's IP address is not routable.
The same mechanism works for the other kind of multicast tree, where all receivers share one path to a meeting point called a Rendezvous Point. What it cannot do is help with the messages a bootstrap router sends to tell the network where that meeting point is.
§3.3.2Processing a Received Vector Attribute
When processing a received PIM Join that contains a Vector Attribute, a router MUST first check whether the Vector IP address is one of its own IP addresses. If it is, the Vector Attribute is discarded and is 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.
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, and 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.
When a router receives a Join carrying a vector, it first checks whether the address in the vector is its own. If it is, the vector is dropped, because the router has reached the exit point. Otherwise the router keeps the vector and passes it on with the next Join, even if it happens to know the route to the source itself.
§3.3.3Asserts and Join Suppression
A PIM Assert message includes the routing protocol's metric to the source of the tree, and that 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 itself has no attribute field and does not mention the Vector.
A router may change its upstream neighbour 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 neighbour that was chosen as the result of Assert processing, if that neighbour is different from the original upstream neighbour. Reachability of the Vector is only guaranteed by the router that advertises reachability to the Vector in its IGP, and 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 on the same interface where the Assert was won, which points the RPF interface to that interface and results in the O-list being NULL. The Vector Attribute therefore MUST NOT be inserted if the RPF neighbour was chosen via an Assert process and the RPF neighbour is different from the RPF neighbour that would have been selected via the local routing table. In all other cases, the Vector MUST be included in the Join message.
Join suppression is the other place the vector matters. If a router receives a PIM Join on the upstream LAN interface for a particular multicast state, Join suppression may be applied if that Join is targeted to the same upstream neighbour. Which routers suppress their Join depends on timing and is unpredictable, and downstream routers on a LAN may include different RPF Vectors in their Joins. To make the upstream router's behaviour more predictable, the RPF Vector address MUST be used as an additional condition to the Join suppression logic: the suppression logic is applied only if the RPF Vector in the PIM Join matches the RPF Vector in the multicast state. It is also possible to disable Join suppression on that LAN.
Two other PIM features need care. An Assert message tells routers who has the better path to the source; when the Join is aimed at a vector rather than the source, the Assert has to carry the metric to the vector. And when routers on the same LAN decide whether to repeat a Join, the vector has to be the same on both sides, otherwise one router's Join could be suppressed on the basis of a vector that another router never sent.
§4The Vector Attribute TLV Format
The Vector Attribute is a TLV in the PIM Join Attribute message, laid out like every other TLV: a byte of flags, a type byte, a length byte and a value.
The F bit is the Forward Unknown TLV bit. If it is set, the TLV is forwarded regardless of whether the router understands the Type; if the TLV is known, the F bit is ignored. The S bit is the Bottom of Stack bit: if it is set, this is the last TLV in the stack. The Type of the Vector Attribute is 0. The Length depends on the address family of the encoded unicast address. The Value is that encoded unicast address.
IANA has assigned the value 0 to the RPF Vector in the PIM Join Attribute Types registry.
The vector is carried as a small extra block inside the Join message, in the same way any other optional piece of information is carried there. It holds one address: the IP address of the exit point.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
F-BIT | F | 1 bits | Forward Unknown TLV: forward the TLV even if the Type is not understood. | |
S-BIT | S | 1 bits | Bottom of Stack: this is the last TLV in the stack. | |
TYPE | Type | 6 bits | The Vector Attribute type is 0. | |
LENGTH | Length | 1 byte | Depends on the address family of the encoded unicast address. |
§6Security Considerations
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 apply here.
The vector has no protection of its own. It is as trustworthy as the Join message that carries it, so the same protections that apply to PIM Join packets apply to it.