PIM Assert Message Packing
draft-ietf-pim-assert-packing-09

PIM                                                          Y. Liu, Ed.
Internet-Draft                                              China Mobile
Intended status: Standards Track                          T. Eckert, Ed.
Expires: 9 September 2023                                     M. McBride
                                                               Futurewei
                                                                Z. Zhang
                                                         ZTE Corporation
                                                            8 March 2023

                       PIM Assert Message Packing
                    draft-ietf-pim-assert-packing-09

Abstract

   LANs often have more than one upstream router.  When PIM Sparse Mode
   (PIM-SM), including PIM Source Specific-Specific Multicast (PIM-SSM),
   is used, 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 September 2023.

Liu, et al.             Expires 9 September 2023                [Page 1]
Internet-Draft               assert-packing                   March 2023

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  PIM Assert Packing Hello Option . . . . . . . . . . . . .   5
     3.2.  Assert Packing Message Formats  . . . . . . . . . . . . .   5
     3.3.  PackedAssert Mechanism  . . . . . . . . . . . . . . . . .   6
       3.3.1.  Sending PackedAssert messages . . . . . . . . . . . .   6
       3.3.2.  Receiving PackedAssert messages . . . . . . . . . . .   9
   4.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  PIM Assert Packing Hello Option . . . . . . . . . . . . .  10
     4.2.  Assert Message Format . . . . . . . . . . . . . . . . . .  10
     4.3.  Simple PackedAssert Message Format  . . . . . . . . . . .  10
     4.4.  Aggregated PackedAssert Message Format  . . . . . . . . .  12
       4.4.1.  Source Aggregated Assert Record . . . . . . . . . . .  14
       4.4.2.  RP Aggregated Assert Record . . . . . . . . . . . . .  15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   8.  Working Group considerations  . . . . . . . . . . . . . . . .  18
     8.1.  Open Issues . . . . . . . . . . . . . . . . . . . . . . .  18
     8.2.  Changelog . . . . . . . . . . . . . . . . . . . . . . . .  18
       8.2.1.  draft-ietf-pim-assert-packing-09  . . . . . . . . . .  18
       8.2.2.  draft-ietf-pim-assert-packing-08  . . . . . . . . . .  19
       8.2.3.  draft-ietf-pim-assert-packing-07  . . . . . . . . . .  19
       8.2.4.  draft-ietf-pim-assert-packing-06  . . . . . . . . . .  19
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Appendix A.  Use case examples  . . . . . . . . . . . . . . . . .  20
     A.1.  Enterprise network  . . . . . . . . . . . . . . . . . . .  21

Liu, et al.             Expires 9 September 2023                [Page 2]
Internet-Draft               assert-packing                   March 2023

     A.2.  Video surveillance  . . . . . . . . . . . . . . . . . . .  21
     A.3.  Financial Services  . . . . . . . . . . . . . . . . . . .  21
     A.4.  IPTV broadcast Video  . . . . . . . . . . . . . . . . . .  21
     A.5.  MVPN MDT  . . . . . . . . . . . . . . . . . . . . . . . .  22
     A.6.  Special L2 services . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   In PIM-SM 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-preference and
   metric 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 to send and receive 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 particularly be 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

   RP: Rendezvous Point

   RPF: Reverse Path Forwarding

Liu, et al.             Expires 9 September 2023                [Page 3]
Internet-Draft               assert-packing                   March 2023

   SPT: Shortest Path Tree

   RPT: RP Tree

   DR: Designated Router

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 network with more than 2 PIM routers, there may be
   multiple upstream routers, which can cause duplicate multicast
   traffic to be forwarded and assert process 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 PIM assert small 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.  These
   L2/L3 topology changes are undesirable though, 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
   50msec failover mechanisms, something not possible equally with an L3
   subnet based ring.  Likewise, IEEE Time Sensitive Networking
   mechanisms would require an L2 topology that can not 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 Assert Packing Hello Option.

Liu, et al.             Expires 9 September 2023                [Page 4]
Internet-Draft               assert-packing                   March 2023

   2.  The encoding of PackedAssert messages.

   3.  How to send and receive PackedAssert messages.

3.1.  PIM Assert Packing Hello Option

   The PIM Assert Packing 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 through 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.

   Assert packing introduces two new PIM Assert message encodings
   through the allocation and use of two flags in the PIM Assert message
   header [I-D.ietf-pim-rfc8736bis], the Packed (P) and the Aggregated
   (A) flags.

   If the (P)acked flag is 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 the (P) flag is 1, then the message is called a PackedAssert
   message and the type and hence encoding format of the payload is
   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".  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).

Liu, et al.             Expires 9 September 2023                [Page 5]
Internet-Draft               assert-packing                   March 2023

   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 Records provide a more compact encoding than the
   Simple PackedAssert message format for (*,G) flows.  The Source
   Address is optionally used by [RFC7761] assert procedures 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 semantic 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 [RFC7761] PIM assert state machine
   specification.  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 (not
   packed) [RFC7761] Assert Message.  There is no change to the assert
   record information elements transmitted or their semantic.  They are
   just transmitted in fewer but larger packets and fewer total number
   of bytes used to encode the information elements.  In result, PIM
   routers should be able to send/receive assert records faster and/or
   with less processing overhead.

3.3.1.  Sending PackedAssert messages

   When using assert packing, the regular [RFC7761] Assert message
   encoding with A=0 and P=0 is still allowed to be sent.  Routers are
   free to choose which PackedAssert message type they send.

   It is out of scope of this specification for which conditions, such
   as data-triggered asserts or Assert Timer (AT) expiry based asserts,
   an implementation should generate PackedAsserts instead of Asserts.

   Instead,

Liu, et al.             Expires 9 September 2023                [Page 6]
Internet-Draft               assert-packing                   March 2023

   *  Implementations are expected to specify in documentation and/or
      management interfaces (such as a YANG model), which PackedAssert
      message types they can send and under which conditions they will.

   *  Implementations SHOULD NOT send only Asserts, but no PackedAsserts
      under all conditions, when all routers on the LAN do support
      Assert Packing.

   *  When any PIM routers on the LAN have not signaled support for
      Assert Packing, implementations MUST send only Asserts and MUST
      NOT send PackedAsserts under any condition.

   When a PIM router has an assert record ready to send according to
   [RFC7761], it calls send Assert(S,G) / send Assert(_,G)
   (Section 4.2), Send Assert(S,G) / SendAssertCancel(S,G)
   (Section 4.6.1), Send Assert(_,G) / Send AssertCancel(*,G)
   (Section 4.6.2) and send Assert(S,G) (Section 4.8.2).  Each of these
   calls will send an Assert message.  When sending of PackedAsserts is
   possible on the network, any of these calls is permitted to not send
   an Assert message, but only remember the assert record, and let PIM
   continue with further processing for other flows that may result in
   additional assert records - to finally packed PackedAssert messages
   from the remembered assert records and send them.

   The following text discusses several conditions to be taken into
   account for this further processing and how to create and schedule
   PackedAssert messages.

   Avoiding possible additional and relevant delay because of further
   processing 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, such as for
   example the following.

Liu, et al.             Expires 9 September 2023                [Page 7]
Internet-Draft               assert-packing                   March 2023

   Asserts/PackedAsserts in this case are scheduled for serialization
   with highest priority, such that they bypass any potentially earlier
   scheduled other packets.  When there is no such Assert/PacketAssert
   message scheduled for or being serialized, the router immediately
   serializes an Assert or PackedAssert message without further assert
   packing.  If there are one or more Assert/PackedAssert messages
   serialized and/or scheduled to be serialized, then the router can
   pack assert records into new PackedAssert messages until shortly
   before the last of those Assert/PackedAssert packets has finished
   serializing.

   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 of [RFC7761] already creates a
   3 second window in which such assert records can be sent, received,
   and processed before an assert losers state would expire 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 100msec.  This will cause 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 as 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.

   Additional delay is not "relevant" when it still causes the overall
   amount of (possible) duplicate IP multicast packets to decrease in a
   condition with large number of (S,G) and/or (*,G), compared to the
   situation in which no delay is added by the implementation.

   This can simply be the case because the implementation can not afford
   to implement the (more advanced) mechanisms described above, and some
   simpler mechanism that does introduce some additional delay still
   causes more overall reduction in duplicate IP multicast packets than
   not sending PackedAsserts at all, but only Asserts.

   "Relevant" is a highly implementation dependent metric and can
   typically only be measured against routers of the same type as
   receivers, and performance results with other routers will likely
   differ.  Therefore it is optional.

   When Asserts are sent, a single packet loss will result only in
   continued or new duplicates from a single IP multicast flow.  Loss of
   (non AssertCancel) PackedAssert impacts duplicates for all flows

Liu, et al.             Expires 9 September 2023                [Page 8]
Internet-Draft               assert-packing                   March 2023

   packed into the PackedAssert and may result in the need for re-
   sending more than one Assert/PacketAssert, because of the possible
   inability to pack the assert records in this condition.  Therefore,
   routers SHOULD support mechanisms allowing for PackedAsserts and
   Asserts to be sent with an appropriate DSCP, 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 50msec 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 records 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]).

   It is sufficient that assert records are not packed up to MTU size,
   but to a size that allows the router to achieve the required
   operating scale of (S,G) and (*,G) flows with minimum duplicates.
   This packing size may be larger when the network is operating with
   the maximum number of supported multicast flows, and it can be a
   smaller packing size when operating with fewer multicast flows.
   Larger than sufficient packets may then not provide additional
   benefits, because they only reduce the performance requirements for
   packet sending and reception, and other performance limiting factors
   may take over once a sufficient size is reached.  And larger packets
   can incur more duplicates on loss.  Routers may support a sufficient
   amount of packing to minimize the negative impacts of loss of
   PackedAssert packets without loss of performance of minimizing IP
   multicast packet duplication.

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 where
   received according to [RFC7761].

4.  Packet Formats

   This section describes the format of new PIM extensions introduced by
   this document.

Liu, et al.             Expires 9 September 2023                [Page 9]
Internet-Draft               assert-packing                   March 2023

4.1.  PIM Assert Packing Hello Option

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

                 Figure 1: PIM Assert Packing Hello Option

   The PIM Assert Packing Hello Option is a new option for PIM Hello
   Messages according to Section 4.9.2 of [RFC7761].

   *  OptionType TBD: PIM Packed Assert Capability Hello Option

   Including the PIM OptionType TBD indicates support for the ability to
   receive and process all the PackedAssert encodings defined in this
   document.

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

                      Figure 2: Assert Message Format

   Figure 2 shows a PIM Assert message as specified in Section 4.9.6 of
   [RFC7761] with the common header showing the "7 6 5 4 3 2" Flag Bits
   as defined in Section 4 of [I-D.ietf-pim-rfc8736bis] and the location
   of the P and A flags, see Section 5.  As specified in Section 3.2
   below, both flags in a (non-packed) PIM Assert message are required
   to be set to 0.

4.3.  Simple PackedAssert Message Format

Liu, et al.             Expires 9 September 2023               [Page 10]
Internet-Draft               assert-packing                   March 2023

    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": IANA registry handled bits according to Section 4
      of [I-D.ietf-pim-rfc8736bis].

   *  Zero: Set to zero on transmission.  Serves to make non assert
      packing capable PIM routers fail in parsing the message instead of
      possible mis-parsing if this field was used.

   *  Reserved: Set to zero on transmission.  Ignored upon receipt.

   *  P: packed flag.  MUST be 1.

   *  A: aggregated flag.  MUST be 0.

Liu, et al.             Expires 9 September 2023               [Page 11]
Internet-Draft               assert-packing                   March 2023

   *  M: The number of Assert Records in the message.  Derived from the
      length of the packet carrying the message.

   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

Liu, et al.             Expires 9 September 2023               [Page 12]
Internet-Draft               assert-packing                   March 2023

    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": IANA registry handled bits according to Section 4
      of [I-D.ietf-pim-rfc8736bis].

   *  P: packed flag.  MUST be 1.

   *  A: aggregated flag.  MUST be 1.

   *  Zero: Set to zero on transmission.  Serves to make non assert
      packing capable PIM routers fail in parsing the message instead of
      possible mis-parsing if this field was used.

Liu, et al.             Expires 9 September 2023               [Page 13]
Internet-Draft               assert-packing                   March 2023

   *  M: The number of Aggregated Assert Records in the message.
      Derived from the length of the packet carrying the message.

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

   *  Reserved: Set to zero on transmission.  Ignored upon receipt.

   *  R: MUST be 0.

      R indicates both that the encoding format of the record is that of
      a Source Aggregated Assert Record, but also 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.

   *  Source Address, Metric Preference, Metric:

      As specified in Section 4.9.6 of [RFC7761].  Source Address MUST
      NOT be zero.

   *  Number of Groups:

      The number of Group Address fields.

   *  Group Address:

Liu, et al.             Expires 9 September 2023               [Page 14]
Internet-Draft               assert-packing                   March 2023

      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 [RFC7761] assert records.

    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.

Liu, et al.             Expires 9 September 2023               [Page 15]
Internet-Draft               assert-packing                   March 2023

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

   *  Reserved: Set to zero on transmission.  Ignored upon receipt.

   *  Number of Group Records:

      The number of packed Group Records.  A record consists of a Group
      Address and a Source Address list with a number of sources.

   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 and Reserved:

      As specified in Section 4.9.6 of [RFC7761].

   *  Reserved: Set to zero on transmission.  Ignored upon receipt.

   *  Number of Sources:

Liu, et al.             Expires 9 September 2023               [Page 16]
Internet-Draft               assert-packing                   March 2023

      The Number of Sources is corresponding to the number of Source
      Address fields in the Group Record.  If this number is 0, the
      Group Record indicates one assert record with a Source Address of
      0.  If this number is not 0 and one of the (*,G) assert records to
      be encoded should have the Source Address 0, then 0 needs to be
      encoded as one of the Source Address fields.

   *  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 is requested to assign a new code point from the "PIM-Hello
   Options" registry for the Packed Assert Capability as follows:

   +=======+========+=========================+================+
   | Value | Length |          Name           | Reference      |
   +=======+========+=========================+================+
   | TBD   |      0 | Packed Assert Capability| [This Document]|
   +=======+========+=========================+================+

                    Figure 9: IANA PIM-Hello Options ask

   IANA is requested to assign two Flag Bits in the Assert message from
   the "PIM Message Types" registry as follows:

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

                   Figure 10: IANA PIM Message Types ask

   [RFC-Editor note: If IANA can not assign the requested two bits 0 and
   1, then the figures showing those two bits need to be fixed to show P
   and A in the actual locations IANA assigns - aka: the bits shown are
   "placeholders" according to the requested bits in this section.]

6.  Security Considerations

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

Liu, et al.             Expires 9 September 2023               [Page 17]
Internet-Draft               assert-packing                   March 2023

   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.

7.  Acknowledgments

   The authors would like to thank: 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 and Shuping Peng for her RtgDir review.

8.  Working Group considerations

   [RFC-Editor: please remove this section].

8.1.  Open Issues

8.2.  Changelog

   This document is hosted starting with -06 on
   https://github.com/toerless/pim-assert-packing.

8.2.1.  draft-ietf-pim-assert-packing-09

   For details of review discussion/replies, see review reply emails in
   (https://github.com/toerless/pim-assert-packing/tree/main/emails)j

   review Alvaro Retana: Reintroduced ref to PIM-DM, fixed typos,
   downgraded MAY->may for "sufficient".

   IANA Expert Review / Stig Venaas:

   Removed Count field from message headers as it complicates parsing
   and is unnecessary.  Added "Zero" field to make packed asserts
   received by a non-packed-assert-capable-router guaranteed to fail
   ("Reserved" address family type).

   Changed from RFC8736 to RFC8736bis so that we can use the word
   "Unassigned" in the IANA table.

   Review Shuping Peng

   Changed explanation of how assert packing works from "layer" to
   "alternative to packetization via PIM Assert Message.  Fixed various
   typos, expanded term etc..

Liu, et al.             Expires 9 September 2023               [Page 18]
Internet-Draft               assert-packing                   March 2023

   Review Robert Sparks:

   Moved Intro explanations of how one could avoid asserts (but how its
   problematic) to appendix.  Applied textual nits found.  Removed
   quotes around term "sufficient" for easier readbility.

   Review Tommy Paul:

   Transport related concern explained in reply, but no additional
   explanations in text because the question referred to basic PIM
   behavior expected to be understood by readers: No discovery of loss/
   trigger for retransmission, just restransmission of same message
   element after discover of ongoing duplicates and/or expiry of timers.

8.2.2.  draft-ietf-pim-assert-packing-08

   Included changes from review of Alvaro Retana
   (https://mailarchive.ietf.org/arch/msg/pim/
   GsKq9bB2a6yDdM9DvAUGCWthdEI)

   Please see the following emails discussing the changes:

   https://raw.githubusercontent.com/toerless/pim-assert-packing/main/
   emails/07-alvaro-review-reply.txt

8.2.3.  draft-ietf-pim-assert-packing-07

   Included changes from review of Alvaro Retana
   (https://mailarchive.ietf.org/arch/msg/pim/
   Cp4o5glUFge2b84X9CQMwCWZjAk/)

   Please see the following emails discussing the changes:

   https://raw.githubusercontent.com/toerless/pim-assert-packing/main/
   emails/05-alvaro-review-reply.txt

   https://raw.githubusercontent.com/toerless/pim-assert-packing/main/
   emails/07-pim-wg-announce.txt

8.2.4.  draft-ietf-pim-assert-packing-06

   This version was converted from txt format into markdown for better
   editing later, but is otherwise text identical to -05.  It was posted
   to DataTracker to make diffs easier.

   Functional changes:

9.  References

Liu, et al.             Expires 9 September 2023               [Page 19]
Internet-Draft               assert-packing                   March 2023

9.1.  Normative References

   [I-D.ietf-pim-rfc8736bis]
              Venaas, S. and A. Retana, "PIM Message Type Space
              Extension and Reserved Bits", Work in Progress, Internet-
              Draft, draft-ietf-pim-rfc8736bis-00, 2 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-
              rfc8736bis-00>.

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

9.2.  Informative References

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
              January 2005, <https://www.rfc-editor.org/info/rfc3973>.

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

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.  These
   L2/L3 topology changes are undesirable though, when they are only
   done to enable IP multicast with PIM because they increase the cost
   of introducing IP multicast with PIM.

Liu, et al.             Expires 9 September 2023               [Page 20]
Internet-Draft               assert-packing                   March 2023

   These designs are also not feasible when specific L2 technologies are
   needed.  For example various L2 technologies for rings provide sub
   50msec failover mechanisms, something not possible equally with an L3
   subnet based ring.  Likewise, IEEE Time Sensitive Networking
   mechanisms would require an L2 topology that can not 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 observerd or are
   expected to require scaling as provided by this specification.

A.1.  Enterprise network

   When an Enterprise network is connected through a layer-2 network,
   the intra-enterprise runs layer-3 PIM multicast.  The different sites
   of the enterprise are equivalent to the PIM connection through the
   shared LAN network.  Depending upon the locations and amount 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 current multicast solution PIM
   is usually deployed.  As the number of multicast flows grow, there
   are many stock data with many groups may result in many PIM asserts
   on a shared LAN network from 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 scenario
   may be benefitted by 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 the situation multicast traffic
   duplication maybe happen in the shared access network and can trigger
   the assert progress.

Liu, et al.             Expires 9 September 2023               [Page 21]
Internet-Draft               assert-packing                   March 2023

A.5.  MVPN MDT

   As described in [RFC6037], MDT (Multicast Distribution Tree) is used
   as tunnels for MVPN.  The configuration of multicast-enabled VRF (VPN
   routing and forwarding) or interface that is in a VRF changing may
   cause many assert packets to be sent in a 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
   (TSN).  The infrastructure may run DetNet over TSN.  These transit L2
   LANs would have multiple upstreams and downstreams.  This document is
   taking a proactive approach to prevention of possible future assert
   issues in these types of environments.

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

Liu, et al.             Expires 9 September 2023               [Page 22]