doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc9466.txt b/doc/rfc/rfc9466.txt
new file mode 100644
index 0000000..ee1ee90
--- /dev/null
+++ b/doc/rfc/rfc9466.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       Y. Liu, Ed.
+Request for Comments: 9466                                  China Mobile
+Category: Standards Track                                 T. Eckert, Ed.
+ISSN: 2070-1721                                               M. McBride
+                                                               Futurewei
+                                                                Z. Zhang
+                                                         ZTE Corporation
+                                                            October 2023
+
+
+                       PIM Assert Message Packing
+
+Abstract
+
+   When PIM Sparse Mode (PIM-SM), including PIM Source-Specific
+   Multicast (PIM-SSM), is used in shared LAN networks, there is often
+   more than one upstream router.  This can lead to duplicate IP
+   multicast packets being forwarded by these PIM routers.  PIM Assert
+   messages are used to elect a single forwarder for each IP multicast
+   traffic flow between these routers.
+
+   This document defines a mechanism to send and receive information for
+   multiple IP multicast flows in a single PackedAssert message.  This
+   optimization reduces the total number of PIM packets on the LAN and
+   can therefore speed up the election of the single forwarder, reducing
+   the number of duplicate IP multicast packets incurred.
+
+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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9466.
+
+Copyright Notice
+
+   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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided 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 is used in shared LAN networks, there is typically more
+   than one upstream router.  When duplicate data packets appear on the
+   LAN from different upstream routers, assert packets are sent from
+   these routers to elect a single forwarder according to [RFC7761].
+   The PIM Assert messages are sent periodically to keep the Assert
+   state.  The PIM Assert message carries information about a single
+   multicast source and group, along with the corresponding Metric and
+   Metric Preference of the route towards the source or PIM Rendezvous
+   Point (RP).
+
+   This document defines a mechanism to encode the information of
+   multiple PIM Assert messages into a single PackedAssert message.
+   This allows sending and receiving information for multiple IP
+   multicast flows in a single PackedAssert message without changing the
+   PIM Assert state machinery.  It reduces the total number of PIM
+   packets on the LAN and can therefore speed up the election of the
+   single forwarder, reducing the number of duplicate IP multicast
+   packets.  This can be particularly helpful when there is traffic for
+   a large number of multicast groups or SSM channels and PIM packet
+   processing performance of the routers is slow.
+
+1.1.  Requirements Language
+
+   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.
+
+1.2.  Terminology
+
+   The reader is expected to be familiar with the terminology of
+   [RFC7761].  The following lists the abbreviations repeated in this
+   document.
+
+   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 occur in many deployments.  See Appendix A for explicit
+   examples and explanations of why it is often not possible to avoid.
+
+   PIM Assert state depends mainly on the network topology.  As long as
+   there is a Layer 2 (L2) network with more than two PIM routers, there
+   may be multiple upstream routers, which can cause duplicate multicast
+   traffic to be forwarded and assert processing to occur.
+
+   As the multicast services become widely deployed, the number of
+   multicast entries increases, and a large number of Assert messages
+   may be sent in a very short period when multicast data packets
+   trigger PIM assert processing in the shared LAN networks.  The PIM
+   routers need to process a large number of small PIM assert packets in
+   a very short time.  As a result, the device load is very large.  The
+   assert packet may not be processed in time or even discarded, thus
+   extending the time of traffic duplication in the network.
+
+   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 to
+   be a ring of point-to-point subnets connected by the routers.
+   However, these Layer 2 (L2) and Layer 3 (L3) topology changes are
+   undesirable when they are only done to enable IP multicast with PIM
+   because they increase the cost of introducing IP multicast with PIM.
+
+   These designs are also not feasible when specific L2 technologies are
+   needed.  For example, various L2 technologies for rings provide
+   sub-50 msec failover mechanisms, something not possible equally with
+   a ring composed from L3 subnets.  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.
+
+3.  Specification
+
+   This document defines three elements in support of 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 used
+   to announce support for the assert packing mechanisms specified in
+   this document.  PackedAssert messages (Section 3.2) MUST NOT be used
+   unless all PIM routers in the same subnet announce this option.
+
+3.2.  Assert Packing Message Formats
+
+   The PIM Assert message, as defined in Section 4.9.6 of [RFC7761],
+   describes the parameters of a (*,G) or (S,G) assert using the
+   following information elements: Rendezvous Point Tree flag (R),
+   Source Address, Group Address, Metric, and Metric Preference.  This
+   document calls this information an "assert record".
+
+   This document introduces two new PIM Assert message encodings through
+   the allocation and use of two flags in the PIM Assert message header
+   [RFC9436]: the Packed (P) and the Aggregated (A) flags.
+
+   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.
+
+   If P=1, then the message is called a "PackedAssert message", and the
+   type and hence encoding format of the payload are determined by the A
+   flag.
+
+   If A=0, then the message body is a sequence of assert records.  This
+   is called a "Simple PackedAssert message".  See Section 4.3.
+
+   If A=1, then 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 as well as a
+   list of one or more Group Addresses.  Source Aggregated Assert
+   Records provide 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 information of assert records for (S,G1)...(S,Gn).
+
+   The "RP Aggregated Assert Record" (see Section 4.4.2) encodes one
+   common Metric and Metric Preference as well as a list of "Group
+   Records", each of which encodes a Group Address and a list of zero or
+   more Source Addresses with a count.  This is called an "RP Aggregated
+   Assert Record", because with standard RPF according to [RFC7761], all
+   the Group Addresses that use the same RP will have the same Metric
+   and Metric Preference.
+
+   RP Aggregation Assert Records provide 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, which maintains its semantics from
+   [RFC7761] but also distinguishes the encodings.  Source Aggregated
+   Assert Records have R=0, as (S,G) assert records do in [RFC7761].  RP
+   Aggregated Assert Records have R=1, as (*,G) assert records do in
+   [RFC7761].
+
+3.3.  PackedAssert Mechanism
+
+   PackedAsserts do not change the PIM Assert state machine
+   specification [RFC7761].  Instead, sending and receiving of
+   PackedAssert messages, as specified in the following subsections, are
+   logically new packetization options for assert records in addition to
+   the (non-packed) Assert message [RFC7761].  There is no change to the
+   assert record information elements transmitted or their semantics.
+   They are just transmitted in fewer but larger packets, and a fewer
+   total number of bytes is used to encode the information elements.  As
+   a result, PIM routers should be able to send and receive assert
+   records faster and/or with less processing overhead.
+
+3.3.1.  Sending PackedAssert Messages
+
+   When using assert packing, the regular Assert message encoding
+   [RFC7761] with A=0 and P=0 is still allowed to be sent.  Routers are
+   free to choose which PackedAssert message format they send -- simple
+   (Section 4.3) and/or aggregated (Section 4.4).
+
+   *  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.
+
+   *  The protocol or system conditions for which an implementation
+      sends PackedAsserts instead of Asserts are out of scope for this
+      specification.  Protocol conditions include protocol triggers such
+      as data-triggered asserts or Assert Timer (AT) expiry-triggered
+      asserts, and system conditions include high or low load or control
+      plane packet reception rates.
+
+   *  Implementations are expected to specify in documentation and/or
+      management interfaces (such as a YANG data model) which
+      PackedAssert message formats they can send and under which
+      conditions they will send them.
+
+   *  Implementations SHOULD be able to indicate to 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.
+
+   *  A configuration option SHOULD be available to disable PackedAssert
+      operations.  PIM-SM implementations [RFC7761] that introduce
+      support for assert packing from day one MAY omit this
+      configuration option.
+
+   When a PIM router has an assert record ready to send according to
+   [RFC7761], it calls one of the following 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 sending of PackedAsserts is possible on the network, instead of
+   sending an Assert message with an assert record, any of these calls
+   MAY instead result in the PIM implementation remembering the assert
+   record and continuing with further processing for other flows, which
+   may result in additional assert records.
+
+   PIM MUST then create PackedAssert messages from the remembered assert
+   records and schedule them for sending according to the considerations
+   in the following subsections.
+
+3.3.1.1.  Handling of Reception-Triggered Assert Records
+
+   Avoiding additional delay because of assert packing compared to
+   immediately scheduling Assert messages is most critical for assert
+   records that are triggered by reception of data or reception of
+   asserts against which the router is in the "I am Assert Winner"
+   state.  In these cases, the router SHOULD send out an Assert or
+   PackedAssert message containing this assert record as soon as
+   possible to minimize the time in which duplicate IP multicast packets
+   can occur.
+
+   To avoid additional delay in this case, the router should employ
+   appropriate assert packing and scheduling mechanisms, as explained
+   here.
+
+   Asserts/PackedAsserts created from reception-triggered assert records
+   should be scheduled for serialization with a higher priority than
+   those created because of other protocol or system conditions.  They
+   should also bypass other PIM messages that can create significant
+   bursts, such as PIM join/prune messages.
+
+   When 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 without further assert packing.
+
+   If one or more reception-triggered Assert/PackedAssert messages are
+   already serializing or are scheduled to be serialized on the outgoing
+   interface, then the router can use the time until the last of those
+   messages has finished serializing for PIM processing of further
+   conditions.  This may result in additional reception-triggered assert
+   records and the packing of these assert records without introducing
+   additional delay.
+
+3.3.1.2.  Handling of Timer Expiry-Triggered Assert Records
+
+   Asserts triggered by expiry of the AT on an assert winner are not
+   time-critical because they can be scheduled in advance and because
+   the Assert_Override_Interval parameter [RFC7761] already creates a
+   3-second window in which such assert records can be sent, received,
+   and processed before an assert loser's state expires and duplicate IP
+   multicast packets could occur.
+
+   An example mechanism to allow packing of AT expiry-triggered assert
+   records on assert winners is to round the AT to an appropriate
+   granularity such as 100 msec.  This will cause the AT for multiple
+   (S,G) and/or (*,G) states to expire at the same time, thus allowing
+   them to be easily packed without changes to the Assert state
+   machinery.
+
+   AssertCancel messages have assert records with an infinite metric and
+   can use assert packing like any other Assert.  They are sent on
+   Override Timer (OT) expiry and can be packed, for example, with the
+   same considerations as AT expiry-triggered assert records.
+
+3.3.1.3.  Beneficial Delay in Sending PackedAssert Messages
+
+   Delay in sending PackedAsserts beyond what was discussed in prior
+   subsections can still be beneficial when it causes the overall number
+   of possible duplicate IP multicast packets to decrease in a situation
+   with a large number of (S,G) and/or (*,G), compared to the situation
+   where an implementation only sends Assert messages.
+
+   This delay can be used in implementations because it cannot support
+   the more advanced mechanisms described above, and this longer delay
+   can be achieved by some simpler mechanisms (such as only periodic
+   generation of PackedAsserts) and still achieves an overall reduction
+   in duplicate IP multicast packets compared to sending only Asserts.
+
+3.3.1.4.  Handling Assert/PackedAssert Message Loss
+
+   When Asserts are sent, a single packet loss will result only in
+   continued or new duplicates from a single IP multicast flow.  Loss of
+   a (non-AssertCancel) PackedAssert impacts duplicates for all flows
+   packed into the PackedAssert and may result in the need for resending
+   more than one Assert/PackedAssert, because of the possible inability
+   to pack the assert records in this condition.  Therefore, routers
+   SHOULD support mechanisms that allow PackedAsserts and Asserts to be
+   sent with an appropriate Differentiated Services Code Point (DSCP)
+   [RFC2475] such as Expedited Forwarding (EF) to minimize their loss,
+   especially when duplicate IP multicast packets could cause congestion
+   and loss.
+
+   Routers MAY support a configurable option for sending PackedAssert
+   messages twice in short order (such as 50 msec apart) to overcome
+   possible loss, but only when the following two 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 that 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 optimal target packing size will vary depending on factors
+   including implementation characteristics and the required operating
+   scale.  At some point, as the target packing size is varied from the
+   size of a single non-packed Assert to the MTU size, a size can be
+   expected to be found where the router can achieve the required
+   operating scale of (S,G) and (*,G) flows with minimum duplicates.
+   Beyond this size, a further increase in the target packing size would
+   not produce further benefits but might introduce possible negative
+   effects such as the incurrence of more duplicates on loss.
+
+   For example, in some router implementations, the total number of
+   packets that a control plane function such as PIM can send/receive
+   per unit of time is a more limiting factor than the total amount of
+   data across these packets.  As soon as the packet size is large
+   enough for the maximum possible payload throughput, increasing the
+   packet size any further may still reduce the processing overhead of
+   the router but may increase latency incurred in creating the packet
+   in a way that may increase duplicates compared to smaller packets.
+
+3.3.2.  Receiving PackedAssert Messages
+
+   Upon reception of a PackedAssert message, the PIM router logically
+   converts its payload into a sequence of assert records that are then
+   processed as if an equivalent sequence of Assert messages were
+   received according to [RFC7761].
+
+4.  Packet Formats
+
+   This section describes the format of new PIM extensions introduced by
+   this document.
+
+4.1.  PIM Packed Assert Capability Hello Option
+
+   The PIM Packed Assert Capability Hello Option is a new option for PIM
+   Hello messages according to 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
+
+   Figure 2 shows a PIM Assert message as specified 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
+
+    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.  Serves to make PIM routers that are
+      not capable of assert packing to fail in parsing the message
+      instead possible mis-parsing of the message as an Assert message
+      [RFC7761] if this field was not 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
+
+    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.  Serves to make PIM routers that are
+      not capable of assert packing to fail in parsing the message
+      instead possible mis-parsing of the message as an Assert message
+      [RFC7761] if this field was not 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
+
+    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
+
+   An RP Aggregation Assert Record aggregates (*,G) assert records with
+   the same Metric Preference and Metric.  Typically, this is the case
+   for all (*,G) using the same RP, but the encoding is not limited to
+   only (*,G) using the same RP because the RP address is not encoded as
+   it is also not present in assert records [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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |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:
+      MUST be 1.
+
+      R indicates both that the encoding format of the record is that of
+      an RP Aggregated Assert Record and that all assert records
+      represented by the RP Aggregated Assert Record have R=1 and are
+      therefore (*,G) assert records according to the definition of R in
+      [RFC7761], Section 4.9.6.
+
+   Metric Preference, Metric:
+      As specified in Section 4.9.6 of [RFC7761].
+
+   Number of Group Records (K):
+      The number of packed Group Records.  A record consists of a Group
+      Address and a Source Address list with a number of sources.
+
+   Reserved:
+      Set to zero on transmission.  Ignored upon receipt.
+
+   The format of each Group Record is:
+
+    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.  Ignored upon receipt.
+
+   Number of Sources (P):
+      The Number of Sources corresponds to the number of Source Address
+      fields in the Group Record.  If this number is not 0 and one of
+      the (*,G) assert records to be encoded has Source Address 0, then
+      0 needs to be encoded as one of the Source Address fields.
+
+   Reserved:
+      Set to zero on transmission.  Ignored upon receipt.
+
+   Source Address:
+      As specified in Section 4.9.6 of [RFC7761].  But there can be
+      multiple Source Address fields in the Group Record.
+
+5.  IANA Considerations
+
+   IANA has updated the "PIM Message Types" registry as follows to
+   include the Packed and Aggregated flag bits for the Assert message
+   type.
+
+   +=======+========+==========================+===========+
+   | Value | Length | Name                     | Reference |
+   +=======+========+==========================+===========+
+   |   40  |   0    | Packed Assert Capability | RFC 9466  |
+   +-------+--------+--------------------------+-----------+
+
+                   Table 1: PIM-Hello Options
+
+   IANA has 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
+
+   The security considerations of [RFC7761] apply to the extensions
+   defined in this document.
+
+   This document packs multiple assert records in 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.  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.
+
+   Authentication of PIM messages, such as that explained in Sections
+   6.2 and 6.3 of [RFC7761], can protect against forged message attacks
+   attacks.
+
+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 to
+   be a ring of point-to-point subnets connected by the routers.
+   However, these L2/L3 topology changes are undesirable when they are
+   only done to enable IP multicast with PIM because they increase the
+   cost of introducing IP multicast with PIM.
+
+   These L3 ring designs are specifically undesirable when particular L2
+   technologies are needed.  For example, various L2 technologies for
+   rings provide sub-50 msec failover mechanisms that will benefit IP
+   unicast and multicast alike without any added complexity to the IP
+   layer (forwarding or routing).  If such L2 rings were to be replaced
+   by L3 rings just to avoid PIM asserts, then this would result in the
+   need for a complex choice of a sub-50 msec IP unicast failover
+   solution (such as [RFC7490] with IP repair tunnels) as well as a
+   separate sub-50 msec IP multicast failover solution, (such as
+   [RFC7431] with dedicated ring support).  The mere fact that, by
+   running at the IP layer, different solutions for IP unicast and
+   multicast are required makes them more difficult to operate, and they
+   typically require more expensive hardware.  This often leads to non-
+   support of the IP multicast part.
+
+   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 type of network and
+   use cases in which subnets with asserts have been observed or are
+   expected to require scaling as provided by this specification.
+
+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 upon the locations and number of groups,
+   there could be many asserts on the first-hop routers.
+
+A.2.  Video Surveillance
+
+   Video surveillance deployments have migrated from analog-based
+   systems to IP-based systems oftentimes using multicast.  In the
+   shared LAN network deployments, when there are many cameras streaming
+   to many groups, there may be issues with many asserts on first-hop
+   routers.
+
+A.3.  Financial Services
+
+   Financial services extensively rely on IP Multicast to deliver stock
+   market data and its derivatives, and the current multicast solution
+   PIM is usually deployed.  As the number of multicast flows grow, many
+   stock data with many groups may result in many PIM asserts on a
+   shared LAN network from the publisher to the subscribers.
+
+A.4.  IPTV Broadcast Video
+
+   PIM DR deployments are often used in 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.
+
+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