PIM Assert Message PackingChina MobileChinaliuyisong@chinamobile.comFutureweiUnited States of Americatte@cs.fau.deFutureweiUnited States of Americamichael.mcbride@futurewei.comZTE CorporationChinazhang.zheng@zte.com.cn
rtg
pimipipv6multicastperformancescalabilitysubnetlansparse-modeASMSSMWhen 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
.
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
() 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
. Introduction
. Requirements Language
. Terminology
. Problem Statement
. Specification
. PIM Packed Assert Capability Hello Option
. Assert Packing Message Formats
. PackedAssert Mechanism
. Sending PackedAssert Messages
. Handling of Reception-Triggered Assert Records
. Handling of Timer Expiry-Triggered Assert Records
. Beneficial Delay in Sending PackedAssert Messages
. Handling Assert/PackedAssert Message Loss
. Optimal Degree of Assert Record Packing
. Receiving PackedAssert Messages
. Packet Formats
. PIM Packed Assert Capability Hello Option
. Assert Message Format
. Simple PackedAssert Message Format
. Aggregated PackedAssert Message Format
. Source Aggregated Assert Record
. RP Aggregated Assert Record
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
. Use Case Examples
. Enterprise Network
. Video Surveillance
. Financial Services
. IPTV Broadcast Video
. MVPN MDT
. Special L2 Services
Acknowledgments
Authors' Addresses
IntroductionWhen 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 . 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.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
when, and only when, they appear in all capitals, as shown here.
TerminologyThe reader is expected to be familiar with the terminology of . 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
Problem StatementPIM Asserts occur in many deployments. See
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.SpecificationThis document defines three elements in support of PIM assert packing:
The PIM Packed Assert Capability Hello Option
The encoding of PackedAssert messages
How to send and receive PackedAssert messages
PIM Packed Assert Capability Hello OptionThe PIM Packed Assert Capability Hello Option () is used to announce support
for the assert packing mechanisms specified in this document.
PackedAssert messages ()
MUST NOT be used unless all PIM routers in the same subnet announce this option.Assert Packing Message FormatsThe PIM Assert message, as defined in , 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 : the Packed (P) and the Aggregated (A)
flags.If P=0, the message is a (non-packed) PIM Assert
message as specified in . See . 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 .If A=1, then the message body is a sequence of aggregated assert
records. This is called an "Aggregated PackedAssert message". See .Two aggregated assert record types are specified.The "Source Aggregated Assert Record" (see ) 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 ) 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 , 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 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
but also distinguishes the encodings. Source
Aggregated Assert Records have R=0, as (S,G) assert records do in
. RP Aggregated Assert Records have R=1, as
(*,G) assert records do in .PackedAssert MechanismPackedAsserts do not change the 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 (non-packed) Assert message . 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.Sending PackedAssert MessagesWhen using assert packing, the regular Assert message encoding
with A=0 and P=0 is still allowed to be
sent. Routers are free to choose which PackedAssert message format
they send -- simple ()
and/or aggregated ().
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 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
, it calls one of the following
functions:
send Assert(S,G) / send Assert(*,G) ()
send Assert(S,G) / send AssertCancel(S,G) ()
send Assert(*,G) / send AssertCancel(*,G) ()
send Assert(S,G) ()
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.Handling of Reception-Triggered Assert RecordsAvoiding 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.Handling of Timer Expiry-Triggered Assert RecordsAsserts 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 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.Beneficial Delay in Sending PackedAssert MessagesDelay 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.Handling Assert/PackedAssert Message LossWhen 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) 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.
The total size of the two PackedAsserts is less than the
total size of equivalent Assert messages.
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 ).
Optimal Degree of Assert Record PackingThe 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.Receiving PackedAssert MessagesUpon 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 .Packet FormatsThis section describes the format of new PIM extensions introduced by
this document.PIM Packed Assert Capability Hello OptionThe PIM Packed Assert Capability Hello Option is a new option for PIM Hello
messages according to .PIM Packed Assert Capability 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 = 40 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Assert Message Format shows a PIM Assert message as
specified in . The Encoded-Group and Encoded-Unicast address
formats are specified in for IPv4 and IPv6.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This common header shows the "7 6 5 4 3 2" flag bits (as defined in
) and the
location of the P and A flags (as described in ).
As specified in , both flags in
a (non-packed) PIM Assert message are required to be set to 0.Simple PackedAssert Message FormatSimple 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] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Checksum:
As specified in .
"7 6 5 4 3 2":
Flag bits per .
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 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 ,
which is the same as the PIM Assert message body as specified in
.
The format of each Assert Record is the same as the PIM Assert
message body as specified in .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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aggregated PackedAssert Message FormatAggregated 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] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Type, Reserved, Checksum:
As specified in .
"7 6 5 4 3 2":
Flag bits per .
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 if this field was not
zero-filled.
Aggregated Assert Record:
Formatted according to .
The number M of Aggregated Assert Records is determined from the
packet size.
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 .
Metric Preference, Metric, Source Address:
As specified in . 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 .
RP Aggregated Assert RecordAn 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 .RP 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Group Records (K) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [K] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
Metric Preference, Metric:
As specified in .
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:Group 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Address:
As specified in .
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 . But there can be multiple Source Address
fields in the Group Record.
IANA ConsiderationsIANA has updated the "PIM Message Types" registry as follows to
include the Packed and Aggregated flag bits for the Assert message
type.
PIM-Hello Options
Value
Length
Name
Reference
40
0
Packed Assert Capability
RFC 9466
IANA has assigned the following two flag bits for PIM Assert messages
in the "PIM Message Types" registry.
PIM Message Types
Type
Name
Flag Bits
Reference
5
Assert
0: Packed
RFC 9466
1: Aggregated
RFC 9466
2-7: Unassigned
Security ConsiderationsThe security considerations of apply to the
extensions defined in this document.This document packs multiple assert records in a single message. As
described in ,
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 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
and of , can protect against forged message attacks
attacks.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.PIM Message Type Space Extension and Reserved BitsThe PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and extends the PIM type space.This document updates RFCs 7761 and 3973 by defining the use of the Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the bits for each PIM message.This document obsoletes RFC 8736.Informative ReferencesAn Architecture for Differentiated ServicesThis document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNsThis document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.Multicast-Only Fast RerouteAs IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.Use Case ExamplesThe 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 with IP repair tunnels) as well as a
separate sub-50 msec IP multicast failover solution, (such as 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.Enterprise NetworkWhen 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.Video SurveillanceVideo 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.Financial ServicesFinancial 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.IPTV Broadcast VideoPIM 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 , 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.MVPN MDTAs described in , 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.Special L2 ServicesAdditionally, 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.AcknowledgmentsThe authors would like to thank the following individuals:
for the valuable contributions of this document, for his thorough and constructive RTG AD
review, for her Gen-ART review,
for his Transport Area review,
for his SecDir review, for her RtgDir review, for his RTG AD review, for
his INT AD review, for his INT AD
review, for his SEC AD review,
for his TSV AD review,
for his OPS AD review, and for his TSV AD review.Authors' AddressesChina MobileChinaliuyisong@chinamobile.comFutureweiUnited States of Americatte@cs.fau.deFutureweiUnited States of Americamichael.mcbride@futurewei.comZTE CorporationChinazhang.zheng@zte.com.cn