The Reverse Path Forwarding (RPF) Vector TLV
Extracted elements (19)
A router that discards a Vector Attribute MAY insert a new one, to handle topologies where a PIM Join must pass through a sequence of edge routers, each pair separated by a core without external routes. Vectors expire along with the corresponding (S,G) state in the absence of periodic refreshment.
In networks with a BGP-free core, core routers do not maintain routes to external destinations. Without an extension, core routers cannot determine where to forward PIM Join messages for sources outside the network, preventing multicast distribution tree construction.
The restriction on sending Vector Attributes to Assert-winner neighbors exists because the Assert winner may not know the path to the Vector. In the worst case, the Assert winner's route to the Vector exits on the same interface where the Assert was won, which would make the RPF interface point back to that interface and result in an empty outgoing interface list.
On a shared LAN, downstream routers MAY include different RPF Vectors in their PIM Joins, causing an upstream router to receive and use different RPF Vectors over time. Join suppression without Vector-matching would make upstream router behavior unpredictable; disabling Join suppression on that LAN is also an option.
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 BSR IP address is not routable.
A router that receives a Vector Attribute MUST use it, even if that router happens to have a route to the source. Only if the Vector address matches the router's own address is the attribute discarded.
A Vector Attribute MUST NOT be sent in a PIM Join to an upstream neighbor chosen as the result of Assert processing if that neighbor is different from the original upstream neighbor, because reachability of the Vector is only guaranteed by the router that advertises it in its IGP.
If a PIM Join is being sent towards a Vector rather than towards the source, the Assert message MUST carry the metric to the Vector instead of the metric to the source. Assert messages do not contain an attribute field and do not mention the Vector.
In all cases where the RPF neighbor was not chosen via an Assert process (or was chosen via Assert but is the same as the routing-table neighbor), the Vector MUST be included in the Join message.
To make upstream router behavior predictable when downstream routers on a LAN may include different RPF Vectors, the RPF Vector address MUST be used as an additional condition in the Join suppression logic: suppression is applied only if the RPF Vector in the received PIM Join matches the RPF Vector in the multicast state.
When an edge router sends a PIM Join message into the core, it MUST include a Vector TLV specifying the IP address of the next edge router along the path to the root of the multicast distribution tree.
When processing a received PIM Join containing a Vector Attribute, a router MUST first check whether the Vector IP address is one of its own IP addresses; if so, the Vector Attribute is discarded and not passed further upstream.
The F (Forward Unknown TLV) bit in the TLV header instructs routers to forward the TLV regardless of whether they understand the Type field. If the TLV type is known, the F bit is ignored.
The RPF Vector TLV is a new TLV in the PIM Join Attribute message (RFC 5384) that contains a single Encoded-Unicast address identifying the exit point of the network (next edge router toward the multicast tree root). Core routers perform their RPF check against this Vector address instead of the source address.
The RPF Vector TLV is not restricted to source trees; it may also be used to construct shared trees, in which case the Vector contains the IP address of the Rendezvous Point (RP). Procedures for (S,G) Joins apply equally to (*,G) and (*,*,RP) Joins.
The S (Bottom of Stack) bit in the TLV header indicates that this is the last TLV in the PIM Join Attribute stack.
IANA has assigned the value 0 to the RPF Vector in the 'PIM Join Attribute Types' registry, as defined by RFC 5384.
Security of the RPF Vector Attribute is only guaranteed by the security of the PIM packet itself; therefore, the security considerations for PIM Join packets as described in PIM-SM (RFC 4601) apply. No additional security mechanisms are defined.
The Vector Attribute TLV is a variable-length field: a 1-octet flags/type byte (bits F=Forward Unknown TLV, S=Bottom of Stack, and a 6-bit Type field set to 0), a 1-octet Length field, and a variable-length Value field containing an Encoded-Unicast address. Length depends on the Address Family of the Encoded-Unicast address.