<?xml version="1.0" encoding="UTF-8"?> <!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-packing-16"> <?rfc toc="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?>docName="draft-ietf-pim-null-register-packing-16" number="9465" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3"> <front> <title abbrev="PIM Null-Registerpacking">PIMPacking">PIM Null-Registerpacking</title>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><code>CA 94304</code> <country>USA</country><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="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><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 MiddlefieldRd STE 200</street>Rd</street> <city>Menlo Park</city><code>CA 94025</code> <country>USA</country><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><code>CA 95134</code> <country>USA</country><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>Routing</area><area>rtg</area> <workgroup>pim</workgroup> <keyword>Multicast</keyword> <abstract> <t>InPIM-SMPIM Sparse Mode (PIM-SM) networks, PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence ofMulticastmulticast 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 source is active. The PIM Null-Register message carries information about a singleMulticastmulticast source and group.</t> <t>This document defines a standard to send information about multipleMulticast sourcemulticast sources andgroup informationgroups in a single PIM message. This document refers to the new messages as thePIM"PIM Packed Null-Registermessagemessage" andPIM"PIM Packed Register-Stopmessage.</t>message".</t> </abstract> </front> <middle> <sectiontitle="Introduction">anchor="sec1"> <name>Introduction</name> <t>The DR periodically sends PIM Null-Registers to keep the state of existing multicast sources active on the RP. As the number of multicast sources increases, the number of PIM Null-Register messages that are sent also increases. This results in more PIM packet processing at the RP and the DR.</t> <t> This document specifies a method to efficiently pack the content of multiple PIM Null-Register and Register-Stop messages <xref target="RFC7761"/> into a single message. </t> <t>The document also discusses interoperability between PIM routers that support PIM Packed Null-Registers and PIM Packed Register-Stops and PIM routers that do not.</t> <sectiontitle="Conventions usedanchor="sec1.1"> <name>Conventions Used inthis document">This Document</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere. </t>here.</t> </section> <sectiontitle="Terminology"> <t> <list style="hanging"> <t hangText="RP:">Rendezvous Point</t> <t hangText="DR:">Designated Router</t> </list> </t>anchor="sec1.2"> <name>Terminology</name> <dl newline="false" spacing="normal"> <dt>RP:</dt> <dd>Rendezvous Point</dd> <dt>DR:</dt> <dd>Designated Router</dd> <dt>MSDP:</dt> <dd>Multicast Source Discovery Protocol</dd> <dt>PIM-SM:</dt> <dd>PIM Sparse Mode</dd> </dl> </section> </section> <sectiontitle="Packed Null-Register Packing Capability">anchor="sec2"> <name>Packing Capability</name> <t> The RP indicates its ability to receive PIM Packed Null-Register messages(Section 3)(<xref target="sec3"/>) and send PIM Packed Register-Stop messages(Section 4)(<xref target="sec4"/>) with a Packing Capability bit (P-bit) in the PIM Register-Stop message. The P-bit is allocated inSection 9.<xref target="sec9"/>. </t> <figure><artwork><name>PIM Register-Stop Message with Packing Capability Option</name> <artwork><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type|P|6|7 6 5 4 3 21 0|1|P| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address (Encoded-Group format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: PIM Register-Stop message with Packing Capability option </artwork>]]></artwork> </figure> <t> The Group Address and Source Address fields in the PIM Register-Stop message are defined inSection 4.9.4 of<xref target="RFC7761"/>, and thesectionFormat="of" section="4.9.4"/>. The common header is defined in <xreftarget='I-D.venaas-pim-rfc8736bis'/>.target="RFC9436"/>. </t><t> Packing<dl newline="false" spacing="normal"> <dt>Packing Capability bit(P-bit / Flag Bit TBD1): When(P-bit; flag bit 0):</dt> <dd>When set, it indicates the ability of the RP to receive PIM Packed Null-Registermessages,messages and send PIM Packed Register-Stopmessages. </t>messages.</dd> </dl> </section> <sectiontitle="PIManchor="sec3"> <name>PIM Packed Null-Registermessage format">Message Format</name> <figure><artwork><name>PIM Packed Null-Register Message Format</name> <artwork><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |Subtype| FB | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address[1] (Encoded-Group format) | | Source Address[1] (Encoded-Unicast format) | . . . . . . . . . Group Address[N] . | Source Address[N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: PIM Packed Null-Register message format </artwork>]]></artwork> </figure> <t> The Group Address and Source Address fields in the PIM Packed Null-Register message are defined inSection 4.9.4 of<xref target="RFC7761"/>, and thesectionFormat="of" section="4.9.4"/>. The common header is defined in <xreftarget='I-D.venaas-pim-rfc8736bis'/></t> <t> Type, Subtype: The PIMtarget="RFC9436"/>.</t> <dl spacing="normal" newline="false"> <dt>Type, Subtype:</dt> <dd>PIM Packed Null-RegisterType value TBD2. <xref target='I-D.venaas-pim-rfc8736bis'/> </t> <t>N: The(13.0).</dd> <dt>N:</dt> <dd>The total number of records;Aa record consists of a Group Address and Source Addresspair.</t>pair.</dd> </dl> <t> After parsing the PIM common header, individual records are then parsed one by one until thelengthend of the PIM Packed Null-Register message. This length is inferred from the IP layer. </t> <t> Sending or receiving a PIM Packed Null-Register messageishas theequivalent, for all purposes,equivalent effect of sending or receiving an individual Null-Register message for each record represented in the PIM Packed Null-Register message.</t> </section> <sectiontitle="PIManchor="sec4"> <name>PIM Packed Register-Stopmessage format">Message Format</name> <figure><artwork><name>PIM Packed Register-Stop Message Format</name> <artwork><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |Subtype| FB | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address[1] (Encoded-Group format) | | Source Address[1] (Encoded-Unicast format) | . . . . . . . . . Group Address[N] . | Source Address[N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: PIM Packed Register-Stop message format </artwork>]]></artwork> </figure> <t>The Group Address and Source Address fields in the PIM Packed Register-Stop message are defined inSection 4.9.4 of<xref target="RFC7761"/>, and thesectionFormat="of" section="4.9.4"/>. The common header is defined in <xreftarget='I-D.venaas-pim-rfc8736bis'/> </t> <t>Type, Subtype: The PIMtarget="RFC9436"/>.</t> <dl newline="false" spacing="normal"> <dt>Type, Subtype:</dt> <dd>PIM Packed Register-StopType TBD3</t> <t>N: The(13.1).</dd> <dt>N:</dt> <dd>The total number of records;Aa record consists of a Group Address and Source Addresspair.</t>pair.</dd> </dl> <t> After parsing the PIM common header, individual records are then parsed one by one until thelengthend 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 messageishas theequivalent, for all purposes,equivalent effect of sending or receiving an individual Null-Register message for each record represented in the PIM Packed Register-Stop.</t> </section> <sectiontitle="Protocol operation"> <t>anchor="sec5"> <name>Protocol Operation</name> <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 enabled/configured, an RP supporting this specificationMUST<bcp14>MUST</bcp14> set the P-bit(Flag(flag bitTBD1)0) in all Register-Stop messages. </t><t> When<t>When a Register-Stop message with the P-bit set is received, the DRSHOULD<bcp14>SHOULD</bcp14> send PIM Packed Null-Register messages(Section 3)(<xref target="sec3"/>) to the RP instead of multiple Register messages with the N-bit set <xref target="RFC7761"/>. The DRMAY<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 isRECOMMENDED<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> The RP, after<t>After receiving a PIM Packed Null-Register message,SHOULDthe RP <bcp14>SHOULD</bcp14> start sending PIM Packed Register-Stop messages(Section 4)(<xref target="sec4"/>) to the corresponding DR instead of individual Register-Stop messages. The RPMAY<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 isRECOMMENDED<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></section> <sectiontitle="Operational Considerations">anchor="sec6"> <name>Operational Considerations</name> <sectiontitle="PIManchor="sec6.1"> <name>PIM Anycast RPConsiderations"> <t> TheConsiderations</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 <xreftarget="RFC4610" />.target="RFC4610"/>. This consideration applies to PIM Anycast RP withMSDPMulticast Source Discovery Protocol (MSDP) <xreftarget="RFC3446" />target="RFC3446"/> as well. </t> </section> <sectiontitle="Interoperabilityanchor="sec6.2"> <name>Interoperability betweendifferent versions" >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 informationMUST<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,<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).sectionFormat="of" section="4.4"/>. </t> </section> <sectiontitle="Disablinganchor="sec6.3"> <name>Disabling PIM Packed Message Support at RP and/orDR" >DR</name> <t> Consider a PIM RP router that supports PIM Packed Null-Registers and PIM Packed Register-Stops. In scenarios where this routernowno longer supports this 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 message. </t> <t> When the DR switches to Data Registers from Null-Registers, itMUST<bcp14>MUST</bcp14> 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_Time seconds, the DR can decide that the RP no longer supports PIM Packed Null-Registers. The Packed_Register_Probe_Time timer is configurable; its default value is 60 seconds. </t> <t> When Packed_Register_Probe_Time expires,Thethe DRMAY<bcp14>MAY</bcp14> also send an unpacked PIM Null-Register and check the PIM Register-Stop to see if the P-bit is set or not. If it is notsetset, then the DR will continue sending unpacked PIM Null-Register messages.</t> <t>In case the network manager disables the Packing Capability at theRP, orRP (or in other words, disables the feature from theRP,RP), the routerMUST NOT<bcp14>MUST NOT</bcp14> advertise the Packing Capability. However, an implementationMAY<bcp14>MAY</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> <sectiontitle="Fragmentation Considerations">anchor="sec7"> <name>Fragmentation Considerations</name> <t> As explained inSection 4.4.1 of<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> <sectiontitle="Security Considerations">anchor="sec8"> <name>Security Considerations</name> <t> The Security Considerationsfromin <xreftarget="RFC7761" />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 justone. </t>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 aDRDR, thus creating unnecessary churn in thenetwork. </t>network.</t> </section> <sectiontitle="IANA Considerations">anchor="sec9"> <name>IANA Considerations</name> <t>When this document is published,IANAis asked to assignhas assigned a Packing Capability bit(TBD1)(0) in the PIM Register-StopCommon Header fromcommon header in thePIM"PIM MessageTypes registry. </t>Types" registry.</t> <t>When this document is published,IANAis asked to assignhas assigned a PIM message type(TBD2)(13.0) forthePIM Packed Null-Registerfromin thePIM"PIM MessageTypesTypes" registry.TheFlagBits (0-3)bits 0-3 forPIMthis message type(TBD2)arerequested to be "Unassigned". </t>"Unassigned".</t> <t>When this document is published,IANAis asked to assignhas assigned a PIM message type(TBD3)(13.1) forthePIM Packed Register-Stopfromin thePIM"PIM MessageTypesTypes" registry. TheFlag Bits (0-3)flag bits 0-3 forPIMthis message type(TBD3)arerequested to be"Unassigned". </t> </section> </middle> <back> <references anchor="norm-ref"> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9436.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3446.xml"/> </references> <sectiontitle="Acknowledgments">anchor="ack" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to thankStig Venaas, Alvaro Retana, Anish Peter, Zheng Zhang and Umesh Dudani<contact fullname="Stig Venaas"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Anish Peter"/>, <contact fullname="Zheng Zhang"/>, and <contact fullname="Umesh Dudani"/> for their helpful comments on the document.</t> </section></middle> <back> <references title="Normative References"> <?rfc include='reference.RFC.2119' ?> <?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>