This 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
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.
The PIM Assert message, as defined in
Section 4.9.6 of
RFC 7761, 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 [
RFC 9436]: the Packed (P) and the Aggregated (A) flags.
If P=0, the message is a (non-packed) PIM Assert message as specified in [
RFC 7761]. 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 [
RFC 7761], 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 [
RFC 7761] 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 [
RFC 7761] but also distinguishes the encodings. Source Aggregated Assert Records have R=0, as (S,G) assert records do in [
RFC 7761]. RP Aggregated Assert Records have R=1, as (*,G) assert records do in [
RFC 7761].
PackedAsserts do not change the PIM Assert state machine specification [
RFC 7761]. 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 [
RFC 7761]. 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.
When using assert packing, the regular Assert message encoding [
RFC 7761] 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 [RFC 7761] 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 [
RFC 7761], it calls one of the following functions:
-
send Assert(S,G) / send Assert(*,G) (RFC 7761, Section 4.2)
-
send Assert(S,G) / send AssertCancel(S,G) (RFC 7761, Section 4.6.1)
-
send Assert(*,G) / send AssertCancel(*,G) (RFC 7761, Section 4.6.2)
-
send Assert(S,G) (RFC 7761, 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.
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.
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 [
RFC 7761] 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.
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.
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) [
RFC 2475] 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 [RFC 7761]).
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.
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 [
RFC 7761].