PIM Assert Message Packing
Extracted elements (29)
PackedAssert messages do not change the PIM Assert state machine; they are purely a packetization optimization that transmits the same assert record information in fewer, larger packets with reduced total byte overhead, enabling faster processing without protocol semantic changes.
Routers MAY send PackedAssert messages twice in short order (e.g., 50 msec apart) to overcome packet loss, but only when the total size of both copies is less than equivalent Assert messages AND the assert records are in a winner state that would not trigger reply storms.
The RP Aggregated Assert Record is named for RP aggregation but deliberately does not encode the RP address, because RP address is not present in RFC 7761 assert records; grouping is based on shared Metric Preference and Metric, which typically corresponds to a shared RP.
Timer expiry-triggered asserts can be packed by rounding the Assert Timer to a coarse granularity (e.g., 100 msec), causing multiple (S,G) and (*,G) timers to expire simultaneously and enabling easy packing without changes to the Assert state machinery.
The Zero field in Simple and Aggregated PackedAssert messages is set to zero on transmission specifically to cause non-capable PIM routers to fail in parsing rather than mis-parse the message as a standard Assert message.
Upon reception of a PackedAssert message, the PIM router logically converts its payload into a sequence of assert records processed as if an equivalent sequence of Assert messages were received per RFC 7761, with no change to the Assert state machine.
A configuration option SHOULD be available to disable PackedAssert operations; PIM-SM implementations that introduce assert packing from day one MAY omit this option.
For reception-triggered assert records, the router SHOULD send out an Assert or PackedAssert message containing this assert record as soon as possible to minimize duplicate IP multicast packets.
If P=0 in the Assert message header, the A flag MUST be set to 0 and MUST be ignored on receipt, indicating a standard non-packed PIM Assert message.
Implementations SHOULD be able to indicate to the operator how many Assert and PackedAssert messages were sent/received and how many assert records were sent/received.
In a Source Aggregated Assert Record, the R flag MUST be 0 and the Source Address MUST NOT be zero.
In an RP Aggregated Assert Record, the R flag MUST be 1.
PackedAssert messages MUST NOT be used unless all PIM routers in the same subnet announce the PIM Packed Assert Capability Hello Option.
Routers SHOULD support mechanisms that allow PackedAsserts and Asserts to be sent with an appropriate DSCP such as Expedited Forwarding (EF) to minimize their loss.
When a PIM router has remembered assert records and sending of PackedAsserts is possible, PIM MUST create PackedAssert messages from the remembered assert records and schedule them for sending.
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.
A Source Aggregated Assert Record encodes one common Source Address, Metric Preference, and Metric with a list of N Group Addresses, representing (S,G1)...(S,Gn) assert records for a shared source. R MUST be 0.
An RP Aggregated Assert Record encodes one common Metric Preference and Metric with K Group Records, each containing a Group Address and a list of P Source Addresses, aggregating (*,G) assert records sharing the same Metric. R MUST be 1.
The PIM Packed Assert Capability Hello Option (OptionType=40, OptionLength=0) announces support for assert packing mechanisms. It has no OptionValue.
Two new flag bits are introduced in the PIM Assert message header via RFC 9436: the Packed (P) flag (bit 0) and the Aggregated (A) flag (bit 1). P=1 indicates a PackedAssert message; A=1 within a PackedAssert indicates aggregated encoding.
IANA updated the 'PIM-Hello Options' registry to add OptionType 40 (Packed Assert Capability, length 0) referencing RFC 9466.
IANA updated the 'PIM Message Types' registry for Assert (Type 5) to assign flag bit 0 as 'Packed' and flag bit 1 as 'Aggregated', both referencing RFC 9466; bits 2-7 remain Unassigned.
A forged Assert message could cause the legitimate designated forwarder to stop forwarding traffic to the LAN; this effect may be amplified when using a PackedAssert message since a single forged PackedAssert impacts all flows packed into it.
A single misconfigured or malicious router emitting forged PIM Hello messages can inhibit assert packing operations for the entire subnet, since the mechanism requires all routers to announce support. Authentication per RFC 7761 Sections 6.2/6.3 can protect against forged message attacks.
The Aggregated PackedAssert message (P=1, A=1) header contains a 1-byte Zero field followed by 3 Reserved bytes, then M Aggregated Assert Records (either Source Aggregated or RP Aggregated). M is determined from the packet size.
The PIM Packed Assert Capability Hello Option wire format is two 16-bit fields: OptionType=40 and OptionLength=0, with no OptionValue field.
The RP Aggregated Assert Record begins with R(1 bit)|Metric Preference(31 bits), Metric (32 bits), Number of Group Records K (16 bits), Reserved (16 bits), followed by K Group Records each containing a Group Address, Number of Sources P (16 bits), Reserved (16 bits), and P Source Addresses.
The Simple PackedAssert message (P=1, A=0) header contains a 1-byte Zero field followed by 3 Reserved bytes, then a sequence of M Assert Records identical in format to RFC 7761 Assert message bodies. M is derived from the packet length.
The Source Aggregated Assert Record begins with R(1 bit)|Metric Preference(31 bits), followed by Metric (32 bits), Source Address (Encoded-Unicast), Number of Groups N (16 bits), Reserved (16 bits), and N Group Addresses (Encoded-Group format).