rfc9465xml2.original.xml | rfc9465.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<rfc category="std" ipr="trust200902" docName="draft-ietf-pim-null-register-pack | ||||
ing-16"> | ||||
<?rfc toc="yes"?> | ||||
<?rfc compact="yes"?> | ||||
<?rfc subcompact="no"?> | ||||
<?rfc symrefs="yes"?> | ||||
<front> | ||||
<title abbrev="PIM Null-Register packing">PIM Null-Register packi | ||||
ng</title> | ||||
<author initials="V." surname="Kamath" fullname="Vikas Ramesh Kam | ||||
ath"> | ||||
<organization>VMware</organization> | ||||
<address> | ||||
<postal> | ||||
<street>3401 Hillview Ave</street> | ||||
<city>Palo Alto</city> | ||||
<code>CA 94304</code> | ||||
<country>USA</country> | ||||
</postal> | ||||
<email>vkamath@vmware.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="R." surname="Chokkanathapuram Sundaram" fullnam | ||||
e="Ramakrishnan Chokkanathapuram Sundaram"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
<address> | ||||
<postal> | ||||
<street>Tasman Drive</street> | ||||
<city>San Jose</city> | ||||
<code>CA 95134</code> | ||||
<country>USA</country> | ||||
</postal> | ||||
<email>ramaksun@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="R." surname="Banthia" fullname="Raunak Banthia" | ||||
> | ||||
<organization>Apstra</organization> | ||||
<address> | ||||
<postal> | ||||
<street>333 Middlefield Rd STE 200</stree | ||||
t> | ||||
<city>Menlo Park</city> | ||||
<code>CA 94025</code> | ||||
<country>USA</country> | ||||
</postal> | ||||
<email>rbanthia@apstra.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="A." surname="Gopal" fullname="Ananya Gopal"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
<address> | ||||
<postal> | ||||
<street>Tasman Drive</street> | ||||
<city>San Jose</city> | ||||
<code>CA 95134</code> | ||||
<country>USA</country> | ||||
</postal> | ||||
<email>ananygop@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<date /> | ||||
<area>Routing</area> | ||||
<keyword>Multicast</keyword> | ||||
<abstract> | ||||
<t>In PIM-SM networks, PIM Null-Register messages are sen | ||||
t by the Designated Router (DR) to the Rendezvous Point (RP) to signal the prese | ||||
nce of Multicast sources in the network. There are periodic PIM Null-Registers s | ||||
ent from the DR to the RP to keep the state alive at the RP as long as the sourc | ||||
e is active. The PIM Null-Register message carries information about a single Mu | ||||
lticast source and group.</t> | ||||
<t>This document defines a standard to send multiple Mult | ||||
icast source and group information in a single PIM message. This document refers | ||||
to the new messages as the PIM Packed Null-Register message and PIM Packed Regi | ||||
ster-Stop message.</t> | ||||
</abstract> | ||||
</front> | ||||
<middle> | ||||
<section title="Introduction"> | ||||
<t>The DR periodically sends PIM Null-Registers to keep t | ||||
he state of existing multicast sources active on the RP. As the number of multic | ||||
ast sources increases, the number of PIM Null-Register messages that are sent al | ||||
so increases. This results in more PIM packet processing at the RP and the DR.</ | ||||
t> | ||||
<t> | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ||||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" | ||||
std" consensus="true" ipr="trust200902" docName="draft-ietf-pim-null-register-pa | ||||
cking-16" number="9465" tocInclude="true" sortRefs="true" symRefs="true" updates | ||||
="" obsoletes="" xml:lang="en" version="3"> | ||||
<front> | ||||
<title abbrev="PIM Null-Register Packing">PIM Null-Register Packing</title> | ||||
<seriesInfo name="RFC" value="9465"/> | ||||
<author initials="V." surname="Kamath" fullname="Vikas Ramesh Kamath"> | ||||
<organization>VMware</organization> | ||||
<address> | ||||
<postal> | ||||
<street>3401 Hillview Ave</street> | ||||
<city>Palo Alto</city> | ||||
<region>CA</region> | ||||
<code>94304</code> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>vkamath@vmware.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="R." surname="Chokkanathapuram Sundaram" fullname="Ramakris | ||||
hnan Chokkanathapuram Sundaram"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
<address> | ||||
<postal> | ||||
<street>Tasman Drive</street> | ||||
<city>San Jose</city> | ||||
<region>CA</region> | ||||
<code>95134</code> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>ramaksun@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="R." surname="Banthia" fullname="Raunak Banthia"> | ||||
<organization>Apstra</organization> | ||||
<address> | ||||
<postal> | ||||
<extaddr>Suite 200</extaddr> | ||||
<street>333 Middlefield Rd</street> | ||||
<city>Menlo Park</city> | ||||
<region>CA</region> | ||||
<code>94025</code> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>rbanthia@apstra.com</email> | ||||
</address> | ||||
</author> | ||||
<author initials="A." surname="Gopal" fullname="Ananya Gopal"> | ||||
<organization>Cisco Systems, Inc.</organization> | ||||
<address> | ||||
<postal> | ||||
<street>Tasman Drive</street> | ||||
<city>San Jose</city> | ||||
<region>CA</region> | ||||
<code>95134</code> | ||||
<country>United States of America</country> | ||||
</postal> | ||||
<email>ananygop@cisco.com</email> | ||||
</address> | ||||
</author> | ||||
<date year="2023" month="September" /> | ||||
<area>rtg</area> | ||||
<workgroup>pim</workgroup> | ||||
<keyword>Multicast</keyword> | ||||
<abstract> | ||||
<t>In PIM Sparse Mode (PIM-SM) networks, PIM Null-Register messages are se | ||||
nt by the Designated Router (DR) to the Rendezvous Point (RP) to signal the pres | ||||
ence of multicast sources in the network. There are periodic PIM Null-Registers | ||||
sent from the DR to the RP to keep the state alive at the RP as long as the sour | ||||
ce is active. The PIM Null-Register message carries information about a single m | ||||
ulticast source and group.</t> | ||||
<t>This document defines a standard to send information about multiple multicast | ||||
sources and groups in a single PIM message. This document refers to the new mes | ||||
sages as the "PIM Packed Null-Register message" and "PIM Packed Register-Stop me | ||||
ssage".</t> | ||||
</abstract> | ||||
</front> | ||||
<middle> | ||||
<section anchor="sec1"> | ||||
<name>Introduction</name> | ||||
<t>The DR periodically sends PIM Null-Registers to keep the state of exist | ||||
ing multicast sources active on the RP. As the number of multicast sources incre | ||||
ases, the number of PIM Null-Register messages that are sent also increases. Thi | ||||
s results in more PIM packet processing at the RP and the DR.</t> | ||||
<t> | ||||
This document specifies a method to efficiently pack the content | This document specifies a method to efficiently pack the content | |||
of multiple PIM Null-Register and Register-Stop messages <xref target="RFC776 1"/> | of multiple PIM Null-Register and Register-Stop messages <xref target="RFC776 1"/> | |||
into a single message. | into a single message. | |||
</t> | </t> | |||
<t>The document also discusses interoperability between PIM routers that s | ||||
<t>The document also discusses interoperability between P | upport PIM Packed Null-Registers and PIM Packed Register-Stops and PIM routers t | |||
IM routers that support PIM Packed Null-Registers and PIM Packed Register-Stops | hat do not.</t> | |||
and PIM routers that do not.</t> | <section anchor="sec1.1"> | |||
<section title="Conventions used in this document"> | <name>Conventions Used in This Document</name> | |||
<t> | <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
"MAY", and "OPTIONAL" in this document are to be interpreted as | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document | |||
, and only when, they | are to be interpreted as described in BCP 14 <xref | |||
appear in all capitals, as shown here. | target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they | |||
</t> | appear in all capitals, as shown here.</t> | |||
</section> | </section> | |||
<section title="Terminology"> | <section anchor="sec1.2"> | |||
<t> | <name>Terminology</name> | |||
<list style="hanging"> | <dl newline="false" spacing="normal"> | |||
<t hangText="RP:">Rendezvous Poin | <dt>RP:</dt> | |||
t</t> | <dd>Rendezvous Point</dd> | |||
<t hangText="DR:">Designated Rout | <dt>DR:</dt> | |||
er</t> | <dd>Designated Router</dd> | |||
</list> | <dt>MSDP:</dt> | |||
</t> | <dd>Multicast Source Discovery Protocol</dd> | |||
</section> | <dt>PIM-SM:</dt> | |||
</section> | <dd>PIM Sparse Mode</dd> | |||
<section title="Packed Null-Register Packing Capability"> | </dl> | |||
<t> | </section> | |||
The RP indicates its ability to receive PIM Packed Null-Register messages (Secti | </section> | |||
on 3) and send PIM Packed Register-Stop messages (Section 4) with a Packing Capa | <section anchor="sec2"> | |||
bility bit (P-bit) in the PIM Register-Stop message. The P-bit is allocated in S | <name>Packing Capability</name> | |||
ection 9. | <t> | |||
</t> | The RP indicates its ability to receive PIM Packed Null-Register messages (<xref | |||
target="sec3"/>) and send PIM Packed Register-Stop messages (<xref target="sec4 | ||||
"/>) with a Packing Capability bit (P-bit) in the PIM Register-Stop message. The | ||||
P-bit is allocated in <xref target="sec9"/>. | ||||
</t> | ||||
<figure> | <figure> | |||
<artwork> | <name>PIM Register-Stop Message with Packing Capability 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|PIM Ver| Type |P|6 5 4 3 2 1 0| Checksum | | |PIM Ver| Type |7 6 5 4 3 2 1|P| Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Group Address (Encoded-Group format) | | | Group Address (Encoded-Group format) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Source Address (Encoded-Unicast format) | | | Source Address (Encoded-Unicast format) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: PIM Register-Stop message with Packing Capability option | ]]></artwork> | |||
</artwork> | </figure> | |||
</figure> | ||||
<t> The fields in the PIM Register-Stop message are defined in Section 4.9.4 of | ||||
<xref target="RFC7761" />, and the common header in <xref target='I-D.venaas-pi | ||||
m-rfc8736bis'/>. </t> | ||||
<t> Packing Capability bit (P-bit / Flag Bit TBD1): When set, it indicates the | ||||
ability of the RP to receive PIM Packed Null-Register messages, and send PIM Pac | ||||
ked Register-Stop messages. </t> | ||||
</section> | ||||
<section title="PIM Packed Null-Register message format"> | <t> The Group Address and Source Address fields in the PIM Register-Stop message | |||
<figure> | are defined in <xref target="RFC7761" sectionFormat="of" section="4.9.4"/>. The | |||
<artwork> | common header is defined in <xref target="RFC9436"/>. </t> | |||
<dl newline="false" spacing="normal"> | ||||
<dt>Packing Capability bit (P-bit; flag bit 0):</dt> | ||||
<dd>When set, it indicates the ability of the RP to receive PIM | ||||
Packed Null-Register messages and send PIM Packed Register-Stop | ||||
messages.</dd> | ||||
</dl> | ||||
</section> | ||||
<section anchor="sec3"> | ||||
<name>PIM Packed Null-Register Message Format</name> | ||||
<figure> | ||||
<name>PIM Packed Null-Register 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 |Subtype| FB | Checksum | | |PIM Ver| Type |Subtype| FB | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Group Address[1] (Encoded-Group format) | | | Group Address[1] (Encoded-Group format) | | |||
| Source Address[1] (Encoded-Unicast format) | | | Source Address[1] (Encoded-Unicast format) | | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
. Group Address[N] . | . Group Address[N] . | |||
| Source Address[N] | | | Source Address[N] | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: PIM Packed Null-Register message format | ]]></artwork> | |||
</artwork> | </figure> | |||
</figure> | ||||
<t> The fields in the PIM Packed Null-Reg | <t> The Group Address and Source Address fields in the PIM Packed Null-Register | |||
ister message are defined in Section | message are defined in | |||
4.9.4 of <xref target="RFC7761" />, and the common header in <xref target='I | <xref target="RFC7761" sectionFormat="of" section="4.9.4"/>. The | |||
-D.venaas-pim-rfc8736bis'/></t> | common header is defined in <xref target="RFC9436"/>.</t> | |||
<t> Type, Subtype: The PIM Packed Null-Re | ||||
gister Type value TBD2. <xref target='I-D.venaas-pim-rfc8736bis'/> </t> | ||||
<t>N: The total number of records; A reco | ||||
rd consists of a Group Address and Source Address pair.</t> | ||||
<t> After parsing the PIM common header, individual records are then pars | <dl spacing="normal" newline="false"> | |||
ed one by one until the length of the PIM Packed Null-Register message. This len | <dt>Type, Subtype:</dt> | |||
gth is inferred from the IP layer. | <dd>PIM Packed Null-Register (13.0).</dd> | |||
</t> | <dt>N:</dt> | |||
<dd>The total number of records; a record consists of a Group | ||||
Address and Source Address pair.</dd> | ||||
</dl> | ||||
<t> Sending or receiving a PIM Packed Null-Register message is the e | <t> After parsing the PIM common header, individual records are then | |||
quivalent, for all | parsed one by one until the end of the PIM Packed Null-Register | |||
purposes, of sending or receiving an individual Null-Register message for eac | message. This length is inferred from the IP layer. | |||
h record | </t> | |||
<t> Sending or receiving a PIM Packed Null-Register message has the equiva | ||||
lent effect of sending or receiving an individual Null-Register message for each | ||||
record | ||||
represented in the PIM Packed Null-Register message.</t> | represented in the PIM Packed Null-Register message.</t> | |||
</section> | ||||
<section anchor="sec4"> | ||||
<name>PIM Packed Register-Stop Message Format</name> | ||||
</section> | <figure> | |||
<section title="PIM Packed Register-Stop message format"> | <name>PIM Packed Register-Stop Message Format</name> | |||
<figure> | <artwork><![CDATA[ | |||
<artwork> | ||||
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 |Subtype| FB | Checksum | | |PIM Ver| Type |Subtype| FB | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Group Address[1] (Encoded-Group format) | | | Group Address[1] (Encoded-Group format) | | |||
| Source Address[1] (Encoded-Unicast format) | | | Source Address[1] (Encoded-Unicast format) | | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
. . | . . | |||
. Group Address[N] . | . Group Address[N] . | |||
| Source Address[N] | | | Source Address[N] | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 3: PIM Packed Register-Stop message format | ]]></artwork> | |||
</figure> | ||||
</artwork> | <t>The Group Address and Source Address fields in the PIM Packed | |||
</figure> | Register-Stop message are defined in <xref target="RFC7761" | |||
<t>The fields in the PIM Packed Register-Stop message are defined in Section 4.9 | sectionFormat="of" section="4.9.4"/>. The common header is defined in <xre | |||
.4 of <xref target="RFC7761" />, and the common header in <xref target='I-D.ven | f | |||
aas-pim-rfc8736bis'/> </t> | target="RFC9436"/>.</t> | |||
<t>Type, Subtype: The PIM Packed Register-Stop Type TBD3</t> | ||||
<t>N: The total number of records; A record consists of a Group Address and Sour | ||||
ce Address pair.</t> | ||||
<t> | ||||
After parsing the PIM common header, individual records are then | ||||
parsed one by one until the length of the PIM Packed Register-Stop message. Thi | ||||
s length is inferred from the IP layer. </t> | ||||
<t> Sending or receiving a PIM Packed Register-Stop message is the equ | <dl newline="false" spacing="normal"> | |||
ivalent, for all | <dt>Type, Subtype:</dt> | |||
purposes, of sending or receiving an individual Null-Register message for eac | <dd>PIM Packed Register-Stop (13.1).</dd> | |||
h record | <dt>N:</dt> | |||
<dd>The total number of records; a record consists of a Group Address | ||||
and Source Address pair.</dd> | ||||
</dl> | ||||
<t> After parsing the PIM common header, individual records are then | ||||
parsed one by one until the end of the PIM Packed Register-Stop | ||||
message. This length is inferred from the IP layer. </t> | ||||
<t> Sending or receiving a PIM Packed Register-Stop message has the equiva | ||||
lent effect of sending or receiving an individual Null-Register message for each | ||||
record | ||||
represented in the PIM Packed Register-Stop.</t> | represented in the PIM Packed Register-Stop.</t> | |||
</section> | ||||
<section title="Protocol operation"> | ||||
<t> | ||||
<t>As specified in <xref | ||||
target="RFC7761"/>, the DR sends PIM Register messages towards the RP when a new | ||||
source is detected. </t> | ||||
<t>When this feature is e | ||||
nabled/configured, an RP supporting this specification MUST set the P-bit (Flag | ||||
bit TBD1) in all Register-Stop messages. </t> | ||||
<t> | ||||
When a Register-S | ||||
top message with the P-bit set is received, the DR SHOULD send PIM Packed Null-R | ||||
egister messages (Section 3) to the RP instead of multiple Register messages wit | ||||
h the N-bit set <xref target="RFC7761"/>. | ||||
The DR MAY use a mixture of PIM Packed Null-Regi | ||||
ster messages and Register messages. The decision is up to the implementation an | ||||
d out of the scope of this document. However, it is RECOMMENDED to stick to the | ||||
PIM Packed Null-Register and PIM Packed Register-Stop formats as long as the RP | ||||
and DR have the feature enabled. | ||||
</t> | ||||
<t> The RP, after receivi | ||||
ng a PIM Packed Null-Register message, SHOULD start sending PIM Packed Register- | ||||
Stop messages (Section 4) to the corresponding DR instead of individual Register | ||||
-Stop messages. | ||||
The RP MAY use a mixture of PIM Packed Register-Stop | ||||
messages and individual Register-Stop messages. The decision is up to the imple | ||||
mentation and out of the scope of this document. However, it is RECOMMENDED to s | ||||
tick to the PIM Packed Null-Register and PIM Packed Register-Stop formats as lon | ||||
g as the RP and DR have the feature enabled. </t> | ||||
</t> | ||||
</section> | ||||
<section title="Operational Considerations"> | ||||
<section title="PIM Anycast RP Considerations"> | ||||
<t> | ||||
The PIM Packed Null-Register packet format should | ||||
be enabled only if it is supported by all the routers in the Anycast-RP set <xr | ||||
ef target="RFC4610" />. This consideration applies to PIM Anycast RP with MSDP < | ||||
xref target="RFC3446" /> as well. | ||||
</t> | ||||
</section> | ||||
<section title="Interoperability between different versions" > | ||||
<t> | ||||
A router (DR) can decide to use the PIM Packed Null-Register | ||||
message format based on the Packing Capability received from the RP as part of | ||||
the PIM Register-Stop. This ensures compatibility with routers that do not suppo | ||||
rt processing of the new packet format. The Packing Capability information MUST | ||||
be indicated by the RP via the PIM Register-Stop message sent to the DR. Thus, a | ||||
DR will switch to the new packet format only when it learns that the RP is capa | ||||
ble of handling the PIM Packed Null-Register messages. | ||||
</t> | ||||
<t> | ||||
Conversely, a DR that does not support the packed | ||||
format can continue generating the PIM Null-Register as defined in | ||||
<xref target="RFC7761" /> (Section 4.4). | ||||
</t> | ||||
</section> | ||||
<section title="Disabling PIM Packed Message Support at RP and/or DR | ||||
" > | ||||
<t> Consider a PIM RP router that supports PIM Packed Null-Regis | ||||
ters and PIM Packed Register-Stops. In scenarios where this router now no longer | ||||
supports this feature, for example, in case of a software downgrade, it will no | ||||
t send a PIM Register-Stop message to the DR in response to a PIM Packed Null-Re | ||||
gister message. | ||||
</t> | ||||
<t> When the DR switches to Data Registers from Null-Registers, | ||||
it MUST start a Packed_Register_Probe_Time timer. If no PIM Packed Register-Stop | ||||
or Register-Stop with the P-bit set is received within Packed_Register_Probe_Ti | ||||
me seconds, the DR can decide that the RP no longer supports PIM Packed Null-Reg | ||||
isters. The Packed_Register_Probe_Time timer is configurable; its default value | ||||
is 60 seconds. | ||||
</t> | ||||
<t> When Packed_Register_Probe_Time expires, The DR MAY also sen | ||||
d an unpacked PIM Null-Register and check the PIM Register-Stop to see if the P- | ||||
bit is set or not. If it is not set then the DR will continue sending unpacked P | ||||
IM Null-Register messages.</t> | ||||
<t>In case the network manager disables the Packing Capab | ||||
ility at the RP, or in other words, disables the feature from the RP, the router | ||||
MUST NOT advertise the Packing Capability. However, an implementation MAY choos | ||||
e to still parse any packed registers if they are received. This may be particul | ||||
arly useful in the transitional period after the network manager disables it.</t | ||||
> | ||||
</section> | ||||
</section> | </section> | |||
<section title="Fragmentation Considerations"> | <section anchor="sec5"> | |||
<t> | <name>Protocol Operation</name> | |||
<t>As specified in <xref target="RFC7761"/>, the DR sends PIM Register mes | ||||
sages towards the RP when a new source is detected. </t> | ||||
<t>When this feature is enabled/configured, an RP supporting this specific | ||||
ation <bcp14>MUST</bcp14> set the P-bit (flag bit 0) in all Register-Stop messag | ||||
es. </t> | ||||
<t>When a Register-Stop message with the P-bit set is received, the DR | ||||
<bcp14>SHOULD</bcp14> send PIM Packed Null-Register messages (<xref | ||||
target="sec3"/>) to the RP instead of multiple Register messages with | ||||
the N-bit set <xref target="RFC7761"/>. The DR <bcp14>MAY</bcp14> use a | ||||
mixture of PIM Packed Null-Register messages and Register messages. The | ||||
decision is up to the implementation and out of the scope of this | ||||
document. However, it is <bcp14>RECOMMENDED</bcp14> to stick to the PIM | ||||
Packed Null-Register and PIM Packed Register-Stop formats as long as the | ||||
RP and DR have the feature enabled. </t> | ||||
<t>After receiving a PIM Packed Null-Register message, the RP | ||||
<bcp14>SHOULD</bcp14> start sending PIM Packed Register-Stop messages | ||||
(<xref target="sec4"/>) to the corresponding DR instead of individual | ||||
Register-Stop messages. The RP <bcp14>MAY</bcp14> use a mixture of PIM | ||||
Packed Register-Stop messages and individual Register-Stop messages. The | ||||
decision is up to the implementation and out of the scope of this | ||||
document. However, it is <bcp14>RECOMMENDED</bcp14> to stick to the PIM | ||||
Packed Null-Register and PIM Packed Register-Stop formats as long as the | ||||
RP and DR have the feature enabled. </t> | ||||
</section> | ||||
<section anchor="sec6"> | ||||
<name>Operational Considerations</name> | ||||
<section anchor="sec6.1"> | ||||
<name>PIM Anycast RP Considerations</name> | ||||
<t>The PIM Packed Null-Register packet format should be enabled only | ||||
if it is supported by all the routers in the Anycast-RP set <xref | ||||
target="RFC4610"/>. This consideration applies to PIM Anycast RP with | ||||
Multicast Source Discovery Protocol (MSDP) <xref target="RFC3446"/> as | ||||
well. | ||||
</t> | ||||
</section> | ||||
<section anchor="sec6.2"> | ||||
<name>Interoperability between Different Versions</name> | ||||
<t> A router (DR) can decide to use the PIM Packed Null-Register | ||||
message format based on the Packing Capability received from the RP as | ||||
part of the PIM Register-Stop. This ensures compatibility with routers | ||||
that do not support processing of the new packet format. The Packing | ||||
Capability information <bcp14>MUST</bcp14> be indicated by the RP via | ||||
the PIM Register-Stop message sent to the DR. Thus, a DR will switch | ||||
to the new packet format only when it learns that the RP is capable of | ||||
handling the PIM Packed Null-Register messages. | ||||
</t> | ||||
<t>Conversely, a DR that does not support the packed format can | ||||
continue generating the PIM Null-Register as defined in <xref | ||||
target="RFC7761" sectionFormat="of" section="4.4"/>. | ||||
</t> | ||||
</section> | ||||
<section anchor="sec6.3"> | ||||
<name>Disabling PIM Packed Message Support at RP and/or DR</name> | ||||
<t> Consider a PIM RP router that supports PIM Packed Null-Registers and | ||||
PIM Packed Register-Stops. In scenarios where this router no longer supports th | ||||
is feature, for example, in case of a software downgrade, it will not send a PIM | ||||
Register-Stop message to the DR in response to a PIM Packed Null-Register messa | ||||
ge. | ||||
</t> | ||||
<t> When the DR switches to Data Registers from Null-Registers, it <bcp1 | ||||
4>MUST</bcp14> start a Packed_Register_Probe_Time timer. If no PIM Packed Regist | ||||
er-Stop or Register-Stop with the P-bit set is received within Packed_Register_P | ||||
robe_Time seconds, the DR can decide that the RP no longer supports PIM Packed N | ||||
ull-Registers. The Packed_Register_Probe_Time timer is configurable; its default | ||||
value is 60 seconds. | ||||
As explained in Section 4.4.1 of <xref target="RFC7761" />, the DR may perfo | </t> | |||
rm Path | <t> When Packed_Register_Probe_Time expires, the DR <bcp14>MAY</bcp14> a | |||
MTU Discovery to the RP before sending PIM Packed Null-Register | lso send an unpacked PIM Null-Register and check the PIM Register-Stop to see if | |||
messages. Similarly, the RP may perform Path MTU Discovery to the | the P-bit is set or not. If it is not set, then the DR will continue sending un | |||
DR before sending PIM Packed Register-Stop messages. In both cases, | packed PIM Null-Register messages.</t> | |||
the number of records in a message should be limited such that it | <t>In case the network manager disables the Packing Capability at the RP | |||
can fit within the Path MTU. | (or in other words, disables the feature from the RP), the router <bcp14>MUST N | |||
</t> | OT</bcp14> advertise the Packing Capability. However, an implementation <bcp14>M | |||
AY</bcp14> choose to still parse any packed registers if they are received. This | ||||
may be particularly useful in the transitional period after the network manager | ||||
disables it.</t> | ||||
</section> | ||||
</section> | ||||
<section anchor="sec7"> | ||||
<name>Fragmentation Considerations</name> | ||||
<t> As explained in <xref target="RFC7761" sectionFormat="of" | ||||
section="4.4.1"/>, the DR may perform Path MTU Discovery to the RP | ||||
before sending PIM Packed Null-Register messages. Similarly, the RP may | ||||
perform Path MTU Discovery to the DR before sending PIM Packed | ||||
Register-Stop messages. In both cases, the number of records in a | ||||
message should be limited such that it can fit within the Path MTU. | ||||
</t> | ||||
</section> | ||||
<section anchor="sec8"> | ||||
<name>Security Considerations</name> | ||||
<t> The Security Considerations in <xref target="RFC7761"/> apply to | ||||
this document. In particular, the effect of forging a PIM Packed | ||||
Null-Register or Register-Stop message would be amplified to all the | ||||
records included instead of just one.</t> | ||||
<t> By forging a PIM Register-Stop message and setting the P-bit, an | ||||
attacker can trigger the use of PIM Packed Null-Register messages by a | ||||
DR, thus creating unnecessary churn in the network.</t> | ||||
</section> | ||||
<section anchor="sec9"> | ||||
<name>IANA Considerations</name> | ||||
<t> IANA has assigned a Packing | ||||
Capability bit (0) in the PIM Register-Stop common header in the | ||||
"PIM Message Types" registry.</t> | ||||
<t> IANA has assigned a PIM | ||||
message type (13.0) for PIM Packed Null-Register in the "PIM | ||||
Message Types" registry. Flag bits 0-3 for this message type | ||||
are "Unassigned".</t> | ||||
<t> IANA has assigned a PIM | ||||
message type (13.1) for PIM Packed Register-Stop in the "PIM | ||||
Message Types" registry. The flag bits 0-3 for this message type | ||||
are "Unassigned". </t> | ||||
</section> | ||||
</middle> | ||||
<back> | ||||
<references anchor="norm-ref"> | ||||
<name>Normative References</name> | ||||
</section> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211 | |||
<section title="Security Considerations"> | 9.xml"/> | |||
<t> The Security Considerations from <xref target="RFC7 | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817 | |||
761" /> apply to this document. In | 4.xml"/> | |||
particular, the effect of forging a PIM Packed Null-Register or | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.776 | |||
Register-Stop message would be amplified to all the records included instead | 1.xml"/> | |||
of just one. | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.461 | |||
</t> | 0.xml"/> | |||
<t> By forging a PIM Register-Stop message and setting th | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.943 | |||
e P-bit, | 6.xml"/> | |||
an attacker can trigger the use of PIM Packed Null-Register | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.344 | |||
messages by a DR thus creating unnecessary churn in the network. | 6.xml"/> | |||
</t> | </references> | |||
</section> | ||||
<section title="IANA Considerations"> | ||||
<t> When this document is published, IANA is asked to ass | <section anchor="ack" numbered="false" toc="default"> | |||
ign a Packing Capability bit (TBD1) in the PIM Register-Stop Common Header from | <name>Acknowledgments</name> | |||
the PIM Message Types registry. | <t>The authors would like to thank <contact fullname="Stig Venaas"/>, | |||
</t> | <contact fullname="Alvaro Retana"/>, <contact fullname="Anish Peter"/>, | |||
<t> When this document is published, IANA is asked to ass | <contact fullname="Zheng Zhang"/>, and <contact fullname="Umesh Dudani"/> | |||
ign a PIM message type (TBD2) for the PIM Packed Null-Register from the PIM Mess | for their helpful comments on the document.</t> | |||
age Types registry. The Flag Bits (0-3) for PIM message type (TBD2) are requeste | </section> | |||
d to be "Unassigned". </t> | ||||
<t> When this document is published, IANA is asked to ass | ||||
ign a PIM message type (TBD3) for the PIM Packed Register-Stop from the PIM Mess | ||||
age Types registry. The Flag Bits (0-3) for PIM message type (TBD3) are requeste | ||||
d to be "Unassigned". </t> | ||||
</section> | ||||
<section title="Acknowledgments"> | ||||
<t>The authors would like to thank Stig Venaas, Alvaro Re | ||||
tana, Anish Peter, Zheng Zhang and Umesh Dudani for their helpful comments on th | ||||
e document.</t> | ||||
</section> | ||||
</middle> | ||||
<back> | ||||
<references title="Normative References"> | ||||
<?rfc include='reference.RFC.2119' ?> | </back> | |||
<?rfc include='reference.RFC.8174' ?> | ||||
<?rfc include='reference.RFC.7761' ?> | ||||
<?rfc include='reference.RFC.4610' ?> | ||||
<?rfc include="reference.I-D.venaas-pim-rfc8736bis.xml"?> | ||||
<?rfc include='reference.RFC.3446' ?> | ||||
</references> | ||||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 22 change blocks. | ||||
325 lines changed or deleted | 339 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |