RFC 9466

PIM Assert Message Packing

📅 published October 2023, from ietf

PIM Assert Message Packing 🎀

Request for Comments: 9466 📜 (this is RFC 9466, bestie) Category: Standards Track 🏆 ISSN: 2070-1721 Date: October 2023 🍓

The authors are Y. Liu, Ed. (China Mobile), T. Eckert, Ed., M. McBride (Futurewei), and Z. Zhang (ZTE Corporation) 🫶. This doc doesn't list any Obsoletes or Updates, so it's not replacing or changing any other RFC. It's a fresh drop 💅✨.

Abstract 🦋

Okay so when PIM Sparse Mode (PIM-SM), including PIM Source-Specific Multicast (PIM-SSM), runs on a shared LAN, there's usually more than one upstream router 👀. That means the same IP multicast packets can get forwarded twice, which is chaotic 😭. PIM Assert messages are how those routers pick ONE forwarder per IP multicast flow on that LAN 👑.

This doc defines a way to cram information for multiple IP multicast flows into one PackedAssert message 🧚. That cuts the total number of PIM packets on the LAN, so the forwarder election can happen faster, and you get fewer duplicate packets floating around 🌈. Iconic optimization, no cap.

Status of This Memo 📌

This is an Internet Standards Track document 🏆.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🎀.

For info on the current status of this doc, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9466 🔗.

Copyright (c) 2023 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 this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License ⚠️.

Table of Contents 🗺️

1.  Introduction
  1.1.  Requirements Language
  1.2.  Terminology
2.  Problem Statement
3.  Specification
  3.1.  PIM Packed Assert Capability Hello Option
  3.2.  Assert Packing Message Formats
  3.3.  PackedAssert Mechanism
    3.3.1.  Sending PackedAssert Messages
      3.3.1.1.  Handling of Reception-Triggered Assert Records
      3.3.1.2.  Handling of Timer Expiry-Triggered Assert Records
      3.3.1.3.  Beneficial Delay in Sending PackedAssert Messages
      3.3.1.4.  Handling Assert/PackedAssert Message Loss
      3.3.1.5.  Optimal Degree of Assert Record Packing
    3.3.2.  Receiving PackedAssert Messages
4.  Packet Formats
  4.1.  PIM Packed Assert Capability Hello Option
  4.2.  Assert Message Format
  4.3.  Simple PackedAssert Message Format
  4.4.  Aggregated PackedAssert Message Format
    4.4.1.  Source Aggregated Assert Record
    4.4.2.  RP Aggregated Assert Record
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Use Case Examples
  A.1.  Enterprise Network
  A.2.  Video Surveillance
  A.3.  Financial Services
  A.4.  IPTV Broadcast Video
  A.5.  MVPN MDT
  A.6.  Special L2 Services
Acknowledgments
Authors' Addresses

1. Introduction ✨

When PIM-SM runs on shared LAN networks, there's typically more than one upstream router 🌸. When duplicate data packets show up on the LAN from different upstream routers, those routers send assert packets to elect a single forwarder, following [RFC7761] 🦋. PIM Assert messages get sent periodically to keep the Assert state alive 💖. Each PIM Assert message carries info about one multicast source and group, plus the matching Metric and Metric Preference for the route toward the source or the PIM Rendezvous Point (RP) 🧚.

This doc defines a way to encode the info from multiple PIM Assert messages into one single PackedAssert message ✨. That means you can send and receive info for several IP multicast flows in one packet, and the Assert state machinery stays exactly the same 🎀. It cuts the total number of PIM packets on the LAN, so the forwarder election can speed up, and you get fewer duplicate IP multicast packets 🌈. This is especially clutch when there's traffic for a huge number of multicast groups or SSM channels, and the routers are slow at processing PIM packets 😭💅.

1.1. Requirements Language 📖

Here's the deal with the key words. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc get interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when, and only when, they appear in all capitals, just like they do right here 👑.

1.2. Terminology 🧠

You should already be familiar with the terminology from [RFC7761] 🤓. Below are the abbreviations that get repeated throughout this doc:

AT:   Assert Timer

DR:   Designated Router

RP:   Rendezvous Point

RPF:  Reverse Path Forwarding

RPT:  RP Tree

SPT:  Shortest Path Tree

2. Problem Statement 😤

PIM Asserts happen in lots of deployments 🙈. Appendix A has explicit examples, plus explanations of why it's often not possible to avoid them 🎀.

PIM Assert state mostly depends on the network topology 🕸️. As long as there's a Layer 2 (L2) network with more than two PIM routers, there may be multiple upstream routers, and that can cause duplicate multicast traffic to get forwarded and assert processing to kick off 😩.

As multicast services get widely deployed, the number of multicast entries grows, and a LOT of Assert messages can get sent in a super short window whenever multicast data packets trigger PIM assert processing on shared LANs 💀. The PIM routers have to process a flood of tiny PIM assert packets in a very short time, so the device load gets huge 🥵. The assert packet might not get processed in time, or it might even get discarded, which stretches out the traffic duplication in the network 😭.

The PIM Assert mechanism can only be avoided by designing the network without transit subnets that have multiple upstream routers 🧩. For example, an L2 ring between routers can sometimes be reconfigured as a ring of point-to-point subnets connected by the routers 🔄. But these Layer 2 (L2) and Layer 3 (L3) topology changes are not fun when they're only done to enable IP multicast with PIM, because they raise the cost of introducing IP multicast with PIM 💸.

These designs also aren't feasible when specific L2 technologies are needed 🚫. For instance, various L2 ring technologies provide sub-50 msec failover mechanisms, and a ring made of L3 subnets just can't match that 🏃‍♀️💨. IEEE Time-Sensitive Networking mechanisms would need an L2 topology that can't simply be swapped out for an L3 topology either ⏱️. L2 sub-topologies can also seriously cut deployment costs 🤑.

3. Specification 🎀

This doc defines three elements to support PIM assert packing 💖:

  1. The PIM Packed Assert Capability Hello Option
  2. The encoding of PackedAssert messages
  3. How to send and receive PackedAssert messages

3.1. PIM Packed Assert Capability Hello Option 🫶

The PIM Packed Assert Capability Hello Option (Section 4.1) is how routers announce that they support the assert packing mechanisms specified in this doc 📣. PackedAssert messages (Section 3.2) MUST NOT be used unless all PIM routers on the same subnet announce this option 🚨. No option, no PackedAssert, bestie 🙅‍♀️.

3.2. Assert Packing Message Formats 📦

The PIM Assert message, defined in Section 4.9.6 of [RFC7761], describes the parameters of a (*,G) or (S,G) assert using these info elements: Rendezvous Point Tree flag (R), Source Address, Group Address, Metric, and Metric Preference 🧾. This doc calls that info an "assert record" 💅.

This doc adds two new PIM Assert message encodings by allocating and using two flags in the PIM Assert message header [RFC9436]: the Packed (P) flag and the Aggregated (A) flag 🚩✨.

If P=0, the message is a non-packed PIM Assert message, as specified in [RFC7761] 🥱. See Section 4.2. In this case, the A flag MUST be set to 0 and MUST be ignored on receipt 🙃. Ignore it, period.

If P=1, the message is called a "PackedAssert message," and the type, which means the encoding format of the payload, gets determined by the A flag 🎁.

If A=0, the message body is a sequence of assert records. This is called a "Simple PackedAssert message." See Section 4.3 🧃.

If A=1, the message body is a sequence of aggregated assert records. This is called an "Aggregated PackedAssert message." See Section 4.4 🍱.

Two aggregated assert record types are specified 🌟.

The "Source Aggregated Assert Record" (see Section 4.4.1) encodes one common Source Address, Metric, and Metric Preference, along with a list of one or more Group Addresses 🌊. Source Aggregated Assert Records give you a more compact encoding than the Simple PackedAssert message format when multiple (S,G) flows share the same source S 🥰. A single Source Aggregated Assert Record with n Group Addresses represents the info for assert records (S,G1)...(S,Gn) 💫.

The "RP Aggregated Assert Record" (see Section 4.4.2) encodes one common Metric and Metric Preference, plus a list of "Group Records." Each Group Record encodes a Group Address and a list of zero or more Source Addresses with a count 🧮. It's called an "RP Aggregated Assert Record" because, with standard RPF according to [RFC7761], all the Group Addresses that use the same RP end up with the same Metric and Metric Preference 🎯.

RP Aggregation Assert Records give you a more compact encoding than the Simple PackedAssert message format for (*,G) flows 🪄. The Source Address is optionally used in the assert procedures in [RFC7761] to indicate the source(s) that triggered the assert. Otherwise, the Source Address is set to 0 in the assert record 🔢.

Both Source Aggregated Assert Records and RP Aggregated Assert Records also include the R flag 🏳️‍🌈. It keeps the semantics it has in [RFC7761], but it also tells the two encodings apart 💜. Source Aggregated Assert Records have R=0, the same as (S,G) assert records in [RFC7761] 🩵. RP Aggregated Assert Records have R=1, the same as (*,G) assert records in [RFC7761] 🌷.

That's the end of part 1, and honestly the vibes are immaculate 🌈👑✨

3.3. PackedAssert Mechanism ✨

okay so PackedAsserts do NOT touch the PIM Assert state machine from [RFC7761] 💅 The new sending and receiving stuff in the subsections below is just a set of extra packetization options for assert records, sitting next to the regular (non-packed) Assert message from [RFC7761]. Same info elements, same meanings, zero changes 🙌 The only difference is you get fewer but bigger packets, and the info takes up fewer total bytes. So PIM routers should be able to send and receive assert records faster and/or with less processing overhead. It's giving efficiency 🧚

3.3.1. Sending PackedAssert Messages

When assert packing is on, the regular Assert encoding from [RFC7761] with A=0 and P=0 is still allowed to be sent 🌸 Routers get to pick whichever PackedAssert format they like: simple (Section 4.3) and/or aggregated (Section 4.4). Your choice, bestie 💖

  • When any PIM routers on the LAN have not signaled support for assert packing, implementations MUST only send Asserts and MUST NOT send PackedAsserts under any condition. Non-negotiable 🚫
  • The protocol or system conditions that decide between sending PackedAsserts and sending Asserts are out of scope for this specification 🙈 Protocol conditions include triggers like data-triggered asserts or Assert Timer (AT) expiry-triggered asserts. System conditions include high or low load or control plane packet reception rates.
  • Implementations are expected to spell out in documentation and/or management interfaces (such as a YANG data model) which PackedAssert message formats they can send and under which conditions they'll send them 📝
  • Implementations SHOULD be able to tell the operator (such as through a YANG data model) how many Assert and PackedAssert messages were sent/received and how many assert records were sent/received. Operators love stats 📊
  • A configuration option SHOULD be available to disable PackedAssert operations. PIM-SM implementations [RFC7761] that add assert packing from day one MAY skip this configuration option 🎀

When a PIM router has an assert record ready to send according to [RFC7761], it calls one of these functions:

  • send Assert(S,G) / send Assert(*,G) ([RFC7761], Section 4.2)
  • send Assert(S,G) / send AssertCancel(S,G) ([RFC7761], Section 4.6.1)
  • send Assert(*,G) / send AssertCancel(*,G) ([RFC7761], Section 4.6.2)
  • send Assert(S,G) ([RFC7761], Section 4.8.2)

If PackedAssert sending is possible on the network, then instead of sending an Assert message with an assert record, any of those calls MAY instead have the PIM implementation remember the assert record and keep going with other flows, which may end up producing more assert records 🧠

PIM MUST then build PackedAssert messages from the remembered assert records and schedule them for sending, following the considerations in the subsections below 📦

3.3.1.1. Handling of Reception-Triggered Assert Records

This is the big one, babe 🔥 Avoiding extra delay from packing matters MOST for assert records triggered by receiving data, or by receiving asserts while the router is in the "I am Assert Winner" state. For these, the router SHOULD send out an Assert or PackedAssert containing that record ASAP, so duplicate IP multicast packets don't hang around for long ⏰

To avoid extra delay here, the router should use the right assert packing and scheduling mechanisms, which I'll explain now 🧚

  • Asserts and PackedAsserts made from reception-triggered assert records should be scheduled for serialization at a higher priority than the ones made for other protocol or system conditions. They should also skip ahead of other PIM messages that can cause big bursts, like PIM join/prune messages 🚀
  • If there are no reception-triggered Assert/PackedAssert messages currently being serialized on the interface or scheduled to be sent, the router should immediately generate and schedule an Assert or PackedAssert message with no extra assert packing 💨
  • If one or more reception-triggered Assert/PackedAssert messages are already serializing or scheduled to be serialized on the outgoing interface, the router can use the time until the last of them finishes serializing to handle PIM processing for other conditions. This can lead to more reception-triggered assert records, which can get packed in without adding any delay ✨

3.3.1.2. Handling of Timer Expiry-Triggered Assert Records

Asserts triggered by the AT expiring on an assert winner aren't time-critical, lowkey 😌 They can be scheduled ahead of time, and the Assert_Override_Interval parameter from [RFC7761] already gives a 3-second window where these records can be sent, received, and processed before an assert loser's state expires and duplicate IP multicast packets could happen.

One example mechanism for packing AT expiry-triggered assert records on assert winners is to round the AT to a suitable granularity, like 100 msec. That way the AT for multiple (S,G) and/or (*,G) states expires at the same time, so they're easy to pack without changing the Assert state machinery 🎀

AssertCancel messages carry assert records with an infinite metric, and they can be packed like any other Assert 💅 They're sent when the Override Timer (OT) expires, and they can be packed using the same considerations as AT expiry-triggered assert records, for example.

3.3.1.3. Beneficial Delay in Sending PackedAssert Messages

Delaying PackedAsserts beyond what the earlier subsections talked about can still be worth it 🦋 It helps when it lowers the overall number of possible duplicate IP multicast packets in a situation with a huge number of (S,G) and/or (*,G) states, compared to an implementation that only sends Assert messages.

Implementations can use this delay because they can't support the more advanced mechanisms above 🙈 The longer delay can come from simpler approaches (like only generating PackedAsserts periodically), and it still cuts down on duplicate IP multicast packets compared to sending only Asserts. Simple but effective, iykyk 💖

3.3.1.4. Handling Assert/PackedAssert Message Loss

When Asserts are sent, a single packet loss only causes continued or new duplicates from a single IP multicast flow 😮‍💨 But losing a (non-AssertCancel) PackedAssert hits duplicates for EVERY flow packed into it, and it might mean resending more than one Assert/PackedAssert, since the assert records may not be packable in that situation 💀 So routers SHOULD support mechanisms that let PackedAsserts and Asserts go out with an appropriate Differentiated Services Code Point (DSCP) [RFC2475], such as Expedited Forwarding (EF), to minimize loss. This matters most when duplicate IP multicast packets could cause congestion and loss 🚨

Routers MAY support a configurable option to send PackedAssert messages twice in quick succession (such as 50 msec apart) to overcome possible loss, but only when BOTH of these conditions are met:

  1. The total size of the two PackedAsserts is less than the total size of equivalent Assert messages.
  2. The condition of the assert record flows in the PackedAssert is such that the router can expect their reception by PIM routers will not trigger Assert/PackedAsserts replies. This condition is true, for example, when sending an assert record while becoming or being assert winner (Action A1/A3 in [RFC7761]).

3.3.1.5. Optimal Degree of Assert Record Packing

The best target packing size depends on things like implementation characteristics and the scale you need to operate at 🌈 As you vary the target packing size from a single non-packed Assert up to the MTU size, there should be a sweet spot where the router hits the required operating scale of (S,G) and (*,G) flows with the fewest duplicates ✨ Past that point, making the target packing size bigger doesn't give you any more benefits, and it might cause negative effects like more duplicates on loss. Too much of a good thing, bestie 🙃

For example, in some router implementations, the total number of packets that a control plane function like PIM can send/receive per unit of time matters more than the total amount of data across those packets. Once the packet size is big enough for the maximum possible payload throughput, making packets even bigger may still cut processing overhead, but it can add latency to building the packet, which can create more duplicates than smaller packets would 😭

3.3.2. Receiving PackedAssert Messages

When a PIM router receives a PackedAssert message, it logically turns the payload into a sequence of assert records 🫶 Then each one gets processed as if an equivalent sequence of Assert messages had been received under [RFC7761]. Same treatment, no drama 👑

4. Packet Formats

This section is the packet format tea ☕ It describes the format of the new PIM extensions introduced by this document 💜

4.1. PIM Packed Assert Capability Hello Option

The PIM Packed Assert Capability Hello Option is a brand-new option for PIM Hello messages, following Section 4.9.2 of [RFC7761] 🎀

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OptionType = 40          |      OptionLength = 0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: PIM Packed Assert Capability Hello Option 🦋

  • OptionType 40 (Packed Assert Capability): Indicates support for the ability to receive and process all the PackedAssert encodings defined in this document ✨
  • OptionLength 0: The Packet Assert Capability has no OptionValue 🙈

4.2. Assert Message Format ✨

Okay so, Figure 2 shows a regular PIM Assert message, the one defined in Section 4.9.6 of [RFC7761] 🦋. The Encoded-Group and Encoded-Unicast address formats are specified in Section 4.9.1 of [RFC7761] for IPv4 and IPv6 🌸.

    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  |7 6 5 4 3 2|A|P|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Group Address (Encoded-Group format)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                      Metric Preference                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: Assert Message Format

This common header shows the "7 6 5 4 3 2" flag bits (as defined in Section 4 of [RFC9436]) and the location of the P and A flags (as described in Section 5). As specified in Section 3.2, both flags in a (non-packed) PIM Assert message are required to be set to 0 🫶.

4.3. Simple PackedAssert Message Format 💖

Here's the Simple PackedAssert layout, and it's giving "packed lunchbox" energy 🍱.

    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  |7 6 5 4 3 2|A|P|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Zero       |                     Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Assert Record [1]                      .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Assert Record [2]                      .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Assert Record [M]                      .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: Simple PackedAssert Message Format
  • PIM Version, Type, Checksum: As specified in Section 4.9.6 of [RFC7761].
  • "7 6 5 4 3 2": Flag bits per Section 4 of [RFC9436].
  • P: Packed flag. MUST be 1. 🔥
  • A: Aggregated flag. MUST be 0.
  • Zero: Set to zero on transmission. This is the sneaky trick 🙈: PIM routers that can't do assert packing will fail to parse the message, instead of possibly mis-parsing it as an Assert message [RFC7761] if this field wasn't zero-filled.
  • Reserved: Set to zero on transmission. Ignored upon receipt.
  • M: The number of Assert Records in the message. Derived from the length of the packet carrying the message.
  • Assert Record: Formatted according to Figure 3, which is the same as the PIM Assert message body as specified in Section 4.9.6 of [RFC7761].

The format of each Assert Record is the same as the PIM Assert message body as specified in Section 4.9.6 of [RFC7761] 💅.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Group Address (Encoded-Group format)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                      Metric Preference                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 4: Assert Record

4.4. Aggregated PackedAssert Message Format 👑

The Aggregated version is the glow-up 🧚. Same packed vibe, but the records are aggregated.

    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  |7 6 5 4 3 2|A|P|           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Zero       |                     Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                     Aggregated Assert Record [1]              .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                     Aggregated Assert Record [2]              .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                     Aggregated Assert Record [M]              .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 5: Aggregated PackedAssert Message Format
  • PIM Version, Type, Reserved, Checksum: As specified in Section 4.9.6 of [RFC7761].
  • "7 6 5 4 3 2": Flag bits per Section 4 of [RFC9436].
  • P: Packed flag. MUST be 1.
  • A: Aggregated flag. MUST be 1. ✨
  • Zero: Set to zero on transmission. Same sneaky trick 🙈: PIM routers that can't do assert packing will fail to parse the message, instead of possibly mis-parsing it as an Assert message [RFC7761] if this field wasn't zero-filled.
  • Aggregated Assert Record: Formatted according to Figure 5. The number M of Aggregated Assert Records is determined from the packet size.

4.4.1. Source Aggregated Assert Record 🦋

Here's the Source Aggregated Assert Record, which is basically the group-packing queen 👑.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                      Metric Preference                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Number of Groups (N)   |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Group Address 1 (Encoded-Group format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Group Address 2 (Encoded-Group format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Group Address N (Encoded-Group format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 6: Source Aggregated Assert Record
  • R: MUST be 0.

R indicates both that the encoding format of the record is that of a Source Aggregated Assert Record and that all assert records represented by the Source Aggregated Assert Record have R=0 and are therefore (S,G) assert records according to the definition of R in [RFC7761], Section 4.9.6. 🫶

  • Metric Preference, Metric, Source Address: As specified in Section 4.9.6 of [RFC7761]. Source Address MUST NOT be zero. 🙈
  • Number of Groups: The number of Group Address fields.
  • Reserved: Set to zero on transmission. Ignored upon receipt.
  • Group Address: As specified in Section 4.9.6 of [RFC7761].

4.4.2. RP Aggregated Assert Record ✨

okay so the RP Aggregated Assert Record is basically the group chat's way of bundling up (,G) assert records 💅 It packs together every (,G) assert record that has the same Metric Preference and Metric. Usually that's all the (*,G) entries using the same RP, but the encoding isn't limited to that, because the RP address isn't encoded here. It isn't in assert records either [RFC7761], so no one's keeping track of it 🙈

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                      Metric Preference                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Group Records (K) |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [1]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [2]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [K]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7: RP Aggregated Assert Record

R: this bit is the big flag 🎀 It MUST be 1. Setting R to 1 tells you two things at once: this record is in the RP Aggregated Assert Record format, and every assert record it stands in for has R=1. That makes them all (*,G) assert records, per the definition of R in [RFC7761], Section 4.9.6 ✨

Metric Preference, Metric: these are exactly as specified in Section 4.9.6 of [RFC7761] 💜

Number of Group Records (K): this is how many packed Group Records are in the message 🧚 Each record is a Group Address plus a Source Address list with a bunch of sources in it.

Reserved: set to zero on transmission and ignored upon receipt 🌸

Each Group Record looks like this, bestie 👑

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Group Address (Encoded-Group format)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Number of Sources (P)  |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Source Address 1 (Encoded-Unicast format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Source Address 2 (Encoded-Unicast format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Source Address P (Encoded-Unicast format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 8: Group Record

Group Address: as specified in Section 4.9.6 of [RFC7761] 🦋

Reserved: set to zero on transmission and ignored upon receipt 🌸

Number of Sources (P): this corresponds to the number of Source Address fields in the Group Record 💖 If this number isn't 0 and one of the (*,G) assert records being encoded has Source Address 0, then 0 needs to be encoded as one of the Source Address fields. Don't skip it, it's the vibe check 😭

Reserved: set to zero on transmission and ignored upon receipt 🌸

Source Address: as specified in Section 4.9.6 of [RFC7761] 🦋 the one twist is that there can be multiple Source Address fields in a single Group Record 🧚

5. IANA Considerations 🎀

IANA has updated the "PIM Message Types" registry so it includes the Packed and Aggregated flag bits for the Assert message type. Lowkey a big deal 🌈

+=======+========+==========================+===========+
| Value | Length | Name                     | Reference |
+=======+========+==========================+===========+
|   40  |   0    | Packed Assert Capability | RFC 9466  |
+-------+--------+--------------------------+-----------+

                   Table 1: PIM-Hello Options

IANA has also assigned the following two flag bits for PIM Assert messages in the "PIM Message Types" registry 🦋

+======+========+=================+=====================+
| Type | Name   | Flag Bits       | Reference           |
+======+========+=================+=====================+
|  5   | Assert | 0: Packed       | RFC 9466            |
|      |        +-----------------+---------------------+
|      |        | 1: Aggregated   | RFC 9466            |
|      |        +-----------------+---------------------+
|      |        | 2-7: Unassigned | [RFC3973] [RFC7761] |
+------+--------+-----------------+---------------------+

                   Table 2: PIM Message Types

6. Security Considerations 💀

okay bestie, this one is serious, so pay attention 🚨

The security considerations of [RFC7761] apply to the extensions defined in this document. No escaping those 🔒

This document packs multiple assert records into a single message. As described in Section 6.1 of [RFC7761], a forged Assert message could cause the legitimate designated forwarder to stop forwarding traffic to the LAN. And the effect may be amplified when using a PackedAssert message 😱

Like other optional extensions of [RFC7761] that are active only when all routers indicate support for them, a single misconfigured or malicious router emitting forged PIM Hello messages can inhibit operations of this extension. One bad router can ruin the whole party 💀

Authentication of PIM messages, such as that explained in Sections 6.2 and 6.3 of [RFC7761], can protect against forged message attacks attacks. Yes, that's really how it's written 🙈 The fix is authentication, so go look at those sections 🫶

7. References 📚

7.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>.

[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>.

[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>.

[RFC9436] Venaas, S. and A. Retana, "PIM Message Type Space Extension and Reserved Bits", RFC 9436, DOI 10.17487/RFC9436, August 2023, <https://www.rfc-editor.org/info/rfc9436>.

7.2. Informative References

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[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>.

[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, DOI 10.17487/RFC6037, October 2010, <https://www.rfc-editor.org/info/rfc6037>.

[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, <https://www.rfc-editor.org/info/rfc7431>.

[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.

Appendix A. Use Case Examples 🧚

The PIM Assert mechanism can only be avoided by designing the network to be without transit subnets with multiple upstream routers. For example, an L2 ring between routers can sometimes be reconfigured into a ring of point-to-point subnets connected by the routers. Still, these L2/L3 topology changes are undesirable when they're only done to enable IP multicast with PIM, because they increase the cost of introducing IP multicast with PIM 💸

These L3 ring designs are especially undesirable when particular L2 technologies are needed 🙅‍♀️ For example, various L2 technologies for rings provide sub-50 msec failover mechanisms that benefit IP unicast and multicast alike, with no added complexity at the IP layer (forwarding or routing) ⚡ If those L2 rings were replaced by L3 rings just to avoid PIM asserts, you'd need a complex choice of a sub-50 msec IP unicast failover solution (such as [RFC7490] with IP repair tunnels), plus a separate sub-50 msec IP multicast failover solution (such as [RFC7431] with dedicated ring support). Running at the IP layer means different solutions for unicast and multicast, which makes things harder to operate, and they typically need more expensive hardware 💅 This often leads to non-support of the IP multicast part, and that's the tea ☕

Likewise, IEEE Time-Sensitive Networking mechanisms would require an L2 topology that cannot simply be replaced by an L3 topology. L2 sub-topologies can also significantly reduce the cost of deployment 🌸

The following subsections give examples of the types of networks and use cases in which subnets with asserts have been observed, or are expected to need the scaling this specification provides 🦋

A.1. Enterprise Network 🏢

When an enterprise network is connected through an L2 network, the intra-enterprise runs L3 PIM multicast. The different sites of the enterprise are equivalent to the PIM connection through the shared LAN network. Depending on the locations and number of groups, there could be many asserts on the first-hop routers 👀

A.2. Video Surveillance 🎥

Okay so video surveillance has totally glowed up from analog systems to IP-based ones, and a lot of the time it's using multicast 🦋. In shared LAN deployments, when there are many cameras streaming to many groups, things can get messy, because there may be issues with many asserts on first-hop routers 😭.

A.3. Financial Services 💸

Financial services are obsessed with IP Multicast for delivering stock market data and its derivatives 📈, and the current multicast solution PIM is usually deployed ✨. As the number of multicast flows grows, lots of stock data with lots of groups may result in many PIM asserts on a shared LAN network going from the publisher to the subscribers 💀.

A.4. IPTV Broadcast Video 📺

PIM DR deployments are often used in the host-side network for IPTV broadcast video services 🎀. Host-side access network failure scenarios may benefit from assert packing when many groups are being used 🧚. According to [RFC7761], the DR will be elected to forward multicast traffic in the shared access network 👑. When the DR recovers from a failure, the original DR starts to send traffic, and the current DR is still forwarding traffic 😳. In this situation, multicast traffic duplication maybe happen in the shared access network and can trigger the assert progress 🔥.

A.5. MVPN MDT 🌸

As described in [RFC6037], Multicast Distribution Tree (MDT) is used as tunnels for Multicast VPN (MVPN) 🫶. The configuration of multicast-enabled VPN Routing and Forwarding (VRF) or changes to an interface that is in a VRF may cause many assert packets to be sent at the same time 🙈.

A.6. Special L2 Services 🌈

Additionally, future backhaul, or fronthaul, networks may want to connect L3 across an L2 underlay supporting Time-Sensitive Networks (TSNs) 💜. The infrastructure may run Deterministic Networking (DetNet) over TSN 🧚. These transit L2 LANs would have multiple upstreams and downstreams. This document takes a proactive approach to prevention of possible future assert issues in these types of environments 💅.

Acknowledgments 🫶

The authors would like to thank the following individuals: Stig Venaas for the valuable contributions of this document, Alvaro Retana for his thorough and constructive RTG AD review, Ines Robles for her Gen-ART review, Tommy Pauly for his Transport Area review, Robert Sparks for his SecDir review, Shuping Peng for her RtgDir review, John Scudder for his RTG AD review, Éric Vyncke for his INT AD review, Eric Kline for his INT AD review, Paul Wouter for his SEC AD review, Zaheduzzaman Sarker for his TSV AD review, Robert Wilton for his OPS AD review, and Martin Duke for his TSV AD review. Thank you all, you absolutely carried 👑💖

Authors' Addresses 📇

  • Yisong Liu (editor), China Mobile, China, Email: liuyisong@chinamobile.com
  • Toerless Eckert (editor), Futurewei, United States of America, Email: tte@cs.fau.de
  • Mike McBride, Futurewei, United States of America, Email: michael.mcbride@futurewei.com
  • Zheng (Sandy) Zhang, ZTE Corporation, China, Email: zhang.zheng@zte.com.cn
📦 where this page comes from