rfc9466xml2.original.xml   rfc9466.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 3.1
.2) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-pim-assert-packing-12" number="9466" submissionType="IETF" category="std" consensus="true" tocDepth="5" tocInclude="true" sortRefs="true" symRefs="true" u pdates="" obsoletes="" xml:lang="en" version="3">
<rfc ipr="trust200902" docName="draft-ietf-pim-assert-packing-12" category="std" consensus="true" submissionType="IETF" tocDepth="5" tocInclude="true" sortRefs= "true" symRefs="true">
<front> <front>
<title abbrev="assert-packing">PIM Assert Message Packing</title> <title abbrev="PIM Assert Packing">PIM Assert Message Packing</title>
<seriesInfo name="RFC" value="9466"/>
<author initials="Y." surname="Liu" fullname="Yisong Liu" role="editor"> <author initials="Y." surname="Liu" fullname="Yisong Liu" role="editor">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<country>China</country> <country>China</country>
</postal> </postal>
<email>liuyisong@chinamobile.com</email> <email>liuyisong@chinamobile.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Eckert" fullname="Toerless Eckert" role="edit or"> <author initials="T." surname="Eckert" fullname="Toerless Eckert" role="edit or">
<organization>Futurewei</organization> <organization>Futurewei</organization>
<address> <address>
<postal> <postal>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>tte@cs.fau.de</email> <email>tte@cs.fau.de</email>
</address> </address>
</author> </author>
<author initials="M." surname="McBride" fullname="Mike McBride"> <author initials="M." surname="McBride" fullname="Mike McBride">
<organization>Futurewei</organization> <organization>Futurewei</organization>
<address> <address>
<postal> <postal>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>michael.mcbride@futurewei.com</email> <email>michael.mcbride@futurewei.com</email>
</address> </address>
</author> </author>
<author initials="Z." surname="Zhang" fullname="Zheng(Sandy) Zhang"> <author initials="Z." surname="Zhang" fullname="Zheng (Sandy) Zhang">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhang.zheng@zte.com.cn</email> <email>zhang.zheng@zte.com.cn</email>
</address> </address>
</author> </author>
<date year="2023" month="October"/>
<date year="2023" month="April" day="19"/> <area>rtg</area>
<workgroup>pim</workgroup>
<workgroup>PIM</workgroup> <workgroup>ip</workgroup>
<workgroup>ipv6</workgroup>
<workgroup>multicast</workgroup>
<workgroup>performance</workgroup>
<workgroup>scalability</workgroup>
<workgroup>subnet</workgroup>
<workgroup>lan</workgroup>
<workgroup>sparse-mode</workgroup>
<workgroup>ASM</workgroup>
<workgroup>SSM</workgroup>
<abstract> <abstract>
<t>In PIM-SM shared LAN networks, there is often more than one upstream router. <t>When PIM Sparse Mode (PIM-SM), including PIM Source-Specific
When PIM Sparse Mode (PIM-SM), including PIM Source Specific-Specific Multicast Multicast (PIM-SSM), is used in shared LAN networks, there is often more
(PIM-SSM), is used, this than one upstream router. This can lead to duplicate IP multicast packets
can lead to duplicate IP multicast packets being forwarded by these being forwarded by these PIM routers. PIM Assert messages
PIM routers. PIM Assert messages are used to elect a single forwarder for are used to elect a single forwarder for each IP multicast traffic
each IP multicast traffic flow between these routers.</t> flow between these routers.</t>
<t>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.</t>
<t>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.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<name>Introduction</name>
<t>When PIM-SM is used in shared LAN networks, there is typically more than
one upstream router. When duplicate data packets appear on the LAN from
different upstream routers, assert packets are sent from these routers to
elect a single forwarder according to <xref target="RFC7761"/>. The PIM
Assert messages are sent periodically to keep the Assert state. The PIM
Assert message carries information about a single multicast source and
group, along with the corresponding Metric and Metric Preference of the
route towards the source or PIM Rendezvous Point (RP).</t>
<t>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.</t>
<section anchor="requirements-language">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="terminology">
<section anchor="introduction"><name>Introduction</name> <name>Terminology</name>
<t>The reader is expected to be familiar with the terminology of <xref t
<t>In PIM-SM shared LAN networks, there is typically more than one arget="RFC7761"/>. The following lists the abbreviations repeated in this docume
upstream router. When duplicate data packets appear on the LAN, from nt.</t>
different upstream routers, assert packets are sent from these <dl newline="false" spacing="normal" indent="6">
routers to elect a single forwarder according to <xref target="RFC7761"/>. The P <dt>AT:</dt>
IM <dd>Assert Timer</dd>
assert messages are sent periodically to keep the assert state. The <dt>DR:</dt>
PIM assert message carries information about a single multicast <dd>Designated Router</dd>
source and group, along with the corresponding metric-preference and <dt>RP:</dt>
metric of the route towards the source or PIM Rendezvous Point (RP).</t> <dd>Rendezvous Point</dd>
<dt>RPF:</dt>
<t>This document defines a mechanism to encode the information of <dd>Reverse Path Forwarding</dd>
multiple PIM Assert messages into a single PackedAssert message. <dt>RPT:</dt>
This allows to send and receive information for multiple IP multicast flows <dd>RP Tree</dd>
in a single PackedAssert message without changing the PIM Assert state <dt>SPT:</dt>
machinery. It reduces the total number of PIM packets on the LAN and can <dd>Shortest Path Tree</dd>
therefore speed up the election of the single forwarder, reducing the number </dl>
of duplicate IP multicast packets. This can particularly be helpful when </section>
there is traffic for a large number of multicast groups or SSM channels and </section>
PIM packet processing performance of the routers is slow.</t> <section anchor="problem-statement">
<name>Problem Statement</name>
<section anchor="requirements-language"><name>Requirements Language</name> <t>PIM Asserts occur in many deployments. See <xref target="use-case-examp
les"/>
<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th
ey appear in all
capitals, as shown here.</t>
</section>
<section anchor="terminology"><name>Terminology</name>
<t>The reader is expected to be familiar with the terminology of <xref target="R
FC7761"/>. The following lists the abbreviations repeated in this document.</t>
<t>AT: Assert Timer</t>
<t>RP: Rendezvous Point</t>
<t>RPF: Reverse Path Forwarding</t>
<t>SPT: Shortest Path Tree</t>
<t>RPT: RP Tree</t>
<t>DR: Designated Router</t>
</section>
</section>
<section anchor="problem-statement"><name>Problem Statement</name>
<t>PIM Asserts occur in many deployments. See <xref target="use-case-examples"/>
for explicit examples and explanations of why it is often not possible to avoid. </t> for explicit examples and explanations of why it is often not possible to avoid. </t>
<t>PIM assert state depends mainly on the network topology. <t>PIM Assert state depends mainly on the network topology.
As long as there is a layer 2 network with more than 2 PIM routers, 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 there may be multiple upstream routers, which can cause duplicate
multicast traffic to be forwarded and assert process to occur.</t> multicast traffic to be forwarded and assert processing to occur.</t>
<t>As the multicast services become widely deployed, the <t>As the multicast services become widely deployed, the
number of multicast entries increases, and a large number of assert number of multicast entries increases, and a large number of Assert
messages may be sent in a very short period when multicast data messages may be sent in a very short period when multicast data
packets trigger PIM assert processing in the shared LAN networks. packets trigger PIM assert processing in the shared LAN networks.
The PIM routers need to process a large number of PIM assert small 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 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 large. The assert packet may not be processed in time or even
discarded, thus extending the time of traffic duplication in the discarded, thus extending the time of traffic duplication in the
network.</t> network.</t>
<t>The PIM Assert mechanism can only be avoided by designing the network
<t>The PIM Assert mechanism can only be avoided by designing the network to be without transit subnets with multiple upstream routers. For example,
to be without transit subnets with multiple upstream routers. For an L2 ring between routers can sometimes be reconfigured to be a ring of
example, an L2 ring between routers can sometimes be reconfigured to be a ring point-to-point subnets connected by the routers. However, these Layer 2
of point-to-point subnets connected by the routers. These L2/L3 topology (L2) and Layer 3 (L3) topology changes are undesirable when they are only
changes are undesirable though, when they are only done to enable IP multicast done to enable IP multicast with PIM because they increase the cost of
with PIM because they increase the cost of introducing IP multicast with PIM.</t introducing IP multicast with PIM.</t>
> <t>These designs are also not feasible when specific L2 technologies are
needed. For example, various L2 technologies for rings provide sub-50
<t>These designs are also not feasible when specific L2 technologies are needed. msec failover mechanisms, something not possible equally with a ring
For example various L2 technologies for rings provide sub 50 msec failover composed from L3 subnets. Likewise, IEEE Time-Sensitive Networking
mechanisms, something not possible equally with an L3 subnet based ring. mechanisms would require an L2 topology that cannot simply be replaced by
Likewise, IEEE Time Sensitive Networking mechanisms would require an an L3 topology. L2 sub-topologies can also significantly reduce the cost
L2 topology that can not simply be replaced by an L3 topology. of deployment.</t>
L2 sub-topologies can also significantly reduce the cost of deployment.</t> </section>
<section anchor="specification">
</section> <name>Specification</name>
<section anchor="specification"><name>Specification</name> <t>This document defines three elements in support of PIM assert packing:<
/t>
<t>This document defines three elements in support of PIM assert packing:</t> <ol spacing="normal" type="1">
<li>The PIM Packed Assert Capability Hello Option</li>
<t><list style="numbers"> <li>The encoding of PackedAssert messages</li>
<t>The PIM Assert Packing Hello Option.</t> <li>How to send and receive PackedAssert messages</li>
<t>The encoding of PackedAssert messages.</t> </ol>
<t>How to send and receive PackedAssert messages.</t> <section anchor="pim-assert-packing-hello-option">
</list></t> <name>PIM Packed Assert Capability Hello Option</name>
<t>The PIM Packed Assert Capability Hello Option (<xref target="assert-p
<section anchor="pim-assert-packing-hello-option"><name>PIM Assert Packing Hello acking-option"/>) is used to announce support
Option</name>
<t>The PIM Assert Packing Hello Option (<xref target="assert-packing-option"/>)
is used to announce support
for the assert packing mechanisms specified in this document. for the assert packing mechanisms specified in this document.
PackedAssert messages (<xref target="assert-packing-formats"/>) PackedAssert messages (<xref target="assert-packing-formats"/>)
MUST NOT be used unless all PIM routers in the same subnet announce this option. <bcp14>MUST NOT</bcp14> be used unless all PIM routers in the same subnet announ
</t> ce this option.</t>
</section>
</section> <section anchor="assert-packing-formats">
<section anchor="assert-packing-formats"><name>Assert Packing Message Formats</n <name>Assert Packing Message Formats</name>
ame> <t>The PIM Assert message, as defined in <xref target="RFC7761"
sectionFormat="of" section="4.9.6"/>, describes the parameters of a
<t>The PIM Assert message, as defined in Section 4.9.6 of <xref target="RFC7761" (*,G) or (S,G) assert using the following information elements:
/>, Rendezvous Point Tree flag (R), Source Address, Group Address, Metric,
describes the parameters of a (*,G) or (S,G) assert through the and Metric Preference. This document calls this information an "assert
following information elements: Rendezvous Point Tree flag (R), Source Address, record".</t>
Group <t>This document introduces two new PIM Assert message encodings
Address, Metric and Metric Preference. This document calls this through the allocation and use of two flags in the PIM Assert message
information an assert record.</t> header <xref target="RFC9436"/>: the Packed (P) and the Aggregated (A)
flags.</t>
<t>Assert packing introduces two new PIM Assert message encodings <t>If P=0, the message is a (non-packed) PIM Assert
through the allocation and use of two flags in the PIM Assert message as specified in <xref target="RFC7761"/>. See <xref
message header <xref target="I-D.ietf-pim-rfc8736bis"/>, the Packed (P) and the target="rfc7761-assert-message"/>. In this case, the A flag
Aggregated (A) <bcp14>MUST</bcp14> be set to 0 and <bcp14>MUST</bcp14> be ignored on
flags.</t> receipt.</t>
<t>If P=1, then the message is called a "PackedAssert
<t>If the (P)acked flag is 0, the message is a (non-packed) PIM Assert message message", and the type and hence encoding format of the payload are
as specified in <xref target="RFC7761"/>. See <xref target="rfc7761-assert-messa determined by the A flag.</t>
ge"/>. In this case, <t>If A=0, then the message body is a sequence of assert records. This
the (A) flag MUST be set to 0, and MUST be ignored on receipt.</t> is called a "Simple PackedAssert message". See <xref
target="simple-packedassert-message"/>.</t>
<t>If the (P) flag is 1, then the message is <t>If A=1, then the message body is a sequence of aggregated assert
called a PackedAssert message and the type and hence records. This is called an "Aggregated PackedAssert message". See <xref
encoding format of the payload is determined by the (A) flag.</t> target="aggregated-packedassert-message"/>.</t>
<t>Two aggregated assert record types are specified.</t>
<t>If A=0, then the message body is a sequence of assert records. This is called <t>The "Source Aggregated Assert Record" (see <xref
a "Simple PackedAssert" message. See <xref target="simple-packedassert-message" target="s-assert-record"/>) encodes one (common) Source Address,
/>.</t> Metric, and Metric Preference as well as a list of one or more Group
Addresses. Source Aggregated Assert Records provide a more compact
<t>If A=1, then the message body is a sequence of aggregated assert records. Thi encoding than the Simple PackedAssert message format when multiple
s is called an "Aggregated PackedAssert". See <xref target="aggregated-packedass (S,G) flows share the same source S. A single Source Aggregated
ert-message"/>.</t> Assert Record with n Group Addresses represents the information of
assert records for (S,G1)...(S,Gn).</t>
<t>Two aggregated assert record types are specified.</t> <t>The "RP Aggregated Assert Record" (see <xref
target="rp-assert-record"/>) encodes one common Metric and Metric
<t>The "Source Aggregated Assert Record", see <xref target="s-assert-record"/>, Preference as well as a list of "Group Records", each of which encodes
encodes one (common) Source Address, Metric and Metric Preference as well as a l a Group Address and a list of zero or more Source Addresses with a
ist count. This is called an "RP Aggregated Assert Record", because with
of one or more Group Addresses. Source Aggregated Assert Records provide standard RPF according to <xref target="RFC7761"/>, all the Group
a more compact encoding than the Simple PackedAssert message format when multipl Addresses that use the same RP will have the same Metric and Metric
e (S,G) flows share the same source S. Preference.</t>
A single Source Aggregated Assert Record with n Group Addresses represents the i <t>RP Aggregation Assert Records provide a more compact encoding than
nformation of the Simple PackedAssert message format for (*,G) flows. The Source
assert records for (S,G1)...(S,Gn).</t> Address is optionally used in the assert procedures in <xref
target="RFC7761"/> to indicate the source(s) that triggered the
<t>The "RP Aggregated Assert Record", see <xref target="rp-assert-record"/>, assert; otherwise, the Source Address is set to 0 in the assert
encodes one common Metric and Metric Preference as record.</t>
well as a list of "Group Records", each of which encodes a Group Address <t>Both Source Aggregated Assert Records and RP Aggregated Assert
and a list of zero or more Source Addresses with a count. This is called an Records also include the R flag, which maintains its semantics from
"RP Aggregated Assert Record", because with standard RPF according to (<xref tar <xref target="RFC7761"/> but also distinguishes the encodings. Source
get="RFC7761"/>), Aggregated Assert Records have R=0, as (S,G) assert records do in
all the Group Addresses that use the same RP will have the same Metric and Metri <xref target="RFC7761"/>. RP Aggregated Assert Records have R=1, as
c Preference.</t> (*,G) assert records do in <xref target="RFC7761"/>.</t>
</section>
<t>RP Aggregation Records provide a more compact encoding than the Simple Packed <section anchor="packedassert-mechanism">
Assert message format <name>PackedAssert Mechanism</name>
for (*,G) flows. The Source Address is optionally used by <xref target="RFC7761 <t>PackedAsserts do not change the PIM Assert state machine
"/> assert procedures specification <xref target="RFC7761"/>. Instead, sending and
to indicate the source(s) that triggered the assert, otherwise the Source Addres receiving of PackedAssert messages, as specified in the following
s is set to 0 in the subsections, are logically new packetization options for assert records
assert record.</t> in addition to the (non-packed) Assert message <xref
target="RFC7761"/>. There is no change to the assert record
<t>Both Source Aggregated Assert Records and RP Aggregated Assert Records also i information elements transmitted or their semantics. They are just
nclude the transmitted in fewer but larger packets, and a fewer total number of
R flag which maintains its semantic from <xref target="RFC7761"/> but also disti bytes is used to encode the information elements. As a result, PIM
nguishes routers should be able to send and receive assert records faster
the encodings. Source Aggregated Assert Records have R=0, as (S,G) assert record and/or with less processing overhead.</t>
s do in <xref target="RFC7761"/>. <section anchor="sending-packedassert-messages">
RP Aggregated Assert Records have R=1, as (*,G) assert records do in <xref targe <name>Sending PackedAssert Messages</name>
t="RFC7761"/>.</t> <t>When using assert packing, the regular Assert message encoding
<xref target="RFC7761"/> with A=0 and P=0 is still allowed to be
</section> sent. Routers are free to choose which PackedAssert message format
<section anchor="packedassert-mechanism"><name>PackedAssert Mechanism</name> they send -- simple (<xref target="simple-packedassert-message"/>)
and/or aggregated (<xref
<t>PackedAsserts do not change the <xref target="RFC7761"/> PIM assert state mac target="aggregated-packedassert-message"/>).</t>
hine specification. Instead, <ul spacing="normal">
sending and receiving of PackedAssert messages as specified in the following sub <li>When any PIM routers on the LAN have not signaled support for
sections are logically assert packing, implementations <bcp14>MUST</bcp14> only send
new packetization options for assert records in addition to the (not packed) <xr Asserts and <bcp14>MUST NOT</bcp14> send PackedAsserts under any
ef target="RFC7761"/> Assert Message. condition.</li>
There is no change to the assert record information elements transmitted or <li>The protocol or system conditions for which an implementation
their semantic. They are just transmitted in fewer but larger packets and fewer sends PackedAsserts instead of Asserts are out of scope
total number of bytes used to encode the information elements. In result, PIM ro for this specification. Protocol conditions include protocol
uters should be able to send/receive assert records faster and/or with less proc triggers such as data-triggered asserts or Assert Timer (AT)
essing overhead.</t> expiry-triggered asserts, and system conditions include high or
low load or control plane packet reception rates.</li>
<section anchor="sending-packedassert-messages"><name>Sending PackedAssert messa <li>Implementations are expected to specify in documentation
ges</name> and/or management interfaces (such as a YANG data model) which
PackedAssert message formats they can send and under which
<t>When using assert packing, the regular <xref target="RFC7761"/> Assert messag conditions they will send them.</li>
e encoding with A=0 and P=0 is <li>Implementations <bcp14>SHOULD</bcp14> be able to indicate to
still allowed to be sent. Routers are free to choose which PackedAssert message the operator (such as through a YANG data model) how many Assert
format they send and PackedAssert messages were sent/received and how many assert
- simple (<xref target="simple-packedassert-message"/>) and/or aggregated (<xref records were sent/received.</li>
target="aggregated-packedassert-message"/>).</t> <li>A configuration option <bcp14>SHOULD</bcp14> be available to
disable PackedAssert operations. PIM-SM implementations <xref
<t><list style="symbols"> target="RFC7761"/> that introduce support for assert packing from day
<t>When any PIM routers on the LAN have not signaled support for Assert Packin one <bcp14>MAY</bcp14> omit this configuration option.</li>
g, </ul>
implementations MUST send only Asserts and MUST NOT send PackedAsserts under <t>When a PIM router has an assert record ready to send according to
any condition.</t> <xref target="RFC7761"/>, it calls one of the following
<t>Implementations SHOULD support sending of PackedAssert messages. functions:</t>
It is out of scope of this specification for which conditions, such as data-trig
gered asserts or
Assert Timer (AT) expiry-triggered asserts, or under which conditions (such as h
igh load) an implementation
will send PackedAsserts instead of Asserts.</t>
<t>Implementations are expected to specify in documentation and/or management
interfaces (such as a YANG model),
which PackedAssert message formats they can send and under which conditions they
will send them.</t>
<t>Implementations SHOULD be able to indicate to the operator (such as through
a YANG model)
how many Assert and PackedAssert messages were sent/received and how many assert
records were sent/received.</t>
<t>A configuration option SHOULD be available to disable PackedAssert operatio
ns.
Implementations that introduce support for assert packing from day one of
their <xref target="RFC7761"/> implementation MAY omit this configuration option
.</t>
</list></t>
<t>When a PIM router has an assert record ready to send according to
<xref target="RFC7761"/>, it calls one of the following functions:</t>
<t><list style="symbols">
<t>send Assert(S,G) / send Assert(*,G) (<xref target="RFC7761"/>, Section 4.2)
,</t>
<t>Send Assert(S,G) / SendAssertCancel(S,G) (<xref target="RFC7761"/>, Section
4.6.1),</t>
<t>Send Assert(*,G) / Send AssertCancel(*,G) (<xref target="RFC7761"/>, Sectio
n 4.6.2)</t>
<t>send Assert(S,G) (<xref target="RFC7761"/>, Section 4.8.2).</t>
</list></t>
<t>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 addit
ional assert records.</t>
<t>PIM MUST then create PackedAssert messages from the remembered assert records
and schedule them for sending according to the considerations of the following
subsections.</t>
<section anchor="handling-of-reception-triggered-assert-records"><name>Handling
of reception-triggered assert records.</name>
<t>Avoiding additional delay because of assert packing compared to immediate sch
eduling of
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.</t>
<t>To avoid additional delay in this case, the router should employ appropriate
assert packing and scheduling mechanisms, as explained here.</t>
<t>Asserts/PackedAsserts created from reception-triggered assert records should
be scheduled
for serialization with a higher priority than those created from other reasons.
They
should also bypass other PIM messages that can create significant bursts, such a
s PIM join/prune messages.</t>
<t>When there is no reception-triggered Assert/PackedAssert messages currently b
eing 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.</
t>
<t>If there are one or more reception-triggered Assert/PackedAssert messages alr
eady serializing
and/or scheduled to be serialized on the outgoing interface, then the router can
use the time
until the last of those messages will have finished serializing for PIM processi
ng of further
conditions that may result in additional reception-triggered assert records as w
ell as packing of these assert
records without introducing additional delay.</t>
</section>
<section anchor="handling-of-timer-expiry-triggered-assert-records"><name>Handli
ng of timer expiry-triggered assert records.</name>
<t>Asserts triggered by expiry of the AT on an assert winner are not time-critic
al because
they can be scheduled in advance and because the Assert_Override_Interval parame
ter of <xref target="RFC7761"/> already
creates a 3 second window in which such assert records can be sent, received, an
d processed before
an assert loser's state would expire and duplicate IP multicast packets could oc
cur.</t>
<t>An example mechanism to allow packing of AT expiry-triggered assert records o
n assert winners is
to round the AT to an appropriate granularity such as 100 msec. This will cause
AT for multiple
(S,G) and/or (*,G) states to expire at the same time, thus allowing them to be e
asily packed
without changes to the assert state machinery.</t>
<t>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 pack
ed for example
with the same considerations as AT expiry-triggered assert records.</t>
</section>
<section anchor="beneficial"><name>Beneficial delay in sending PackedAssert mess
ages</name>
<t>Delay in sending PackedAsserts beyond what was discussed in prior subsections
can still be beneficial when
it causes the overall amount of (possible) duplicate IP multicast packets to dec
rease in a condition with
large number of (S,G) and/or (*,G), compared to the situation in which an implem
entation only
sends Assert messages.</t>
<t>This delay can simply be used in implementations because it can not support t
he (more advanced)
mechanisms described above, and this longer delay can be achieved by some simple
r mechanism
(such as only periodic generation of PackedAsserts) and still achieves an overal
l reduction
in duplicate IP multicast packets compared to sending only Asserts.</t>
</section>
<section anchor="handling-assertpackedassert-message-loss"><name>Handling Assert
/PackedAssert message loss</name>
<t>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) PackedAs
sert impacts
duplicates for all flows packed into the PackedAssert and may result in the need
for re-sending more than one Assert/PackedAssert, because of the possible inabil
ity to pack the assert records in this condition. Therefore, routers SHOULD sup
port mechanisms allowing for PackedAsserts and Asserts to
be sent with an appropriate Differentiated Services Code Point (DSCP, <xref targ
et="RFC2475"/>), such as Expedited Forwarding (EF), to minimize their loss, esp
ecially
when duplicate IP multicast packets could cause congestion and loss.</t>
<t>Routers MAY support a configurable option for sending PackedAssert messages t
wice in short order
(such as 50 msec apart), to overcome possible loss, but only when the following
two conditions
are met.</t>
<t><list style="numbers">
<t>The total size of the two PackedAsserts is less than the total size of equi
valent Assert messages,</t>
<t>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/PackedAss
erts replies.
This condition is true for example when sending an assert record while becoming
or being Assert Winner (Action A1/A3 in <xref target="RFC7761"/>).</t>
</list></t>
</section>
<section anchor="optimal-degree-of-assert-record-packing"><name>Optimal degree o
f assert record packing</name>
<t>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.</t>
<t>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.</t>
</section> <ul spacing="normal">
</section> <li>send Assert(S,G) / send Assert(*,G) (<xref target="RFC7761"
<section anchor="receiving-packedassert-messages"><name>Receiving PackedAssert m sectionFormat="comma" section="4.2"/>)</li>
essages</name> <li>send Assert(S,G) / send AssertCancel(S,G) (<xref
target="RFC7761" sectionFormat="comma" section="4.6.1"/>)</li>
<li>send Assert(*,G) / send AssertCancel(*,G) (<xref
target="RFC7761" sectionFormat="comma" section="4.6.2"/>)</li>
<li>send Assert(S,G) (<xref target="RFC7761" sectionFormat="comma"
section="4.8.2"/>)</li>
</ul>
<t>If sending of PackedAsserts is possible on the network, instead of
sending an Assert message with an assert record, any of these calls
<bcp14>MAY</bcp14> 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.</t>
<t>PIM <bcp14>MUST</bcp14> then create PackedAssert messages from
the remembered assert records and schedule them for sending
according to the considerations in the following subsections.</t>
<section anchor="handling-of-reception-triggered-assert-records">
<name>Handling of Reception-Triggered Assert Records</name>
<t>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
<bcp14>SHOULD</bcp14> 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.</t>
<t>To avoid additional delay in this case, the router should
employ appropriate assert packing and scheduling mechanisms, as
explained here.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="handling-of-timer-expiry-triggered-assert-records">
<name>Handling of Timer Expiry-Triggered Assert Records</name>
<t>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 <xref
target="RFC7761"/> already creates a 3-second window in which such
assert records can be sent, received, and processed before an
assert loser's state expires and duplicate IP multicast
packets could occur.</t>
<t>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 fo
r
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.</t>
<t>Upon reception of a PackedAssert message, the PIM router logically <t>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.</t>
</section>
<section anchor="beneficial">
<name>Beneficial Delay in Sending PackedAssert Messages</name>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="handling-assertpackedassert-message-loss">
<name>Handling Assert/PackedAssert Message Loss</name>
<t>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 <bcp14>SHOULD</bcp14> support mechanisms
that allow PackedAsserts and Asserts to be sent with an
appropriate Differentiated Services Code Point (DSCP) <xref
target="RFC2475"/> such as Expedited Forwarding (EF) to
minimize their loss, especially when duplicate IP multicast
packets could cause congestion and loss.</t>
<t>Routers <bcp14>MAY</bcp14> 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.</t>
<ol spacing="normal" type="1">
<li>The total size of the two PackedAsserts is less than the
total size of equivalent Assert messages.</li>
<li>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 <xref target="RFC7761"/>).</li>
</ol>
</section>
<section anchor="optimal-degree-of-assert-record-packing">
<name>Optimal Degree of Assert Record Packing</name>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="receiving-packedassert-messages">
<name>Receiving PackedAssert Messages</name>
<t>Upon reception of a PackedAssert message, the PIM router logically
converts its payload into a sequence of assert records that are then processed 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 <xref target="RFC7761"/>.</t> as if an equivalent sequence of Assert messages were received according to <xref target="RFC7761"/>.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="packet-formats">
<section anchor="packet-formats"><name>Packet Formats</name> <name>Packet Formats</name>
<t>This section describes the format of new PIM extensions introduced by
<t>This section describes the format of new PIM extensions introduced by
this document.</t> this document.</t>
<section anchor="assert-packing-option">
<section anchor="assert-packing-option"><name>PIM Assert Packing Hello Option</n <name>PIM Packed Assert Capability Hello Option</name>
ame> <t>The PIM Packed Assert Capability Hello Option is a new option for PIM
Hello
<figure title="PIM Assert Packing Hello Option" anchor="FIG-HELLO-OPTION"><artwo messages according to <xref target="RFC7761" sectionFormat="of"
rk><![CDATA[ section="4.9.2"/>.</t>
<figure
anchor="FIG-HELLO-OPTION"> <name>PIM Packed Assert Capability Hello
Option</name>
<artwork><![CDATA[
0 1 2 3 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 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 | | OptionType = 40 | OptionLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t>The PIM Assert Packing Hello Option is a new option for PIM Hello Messages ac
cording to Section 4.9.2 of <xref target="RFC7761"/>.</t>
<t><list style="symbols">
<t>OptionType TBD:
PIM Packed Assert Capability Hello Option</t>
</list></t>
<t>Including the PIM OptionType TBD indicates support for the ability to
receive and process all the PackedAssert encodings defined in this document.</t>
</section>
<section anchor="rfc7761-assert-message"><name>Assert Message Format</name>
<figure title="Assert Message Format" anchor="FIG-MESSAGE-ASSERT"><artwork><![CD <dl spacing="normal" newline="true">
ATA[ <dt>OptionType 40 (Packed Assert Capability):</dt>
<dd>Indicates support for the ability to receive and process all the
PackedAssert encodings defined in this document.</dd>
<dt>OptionLength 0:</dt>
<dd>The Packet Assert Capability has no OptionValue.</dd>
</dl>
</section>
<section anchor="rfc7761-assert-message">
<name>Assert Message Format</name>
<t><xref target="FIG-MESSAGE-ASSERT"/> shows a PIM Assert message as
specified in <xref target="RFC7761" sectionFormat="of"
section="4.9.6"/>. The Encoded-Group and Encoded-Unicast address
formats are specified in <xref target="RFC7761" sectionFormat="of"
section="4.9.1"/> for IPv4 and IPv6.</t>
<figure anchor="FIG-MESSAGE-ASSERT">
<name>Assert Message Format</name>
<artwork><![CDATA[
0 1 2 3 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 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 | |PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) | | Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference | |R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><xref target="FIG-MESSAGE-ASSERT"/> shows a PIM Assert message as specified i
n Section 4.9.6 of
<xref target="RFC7761"/>. The Encoded-Group and Encoded-Unicast address formats
are specified in Section 4.9.1 of
<xref target="RFC7761"/> for IP and IPv6.</t>
<t>This common header is showing the "7 6 5 4 3 2" Flag Bits as defined
in Section 4 of <xref target="I-D.ietf-pim-rfc8736bis"/> and the location of the
P and A flags,
as described in <xref target="IANA"/>.  As specified in <xref target="assert-pa
cking-formats"/>, both
flags in a (non-packed) PIM Assert message are required to be set to 0.</t>
</section> <t>This common header shows the "7 6 5 4 3 2" flag bits (as defined in
<section anchor="simple-packedassert-message"><name>Simple PackedAssert Message <xref target="RFC9436" sectionFormat="of" section="4"/>) and the
Format</name> location of the P and A flags (as described in <xref target="IANA"/>).
As specified in <xref target="assert-packing-formats"/>, both flags in
a (non-packed) PIM Assert message are required to be set to 0.</t>
</section>
<figure title="Simple PackedAssert Message Format" anchor="FIG-MESSAGE-SIMPLE">< <section anchor="simple-packedassert-message">
artwork><![CDATA[ <name>Simple PackedAssert Message Format</name>
<figure anchor="FIG-MESSAGE-SIMPLE">
<name>Simple PackedAssert Message Format</name>
<artwork><![CDATA[
0 1 2 3 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 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 | |PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero | Reserved | | Zero | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Assert Record [1] . . Assert Record [1] .
skipping to change at line 481 skipping to change at line 528
| . | | . |
. . . . . .
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Assert Record [M] . . Assert Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal" newline="true">
<t>PIM Version, Type, Checksum: <vspace blankLines='1'/> <dt>PIM Version, Type, Checksum:</dt>
As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t> <dd>As specified in <xref target="RFC7761" sectionFormat="of"
<t>"7 6 5 4 3 2": IANA registry handled bits according to Section 4 of <xref t section="4.9.6"/>.</dd>
arget="I-D.ietf-pim-rfc8736bis"/>.</t> <dt>"7 6 5 4 3 2":</dt>
<t>Zero: <dd>Flag bits per <xref
Set to zero on transmission. Serves to make non assert packing capable PIM ro target="RFC9436" sectionFormat="of" section="4"/>.</dd>
uters fail in parsing the message instead of possible mis-parsing if this field <dt>P:</dt>
was used.</t> <dd>Packed flag. <bcp14>MUST</bcp14> be 1.</dd>
<t>Reserved: <dt>A:</dt>
Set to zero on transmission. Ignored upon receipt.</t> <dd>Aggregated flag. <bcp14>MUST</bcp14> be 0.</dd>
<t>P: packed flag. MUST be 1.</t> <dt>Zero:</dt>
<t>A: aggregated flag. MUST be 0.</t> <dd>Set to zero on transmission. Serves to make PIM routers that are
<t>M: The number of Assert Records in the message. Derived from the length of not capable of assert packing to fail in parsing the message instead
the packet carrying the message.</t> possible mis-parsing of the message as an Assert message <xref
<t>Assert Record: formatted according to {FIG-MESSAGE-SIMPLE}}, which is the s target="RFC7761" format="default"/> if this field was not
ame zero-filled.</dd>
as the PIM assert message body as specified in Section 4.9.6 of <xref target="RF <dt>Reserved:</dt>
C7761"/>. <dd>Set to zero on transmission. Ignored upon receipt.</dd>
The number M of Assert Records is determined from the packet size.</t> <dt>M:</dt>
</list></t> <dd>The number of Assert Records in the message. Derived from the
length of the packet carrying the message.</dd>
<t>The format of each Assert Record is the same as the PIM assert message body a <dt>Assert Record:</dt>
s specified in Section 4.9.6 of <xref target="RFC7761"/>.</t> <dd>Formatted according to <xref target="FIG-MESSAGE-SIMPLE"/>,
which is the same as the PIM Assert message body as specified in
<figure title="Assert Record" anchor="FIG-ASSERT-RECORD-FORMAT"><artwork><![CDAT <xref target="RFC7761" sectionFormat="of" section="4.9.6"/>.</dd>
A[ </dl>
<t>The format of each Assert Record is the same as the PIM Assert
message body as specified in <xref target="RFC7761" sectionFormat="of"
section="4.9.6"/>.</t>
<figure anchor="FIG-ASSERT-RECORD-FORMAT">
<name>Assert Record</name>
<artwork><![CDATA[
0 1 2 3 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 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) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) | | Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference | |R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="aggregated-packedassert-message"><name>Aggregated PackedAssert <section anchor="aggregated-packedassert-message">
Message Format</name> <name>Aggregated PackedAssert Message Format</name>
<figure anchor="FIG-PACKET-FORMAT-SG">
<figure title="Aggregated PackedAssert Message Format" anchor="FIG-PACKET-FORMAT <name>Aggregated PackedAssert Message Format</name>
-SG"><artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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 | |PIM Ver| Type |7 6 5 4 3 2|A|P| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero | Reserved | | Zero | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Aggregated Assert Record [1] . . Aggregated Assert Record [1] .
skipping to change at line 548 skipping to change at line 611
| . | | . |
. . . . . .
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Aggregated Assert Record [M] . . Aggregated Assert Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal" newline="true">
<t>PIM Version, Type, Reserved, Checksum: <vspace blankLines='1'/> <dt>PIM Version, Type, Reserved, Checksum:</dt>
As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t> <dd>As specified in <xref target="RFC7761" sectionFormat="of"
<t>"7 6 5 4 3 2": IANA registry handled bits according to Section 4 of <xref t section="4.9.6"/>.</dd>
arget="I-D.ietf-pim-rfc8736bis"/>.</t> <dt>"7 6 5 4 3 2":</dt>
<t>P: packed flag. MUST be 1.</t> <dd>Flag bits per <xref
<t>A: aggregated flag. MUST be 1.</t> target="RFC9436" sectionFormat="of" section="4"/>.</dd>
<t>Zero: <dt>P:</dt>
Set to zero on transmission. Serves to make non assert packing capable PIM ro <dd>Packed flag. <bcp14>MUST</bcp14> be 1.</dd>
uters fail in parsing the message instead of possible mis-parsing if this field <dt>A:</dt>
was used.</t> <dd>Aggregated flag. <bcp14>MUST</bcp14> be 1.</dd>
<t>Aggregated Assert Record: formatted according to <xref target="FIG-PACKET-F <dt>Zero:</dt>
ORMAT-SG"/>. <dd>Set to zero on transmission. Serves to make PIM routers that are
The number M of Aggregated Assert Records is determined from the packet size.</t not capable of assert packing to fail in parsing the message instead
> possible mis-parsing of the message as an Assert message <xref
</list></t> target="RFC7761" format="default"/> if this field was not
zero-filled.</dd>
<section anchor="s-assert-record"><name>Source Aggregated Assert Record</name> <dt>Aggregated Assert Record:</dt>
<dd>Formatted according to <xref target="FIG-PACKET-FORMAT-SG"/>.
<figure title="Source Aggregated Assert Record" anchor="FIG-RECORD-FORMAT-SG"><a The number M of Aggregated Assert Records is determined from the
rtwork><![CDATA[ packet size.</dd>
</dl>
<section anchor="s-assert-record">
<name>Source Aggregated Assert Record</name>
<figure anchor="FIG-RECORD-FORMAT-SG">
<name>Source Aggregated Assert Record</name>
<artwork><![CDATA[
0 1 2 3 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 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 | |R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) | | Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Groups (N) | Reserved | | Number of Groups (N) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) | | Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 2 (Encoded-Group format) | | Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address N (Encoded-Group format) | | Group Address N (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols">
<t>Reserved:
Set to zero on transmission. Ignored upon receipt.</t>
<t>R: MUST be 0. <vspace blankLines='1'/>
R indicates both that the encoding format of the record is that of a Source Aggr
egated Assert Record,
but also that all assert records represented by the Source Aggregated Assert R
ecord have R=0 and are therefore
(S,G) assert records according to the definition of R in <xref target="RFC7761
"/>, Section 4.9.6.</t>
<t>Source Address, Metric Preference, Metric: <vspace blankLines='1'/>
As specified in Section 4.9.6 of <xref target="RFC7761"/>. Source Address MUST
NOT be zero.</t>
<t>Number of Groups: <vspace blankLines='1'/>
The number of Group Address fields.</t>
<t>Group Address: <vspace blankLines='1'/>
As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t>
</list></t>
</section>
<section anchor="rp-assert-record"><name>RP Aggregated Assert Record</name>
<t>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 <xref target="RFC7761"/> assert records.</t
>
<figure title="RP Aggregated Assert Record" anchor="FIG-RECORD-FORMAT-RP"><artwo <dl spacing="normal" newline="true">
rk><![CDATA[ <dt>R:</dt>
<dd><t><bcp14>MUST</bcp14> be 0.</t>
<t>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 <xref target="RFC7761" sectionFormat="comma"
section="4.9.6"/>.</t>
</dd>
<dt>Metric Preference, Metric, Source Address:</dt>
<dd>As specified in <xref target="RFC7761" sectionFormat="of"
section="4.9.6"/>. Source Address <bcp14>MUST NOT</bcp14> be
zero.</dd>
<dt>Number of Groups:</dt>
<dd>The number of Group Address fields.</dd>
<dt>Reserved:</dt>
<dd> Set to zero on transmission. Ignored upon receipt.</dd>
<dt>Group Address:</dt>
<dd>As specified in <xref target="RFC7761" sectionFormat="of"
section="4.9.6"/>.</dd>
</dl>
</section>
<section anchor="rp-assert-record">
<name>RP Aggregated Assert Record</name>
<t>An RP Aggregation Assert Record aggregates (*,G) assert records
with the same Metric Preference and Metric. Typically, this is the
case for all (*,G) using the same RP, but the encoding is not
limited to only (*,G) using the same RP because the RP address is
not encoded as it is also not present in assert records <xref
target="RFC7761"/>.</t>
<figure anchor="FIG-RECORD-FORMAT-RP">
<name>RP Aggregated Assert Record</name>
<artwork><![CDATA[
0 1 2 3 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 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 | |R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Group Records (K) | Reserved | | Number of Group Records (K) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at line 643 skipping to change at line 728
| . | | . |
. . . . . .
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Group Record [K] . . Group Record [K] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal" newline="true">
<t>R: MUST be 1. <vspace blankLines='1'/> <dt>R:</dt>
R indicates both that the encoding format of the record is that of an RP Aggrega <dd><t><bcp14>MUST</bcp14> be 1.</t>
ted Assert Record, <t>R indicates both that the encoding format of the record is
and that all assert records represented by the RP Aggregated Assert Record hav that of an RP Aggregated Assert Record and that all assert
e R=1 and are therefore records represented by the RP Aggregated Assert Record have R=1
(*,G) assert records according to the definition of R in <xref target="RFC7761 and are therefore (*,G) assert records according to the
"/>, Section 4.9.6.</t> definition of R in <xref target="RFC7761" sectionFormat="comma"
<t>Metric Preference, Metric: <vspace blankLines='1'/> section="4.9.6"/>.</t>
As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t> </dd>
<t>Reserved: <dt>Metric Preference, Metric:</dt>
Set to zero on transmission. Ignored upon receipt.</t> <dd>As specified in <xref target="RFC7761" sectionFormat="of"
<t>Number of Group Records (K): <vspace blankLines='1'/> section="4.9.6"/>.</dd>
The number of packed Group Records. A record consists of a Group <dt>Number of Group Records (K):</dt>
Address and a Source Address list with a number of sources.</t> <dd>The number of packed Group Records. A record consists of a
</list></t> Group Address and a Source Address list with a number of
sources.</dd>
<t>The format of each Group Record is:</t> <dt>Reserved:</dt>
<dd>Set to zero on transmission. Ignored upon receipt.</dd>
<figure title="Group Record" anchor="FIG-GROUP-RECORD"><artwork><![CDATA[ </dl>
<t>The format of each Group Record is:</t>
<figure anchor="FIG-GROUP-RECORD">
<name>Group Record</name>
<artwork><![CDATA[
0 1 2 3 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 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) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sources (P) | Reserved | | Number of Sources (P) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address 1 (Encoded-Unicast format) | | Source Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address 2 (Encoded-Unicast format) | | Source Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address P (Encoded-Unicast format) | | Source Address P (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal" newline="true">
<t>Group Address and Reserved: <vspace blankLines='1'/> <dt>Group Address:</dt>
As specified in Section 4.9.6 of <xref target="RFC7761"/>.</t> <dd>As specified in <xref target="RFC7761" sectionFormat="of"
<t>Reserved: section="4.9.6"/>.</dd>
Set to zero on transmission. Ignored upon receipt.</t> <dt>Reserved:</dt>
<t>Number of Sources (P): <vspace blankLines='1'/> <dd>Set to zero on transmission. Ignored upon receipt.</dd>
The Number of Sources is corresponding to the number of Source Address fields in <dt>Number of Sources (P):</dt>
the Group Record. <dd>The Number of Sources corresponds to the number of Source
If this number is 0, the Group Record indicates one assert record with a Sourc Address fields in the Group Record. If this number is not 0 and
e Address of 0. one of the (*,G) assert records to be encoded has Source Address
If this number is not 0 and one of the (*,G) assert records to be encoded shou 0, then 0 needs to be encoded as one of the Source Address
ld have fields.</dd>
the Source Address 0, then 0 needs to be encoded as one of the Source Address <dt>Reserved:</dt>
fields.</t> <dd> Set to zero on transmission. Ignored upon receipt.</dd>
<t>Source Address: <vspace blankLines='1'/> <dt>Source Address:</dt>
As specified in Section 4.9.6 of <xref target="RFC7761"/>. <dd>As specified in <xref target="RFC7761" sectionFormat="of"
But there can be multiple Source Address fields in the Group Record.</t> section="4.9.6"/>. But there can be multiple Source Address
</list></t> fields in the Group Record.</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA"><name>IANA Considerations</name> <section anchor="IANA">
<name>IANA Considerations</name>
<t>IANA has assigned the following code point value to the "PIM-Hello <t>IANA has updated the "PIM Message Types" registry as follows to
Options" registry for the Packed Assert Capability.</t> include the Packed and Aggregated flag bits for the Assert message
type.</t>
<figure title="IANA PIM-Hello Options" anchor="FIG-IANA"><artwork><![CDATA[
+=======+========+=========================+================+
| Value | Length | Name | Reference |
+=======+========+=========================+================+
| 40 | 0 | Packed Assert Capability| [This Document]|
+=======+========+=========================+================+
]]></artwork></figure>
<t>IANA has assigned the following two Flag Bits for PIM Assert messages
to the "PIM Message Types" registry.</t>
<figure title="IANA PIM Message Types" anchor="FIG-IANA2"><artwork><![CDATA[
+======+========+=================+====================+
| Type | Name | Flag Bits | Reference |
+======+========+=================+====================+
| 5 | Assert | 0: Packed | [This Document] |
| | | 1: Aggregated | [This Document] |
| | | 2-7: Unassigned | [RFC3973][RFC7761] |
+======+========+=================+====================+
]]></artwork></figure>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>The security considerations of <xref target="RFC7761"/> apply to the extensio
ns
defined in this document.</t>
<t>This document packs multiple assert records in a single message. As
described in Section 6.1 of <xref target="RFC7761"/>, a forged Assert message co
uld
cause the legitimate designated forwarder to stop forwarding traffic
to the LAN. The effect may be amplified when using a PackedAssert message.</t>
<t>Like other optional extensions of <xref target="RFC7761"/> that are active
only when all routers indicate support for them, a single misconfigured or malic
ious
router emitting forged PIM Hello messages can inhibit operations of this extensi
on.</t>
<t>Authentication of PIM messages such as explained in <xref target="RFC7761"/>,
Sections 6.2 and 6.3 can
protect against the forged message attacks attacks.</t>
</section>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>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, Shuping Peng for her RtgDir review, John Scudder
for his RTG AD review, Eric Vyncke for his INT AD review,
Eric Kline for his INT AD review, Paul Wouter for his SEC AD review,
Zaheduzzaman Sarker for his TSV AD review, Robert Wilton for his
OPS AD review and Martin Duke for his TSV AD review.</t>
</section>
<section anchor="working-group-considerations"><name>Working Group consideration
s</name>
<t>[RFC-Editor: please remove this section].</t>
<section anchor="open-issues"><name>Open Issues</name>
</section>
<section anchor="changelog"><name>Changelog</name>
<t>This document is hosted starting with -06 on https://github.com/toerless/pim-
assert-packing.</t>
<section anchor="draft-ietf-pim-assert-packing-12"><name>draft-ietf-pim-assert-p
acking-12</name>
<t>Changed text of IANA considerations from request to assigned after IANA has a
ssigned the code points.</t>
<t>Fixed leftover nits from John Scudders review that where not done right in -1
1.</t>
</section>
<section anchor="draft-ietf-pim-assert-packing-11"><name>draft-ietf-pim-assert-p
acking-11</name>
<t>Comprehensive 2 round AD review by John Scudder.</t>
<t>Functional enhancement: add requirement for existing implementation to be abl
e to disable assert packing so that any possible compatibility issues introduced
(which we think will not happen) can be avoided when upgrading to a packedasser
t version of the software. Also to allow performance comparison. No making a req
uirement for day 0 implementations because they may want to save the work of hav
ing a non-packed-assert code path.</t>
<t>Some rewrite to increase readibility, subdivided 3.3.1 into multiple subsecti
ons to better structure it.</t>
<t>3.3.1 improved core requirements - added requirement for counters to show ass
ert/packedassert operations, documentation (e.g.: YANG) for what/how it can send
, config option to disable packedasserts. Refined text: Bulletized cases of asse
rts in rfc7761,</t>
<t>Subdivided 3.3.1 into multiple subsections for readability improved text base
d on review. Added reference for DSCP.</t>
<t>3.3.1.5 Added explicit example of improvement because of packet size/throughp
ut limits of router.</t>
<t>Added notion of attacks by wrong hellos to security section.</t>
<t>Eric Vyncke review:</t>
<t>Appendix A: Better elaboration of L2 ring vs L3 ring benefits. Nits.</t>
<t>Paul Wouter review:</t>
<t>Changed explanation of number "M" of records to be inline with formatting of
other data (sections 4.3 and 4.4).</t>
<t>Some nits.</t>
</section>
<section anchor="draft-ietf-pim-assert-packing-10"><name>draft-ietf-pim-assert-p
acking-10</name>
<t>Fixed up Reserved field of PackedAsserts to get back to 32 bit alignment
of the following fields (was down to 16 bits). Sorry, had a misinterpretation
reading rfc7761, though there ws something that had only made it 16 bit
aligned. Anyhow. Only this one change, 8 -&gt; 24 bit for this field.</t>
</section>
<section anchor="draft-ietf-pim-assert-packing-09"><name>draft-ietf-pim-assert-p
acking-09</name>
<t>For details of review discussion/replies, see review reply emails in (https:/
/github.com/toerless/pim-assert-packing/tree/main/emails)j</t>
<t>review Alvaro Retana:
Reintroduced ref to PIM-DM, fixed typos, downgraded MAY-&gt;may for "sufficient"
.</t>
<t>IANA Expert Review / Stig Venaas:</t>
<t>Removed Count field from message headers as it complicates parsing and is unn
ecessary. Added "Zero" field to make packed asserts received by a non-packed-ass
ert-capable-router guaranteed to fail ("Reserved" address family type).</t>
<t>Changed from RFC8736 to RFC8736bis so that we can use the word "Unassigned" i
n the IANA table.</t>
<t>Review Shuping Peng</t>
<t>Changed explanation of how assert packing works from "layer" to "alternative
to
packetization via PIM Assert Message.
Fixed various typos, expanded term etc..</t>
<t>Review Robert Sparks:</t>
<t>Moved Intro explanations of how one could avoid asserts (but how its problema
tic) to appendix.
Applied textual nits found. Removed quotes around term "sufficient" for easier r
eadbility.</t>
<t>Review Tommy Paul:</t>
<t>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.</t>
</section>
<section anchor="draft-ietf-pim-assert-packing-08"><name>draft-ietf-pim-assert-p
acking-08</name>
<t>Included changes from review of Alvaro Retana (https://mailarchive.ietf.org/a
rch/msg/pim/GsKq9bB2a6yDdM9DvAUGCWthdEI)</t>
<t>Please see the following emails discussing the changes:</t>
<t>https://raw.githubusercontent.com/toerless/pim-assert-packing/main/emails/07-
alvaro-review-reply.txt</t>
</section>
<section anchor="draft-ietf-pim-assert-packing-07"><name>draft-ietf-pim-assert-p
acking-07</name>
<t>Included changes from review of Alvaro Retana (https://mailarchive.ietf.org/a
rch/msg/pim/Cp4o5glUFge2b84X9CQMwCWZjAk/)</t>
<t>Please see the following emails discussing the changes:</t>
<t>https://raw.githubusercontent.com/toerless/pim-assert-packing/main/emails/05-
alvaro-review-reply.txt</t>
<t>https://raw.githubusercontent.com/toerless/pim-assert-packing/main/emails/07-
pim-wg-announce.txt</t>
</section> <table anchor="FIG-IANA" align="left">
<section anchor="draft-ietf-pim-assert-packing-06"><name>draft-ietf-pim-assert-p <name>PIM-Hello Options</name>
acking-06</name> <thead>
<tr>
<th>Value</th>
<th>Length</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">40</td>
<td align="center">0</td>
<td>Packed Assert Capability</td>
<td>RFC 9466</td>
</tr>
</tbody>
</table>
<t>This version was converted from txt format into markdown for better editing l <t>IANA has assigned the following two flag bits for PIM Assert messages
ater, but is otherwise text identical to -05. It was posted to DataTracker to ma in the "PIM Message Types" registry.</t>
ke diffs easier.</t>
<t>Functional changes:</t> <table anchor="FIG-IANA2" align="left">
<name>PIM Message Types</name>
<thead>
<tr>
<th>Type</th>
<th>Name</th>
<th>Flag Bits</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center" rowspan="3">5</td>
<td rowspan="3">Assert</td>
<td>0: Packed</td>
<td>RFC 9466</td>
</tr>
<tr>
<td>1: Aggregated</td>
<td>RFC 9466</td>
</tr>
<tr>
<td>2-7: Unassigned</td>
<td><xref target="RFC3973"
format="default"/> <xref target="RFC7761" format="default"/></td>
</tr>
</tbody>
</table>
</section> </section>
</section> <section anchor="security-considerations">
</section> <name>Security Considerations</name>
<t>The security considerations of <xref target="RFC7761"/> apply to the
extensions defined in this document.</t>
<t>This document packs multiple assert records in a single message. As
described in <xref target="RFC7761" sectionFormat="of" section="6.1"/>,
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.</t>
<t>Like other optional extensions of <xref target="RFC7761"/> that are
active only when all routers indicate support for them, a single
misconfigured or malicious router emitting forged PIM Hello messages can
inhibit operations of this extension.</t>
<t>Authentication of PIM messages, such as that explained in Sections
<xref target="RFC7761" section="6.2" sectionFormat="bare"/> and <xref
target="RFC7761" section="6.3" sectionFormat="bare"/> of <xref
target="RFC7761"/>, can protect against forged message attacks
attacks.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
761.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
436.xml"/>
<references title='Normative References'> </references>
<references>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <name>Informative References</name>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title>Key words for use in RFCs to Indicate Requirement Levels</title> 475.xml"/>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
uthor> 973.xml"/>
<date month='March' year='1997'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<abstract><t>In many standards track documents several words are used to signify 037.xml"/>
the requirements in the specification. These words are often capitalized. This <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
document defines these words as they should be interpreted in IETF documents. 431.xml"/>
This document specifies an Internet Best Current Practices for the Internet Comm <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
unity, and requests discussion and suggestions for improvements.</t></abstract> 490.xml"/>
</front> </references>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC7761' target='https://www.rfc-editor.org/info/rfc7761'>
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specifica
tion (Revised)</title>
<author fullname='B. Fenner' initials='B.' surname='Fenner'><organization/></aut
hor>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></a
uthor>
<author fullname='H. Holbrook' initials='H.' surname='Holbrook'><organization/><
/author>
<author fullname='I. Kouvelas' initials='I.' surname='Kouvelas'><organization/><
/author>
<author fullname='R. Parekh' initials='R.' surname='Parekh'><organization/></aut
hor>
<author fullname='Z. Zhang' initials='Z.' surname='Zhang'><organization/></autho
r>
<author fullname='L. Zheng' initials='L.' surname='Zheng'><organization/></autho
r>
<date month='March' year='2016'/>
<abstract><t>This document specifies Protocol Independent Multicast - Sparse Mod
e (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying
unicast routing information base or a separate multicast-capable routing informa
tion base. It builds unidirectional shared trees rooted at a Rendezvous Point (
RP) per group, and it optionally creates shortest-path trees per source.</t><t>T
his document obsoletes RFC 4601 by replacing it, addresses the errata filed agai
nst it, removes the optional (*,*,RP), PIM Multicast Border Router features and
authentication using IPsec that lack sufficient deployment experience (see Appen
dix A), and moves the PIM specification to Internet Standard.</t></abstract>
</front>
<seriesInfo name='STD' value='83'/>
<seriesInfo name='RFC' value='7761'/>
<seriesInfo name='DOI' value='10.17487/RFC7761'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='I-D.ietf-pim-rfc8736bis' target='https://datatracker.ietf.org
/doc/html/draft-ietf-pim-rfc8736bis-00'>
<front>
<title>PIM Message Type Space Extension and Reserved Bits</title>
<author fullname='Stig Venaas' initials='S.' surname='Venaas'>
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname='Alvaro Retana' initials='A.' surname='Retana'>
<organization>Futurewei Technologies, Inc.</organization>
</author>
<date day='2' month='March' year='2023'/>
<abstract>
<t> The 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
creates a registry containing the per-message-type usage. This
document also extends the PIM type space by defining three new
message types. For each of the new types, four of the previously
reserved bits are used to form an extended type range.
This document updates RFCs 7761 and 3973 by defining the use of the
currently 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 currently reserved bits for
each PIM message.
This document obsoletes RFC 8736.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-pim-rfc8736bis-00'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC2475' target='https://www.rfc-editor.org/info/rfc2475'>
<front>
<title>An Architecture for Differentiated Services</title>
<author fullname='S. Blake' initials='S.' surname='Blake'><organization/></autho
r>
<author fullname='D. Black' initials='D.' surname='Black'><organization/></autho
r>
<author fullname='M. Carlson' initials='M.' surname='Carlson'><organization/></a
uthor>
<author fullname='E. Davies' initials='E.' surname='Davies'><organization/></aut
hor>
<author fullname='Z. Wang' initials='Z.' surname='Wang'><organization/></author>
<author fullname='W. Weiss' initials='W.' surname='Weiss'><organization/></autho
r>
<date month='December' year='1998'/>
<abstract><t>This document defines an architecture for implementing scalable ser
vice differentiation in the Internet. This memo provides information for the In
ternet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2475'/>
<seriesInfo name='DOI' value='10.17487/RFC2475'/>
</reference>
<reference anchor='RFC3973' target='https://www.rfc-editor.org/info/rfc3973'>
<front>
<title>Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specificat
ion (Revised)</title>
<author fullname='A. Adams' initials='A.' surname='Adams'><organization/></autho
r>
<author fullname='J. Nicholas' initials='J.' surname='Nicholas'><organization/><
/author>
<author fullname='W. Siadak' initials='W.' surname='Siadak'><organization/></aut
hor>
<date month='January' year='2005'/>
<abstract><t>This document specifies Protocol Independent Multicast - Dense Mode
(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unic
ast routing information base to flood multicast datagrams to all multicast route
rs. Prune messages are used to prevent future messages from propagating to rout
ers without group membership information. This memo defines an Experimental Pro
tocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3973'/>
<seriesInfo name='DOI' value='10.17487/RFC3973'/>
</reference>
<reference anchor='RFC6037' target='https://www.rfc-editor.org/info/rfc6037'>
<front>
<title>Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs</title>
<author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'><organiz
ation/></author>
<author fullname='Y. Cai' initials='Y.' role='editor' surname='Cai'><organizatio
n/></author>
<author fullname='IJ. Wijnands' initials='IJ.' surname='Wijnands'><organization/
></author>
<date month='October' year='2010'/>
<abstract><t>This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) so
lution designed and deployed by Cisco Systems. The procedures specified in this
document are largely a subset of the generalized MVPN framework recently standa
rdized by the IETF. However, as the deployment of the procedures specified here
in 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 fu
lly standards-compliant implementation. These differences are pointed out in th
e document. This document defines a Historic Document for the Internet communi
ty.</t></abstract>
</front>
<seriesInfo name='RFC' value='6037'/>
<seriesInfo name='DOI' value='10.17487/RFC6037'/>
</reference>
<reference anchor='RFC7431' target='https://www.rfc-editor.org/info/rfc7431'>
<front>
<title>Multicast-Only Fast Reroute</title>
<author fullname='A. Karan' initials='A.' surname='Karan'><organization/></autho
r>
<author fullname='C. Filsfils' initials='C.' surname='Filsfils'><organization/><
/author>
<author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'>
<organization/></author>
<author fullname='B. Decraene' initials='B.' surname='Decraene'><organization/><
/author>
<date month='August' year='2015'/>
<abstract><t>As 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 m
echanism for minimizing packet loss in a network when node or link failures occu
r. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to mu
lticast routing protocols such as Protocol Independent Multicast (PIM) and Multi
point LDP (mLDP).</t></abstract>
</front>
<seriesInfo name='RFC' value='7431'/>
<seriesInfo name='DOI' value='10.17487/RFC7431'/>
</reference>
<reference anchor='RFC7490' target='https://www.rfc-editor.org/info/rfc7490'>
<front>
<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
<author fullname='S. Bryant' initials='S.' surname='Bryant'><organization/></aut
hor>
<author fullname='C. Filsfils' initials='C.' surname='Filsfils'><organization/><
/author>
<author fullname='S. Previdi' initials='S.' surname='Previdi'><organization/></a
uthor>
<author fullname='M. Shand' initials='M.' surname='Shand'><organization/></autho
r>
<author fullname='N. So' initials='N.' surname='So'><organization/></author>
<date month='April' year='2015'/>
<abstract><t>This document describes an extension to the basic IP fast reroute m
echanism, described in RFC 5286, that provides additional backup connectivity fo
r point-to-point link failures when none can be provided by the basic mechanisms
.</t></abstract>
</front>
<seriesInfo name='RFC' value='7490'/>
<seriesInfo name='DOI' value='10.17487/RFC7490'/>
</reference>
</references> </references>
<section anchor="use-case-examples">
<name>Use Case Examples</name>
<t>The PIM Assert mechanism can only be avoided by designing the network
to be without transit subnets with multiple upstream routers. For
example, an L2 ring between routers can sometimes be reconfigured to be
a ring of point-to-point subnets connected by the routers. However, these
L2/L3
topology changes are undesirable when they are only done to
enable IP multicast with PIM because they increase the cost of
introducing IP multicast with PIM.</t>
<t>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 <xref
target="RFC7490" format="default"/> with IP repair tunnels) as well as a
separate sub-50 msec IP multicast failover solution, (such as <xref
target="RFC7431" format="default"/> 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.</t>
<t>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.</t>
<t>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.</t>
<section anchor="enterprise-network">
<name>Enterprise Network</name>
<t>When an enterprise network is connected through an L2 network,
the intra-enterprise runs L3 PIM multicast. The different sites
of the enterprise are equivalent to the PIM connection through the
shared LAN network. Depending upon the locations and number of groups,
there could be many asserts on the first-hop routers.</t>
</section>
<section anchor="video-surveillance">
<name>Video Surveillance</name>
<t>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.</t>
</section>
<section anchor="financial-services">
<name>Financial Services</name>
<t>Financial services extensively rely on IP Multicast to deliver
stock market data and its derivatives, and the current multicast
solution PIM is usually deployed. As the number of multicast flows
grow, many stock data with many groups may result in many PIM asserts
on a shared LAN network from the publisher to the subscribers.</t>
</section>
<section anchor="iptv-broadcast-video">
<name>IPTV Broadcast Video</name>
<t>PIM DR deployments are often used in host-side network for IPTV
broadcast video services. Host-side access network failure scenarios
may benefit from assert packing when many groups are being
used. According to <xref target="RFC7761"/>, the DR will be elected to
forward multicast traffic in the shared access network. When the DR
recovers from a failure, the original DR starts to send traffic, and
the current DR is still forwarding traffic. In this situation, multicast
traffic duplication maybe happen in the shared access network and can
trigger the assert progress.</t>
</section>
<section anchor="mvpn-mdt">
<name>MVPN MDT</name>
<t>As described in <xref target="RFC6037"/>, Multicast Distribution
Tree (MDT) is used as tunnels for Multicast VPN (MVPN). The
configuration of multicast-enabled VPN Routing and Forwarding (VRF) or
changes to an interface that is in a VRF may cause many assert packets
to be sent at the same time.</t>
</section>
<section anchor="special-l2-services">
<name>Special L2 Services</name>
<t>Additionally, future backhaul, or fronthaul, networks may want to
connect L3 across an L2 underlay supporting Time-Sensitive Networks
(TSNs). The infrastructure may run Deterministic Networking (DetNet)
over TSN. These transit L2 LANs would have multiple upstreams and
downstreams. This document takes a proactive approach to
prevention of possible future assert issues in these types of
environments.</t>
</section>
</section>
<section anchor="use-case-examples"><name>Use case examples</name> <section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The PIM Assert mechanism can only be avoided by designing the network <t>The authors would like to thank the following individuals: <contact ful
to be without transit subnets with multiple upstream routers. For lname="Stig Venaas"/>
example, an L2 ring between routers can sometimes be reconfigured to be a ring for the valuable contributions of this document, <contact
of point-to-point subnets connected by the routers. These L2/L3 topology fullname="Alvaro Retana"/> for his thorough and constructive RTG AD
changes are undesirable though, when they are only done to enable IP multicast review, <contact fullname="Ines Robles"/> for her Gen-ART review,
with PIM because they increase the cost of introducing IP multicast with PIM.</t <contact fullname="Tommy Pauly"/> for his Transport Area review,
> <contact fullname="Robert Sparks"/> for his SecDir review, <contact
fullname="Shuping Peng"/> for her RtgDir review, <contact fullname="John
<t>These L3 ring designs are specifically undesirable, when particular L2 techno Scudder"/> for his RTG AD review, <contact fullname="Éric Vyncke"/> for
logies are needed. his INT AD review, <contact fullname="Eric Kline"/> for his INT AD
For example various L2 technologies for rings provide sub 50 msec failover review, <contact fullname="Paul Wouter"/> for his SEC AD review,
mechanisms that will benefit IP unicast and multicast alike without any <contact fullname="Zaheduzzaman Sarker"/> for his TSV AD review,
added complexity to the IP layer (forwarding or routing). If such L2 rings where <contact fullname="Robert Wilton"/> for his OPS AD review, and <contact
to be replaced fullname="Martin Duke"/> for his TSV AD review.</t>
by L3 rings just to avoid PIM asserts, then this would result in the need for </section>
a complex choice of of a sub 50 msec IP unicast failover solutions as well
as a sub 50 msec IP multicast failover solution. The mere fact that by
operating at the IP layer, different solutions for IP unicast and multicast
are required makes them more difficult to operate, they typically require more
expensive hardware and therefore most often, they are not even available
on the target equipment, such as <xref target="RFC7490"/> with IP repair tunnels
for IP unicast or
<xref target="RFC7431"/> for IP multicast.</t>
<t>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.</t>
<t>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.</t>
<section anchor="enterprise-network"><name>Enterprise network</name>
<t>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.</t>
</section>
<section anchor="video-surveillance"><name>Video surveillance</name>
<t>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.</t>
</section>
<section anchor="financial-services"><name>Financial Services</name>
<t>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.</t>
</section>
<section anchor="iptv-broadcast-video"><name>IPTV broadcast Video</name>
<t>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 <xref target="RFC7761"/> the DR will be elected to forw
ard
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.</t>
</section>
<section anchor="mvpn-mdt"><name>MVPN MDT</name>
<t>As described in <xref target="RFC6037"/>, MDT (Multicast Distribution Tree) i
s 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.</t>
</section>
<section anchor="special-l2-services"><name>Special L2 services</name>
<t>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.</t>
</section>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1963LjRpLuf0XoHSrkHyudJalbX9yK8MbQLXVba6lbK6nt
tWcnJkCySGIaBDgAKJp9eZd5lnmyk19mVqEAkmLbI9u7tntjxxQJVGVlZuWt
sjLb7fb2Vj8bxOnoxMzKYfvz7a3trTIuE3tirs4vTbcobF6aS1sU0ciaq6j/
lp7d3op6vdzenZiIf29P3feDrJ9GE3p5kEfDsh1bGnMaT9r159qHRzRtVNpR
li9OTFEOtreKMrfR5MScn92+2N6aj3j+7a14mp+YMp8V5dHBwbODI8BXlFE6
+GuUZClNtLDF9tY0PjHbW8aUWV+/4c8DOy3HJ+Yx/iyynGYYFv73YjGp/d3P
JhOblu4LWuOsHGf5CX5r43+MkaV9FxdZOjIX8Uy+zTNgyw7iMsvlmywn8J+P
4zQyl1kvTuy6B/vZLC2BAn5YvrOTKE5OTBLPFjzRn/r4bcLjdAjIJXhuM5sn
RCBz1n9LSA5AeDErZ7md23jj/G9uurXZy9L+qV90htGsM7BLM17Gb6257H+Z
xwO7frq1g0/i/jiySWfS72GEPw3deyuX9/3YpqPdGyL5Yo/+iMBmfsrvb8/M
8yyfZnlUxlm6Eavv8H7nHYb807uS8dnpp6B2muUTGuPOMsGvXzw/Ojx85j4/
ffrk0H3+/PDpI/583j7teAbPh/3Pnx4/6cXFCUaL0+HSeI+ePnafj589PXaf
nxwcP/XzPDo+rD4/O+Cx2u22iXq0P6J+ib/PU2yN9s2lKcZRbgfmovvKpLac
Z/nbomXKsc2tiQuTDUubmklGf5W0bEPbxcymss+IF2alzTvbW98SLnir30yj
vCCyZgNrdmWCvZaJ034yg3yQZ7JZ3rf0qO3Hw7jfdh/M5Swp435UlPqqvFuY
WWEHACkusOFTk9hoQDvTDGbTJIYEMOdXZuJfhnywZWF6FjMSCudRPqAV9hZY
VkHMBigE9qJjQhE1ERFVGEIJT4tpbGL7pYlMQcMl1g+Y49P2lo364/r8hOMh
ljNMsjkBUc4tIYdn9pOCAre0HkOibgaBYQZ2GKeYmGAgxk7jYoK5C5uSWCO2
NbntW2IE45kiSwGAzDtNGjjA3IUBC1WAQ+7aQX2lHcNgZNMynsTvZFTihlmf
QCGQSYxnZZSYdDbp0YKzISPLITjjZTHnAEKQhvlmCG4pppbQN5vSEPQM4xCD
0xD4u4nLlswKguHnar6Qxttby0Qm1prl9G7HMfkkHgwgK7e3PjPntIMzGlZ2
9aczfbmY0ixJsqgz/vZWk/MNM34F4yAqIw9aNJ3aKA+w1DLDHLJpEA+HNBNR
vTEewSA6rhoDmMSTeNOxrz58L29G/X6W85ajp96/V/Hz8SMIbkUrRit4nuea
2jwmdS4YoNffWjvlNegbpDpL5hzdSvWBiA/yPLZFjVOjHsFcwenpSHpYpAEY
aEQLmxIKEmjGeVyOeVJaR26LaZbyaia2zElmTInLgEJ5kxiDv3bcxQgiyIGL
QvhNZqH9AoCvaVfZd3fZrDBXWUwr3r2+2vv0TUnTQr5h3HCNNLlyKLbjKqlC
U2Ub9qOCQKjHBlYJYH4+AcB4Bm2wvpHbfwHwTGxaVwQLwuaLjjkvQxFhfpyE
YHHQEBHmJ0uI7a2GiFhWAyTgGaOQTqSc6MdZEuXE2D1rxjaZDmeJmdMuVsB4
+zsBTtiNDD09CiVSNQPzawGmIlXFCExtUghDVlgw0zwjXGE92FlMPPBtyKu0
mWnegmjGXPjZZ8Sif5/FuWVj0lwQaWZELOFQSxtyYUhmEW/vXL65ud1pyX/N
q9f8+frsv96cX5+d4vPNV92LC/9Bntjeor9ev7nQB/CpevX568vLs1en8jZ9
axpfXXa/o//wGndeX92ev37VvdghpmT9XG0dCBPi3h74ldZH+7UkWkf0hC36
edyjP2LC+ZfPr8zhIxFQsJU+fpTPsI/oMwjDkxEnEcnkT8LawglXsHeSwCyY
xsSGLEBJuGfz1ICaDpu3Np/EaZZko4XDIYldyEmC2f5ABkgpup7gHUaTOIlp
bC+ByuptUG1Jmg4z7FbQN4mLUnaF+DYxb9OCJiNoS15zHU8MYPf2xO2223gC
rt7eur46WRJT8v0L/HBnYWZdRQThC9kh7Dltb91c0WA35HKUljiUH7jNrZVX
6afrK//36fWJObVFPEoZtGtmRFGcV3nWS+zE3GDzMz3xfSUViOn7pHexHGLm
BRF1mmQLZtaOubGWcETWU5t2iW3bH6IJiafi48ftLewoQjdt17g07gemL76N
UkUXIXk+Xhh6xlugaUYbKaNdRHCBUNFdFovSDzQQyyoAQ4grCLIYTKMySNU8
vTtlStK73cKwqomKSvVjvy+IL478C8wGlR1wZALrseWkxiRigeJl8bJin4/J
YWEp1I8IN5XUCq0aJ3mUE73pCgw5y0CkCR5hGggHCdNVA9GjdzEkdM+SdwIp
P7CJo5NY0zTxKqFGNFTt3acFFLaQ/bcsBwUeqF7VbooDNiFY7RCTLrAZc2dS
8AYO5oK5RH63KguadzSyoqHri8XWioWMKwy3jmzogCz0k2xnh6xl6EOumbAI
qSzKOuhkGZOx08UgZIcQ7Iw8QiUQTAxEvgjxDV7Y3uJZRCjUDDnGDViY8KMw
qTCgwaFAaEOnMAyLPhMcU8wgmYj1B07lybNDzySOg6A0BTtEUcFJx0m5mhXi
TJg+m7OiAnkfiXM0YFngFayMBA8AzzkzgSZPC9qYxayXAluyO9axfQfSiXwk
2engJHNxZHLM4RwjRzIAVRCrYpVgW9g7WTqMR7Pci+aIX2WlP4VAbJdZmz94
cOiVVIS5eHsVILfsgF0c7V8cexlAegNWj/P3UmAgj1jC0GJH45YwrCgceoKR
NoALzFYgPxnaHNtbjA4gnfYdb3N+1+0ltWeJ82kFsTonQEbNcHFjOCJCWDBp
BEzSchnz0pCGZHHIQBbOiyYEl0Rq1lexLg37gX2kFyyAmRrmLqI9SVzWfAFC
GnguwKp3xB3Arnl8YCaFJaMoipPsDorCMxSJCKbcGEupCWoyYtiJ4CWB+MdK
KdOLsAMwTYd0y0X81s7jgjjk/OzsjLUgqREwGizeV8KKYv67OckAmiWwitlO
MrAssRClLGR1yTwFeIqYFrwQpiI10xf2EHgCfUDvE3Rt/QaowACMb94ZhN0o
LWkgMX9r1Kw0oNgcPrwROedztWtRjkkbw/gVS4/2cTGbTiF36kJKg54cyzn0
Tpzb2xpSNV9ZskTM6ynmJDiO5EH2V/AzhlzhAxTy6FfZfKXDse4Vtqw2ALFC
Dq16zOy+f9+I7mb8w8ePey4CxFo/TbMZjGdFklgUZV3cNvhEN8Zq42vl2lZA
Iy5XAXC2t5ytDYZiyGYph06J1f/5j1ANOZ0VTazje7+C0sVdmFKMywaCXLz8
hcxt3n+2BqiVwp7fbYnFDVbj5d+oj/Wo86zzpGHLki3jbHOxJshbIsB5IVD3
Zvd//l/r5R601e4NPijKiYMhK0X/VKZw6KY69l42adkYJWc1GpEPvtdyscHu
YEC6luTKS7hYZN+4vy/Fzwd76scrHwnQWJbfYohfFBo2rMUiUgc6VEw+UAuq
xj9OOAMVcxK3dr4Cu35jFTADPRbYee+7uQZgEVbbNA4W6tmiGtAbUeS0sFfy
/v2auDCRSd5lvjW7V3s8Bb7qjka5HbEpv9vdI1JgLl7buXia9LC8xegmTB3I
WG5utn530yxlBrODvRVLRtSovqNq3pCY/gQuvnDnNfoqfj/XHQjHQGxnwCoA
8a5i+7HEVj8Qu9N9S/I3gyHA8UmSS9OysTS/qkNeVdpYGlzEJIEpvToM4rBY
LqbyxxgsRaaLk53CP85rn0YLZ/kNrPiHlc3hluQg7H5xsAKmXjZYCM4L0mFW
QwI1ziyUpRljCv3OTczaO1zFThXOFQqwwrNKxyUyeLBWoWoNWBVzbYIwNTsB
K9bAdOBVo90H4i1tmHXzMp00ZOm4kV8SSbjj5Ej1utL7ml/fIYtFEOWYVIZl
KSjhvYKPOnZxoJele0uC6T5BBKE7J+2G/0YcE2CTFeMhXgdXkuWaG80iSLUB
Ym+M0Q6UIQgyQl5ZaXd2T0HKFRziyatsXDlieFLkuYQM2cEK1JYe1sBK67qg
3AZYxdxLm4uE8UWf2M5Zjp36eLQyFpuhAOxwr9Pp4EO61zGewNdXm4mbTzdQ
V4i7iZZk1deIif2wI2tT2tCMfAzEcQu4+W6SqI4DOcmpRnln88yzRJ3DrLpW
kRxErthm21sbkOBcEB6Hj7vJtzTXVy/qhwO7gQTfIwTR+EyeJvXYolaXRniD
pp/H9PQ4ugu+vVdFSxzKQw3SN/jbPAB7i1mo9gqzNUeBmzg23gJjJ4VNORLh
AT5qcYgBeaIF+8NxOpCAc3W0sFvsCYY0imEHgVnaMhnCRPBwZAVLYDil5x35
ZQvlSxpjs5QA2u9hi0LcGTmQtTLVtahO4VwEzUr6f4KqBFgT8ngQCsfxU4iY
Ho5zMNSAeJnIM4uLMWMn8DcQC9wEL/PONRQk7a+aXenkwCBrmhk1Flo75KEM
KUzwCWOKOxMy1aVzIjjMGPzCA8CxlPAB0zREzlJIUk9PvJPOnA9zqCjJ4KNN
V2icp/K77vPXTNMIK2tRaHI1CjH0RUPCmeXDPMSH5hqScqe9sgFE3DawhEjY
YBDzY8ScbNqwe6/mYbjkeo4PBPWtC6mmmcdTFvpqqslXOQoSZprEJciLCBK9
FueeHdmtlZDM32ZFWXuagB7aOdnQ4FCOx+XVaSphV35sHlr1FqWt3Mw1B3wO
OrZjXSww9PeKMcckEKnSMDXouu8c6aaCi4j6OYDaz/S0gd3IIOiJQAtcAmXP
zxAUkTyKVWyBh/hAesYv111isfVpy+D4axXpmk6NQES2K6Ptiv4LK5o2O3Qh
WM2H5aDSScBeKxZAliHcuhKEzzKoIJYt9xkkHCfj0MP2VlsCNhaq6V5Lds8h
LzATdz/BvFRDoi3H9zjACKkYHFqyKJEI0oiUBA3vojPYLnV/vYWUG4YWTKIn
Gey+8LI4dujEh/dsEEXgn+viBaFIzq4CbH0cffs4QducN+bQEzwHmRMl9wR7
DM5wofxmbIYU/Wyq55FxUZdRvE49unBgINw3oy8QWojKqF1pvMgdDuWcSBee
aZFTdLuHU544Xyy/0cIrvOilycyum2wck38Nrwtkb2Aa07EtsgKZsUhZLFC/
WoNIMG54GCiYQPjWBxW8Vw+uI2FECJ3IeQexzjBCvMDDG5nvuq9ekjUzsMke
c8fGbVDIPuBYuAvDrUELP1gtmf6cOK5ewyCBWKoMGJHIRP88KmEzOeBdPKO2
CKxhnM3lzE8XEDXwXSmpudWEEicAZT1+gIY4XH5cydQ17iAg1Fjhqu6iOHFL
I3uEP9ZgkvUBGcL9DQSx4eZDPrU93ogrsh00iBbizA05RZRVUyhQ66xpLrvf
mYy0k4Y+Vqyl4yV3FEgikj7FUrCKz60XVZw2sOS3t8JoHk5PJQImoDZshOEs
FQtBsgNlNMGWWGH7ta/EitqtTVAFE4/A3m1WTo0x8JV88xxJD4l8v26cJ53D
5ZFk6v3wOx3rfqCeEFgrV7buhc/pBdlC58N1UpSNdX+8UT9abiHM6EVNZdE1
Faw7DKnRtcWiXsiEHC8hHVjHjSkGRxg8bPAZskVgz7gTvPr44nsS95G1PvPq
fTjL4ZmENge4nt0VDQg4v2ARQODMwihZCge5I3lWbxxdwtlXueYYwee1eeiX
IkwCeNEfkwPGJ3N2wjB6BIfOrBzJpAU5knmVTFBjfbJhKvvYGVafma9olkQp
DgHEG3NJU/l1cswYZ6cMQoUOEpN8DC6udxXQcwKE3Vo90YwnEzuIgRtdnUzv
g9FV3lhBApjs3H4e44wwWWWsswzj0I0HuUcGv18KH1IhPRGne+GXTmlHI7h9
pdK7OjslrvYh651zE00cP38bp6nNd1w64D//ce7SXBHeLWpDOBuFLSG4jn5X
ICVvlUIEpxJAwsyIR4bLlTB0BlVc1NJCJvTGJH5nqwNzglxWtCFbmA/FfULF
rWaYLJM2DkPYwRqd8W8nOAhEflKeTfOYEzwaPBDwc/2sij1WzoThcLLPYFLZ
s1+XRLKvBrKFNrNs4J24zTSQQAk9FUeJcwg17ARriwVDnBHXLVz4BdZ8bWIR
FTjexnZix4x2mEzFAYLeYkqA6HOQDJ6t/RmtSojgkJW8t7woA0sTL/4ti9P9
aT5Lbf0Y8luNYXt3cxUyBGv7q6UQ5xDz0a4kjTuMAEMq5L2FB471CAw8oFXM
4Hc4jTyyKWSSbcizzTvBpV44WV3npuAYBMfgnKVQxZl/NCaiRAwMhwG5qCP2
7vKqHZacJiQwR5menwm2ghMGRQ0I7sKI2KHbWzPSSRJzTKJCj1jAZ5Ul6aOM
Q9rfxRh+WAUfS0POtwwc56FDF64mBUZzVK5XZZ+wh4LIvtvNTmf7hChv0Crd
wkSPpjhZrX9K9pjWOEt1FaSyIBT6+qJTfN1bUzv0nLPYlrSQTNKb2l6xqOLi
gIv4IaG4EHzdRZp2HSa5KFf99fWdzXEf56/n4IA7GtIfIzfOmx2rEYF4+8Nh
Oia6glwAckB+ghfeKgZqtHDQ8d5zPoOcGlY5Vj1ONQYLu9cTYq383wqNzEkW
CWNM1rRJTfDzQeZd6vNpajniHCEJeYTIsIGgTKaQRgVHXGgw2jnukPdW0iBC
/WJGeZQiqgMx7eTl4YHk67j0Z95CQi0aI8wb397SsKtscrWqGTtyxUBxU1Yh
fvCMpqhFzqFgu0zkAvKSSOBJ7EVyonyGuYwZmKe1AGm+CLharPxKCrAAaDqN
akvHKSQDBqpOH5ygqctLNh3Y1mZhKlMFAUVOXyRKOEZ24YvXPnzhB0cyn56o
V2lVmgPmcdWwRmnyzZxQSYUvSWmQRoxD86O4LwZo3n/W8+9wZsjpfe8h027B
Gw6ScY6QTlz0Z4WmJ7L2r8WTOTTBMUBafTWTptCzzzlzxh+ilzhNiiY4wsIm
2HW22t6mfQZP3mrWHGdkeinONNdUyyCCu4KJWzVrmykSlzOfMCmSZSmUxJE6
icgXzRscwR0RxipjwyeXzRRrzSCgE5NxkJGmIQaOqbOmVrk62AsT64Js+ahH
6GxpnkIsmcu08goOBEJoE9k7UQLIyNM4ah6IJtrtTkRwRNLd9XHmiToFNR6R
HBON/MoUHJhw9OV0OInCxelmAVqRxDvZQWx0hUa8x2CBNK/i3j68mju14O++
aB4uHhdZqBYAT01Qq2PMxw1I99ne8utQJ9UPtXTPhmTsBcYFF6ZZWgtS7NW3
acyHmkV9dDhzBJG42ypR+KpQlekTBNvq5ovEH5wln9u2w2n9yuYKFLZCL5Vz
WpwfFadRL07Y6M8YnuVwQlH5QT46zUescrWn5YPpjeB0wNpecwwbhq+Ex71l
k21vuaxyHzkJlN+pu0wXs09y4xLfn+MER293nd48v2rpJZNHTx/jnNsryrMf
prjMTK9WFymM2T17Qc80HMo4Z/5pGcuRYTlRm9dvAN5jNAiy+9i3hU8Ow4By
Kq4IQ8jHYSuqooUcbpr6kPz9OqCcIzUdIp8z2LOcTxP8xnepvBHuQ8kysZX5
ooBnAlkpDtH81ZtGCBEJbZVtTXo1Z/XbCVJU5ZitAP6UyfDSUkCNj738+X79
JeT3khkJ8jeW2cJEmuJaaQedp3nWxnvLxc5qO7IQVpDD+yBkgTvgUaoHAv7n
OIye9OoHRyxX2KbWmwwrdh1nwSSxHsPo1TQPPF8+m9nQntDs7iqaWA8HkxJL
rNzyYEmaqwdbi9GY3a4EObuH+93jxtG3xjxZ5CIbd8K2xggHeM18tMqGkiyc
TB8voYur+AaTjpFxF+ULvY8jct6QT1hmOWdkujvhDfVLAgKX1Ekv0S7pFz4z
TzO9By6Yz5E88llwOaMUdcd3AVp6n2clVLipQYayC15w/oPjNC/gqxRI40Sl
CuPL2zc8jiiWd1YVL2441O+QscE+Z5e84fqqAq0taXvLr8nwkmoGTS2RRS9c
QCrNJpXcATt9KZacHOIpkC5m4G8g6BZYSTFIKdQw4HwXPglxr4uhV6pAmMSj
cXhe4mVGyjk9d8AHCeV+WZjqOMm6q9qaUcj6KdCCRHkvC4NbCi0WYyCu4rBh
XLUCkeGNweBOEUdFWbvnGfmiSZRaf/ZRCy65Mzd3+kRjWJxJxqXzyCUrkuFO
SCcwtYSdm7JLDF65nIqQa9TPM5ZwCBP4e6ndKoQpKaVsoTg2ZfsW6Wp8DOfS
3CfRD0x4j3KXiKrnddNZ2XLEVq/MIUNGhufjqApLQqy64ELDiuwDXkjFxsoE
UXCvJSESpv2Fv43PFhW8+iYMbMrPo0UVifFjBLxQsxFxOwvy2OHNpUJc+zSZ
tckQb6aaLlwFu1c+3PJHKspkQcYMsc6d6KmyqNJ+9SL32sTdIBwP8e3jEex9
xkPI8UCxheOsPEWtDlDXXevXe5uCZb0x4J0V9d5MPb+/ymh26e1836xgn8Xv
bjlGWL60uvnux/KFBb3TgddRTsUcmOV/hyu+O1rx3bEf45B+PzaPzGPzxDw1
n5tnP+Y7GeXf2//i/8kwHwQ0Wf4tMsm/MLdfnnqYa79f2HREovyLAAsfHgya
9yfmsxfnL9tfnV1cvG7LPW3DJZm+2NlAtp1V90lW0pflIXgnMEzxjjx06UPK
Ic+GN1COmrep5Sg6QB8hT2oySZWWq1Apm+dkv6qf0rxydO6NC7ex64P6BIii
dtjPhqN3feTwjBO3qpCicemxNTniMx7DyzYr90w9T053Ku2UNXcmfrtbBUT5
xuYfDNPEfHhKUz2mKY/N0Yfuh6sPAfzPx7b/tiCtF/x7uK0SbEz3r5b6TL4g
pwMO2vK1iM098wtB08gV9sC8STUAsQzOA0Nz3cCO+7ecK7/y389KqdUg3fPv
4UXs5dnNTfflWbt7c3N2feuE7Mp9LqL1/fvl1z5+5KoVhSYANYJczXTf5jW+
WuaPOMR1noUAazJOpBzlMs9qd2masxw2ZmFxeX7FA59f3T2pAqN6p2Lsy2tg
XU4S7wS7fMe8QNr5l7CrqluKHEL0M4uCWHsXzvuG/r6dGqoCWFfu27XY6Arr
jmDM7qsucGX++Y/u0o22htniL3+S5Zsh9uyv8W28L8dY9Z6rOzaVXH+nElbd
Z1jSD/flwf6hJMwvpiS+x5UdHX2lgLkmHy+Hqf4zip71s3/6P4Wm8y8O09kw
TO1uhvnz4V9+2jA/DpoHws3vmlJHf1BqGehPg2bTYxt/f1BoftdcfPk74+Km
UXpzfnl1ceaM0s2WhliobaOKF7GgFivfllewJ87caNpN9xWXUNe+Zv+dGBhh
uJIUF2W+MGOc9yLexBbhyqDBBntQZ4GOPlFz5kaMLblpm7qbYkXBB5Y4LJSE
lEn0luP+S+m6iDEk9eJSqIDDyRFR7mKsVaGBKgHch2hpurZ7NtZLNoSzZMD5
FkgaULid6fBJsJtzrYgwc0FOVxOBqHfiE1NQhsAXUTh0NypOwhtT9WcO9JnL
E/YjqgSL2s7yZ2m+8MCpzTlC6RO6E4lv+YIJHJlEbdBFA2kOqHD8E3VLyqWY
5zJ3wy6XXI648Hk3fHmq8OGfqG6Vc5GDTV5Vg39NiI/LVRip1YLweAii774s
VxV65XvjdaEVrOKBl/BbdRPqIP4RvQmh+SN6sxIapygl/NJGkdPr0/aL19eX
3WYMRwsqfHQR3NXFTZZd9k3XUH+7+/EPt/0n7oDN/34JM3ptXZcl9/23akY/
IDS/EqWa7vvvmVJ/uO0//d+vy8VN9/23ysXOGrnqPv/67FbNkPbNS2+JfJLN
cY/z7tTb/yU3/l/xYg//j4cC1m2J9X7x+1X8s85xXVs76RN9WC5Fs6EI3PvP
msX1frsG7x9O1qdB8+u7w27YVz6u9VK6eOy+2mtAu8ol+LkpVY9dHG6IXvyy
0Bz9ytCE/zZbAB8edJhfCMWvfjEUO4ujFvgILI5NBVQ/PnDI+vqkEYHGaNdB
nh4yL6pLGmvK8uZBBFW+jTbpqZZM5esZSuJu0ixsUhUvrer8btKArrahNNCQ
XOBc7yNjzpXlDpfKmXBijL/bct24vdGq22uKzTXVais95L76aVbgkiAPK6KD
9gpGU8j62eonC/U9wPaQK9FV++mnm6ycL76+ZiTyL5u1YvVyd6NYabd2Hcab
n+vqTMpVVR/NX1Fd1ldJ7cBSdz3XtNYrV7OJCiuX+8CUOs3MW5taiFVy8ms7
g0thlHJVAXlVuOWFm1zrhqjd5qc/o6o6KY3jCudyDydpzOMbUejGaHDmqjvN
LCP+sP7q/37r1l9DCnhfY/frvV/d3vpx/36hHIYQTetTpn6zwZAHhOaXpdS6
lKnfNaX+CL7+9H+/Chd//Xvj4tWuEFlA6grdV2X/45L3cvig3kt6n9mqrosk
wX+y13KfHexKp6/1WFZauQ/isjywi7LSPf3J3uk9Jswan0Yj17XHO6braMxV
gdArlF1U7XLEi1SrWxpFNNws7huh9fmqqaQBgatNs5RcVNvdceVE/fbs8DqI
/1vSgCreEWoW3K3o17V8G3x1uDES+0tCc/TrQtP499uINDZQfPULotip15fX
r99cqZJ1qjWUTU6X1vct9zOppPhDaYKHUAXBdq4pgeUn+Fpc2MVe9WTaeLIR
A3M5tiGW1Ho618NDHaFq5laX9t7+QA2oRuEYUSONiQmUg7VTINZzoN24fUGf
1SaBFgLUkJFWQ4V1IWOH0VOd2bVIO+ByVs0RoloZ85XYWhn6/Kksg1e+lIha
7qq8VP2yfgy1UJaBD8if1wsBvv+MryDybXX8zMXeC5TA1dZBVaElbkYifW7v
omTmq/bjJn+br75vb8n99mKnOod3F9rXXZr3duq/fyH/3H+rD0v/ln7x0uYb
BuyD0aoGgfh5hfBiIOYINbVw2IcHhMI8Oqhk3wF9WLf4D+bPfFv1VK/n/+Vh
oHCyjimqMo4/e0oZR6hPojyqZVW3ZF19haVKJwE/+JQQ5H0E7NCk9j0LXLlk
j2JO6fzgqPohAG8NfZdp/JPnNmQ90n90/fj74MSRWJ5oUDWY+4MDz1QfDk9C
V+jHvX3Ufnpi3qSecPQ2CZDjZ0+P//JnlSR/+dfXHTLUUZOjGrSWBGWotv6M
a8HWJY5zDwr383Kd/Fr0foqqlspZVWEYNIm9p8JFvQMrnKCiEpvLFQR9yS1/
jaRbVG1oa4L6Cd9Br/uREbbEqNrfVe14rmRVHWcktAtQqqx0rbQlZUgK/nE7
KFOU2dR9w1tPuqz7zXXRfaXdlLm0let2jyJVolTmQeellVWGGEHodK2lZ13r
ubDsToMIvopQ1Je6WlUtPi686fsMazuXRjGTSVAAk4yboJ86d69J4j4agG9v
adUjixZaGpYAVqtaLlWhdK61O457cdhUxfcO8iuRMr4zaPQyru7m18q/u+pb
VcH7NXGCgoh/xHbHk84xQNjemuZZCSq4pgVazwhQ+5v3Zcnsp/9VVdztv02z
eWIHI27l5TZFRKBmuWsqnoBITPcofXtibsp4ZL6xaRQVXqtCESMdjAtElcSt
szom3B5omW5yF5GReW3LKGWGNWOO8GRcsMu35SAhPWMim+vbl6Z7StvkLrbz
ljlHm/DrjOaS2cE6L23a7l7fumfQr2AyWRDXzZJFNQVsWqkjmdvIj0dDgSlv
plH+tnAPb28Rrk+5uKE8dTOeTbm2ltUKnZj2uhyFz/xnNqb92Z8NuLykm7YB
/hmiOt8sUtoPHrLzV7fBI9tb/MzXCTrkrX6EV2a+FTZ1j9ycPa+N8n2EMuXv
3kUTYtIbWl3w7O3NN+FwioNv46TUukWMg9dXN9VTcjYb5bQjzOksgL42lrLV
t9qfXoy//pLg/R/ohPbZIC6z/MSQMETFs9xOsjvtBK4luv7iikK8ntIePy+K
mVQyo2+ec/nsJBsty1n6PM4KiLSiZIC1u0v74Amcm3FZTouT/X2SgeNZr9PP
JvtlZnNU3dxH7mW93IU/MB+QBCzbPkOzURTj8AjPCVBkttDOB++zamooFu1P
8XdaCvtcXmXS8ESi1TZQZfNqScD4B/olscMSVelMyvYQBg6ZsHCkY7kp5Rfh
tAzgO+RatdC0Dw8/dY2HvMZsMs3tGIKNqHWk1dgrPuktakAIuFpiENI9HaMS
MAh1gkN1Vw6EKSeFPqWFZrMQpnhAzb5WjaxUn7GSLqo0U66fV8ZaySpmLgor
uu3Kdck58176tipcOiatb9M9X08aLVC8apuO8sh5r5EJrzSZO8k2dv5ZkQ1L
0qNQ55xS48vh25zDDLANpcZfXMDffsVZt6I5m9hBs62DtSW1uU0BVPEcTUOg
xl0vWnRkAjzkdMrAVaEWJbPyWFSOmWQ3XGTSzvO41B5pWpgQXQoUlygb3BvE
d4yV484x2SRcCtCbOGGpdKZfyd1AWLbP0J9EzCR9dYKetxbiv6oSI/0v2+AU
u8wr3AwYjI6lopOaLGW/Ro1KMbcajet2bWfUOeGWbnva2i8q9zGO1iZHBcyW
Vh12Zd0C5gunKTqw9FlvY/efkL+cJOgrigVxA6CguRBtO61w1uJqszefjkap
ax0NXGE2jzWWOb2osNoVnsUxnHLGm/NB8DrqP1d47zzWh2B4kAlU+lK7BLCO
zggP6mMHCdD7ValNSa7hhYoJJWYPD07bydWcVEOE5MQ8z4gXx7CphITOFtfV
8vuhxpRVcRSjO+Uyuj8g7/1L4SubRL2sKtp+QbIJvH5XmItj+egKt9Iei1WS
hqo0GN5JcrbGUj+mRn92Lne0MVYQ3olTVtnSSEzS0rXZhRi4XPt01xPyERlv
0KmPOo/2qh2XxkFNzw3i+KDSBBxi0ai5ZNAvdWojIFHjtscFzDNzfIQrCSSJ
SMmAvL6qadAUTwI5u9wHIZsz6x8+4ZsMe+hlnOckAcYRTmbInOYeN6QZXAdK
lhM0imd0tL0YjTWGhNbqtF4I3JGIbAzE9vwkGnBzAJkKHbhZDxIvp4sxysu/
Tl1SGHctZ0q1zOem/R/m6BGvSsxSd5vgE/F58MwV2x3QIuJEGFmUmraBoIXt
a8Fq6aquP+O7BTkM/BZt7t0fZ2Psl7m1++g1vS9j7P0NoOjgNYuZmPPaBrqL
djbIgoDK6WWL1gtuKBek+1pMMygp+uay+137P6AYgJmdYgZfLiaq73R83AWV
3/nokyfdD8183hHXbJ4NyI1G9wphMjY5nIchNc4KzYiDQnMFbN0dD7B7jHau
qUXxyChfOAG1g5spOzqqu3Wih4ZOaPqqryQ5Vuivtt5Iaav7NppFZPGXVgqN
8dWU3R23SXaqem/RBN1ZCGVWtqHb+bw2MlNxDwcj6McerFO1Mua21r5pjkDy
ThUE2XExUIl/ATipbS8oDn2Ke0ROpda8lQNlrvbeThIt0HWOANyJElp3yiWn
uV5nvbP1XVwrpnfpvXCRIKgDTt6v4x0CgqjFaiWfGFv2OyHoNaeJueOSeeMc
jBkuoHAr4J0qXdCkkZwSdReJmqJxudUz4Qjtpft7bCapjO+wuE9i1XIzFLeW
CCCZntC7wpl/n2XcN0n7AwHwkNXFuoyKWBq0DYK4ry6rchslUH7rXcbcJhwj
IVOgTziuO+m8+znlFOXCw6ZWNUyAGVhHB4ml7AVIt0rS0FIUb3uLtDjO/olY
PQuDja3iWkV17oJblFnGuyGXnXcCyxGSCj7BggU6aojvu/r7YjqEZzstaRhO
GyH8lk/RuWiIb4It1qa6KG4KVm2pdDgLylVr0xlp6iNqBT2DPlWtHXxelawF
xrVNkrpNTCfc2aqFEby8hfSM8v6YtgBfputk+WgfX+xPihEk7/7L4uu/P+t9
eRQ9WZwOLp+d3nXfvHz+bTkenJ3vsT0gziiEe10bqnR3mkCzhRU85hcHRB7N
OyL4icw5AiKIB27SAYH43z942o54gW1ZcZtZrFP+UH4iDp/+rDh8Pn2UPR4l
b16M7FHv80f//ez5f13On3/7/d+6b/f/FyHx8X1IfFBi4Yn5qB2lKYmevv0R
hHriwxfOaYS1pVXW/Z3DH9yBtDoGJHbZIBtygwsxfgdSgh9ySmvSx9pmch5D
2kD0kIeRSmc7GqV98LiDzudzaRqqwuWUrFSSe/23EgdmRTyIh8NCRWfTnw9p
12632b6UINAbbX3q/Akc8hGO2/iu7b5bVV27as/EXUhTaSflvO/eQoPWjnu0
3zCHpntVf0iWaDF6S/VS9D6QThHOpZpNSeTZaOKCxh1cGkbjCm2zQBM7/4EQ
PLfk8bvwMjuGsF1JqsH1ZjfAh5I1TMGvsvDjqE27zNpyZOnAoVdSkeiaiOYB
ueW+CBdH++S1lNk0S7IRCu/rHkb4G9K/iKULjljVLd+RZqFNLwlpHOdBy7qU
nwx78WhbNlExQezAe/kSdJL2k2HHxlpDHzeGy7UC2OppCYlqZXTlMkcAuwKN
tjtxHx37gPKSiJ9izbEuFufffBE4aIPhrZXmC6ziuPI4/Fb0qyN8+w4/MAKh
uGo9xcSSkxZu7B1ijTNXFRgdpvx6I46EOwaLUiKLxCXY2LU/aI8oNvmuDFtm
Zjc4RAFw9CZ9JP8JXbUR8lc2K1x/lExYigyHPu6pEHcoTgtR1qXrxVtVwSp8
W9HYxeyXW2IBNwSvg5U2bhZLjwVp9hLgKUCAQxlxfDLzPfvQ9FM6BzbfC1qB
Nd+U86IJFok+IYJ4dFOour1oQqhDXoslD7ezCubXWssrSSRtl3yFYUgvvjc0
0QYrMaxBIAbXf3ha6XbBDoByqL7Nb0grGwl1jomK80j7YvpMUGlFnZFhlLaq
/Yfoob3DudQdtCm2n2+dq81mMMtUzkTc0Y+c9jx6dvDxo+wtWiZxQhSTKIbT
lCwtHiTVt45xQqY/e3z4QzbogJY5Pzs74w6OaB9PwhHLeiXis9562XORoAJn
TNhqKo2Mb1XMzft8xz/HteyhpSaQXx1+n3ilrd/EenrGt6aCTseMf999xUmg
gUUX6eBYNbQpwujYCCvy+sY12cIZPff14JUy/Zwi4tZLvqtqoCmcg8I5wD3I
/6zHvmPOx4UgcmiTK6akBxOzshdBKuHjohKEPrhFBsKZxE2go70m0wZ+hJ/l
XyV9yikPjb7RRuQd0z5yj7Xkoh1kd9S21Sj5LC302WM5gPS8wvsz2HFxCfQo
EoMheO1VuxbXmQ9dgwQuDpMqYNzuphhz/5qL7isHHiokuj5YnFYW1i3XfF/X
J3N7aySX0jX9yPXtniDK7+ikQwxjcova42zq9ami+RuiBHHajChIsh4xd/yw
/G3Aa0r8STzKqwbfZCoT+0qglRa2ILtpwsG186u2RF/ddywTxEiQc/AA09Ib
fhViwvkrra69rHnFfXLN8ogoIxaMHkHwTzU86ZG8nneI+VPH2PbWWnS9iFPC
BlqZuhaCEmx03xausaCecd9Z3rn0P0QIkkCXXg9w69IkZk1QZjAOYb6SAJRe
UAgJlSizkRM/QSAV0tVTe5AHCsVpAHAa7VpgdcYCWzDGEcKikUhY70xZAEHz
luBHO/QBIwyXwFOhSXFZ7y/JvwSKl4U6KcFlMjKzTGe9BA26c99xlWQVJ3NU
mD6/uv3G9PIsGjCczJHsQ9Esp9c1dmTLDlzle6vinLON08VqXqiExph3wuVK
so75yr8V9bmLi3+ZlNVMpBgZjWRiOSZS00jN1WY4Ckwa4izCENJ4j4u4mO6a
Pk2ME1qkml+IMziBqmYTcUvFSZKD4owaRXp9CR3zrWvNSOPCModfRYwuPUt1
gZIcmuXxKIYPQ0/ySXHhurC6qVyDWeQ1KD/Ss5Dk3CdsOT/G7eygtW5gm7gF
uGAJ/xwtelZPGu9dGUBBEk/q+ymWVWNHUjUjhDMdU11+c/XKXJ7e8knJUrcH
wv+Tg+OnyCmhZ8xutVlPkR2n2RvmNrd2jwO2rlVXaIVgCt9tUrpyupClX3Jb
XI+B+eb6hdmlFyS5xsWCK/ztQafyCQKZhlbsi1hzovAuez8sQ6OFy2QKhFnY
J9l1R5V8Ktef23eXkFalsLqLQLB1fcwOkbzhjE8n4cqOo1nSAnDEQGkpfylB
ivCklRNfoPtg9WiDO/EhOVSHrsSajYRVrDbBCJLd25tXe4LVOB2SlPdHpSyH
ZimpzZIe52Z0hh527qLzdi+OyNLqvnIGnCiwptMr+hURBP27Y5oZFMSs7gia
eEvyraTRLC7RoBFuDvvWUdyftSvqhCyQ0nrYDmYtxBRju8ymdzFhlOUa0+b/
A4xDeMs3tQAA
</rfc> </rfc>
 End of changes. 49 change blocks. 
1417 lines changed or deleted 780 lines changed or added

This html diff was produced by rfcdiff 1.48.