RFC 8364
PIM Flooding Mechanism (PFM) and Source Discovery (SD)
RFC 8364: PIM Flooding Mechanism (PFM) and Source Discovery (SD) ✨
okay bestie, this one is RFC 8364 🎀 It's from March 2018, and it's an Experimental doc, so it's not a standards-track spec. The authors are IJ. Wijnands and S. Venaas from Cisco Systems, Inc., plus M. Brig from the Aegis BMD Program Office and A. Jonasson from FMV. It's published as ISSN 2070-1721. The header doesn't list anything this doc obsoletes or updates, so it's a standalone vibe 🦋
Abstract
okay so PIM-SM uses a Rendezvous Point (RP) and shared trees to forward multicast packets from new sources 🌸 Once Last-Hop Routers (LHRs) get packets from a new source, they may join the Shortest Path Tree (SPT) for that source so the forwarding is optimal ✨
This doc defines a new mechanism that supports PIM-SM without PIM registers, RPs, or shared trees 😭 Instead, multicast source info gets flooded through the whole multicast domain using a brand new generic PIM Flooding Mechanism (PFM). The payoff is that LHRs can learn about new sources without having to wait for initial data packets 💅
Status of This Memo
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 💜 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🙈
For info on the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8364 🔥
Copyright Notice
Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these docs carefully, because 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 they're provided without warranty as described in the Simplified BSD License 🎀
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Testing and Deployment Experiences . . . . . . . . . . . . . 5
3. A Generic PIM Flooding Mechanism . . . . . . . . . . . . . . 5
3.1. PFM Message Format . . . . . . . . . . . . . . . . . . . 6
3.2. Administrative Boundaries . . . . . . . . . . . . . . . . 7
3.3. Originating PFM Messages . . . . . . . . . . . . . . . . 7
3.4. Processing PFM Messages . . . . . . . . . . . . . . . . . 9
3.4.1. Initial Checks . . . . . . . . . . . . . . . . . . . 9
3.4.2. Processing and Forwarding of PFM Messages . . . . . . 10
4. Distributing SG Mappings . . . . . . . . . . . . . . . . . . 11
4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 11
4.2. Originating Group Source Holdtime TLVs . . . . . . . . . 12
4.3. Processing GSH TLVs . . . . . . . . . . . . . . . . . . . 13
4.4. The First Packets and Bursty Sources . . . . . . . . . . 13
4.5. Resiliency to Network Partitioning . . . . . . . . . . . 14
5. Configurable Parameters . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 181. Introduction ✨
okay so PIM-SM [RFC7761] uses a Rendezvous Point (RP) and shared trees to forward multicast packets to Last-Hop Routers (LHRs) 🦋 After the first packet hits an LHR, the source of the stream is learned and the Shortest Path Tree (SPT) can be joined 💖
This doc defines a new mechanism that supports PIM-SM without PIM registers, RPs, or shared trees 😭 Multicast source info gets flooded through the multicast domain using a new generic PIM flooding mechanism. Removing the need for RPs and shared trees simplifies the PIM-SM procedures, which makes router operations and management better and the protocol more robust 💅 Also, data packets only go on the SPTs, so the forwarding is optimal 🫶
This mechanism is kinda similar to Protocol Independent Multicast - Dense Mode (PIM-DM) with its State-Refresh signaling [RFC3973], except there's no initial flooding of data packets for new sources 🙈 It gets the traffic efficiency of PIM-SM while being as easy to deploy as PIM-DM 🌈 The catch is that it can't forward the initial packets from a new source, see Section 4.4 👀
PIM-DM is very different from PIM-SM, tbh. It's not as mature, it's categorized as Experimental and not an Internet Standard, and there are only a few implementations of it 🥀 The solution here is a lightweight source discovery mechanism on top of the Source-Specific Multicast (SSM) [RFC4607] parts of PIM-SM. It's feasible to implement only a subset of PIM-SM to get SSM support and, on top of that, implement this mechanism to offer source discovery for apps that don't do their own 🍓
This doc defines a generic flooding mechanism for distributing info throughout a PIM domain 🧚 The forwarding rules are largely similar to the Bootstrap Router (BSR) mechanism [RFC5059], but any router can originate info, so any kind of info can be flooded 🔥 Each message holds one or more pieces of info encoded as TLVs. This doc defines one TLV for distributing info about active multicast sources, and other docs may define more 🌸
Note that this doc is an Experimental RFC ⚠️ The flooding mechanism is largely similar to BSR, but there are concerns about scale, since multiple routers can distribute info and there may be a lot more data to process and store 😭 Distributing knowledge of active sources this way is new, and the main worry is the potentially large amounts of source state that need distributing. There's been some testing in the field, but we still need to learn more about forwarding efficiency, the processing per router, propagation delay, and how much state can be distributed 👑 Especially: how many active sources one can support without eating too many resources 💀 There are also parameters, see Section 5, that can be tuned for how often info gets distributed. It's not clear which parameters are useful for different types of networks 🤷♀️
1.1. Conventions Used in This Document
Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖 Lowercase versions don't count, so no drama 💜
1.2. Terminology
Here's the glossary, bestie 🎀
- RP: Rendezvous Point
- BSR: Bootstrap Router
- RPF: Reverse Path Forwarding
- SPT: Shortest Path Tree
- FHR: First-Hop Router, directly connected to the source
- LHR: Last-Hop Router, directly connected to the receiver
- PFM: PIM Flooding Mechanism
- PFM-SD: PFM Source Discovery
- SG Mapping: Multicast source group (SG) mapping
2. Testing and Deployment Experiences 🧪
A prototype of this spec has been implemented, and there's been some limited testing in the field 💖 The prototype was tested in a network with low-bandwidth radio links. The network has frequent topology changes, including frequent link or router failures, which is chaotic 😭 Previously existing mechanisms were tested too (for example, PIM-SM and PIM-DM).
With PIM-SM, the existing RP election mechanisms were found to be too slow 🐢 With PIM-DM, there were issues with new multicast sources starving low-bandwidth links, even when there were no receivers. In some cases it was so bad that there was no bandwidth left for prune messages 💀
For the PFM-SD prototype tests, all routers were configured to send PFM-SD for the directly connected source and to cache received announcements 🫶 Apps like SIP with multicast subscriber discovery, multicast voice conferencing, position tracking, and NTP were successfully tested ✨ The tests went quite well! Packets got rerouted as needed, and there was no unnecessary forwarding of packets 🦋 Ease of configuration was seen as a plus 👑
3. A Generic PIM Flooding Mechanism 🌈
okay so the Bootstrap Router (BSR) mechanism [RFC5059] is a commonly used mechanism for distributing dynamic Group-to-RP mappings in PIM 🧚 It's responsible for flooding info about those mappings throughout a PIM domain, so all routers in the domain can have the same info. BSR, as defined, can only distribute Group-to-RP mappings 🥺 This doc defines a more generic mechanism that can flood any kind of info. Administrative boundaries, see Section 3.2, may be configured to limit which parts of a network the info gets flooded to 🌸
The forwarding rules are identical to BSR, except that you can control whether routers should forward unsupported data types 💅 Some types of info are super useful to distribute without every router having to support that particular type, but there may also be types where it's necessary for every single router to support it 🔥 The mechanism includes an originator address that's used for RPF checking to restrict the flooding and prevent loops, just like BSR 💖 Like BSR, messages are forwarded hop-by-hop. The messages are link-local, and each router processes and resends them 🫶 Note that there's no equivalent to the BSR election mechanism, since there can be multiple originators 🙃 This mechanism is named the PIM Flooding Mechanism (PFM) and that's the whole vibe 🌈
Next up is the PFM message format 👀
3.1. PFM Message Format 🎀
Okay, this is the PFM message layout, and it's giving packet-shaped puzzle 🧩
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Type 1 | Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value 1 |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
|T| Type n | Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value n |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- PIM Version, Reserved, and Checksum: These are exactly as specified in [RFC7761], so go check there for the details 💅
- Type: The PIM Message Type. The value is
12for a PFM message. - [N]o-Forward bit: When this bit is set, it means the PFM message is not to be forwarded. It's defined to stop Bootstrap message forwarding in [RFC5059] 🙅♀️
- Originator Address: The address of the router that originated the message. It can be any address assigned to that router, but it MUST be routable in the domain so the message can actually get forwarded. The format is the Encoded-Unicast address from [RFC7761] 🧭
- [T]ransitive bit: Every TLV in the message has a bit called the "Transitive" bit, which decides whether routers that don't support that type still forward the TLV. See Section 3.4.2 🦋
- Type 1..n: A message holds one or more TLVs, so n TLVs in this case. The Type says what kind of info lives in the Value. The Type range is 0 to 32767 (15 bits) ✨
- Length 1..n: The length of the Value field, counted in octets 📏
- Value 1..n: The value tied to the type, at the specified length 🎁
3.2. Administrative Boundaries 🚧
PFM messages are usually forwarded hop-by-hop to every PIM router. BUT, similar to BSR, you can set up administrative boundaries to limit the info to certain domains or parts of the network. It's giving gatekeeper energy 🔐
Implementations MUST have a way of defining a set of interfaces on a router as administrative boundaries for all PFM messages or, optionally, for certain TLVs. That means you can have different boundaries for different TLVs 💜 Usually you want boundaries to work both ways, but an implementation MAY also offer unidirectional boundaries.
When a router forwards a message, it MUST NOT send it out on an interface that's an outgoing boundary (bidirectional ones count too) for all PFM messages. If an interface is only an outgoing boundary for certain TLVs, the message MUST NOT go out on that interface if it's a boundary for all the TLVs in the message. Otherwise, the router MUST remove all the boundary TLVs from the message and send the rest. 🫶
Receiving is similar. When a PFM message comes in on an interface, the message MUST be discarded if that interface is an incoming boundary (bidirectional ones count) for all PFM messages. If the interface is an incoming boundary for only certain TLVs, the router MUST ignore all the boundary TLVs. If every TLV in the message is a boundary TLV, the message is effectively ignored 💀
Also, the boundary gets applied before forwarding. If the message was discarded or all its TLVs were ignored, then nothing gets forwarded. And when a message is forwarded, it MUST NOT contain any TLVs where the incoming interface is an incoming or bidirectional boundary 🌸
3.3. Originating PFM Messages 📣
A router originates a PFM message whenever it needs to share info with other routers in the network. When that happens depends on what info is being shared. For example, this document defines a TLV for info about active sources. When a router gets a new active source, a PFM message should go out as soon as possible, so basically every time there's a new active source. BUT the TLV also has a holdtime, so PFM messages also need to go out periodically 🔄
Generally, a PFM message gets sent when there's a local state change that changes the info being distributed. Some info also needs to go out on a schedule. These are called "triggered" and "periodic" messages, respectively. Each TLV definition has to spell out when a triggered PFM message gets originated, whether periodic messages get sent, and how often 📅
A router MUST NOT originate more than Max_PFM_Message_Rate messages per minute. This document doesn't dictate how to implement that. A few options: keep a minimum time between messages, count the messages and reset the count every minute, or use a leaky bucket algorithm. A leaky bucket is nice because it handles bursts better 🪣 The default value of Max_PFM_Message_Rate is 6. The value MUST be configurable. Depending on the network, you might want a bigger value so new info spreads faster, but with lots of routers and lots of updates, the total number of messages could get huge and need way too much processing 😵💫
There MUST be a minimum of Min_PFM_Message_Gap milliseconds between each originated message. The default for Min_PFM_Message_Gap is 1000 (1 second). The value MUST be configurable. ⏱️
Unless the TLV definitions say otherwise, different TLVs have no relationship to each other, so an implementation can choose whether to bundle TLVs into one message or spread them across separate messages. It is RECOMMENDED to combine multiple TLVs in one message to cut down on the number of messages, but it is also RECOMMENDED that the message stay small enough to avoid fragmentation at the IP layer 📦 When a triggered PFM message is needed because of a state change, a router MAY send a message with only the info that changed. If lots of changes happen at about the same time, you might be able to combine them into one message. And if periodic messages are also needed, an implementation MAY pack periodic PFM info into a triggered PFM. For example, say some info needs to go out every 60 seconds, and a triggered PFM is about to go out 20 seconds before the next periodic one was scheduled. The triggered message can carry the periodic info, and the next periodic message can then be scheduled 60 seconds after that, instead of 20 seconds later. Efficiency is everything 🧠✨
When a router originates a PFM message, it puts one of its own addresses in the originator field. An implementation MUST allow an administrator to configure which address gets used. For a message to reach every router in a domain, all the routers need a route to this address because of RPF-based forwarding, so the administrator has to pick carefully 🧐 If no address is configured, an implementation MUST NOT use a link-local address. It is RECOMMENDED to use the address of a virtual interface, so the originator stays the same and stays routable no matter which physical interfaces or links go down 🌈
The No-Forward bit MUST NOT be set, with one exception. A router can set it when it gets a PIM Hello from a new neighbor, or when a PIM Hello with a new Generation Identifier (GenID), defined in [RFC7761], comes in from an existing neighbor. In those cases, an implementation MAY send PFM messages with relevant info so the neighbor can get the right state quickly. The definition of each PFM message TLV needs to say what, if anything, gets sent in this situation. If such a PFM message is sent, the No-Forward bit MUST be set, and the message has to be sent within 60 seconds after the neighbor state change. The processing rules for PFM messages make sure that any other neighbors on the same link ignore the message. This behavior (and the 60-second choice) matches what's defined for the No-Forward bit in [RFC5059] 🫧
3.4. Processing PFM Messages 🔍
A router that receives a PFM message MUST perform the initial checks described here. If the checks fail, the message MUST be dropped. An error MAY be logged; otherwise, the message MUST be dropped silently. If the checks pass, the contents get processed according to the processing rules of the included TLVs 💅
3.4.1. Initial Checks ✅
To do any further processing, a message MUST meet the following requirements. The message MUST be from a directly connected PIM neighbor, and the destination address MUST be ALL-PIM-ROUTERS. Also, the interface MUST NOT be an incoming or bidirectional administrative boundary for PFM messages (see Section 3.2). If the No-Forward bit is not set, the message MUST be from the RPF neighbor of the originator address. If the No-Forward bit is set, this system (the router doing these checks) MUST have enabled the PIM protocol within the last 60 seconds. See Section 3.3 for details 🫶
Here's the pseudocode, which is the algorithm in a nutshell:
if ((DirectlyConnected(PFM.src_ip_address) == FALSE) OR
(PFM.src_ip_address is not a PIM neighbor) OR
(PFM.dst_ip_address != ALL-PIM-ROUTERS) OR
(Incoming interface is admin boundary for PFM)) {
drop the message silently, optionally log error.
}
if (PFM.no_forward_bit == 0) {
if (PFM.src_ip_address !=
RPF_neighbor(PFM.originator_ip_address)) {
drop the message silently, optionally log error.
}
} else if (more than 60 seconds elapsed since PIM enabled)) {
drop the message silently, optionally log error.
}Quick note: src_ip_address is the source address in the IP header of the PFM message. Originator is the originator field inside the PFM message, and it names the router that started the message. When a message gets forwarded hop-by-hop, the originator address never changes, but the source address becomes an address on whichever router forwarded it last 🦋✨
3.4.2. Processing and Forwarding of PFM Messages ✨
Okay so, when a message lands, the initial checks from before have to run first 🧐. If it passes them, then for every TLV tucked inside, you process it according to that TLV's own spec 💅.
After processing, the message gets forwarded 🦋. Some TLVs might get left out or changed in the forwarded copy, and that depends on administrative boundaries (see Section 3.2), the type spec, and the Transitive bit setting for that TLV 🎀. If a router knows the type, the TLV goes out with no changes unless the type spec says otherwise 🌸. A router that doesn't support the type MUST include the TLV in the forwarded message if and only if the Transitive bit is set ✨. Whether or not the router supports the type, the value of the Transitive bit MUST be preserved if the TLV is included in the forwarded message 🫶. The message goes out of all interfaces with PIM neighbors, including the interface it came in on 🙈. As Section 3.2 says, if an interface is an outgoing boundary for any TLVs, the message MUST NOT be sent out on that interface if it's an outgoing boundary for all the TLVs in the message 😭. Otherwise, the router MUST remove any outgoing boundary TLVs of that interface from the message and send it out that interface with the remaining TLVs 💖.
4. Distributing SG Mappings ✨
The generic PFM from the last section can be used to distribute SG mappings about active multicast sources all over a PIM domain 🌍. A Group Source Holdtime (GSH) TLV is defined just for this 👑.
4.1. Group Source Holdtime TLV 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1(the Transitive bit): The Transitive bit is set to 1. This means this type gets forwarded even if a router doesn't support it 🦋. See Section 3.4.2.- Type: This TLV has type 1 🔢.
- Length: The length of the value in octets 📏.
- Group Address: The group that sources are to be announced for. The format for this address is given in the Encoded-Group format in [RFC7761] 🌷.
- Src Count: The number of source addresses that are included 🧮.
- Src Holdtime: The holdtime (in seconds) for the included source(s) ⏳.
- Src Address: The source address for the corresponding group. The format for these addresses is given in the Encoded-Unicast address in [RFC7761] 💜.
4.2. Originating Group Source Holdtime TLVs 📡
A PFM message MAY contain one or more Group Source Holdtime (GSH) TLVs 💌. This is how info about active multicast sources gets flooded around ✨. Each FHR that's directly connected to an active multicast source originates PFM messages containing GSH TLVs 🙌. How a multicast router figures out the source of a multicast packet, and when it considers itself the FHR, follows the same procedures as the registering process in [RFC7761] 🕵️♀️. When an FHR has decided a register needs to be sent per [RFC7761], the SG is not registered via the PIM-SM register procedures. Instead, the SG mapping goes into a GSH TLV in a PFM message 🎀. Note that only the SG mapping gets distributed, not the entire packet like would happen with a PIM register 🙅♀️.
The PFM messages with the GSH TLV get sent periodically for as long as the multicast source is active, kind of like how PIM registers get sent periodically 🔁. So as long as the source is active, it's included in a PFM message originated every Group_Source_Holdtime_Period seconds, within the general PFM timing requirements in Section 3.3 ⏰. The default value of Group_Source_Holdtime_Period is 60. The value MUST be configurable 🎛️. The holdtime for the source MUST be set to either zero or Group_Source_Holdtime_Holdtime 💅. The value of the Group_Source_Holdtime_Holdtime parameter MUST be larger than Group_Source_Holdtime_Period 📈. It is RECOMMENDED to be 3.5 times the Group_Source_Holdtime_Period ✨. The default value is 210 (seconds). The value MUST be configurable. A source MAY be announced with a holdtime of zero to indicate that the source is no longer active 👋.
If an implementation supports originating GSH TLVs with different holdtimes for different sources, it can (if needed) send multiple TLVs with the same group address 🧩. Due to the format, all the sources in the same TLV have the same holdtime, so that's the deal 🤷♀️.
When a new source is detected, an implementation MAY send a PFM message containing just that particular source 🆕. It MAY also include info about other sources that were just detected, sources that are scheduled for periodic announcement later, or other types of info 🎁. See Section 3.3 for details. Note that when a new source is detected, you should trigger the sending of a PFM message as soon as possible 🏃♀️💨. If a source becomes inactive though, there's no reason to trigger a message 😌. There's no urgency in removing state for inactive sources. Note that the message timing requirements in Section 3.3 apply, which means you can't always send a triggered message immediately when a new source shows up 🙈. To meet the timing requirements, the sending of the message may have to be delayed for a small amount of time ⏳.
When a new PIM neighbor is detected, or an existing neighbor changes GenID, an implementation MAY send a triggered PFM message containing GSH TLVs 🌈. Those can cover any SG mappings it learned by receiving PFM GSH TLVs, as well as any active directly connected sources 💖. See Section 3.3 for further details.
4.3. Processing GSH TLVs 🔍
A router that receives a PFM message containing GSH TLVs MUST parse the GSH TLVs and store each of them as SG mappings with an Expiry Timer started with the advertised holdtime 📝. That's unless the implementation specifically doesn't support GSH TLVs, the router is configured to ignore GSH TLVs in general, or it's configured to ignore GSH TLVs for certain sources or groups 🙅♀️. An admin might, for example, configure a router not to process GSH TLVs if the router is known never to have any directly connected receivers 🧑💻.
For each group that has directly connected receivers, this router SHOULD send PIM (S,G) joins for all the SG mappings advertised in the message for that group 🎯. Generally joins get sent, but there could be an administrative policy limiting which sources and groups to join 🚧. The SG mappings stay alive for as long as the Expiry Timer for the source is running ⏱️. Once the Expiry Timer expires, a PIM router MAY send a PIM (S,G) prune to remove itself from the tree 🌳. However, when this happens, there should be no more packets sent by the source, so it may be desirable to let the state time out instead of sending a prune 😴.
Note that a holdtime of zero has a special meaning 🚨. It's treated as if the source just expired, and then the state should be removed 🧹. Source information MUST NOT be removed just because the source was omitted in a message 🛑. For instance, if there are a bunch of sources for one group, there may be multiple PFM messages, each one containing a different list of sources for that group 📦.
4.4. The First Packets and Bursty Sources 🚀
The PIM register procedure is designed to deliver multicast packets to the RP when there's no SPT from the RP to the source 🛤️. The register packets received on the RP get decapsulated and forwarded down the shared tree to the LHRs 🎁. As soon as an SPT is built, multicast packets flow natively over the SPT to the RP or LHR, and the register process stops 🛑. The PIM register process makes sure packets get delivered until an SPT is in place reaching the FHR 💪. If the packets weren't unicast encapsulated to the RP, the FHR would drop them until the SPT was set up 😬. This matters for applications where the initial packet(s) must be received for the application to work correctly 🥺. Another reason is bursty sources. If an application sends out a multicast packet every 4 minutes (or longer), the SPT gets torn down (typically after 3:30 minutes of inactivity) before the next packet is forwarded down the tree 💀. That means multicast packets would never get forwarded at all 😱. A well-behaved application should be able to deal with packet loss, since IP is a best-effort packet delivery system 🤓. But in reality, that's not always the case 🙃.
With the procedures in this document, the packet(s) received by the FHR will be dropped until the LHR has learned about the source and the SPT is built 🫠. For bursty sources, or applications sensitive to the delivery of the first packet, this solution wouldn't be very applicable 🙅♀️. It's mostly useful for applications that don't have a strong dependency on the initial packet(s) and have a fairly constant data rate, like video distribution, for example 📺. For applications with a strong dependency on the initial packet(s), using BIDIR-PIM [RFC5015] or SSM [RFC4607] is recommended 🎀. Their protocol operations are much simpler compared to PIM-SM, so they cause less churn in the network 🧘♀️. Both guarantee best-effort delivery for the initial packet(s) 💜.
4.5. Resiliency to Network Partitioning 🌐
In a PIM-SM deployment where the network gets partitioned due to link or node failure, the RP can become unreachable to a certain part of the network 💔. New sources that become active in that partition won't be able to register to the RP, and receivers in that partition won't be able to receive the traffic 😭. Ideally, having a candidate RP in each partition is desirable, but which routers will form a partitioned network is unknown in advance 🔮. To be fully resilient, each router in the network may end up being a candidate RP, but that would increase the operational complexity of the network 🥴.
The solution described in this document doesn't have that problem 🙌. If a network gets partitioned and new sources become active, the receivers in that partition will receive the SG mappings and join the source tree 🌳. Each partition works independently of the others and keeps access to sources within itself 🏝️. Once the network has healed, the periodic flooding of SG mappings makes sure they get reflooded into the other partitions, and then other receivers can join the newly learned sources 🥳✨.
5. Configurable Parameters 🎀
okay so this section is basically a cheat sheet ✨ the document has a bunch of configurable parameters, and they're formally defined back in Sections 3.3 and 4.2, but they're repeated here so you don't have to go hunting 🫶 every one of them has a default value, listed below.
Max_PFM_Message_Rate: the maximum number of PFM messages a router is allowed to originate per minute 💅 see Section 3.3 for the deets. The default value is 6.
Min_PFM_Message_Gap: the minimum amount of time between each PFM message originated by a router, in milliseconds 🦋 see Section 3.3 for details. The default is 1000.
Group_Source_Holdtime_Period: the announcement period for Group Source Holdtime TLVs, in seconds 🌸 see Section 4.2 for details. The default value is 60.
Group_Source_Holdtime_Holdtime: the holdtime for Group Source Holdtime TLVs, in seconds 💜 see Section 4.2 for details. The default value is 210.
6. Security Considerations 🔥
okay bestie, this section is SERIOUS and I need you to take it seriously 😭🫶
For general PIM message security, see [RFC7761]. PFM messages MUST only be accepted from a PIM neighbor 🙈 but as [RFC7761] talks about, ANY router can become a PIM neighbor just by sending a Hello message. yikes. So to control where PFM packets get accepted from, you can limit which interfaces PIM is enabled on 🚧 You can also configure interfaces as administrative boundaries for PFM messages, see Section 3.2. The implications of forged PFM messages depend on which TLVs they contain. Documents that define new TLVs will need to discuss the security considerations for those specific TLVs 📝 In general though, PFM messages are flooded throughout the network, so if someone forges a large number of them, they could stress every router in the network 💀
If an attacker can forge PFM messages, those messages may contain arbitrary GSH TLVs. The issue here is that an attacker might send these TLVs for a HUGE amount of sources, potentially making every router in the network store huge amounts of source state 😱 Also, if there's receiver interest in the groups named in the GSH TLVs, routers with directly connected receivers will build SPTs for the announced sources, even if those sources aren't actually active. Building those trees eats up extra resources on the routers the trees pass through 🫠
PIM-SM link-local messages can be authenticated using IPsec, see Section 6.3 of [RFC7761] and [RFC5796] 🔐 Since PFM messages are link-local messages sent hop-by-hop, a link-local PFM message can be authenticated with IPsec, so a router can verify that a message came from a trusted neighbor and hasn't been modified. However, to verify that a received message contains correct information announced by the originator named in the message, you have to trust every router on the path from the originator, AND trust that each of those routers has authenticated the message it received 👑
7. IANA Considerations 🌈
This document registers a new PIM message type for the PIM Flooding Mechanism (PFM), with the name "PIM Flooding Mechanism" in the "PIM Message Types" registry, with the value of 12 🍓
IANA also created a registry for PFM TLVs called "PIM Flooding Mechanism Message Types". Assignments for this registry are to be made according to the policy "IETF Review" as defined in [RFC8126] ✨ The initial content of the registry looks like this:
Type Name Reference
---------------------------------------------
0 Reserved [RFC8364]
1 Source Group Holdtime [RFC8364]
2-32767 Unassigned8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
2008, <https://www.rfc-editor.org/info/rfc5059>.
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796,
DOI 10.17487/RFC5796, March 2010,
<https://www.rfc-editor.org/info/rfc5796>.
[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, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>.Acknowledgments 🫶
The authors would like to thank Arjen Boers for contributing to the initial idea 💖 and David Black, Stewart Bryant, Yiqun Cai, Papadimitriou Dimitri, Toerless Eckert, Dino Farinacci, Alvaro Retana, and Liang Xia for their super helpful comments on the document 🧚
Authors' Addresses 🦋
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
United States of America
Email: stig@cisco.com
Michael Brig
Aegis BMD Program Office
17211 Avenue D, Suite 160
Dahlgren VA 22448-5148
United States of America
Email: michael.brig@mda.mil
Anders Jonasson
Swedish Defence Material Administration (FMV)
Loennvaegen 4
Vaexjoe 35243
Sweden
Email: anders@jomac.se📦 where this page comes from
- ietf: rfc8364 2018-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms