RFC 5496

The Reverse Path Forwarding (RPF) Vector TLV

📅 published March 2009, from ietf

The Reverse Path Forwarding (RPF) Vector TLV ✨

Okay bestie, let's start with the title block 🎀 This is RFC 5496, called The Reverse Path Forwarding (RPF) Vector TLV. It's a Standards Track doc from the Network Working Group, dated March 2009. The authors are IJ. Wijnands, A. Boers, and E. Rosen, all from Cisco Systems, Inc. 💅 The title block doesn't list anything it obsoletes or updates, so no drama there 🫶

Status of This Memo

Real talk first 💖 This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. If you want the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

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 read these carefully, because they describe your rights and restrictions for this document 📜

Abstract

This doc describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384. It lets PIM build multicast trees through an MPLS-enabled network, even when that network's IGP doesn't 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 🌸

Sometimes it's super handy to split the routers in a network into two groups: "edge routers" and "core routers" 🧚 Edge routers hook up directly to users or other networks, while core routers only connect to other routers in the same network. If the network is MPLS-enabled, then any unicast packet that needs to leave the network can get "tunneled" over MPLS from one edge router to another. To handle a unicast packet that has to go 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. Core routers don't need to know any routes that lead outside the network. They only handle tunneled packets, so they only need to know how to reach the edge routers and the other core routers 💅

Let's look at an example. Say the network is an Autonomous System (AS), the edge routers are External Border Gateway Protocol (EBGP) speakers, and the core routers make up what's called a "BGP-free core" 👑 The edge routers pass BGP routes to each other, but not to the core routers.

Multicast is where that "keep the core free of external routes" plan gets messy 😭 When you use PIM Sparse-Mode (PIM-SM) [RFC4601], PIM Source-Specific Mode (PIM-SSM) [RFC4607], or Bidirectional PIM (BIDIR-PIM) [RFC5015] to build a multicast distribution tree for a group, you want the core routers to be full participants in PIM so multicast can run efficiently in the core. That means the core routers have to correctly process PIM Join messages for the group, which in turn means they have to send those Joins toward the root of the distribution tree. If the root sits outside the network's borders (for example, in a different AS) and the core routers don't keep routes to external destinations, the PIM Joins can't be processed, and the tree can't be built 🙈

So to make PIM work in a setup where the core routers don't keep external routes, a PIM extension is needed 🔥 When an edge router sends a PIM Join 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 toward the specified edge router, which is toward the Vector. Basically, the Vector acts as an attribute, inside one particular network, for the root of the tree ✨

This document defines a new TLV in the PIM Join Attribute message [RFC5384]. It has 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]. Yes, these words are the official rulebook 🎀

3. Use of the RPF Vector TLV 🫶

Before a router can start forwarding multicast packets, it has to build a forwarding tree by sending PIM Joins hop-by-hop. Each router on the path creates forwarding state and passes the Join toward the root of the forwarding tree. Building this tree is receiver driven. Check out Figure 1 🌈

            ------------------ BGP -----------------
           |                                        |
[S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R]
               <--- (S,G) Join

                              Figure 1

In this example, both edge routers are BGP speakers. The core routers aren't BGP speakers and don't have any BGP-distributed routes 💖 The route to S is BGP-distributed, so the edge knows about it but the core doesn't. Edge 2 finds the interface that leads to S and sends a PIM Join to its upstream router. But here the upstream router is a core router with no route to S. Without the PIM extensions in this document, the core router can't figure out where to send the Join, so the tree can't get built 😭

To let the core router help build the tree, Edge 2 puts an "RPF (Reverse Path Forwarding) Vector" TLV in the PIM Join Attribute [RFC5384] of the PIM Join. In this example, the RPF Vector TLV holds the IP address of Edge 1. Edge 2 forwards the PIM Join toward Edge 1. Each intermediate core router does its RPF check [RFC4601] on the address in the RPF Vector TLV (the IP address of Edge 1) instead of doing it on the address S. That's what lets the tree get constructed 🧚

3.1. Attribute and Shared Tree Joins 🌸

In the example above, we build a source tree to show how the attribute behaves. The attribute isn't limited to source trees, though. It can also be used to build a shared tree. In that case, the RPF Vector TLV holds the IP address of a Rendezvous Point (RP). The procedures this document defines for (S,G) Joins apply equally to (,G) and (,*,RP) Joins, unless noted otherwise 💅

3.2. Attribute and Bootstrap Messages 🙈

There's no way to carry an RPF Vector TLV in a Bootstrap Router (BSR) bootstrap message. The procedures in this document don't define a way for BSR messages to be forwarded across a core where the BSP IP address isn't routable 🍓

3.3. The Vector Attribute ✨

3.3.1. Inserting a Vector Attribute in a Join 🦋

In the Figure 1 example, when Edge 2 looks up the route to the source of the multicast distribution tree, it finds 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, which is Core 2 👑

When Edge 2 sends a PIM Join to Core 2, it includes a Vector Attribute that specifies the address of Edge 1. Core 2, along with any later core routers, forwards the Join along the Vector (so toward Edge 1) instead of trying to forward it toward 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 figures out whether that's the case (and so how it decides whether to insert an attribute field) is outside the scope of this document 🫶

3.3.2. Processing a Received Vector Attribute 🌈

When a router processes a received PIM Join that contains a Vector Attribute, it MUST first check whether the Vector IP address is one of its own IP addresses 😭 If it is, the Vector Attribute gets discarded and isn't passed further upstream. Otherwise, the Vector Attribute is used to find the route to the source, and it's passed along when a PIM Join is sent upstream. Note that a router receiving 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 one. This would typically happen if a PIM Join needed to pass through a sequence of Edge routers, where each pair of them is separated by a core that doesn't have external routes 🧚 Without periodic refreshment, Vectors expire along with the corresponding (S,G) state ⭐

3.3.3. Vector Attribute and Asserts

okay so Asserts, bestie 🙈 A PIM Assert message carries the routing protocol's "metric" to the source of the tree, and that number is what decides who wins the Assert 👑 Now if a PIM Join is heading toward a Vector instead of the source, the Assert message MUST have the metric to the Vector instead of the metric to the source. The Assert message doesn't have an attribute field though, and it never mentions the Vector 🦋

Routers can switch their upstream neighbor on a multicast tree because of Assert messages 💅 But a Vector Attribute MUST NOT be sent in a PIM Join to an upstream neighbor that was chosen through Assert processing, if that neighbor is different from the original upstream neighbor. The Vector's reachability is only guaranteed by the router that advertises it in its IGP 🌸 If the Assert winner upstream isn't the real preferred next-hop, the Assert winner might not know the path to the Vector. Worst case, its route to the Vector is on the same interface where it won the Assert, which points the RPF interface right back at that interface and leaves the O-list NULL 💀 So the Vector Attribute 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

so Join suppression is giving "it depends on timing" 😭 If a router gets 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) suppress their PIM Join is unpredictable, because it all comes down to timing 🌈 Downstream routers on a LAN MAY include different RPF Vectors in their PIM Joins. So an upstream router on that LAN might 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's behavior more predictable, the RPF Vector address MUST be used as an additional condition in the Join suppression logic. The suppression logic only gets applied if the RPF Vector in the PIM Join matches the RPF Vector in the multicast state 🔥 It's also possible to disable Join suppression on that LAN, if you want the extra control 🧚

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 🔐

Okay, this part is serious, bestie 😭 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

That's the whole RFC, bestie! 🌈👑✨

📦 where this page comes from