rfc9466.original   rfc9466.txt 
PIM Y. Liu, Ed. Internet Engineering Task Force (IETF) Y. Liu, Ed.
Internet-Draft China Mobile Request for Comments: 9466 China Mobile
Intended status: Standards Track T. Eckert, Ed. Category: Standards Track T. Eckert, Ed.
Expires: 21 October 2023 M. McBride ISSN: 2070-1721 M. McBride
Futurewei Futurewei
Z. Zhang Z. Zhang
ZTE Corporation ZTE Corporation
19 April 2023 October 2023
PIM Assert Message Packing PIM Assert Message Packing
draft-ietf-pim-assert-packing-12
Abstract Abstract
In PIM-SM shared LAN networks, there is often more than one upstream When PIM Sparse Mode (PIM-SM), including PIM Source-Specific
router. When PIM Sparse Mode (PIM-SM), including PIM Source Multicast (PIM-SSM), is used in shared LAN networks, there is often
Specific-Specific Multicast (PIM-SSM), is used, this can lead to more than one upstream router. This can lead to duplicate IP
duplicate IP multicast packets being forwarded by these PIM routers. multicast packets being forwarded by these PIM routers. PIM Assert
PIM Assert messages are used to elect a single forwarder for each IP messages are used to elect a single forwarder for each IP multicast
multicast traffic flow between these routers. traffic flow between these routers.
This document defines a mechanism to send and receive information for This document defines a mechanism to send and receive information for
multiple IP multicast flows in a single PackedAssert message. This multiple IP multicast flows in a single PackedAssert message. This
optimization reduces the total number of PIM packets on the LAN and optimization reduces the total number of PIM packets on the LAN and
can therefore speed up the election of the single forwarder, reducing can therefore speed up the election of the single forwarder, reducing
the number of duplicate IP multicast packets incurred. the number of duplicate IP multicast packets incurred.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 October 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9466.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Specification
3.1. PIM Assert Packing Hello Option . . . . . . . . . . . . . 5 3.1. PIM Packed Assert Capability Hello Option
3.2. Assert Packing Message Formats . . . . . . . . . . . . . 5 3.2. Assert Packing Message Formats
3.3. PackedAssert Mechanism . . . . . . . . . . . . . . . . . 6 3.3. PackedAssert Mechanism
3.3.1. Sending PackedAssert messages . . . . . . . . . . . . 7 3.3.1. Sending PackedAssert Messages
3.3.1.1. Handling of reception-triggered assert 3.3.1.1. Handling of Reception-Triggered Assert Records
records. . . . . . . . . . . . . . . . . . . . . . 8 3.3.1.2. Handling of Timer Expiry-Triggered Assert Records
3.3.1.2. Handling of timer expiry-triggered assert 3.3.1.3. Beneficial Delay in Sending PackedAssert Messages
records. . . . . . . . . . . . . . . . . . . . . . 9 3.3.1.4. Handling Assert/PackedAssert Message Loss
3.3.1.3. Beneficial delay in sending PackedAssert 3.3.1.5. Optimal Degree of Assert Record Packing
messages . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Receiving PackedAssert Messages
3.3.1.4. Handling Assert/PackedAssert message loss . . . . 9 4. Packet Formats
3.3.1.5. Optimal degree of assert record packing . . . . . 10 4.1. PIM Packed Assert Capability Hello Option
3.3.2. Receiving PackedAssert messages . . . . . . . . . . . 10 4.2. Assert Message Format
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Simple PackedAssert Message Format
4.1. PIM Assert Packing Hello Option . . . . . . . . . . . . . 10 4.4. Aggregated PackedAssert Message Format
4.2. Assert Message Format . . . . . . . . . . . . . . . . . . 11 4.4.1. Source Aggregated Assert Record
4.3. Simple PackedAssert Message Format . . . . . . . . . . . 11 4.4.2. RP Aggregated Assert Record
4.4. Aggregated PackedAssert Message Format . . . . . . . . . 13 5. IANA Considerations
4.4.1. Source Aggregated Assert Record . . . . . . . . . . . 15 6. Security Considerations
4.4.2. RP Aggregated Assert Record . . . . . . . . . . . . . 16 7. References
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Use Case Examples
8. Working Group considerations . . . . . . . . . . . . . . . . 19 A.1. Enterprise Network
8.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. Video Surveillance
8.2. Changelog . . . . . . . . . . . . . . . . . . . . . . . . 19 A.3. Financial Services
8.2.1. draft-ietf-pim-assert-packing-12 . . . . . . . . . . 19 A.4. IPTV Broadcast Video
8.2.2. draft-ietf-pim-assert-packing-11 . . . . . . . . . . 19 A.5. MVPN MDT
8.2.3. draft-ietf-pim-assert-packing-10 . . . . . . . . . . 20 A.6. Special L2 Services
8.2.4. draft-ietf-pim-assert-packing-09 . . . . . . . . . . 20 Acknowledgments
8.2.5. draft-ietf-pim-assert-packing-08 . . . . . . . . . . 21 Authors' Addresses
8.2.6. draft-ietf-pim-assert-packing-07 . . . . . . . . . . 21
8.2.7. draft-ietf-pim-assert-packing-06 . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Use case examples . . . . . . . . . . . . . . . . . 23
A.1. Enterprise network . . . . . . . . . . . . . . . . . . . 24
A.2. Video surveillance . . . . . . . . . . . . . . . . . . . 24
A.3. Financial Services . . . . . . . . . . . . . . . . . . . 24
A.4. IPTV broadcast Video . . . . . . . . . . . . . . . . . . 24
A.5. MVPN MDT . . . . . . . . . . . . . . . . . . . . . . . . 24
A.6. Special L2 services . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In PIM-SM shared LAN networks, there is typically more than one When PIM-SM is used in shared LAN networks, there is typically more
upstream router. When duplicate data packets appear on the LAN, from than one upstream router. When duplicate data packets appear on the
different upstream routers, assert packets are sent from these LAN from different upstream routers, assert packets are sent from
routers to elect a single forwarder according to [RFC7761]. The PIM these routers to elect a single forwarder according to [RFC7761].
assert messages are sent periodically to keep the assert state. The The PIM Assert messages are sent periodically to keep the Assert
PIM assert message carries information about a single multicast state. The PIM Assert message carries information about a single
source and group, along with the corresponding metric-preference and multicast source and group, along with the corresponding Metric and
metric of the route towards the source or PIM Rendezvous Point (RP). Metric Preference of the route towards the source or PIM Rendezvous
Point (RP).
This document defines a mechanism to encode the information of This document defines a mechanism to encode the information of
multiple PIM Assert messages into a single PackedAssert message. multiple PIM Assert messages into a single PackedAssert message.
This allows to send and receive information for multiple IP multicast This allows sending and receiving information for multiple IP
flows in a single PackedAssert message without changing the PIM multicast flows in a single PackedAssert message without changing the
Assert state machinery. It reduces the total number of PIM packets PIM Assert state machinery. It reduces the total number of PIM
on the LAN and can therefore speed up the election of the single packets on the LAN and can therefore speed up the election of the
forwarder, reducing the number of duplicate IP multicast packets. single forwarder, reducing the number of duplicate IP multicast
This can particularly be helpful when there is traffic for a large packets. This can be particularly helpful when there is traffic for
number of multicast groups or SSM channels and PIM packet processing a large number of multicast groups or SSM channels and PIM packet
performance of the routers is slow. processing performance of the routers is slow.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
The reader is expected to be familiar with the terminology of The reader is expected to be familiar with the terminology of
[RFC7761]. The following lists the abbreviations repeated in this [RFC7761]. The following lists the abbreviations repeated in this
document. document.
AT: Assert Timer AT: Assert Timer
RP: Rendezvous Point DR: Designated Router
RPF: Reverse Path Forwarding RP: Rendezvous Point
SPT: Shortest Path Tree RPF: Reverse Path Forwarding
RPT: RP Tree RPT: RP Tree
DR: Designated Router SPT: Shortest Path Tree
2. Problem Statement 2. Problem Statement
PIM Asserts occur in many deployments. See Appendix A for explicit PIM Asserts occur in many deployments. See Appendix A for explicit
examples and explanations of why it is often not possible to avoid. examples and explanations of why it is often not possible to avoid.
PIM assert state depends mainly on the network topology. As long as PIM Assert state depends mainly on the network topology. As long as
there is a layer 2 network with more than 2 PIM routers, there may be there is a Layer 2 (L2) network with more than two PIM routers, there
multiple upstream routers, which can cause duplicate multicast may be multiple upstream routers, which can cause duplicate multicast
traffic to be forwarded and assert process to occur. traffic to be forwarded and assert processing to occur.
As the multicast services become widely deployed, the number of As the multicast services become widely deployed, the number of
multicast entries increases, and a large number of assert messages multicast entries increases, and a large number of Assert messages
may be sent in a very short period when multicast data packets may be sent in a very short period when multicast data packets
trigger PIM assert processing in the shared LAN networks. The PIM trigger PIM assert processing in the shared LAN networks. The PIM
routers need to process a large number of PIM assert small packets in 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 large. The a very short time. As a result, the device load is very large. The
assert packet may not be processed in time or even discarded, thus assert packet may not be processed in time or even discarded, thus
extending the time of traffic duplication in the network. extending the time of traffic duplication in the network.
The PIM Assert mechanism can only be avoided by designing the network The PIM Assert mechanism can only be avoided by designing the network
to be without transit subnets with multiple upstream routers. For to be without transit subnets with multiple upstream routers. For
example, an L2 ring between routers can sometimes be reconfigured to example, an L2 ring between routers can sometimes be reconfigured to
be a ring of point-to-point subnets connected by the routers. These be a ring of point-to-point subnets connected by the routers.
L2/L3 topology changes are undesirable though, when they are only However, these Layer 2 (L2) and Layer 3 (L3) topology changes are
done to enable IP multicast with PIM because they increase the cost undesirable when they are only done to enable IP multicast with PIM
of introducing IP multicast with PIM. because they increase the cost of introducing IP multicast with PIM.
These designs are also not feasible when specific L2 technologies are These designs are also not feasible when specific L2 technologies are
needed. For example various L2 technologies for rings provide sub 50 needed. For example, various L2 technologies for rings provide
msec failover mechanisms, something not possible equally with an L3 sub-50 msec failover mechanisms, something not possible equally with
subnet based ring. Likewise, IEEE Time Sensitive Networking a ring composed from L3 subnets. Likewise, IEEE Time-Sensitive
mechanisms would require an L2 topology that can not simply be Networking mechanisms would require an L2 topology that cannot simply
replaced by an L3 topology. L2 sub-topologies can also significantly be replaced by an L3 topology. L2 sub-topologies can also
reduce the cost of deployment. significantly reduce the cost of deployment.
3. Specification 3. Specification
This document defines three elements in support of PIM assert This document defines three elements in support of PIM assert
packing: packing:
1. The PIM Assert Packing Hello Option. 1. The PIM Packed Assert Capability Hello Option
2. The encoding of PackedAssert messages. 2. The encoding of PackedAssert messages
3. How to send and receive PackedAssert messages. 3. How to send and receive PackedAssert messages
3.1. PIM Assert Packing Hello Option 3.1. PIM Packed Assert Capability Hello Option
The PIM Assert Packing Hello Option (Section 4.1) is used to announce The PIM Packed Assert Capability Hello Option (Section 4.1) is used
support for the assert packing mechanisms specified in this document. to announce support for the assert packing mechanisms specified in
PackedAssert messages (Section 3.2) MUST NOT be used unless all PIM this document. PackedAssert messages (Section 3.2) MUST NOT be used
routers in the same subnet announce this option. unless all PIM routers in the same subnet announce this option.
3.2. Assert Packing Message Formats 3.2. Assert Packing Message Formats
The PIM Assert message, as defined in Section 4.9.6 of [RFC7761], The PIM Assert message, as defined in Section 4.9.6 of [RFC7761],
describes the parameters of a (*,G) or (S,G) assert through the describes the parameters of a (*,G) or (S,G) assert using the
following information elements: Rendezvous Point Tree flag (R), following information elements: Rendezvous Point Tree flag (R),
Source Address, Group Address, Metric and Metric Preference. This Source Address, Group Address, Metric, and Metric Preference. This
document calls this information an assert record. document calls this information an "assert record".
Assert packing introduces two new PIM Assert message encodings This document introduces two new PIM Assert message encodings through
through the allocation and use of two flags in the PIM Assert message the allocation and use of two flags in the PIM Assert message header
header [I-D.ietf-pim-rfc8736bis], the Packed (P) and the Aggregated [RFC9436]: the Packed (P) and the Aggregated (A) flags.
(A) flags.
If the (P)acked flag is 0, the message is a (non-packed) PIM Assert If P=0, the message is a (non-packed) PIM Assert message as specified
message as specified in [RFC7761]. See Section 4.2. In this case, in [RFC7761]. See Section 4.2. In this case, the A flag MUST be set
the (A) flag MUST be set to 0, and MUST be ignored on receipt. to 0 and MUST be ignored on receipt.
If the (P) flag is 1, then the message is called a PackedAssert If P=1, then the message is called a "PackedAssert message", and the
message and the type and hence encoding format of the payload is type and hence encoding format of the payload are determined by the A
determined by the (A) flag. flag.
If A=0, then the message body is a sequence of assert records. This If A=0, then the message body is a sequence of assert records. This
is called a "Simple PackedAssert" message. See Section 4.3. is called a "Simple PackedAssert message". See Section 4.3.
If A=1, then the message body is a sequence of aggregated assert If A=1, then the message body is a sequence of aggregated assert
records. This is called an "Aggregated PackedAssert". See records. This is called an "Aggregated PackedAssert message". See
Section 4.4. Section 4.4.
Two aggregated assert record types are specified. Two aggregated assert record types are specified.
The "Source Aggregated Assert Record", see Section 4.4.1, encodes one The "Source Aggregated Assert Record" (see Section 4.4.1) encodes one
(common) Source Address, Metric and Metric Preference as well as a (common) Source Address, Metric, and Metric Preference as well as a
list of one or more Group Addresses. Source Aggregated Assert list of one or more Group Addresses. Source Aggregated Assert
Records provide a more compact encoding than the Simple PackedAssert Records provide a more compact encoding than the Simple PackedAssert
message format when multiple (S,G) flows share the same source S. A message format when multiple (S,G) flows share the same source S. A
single Source Aggregated Assert Record with n Group Addresses single Source Aggregated Assert Record with n Group Addresses
represents the information of assert records for (S,G1)...(S,Gn). represents the information of assert records for (S,G1)...(S,Gn).
The "RP Aggregated Assert Record", see Section 4.4.2, encodes one The "RP Aggregated Assert Record" (see Section 4.4.2) encodes one
common Metric and Metric Preference as well as a list of "Group common Metric and Metric Preference as well as a list of "Group
Records", each of which encodes a Group Address and a list of zero or Records", each of which encodes a Group Address and a list of zero or
more Source Addresses with a count. This is called an "RP Aggregated more Source Addresses with a count. This is called an "RP Aggregated
Assert Record", because with standard RPF according to ([RFC7761]), Assert Record", because with standard RPF according to [RFC7761], all
all the Group Addresses that use the same RP will have the same the Group Addresses that use the same RP will have the same Metric
Metric and Metric Preference. and Metric Preference.
RP Aggregation Records provide a more compact encoding than the RP Aggregation Assert Records provide a more compact encoding than
Simple PackedAssert message format for (*,G) flows. The Source the Simple PackedAssert message format for (*,G) flows. The Source
Address is optionally used by [RFC7761] assert procedures to indicate Address is optionally used in the assert procedures in [RFC7761] to
the source(s) that triggered the assert, otherwise the Source Address indicate the source(s) that triggered the assert; otherwise, the
is set to 0 in the assert record. Source Address is set to 0 in the assert record.
Both Source Aggregated Assert Records and RP Aggregated Assert Both Source Aggregated Assert Records and RP Aggregated Assert
Records also include the R flag which maintains its semantic from Records also include the R flag, which maintains its semantics from
[RFC7761] but also distinguishes the encodings. Source Aggregated [RFC7761] but also distinguishes the encodings. Source Aggregated
Assert Records have R=0, as (S,G) assert records do in [RFC7761]. RP Assert Records have R=0, as (S,G) assert records do in [RFC7761]. RP
Aggregated Assert Records have R=1, as (*,G) assert records do in Aggregated Assert Records have R=1, as (*,G) assert records do in
[RFC7761]. [RFC7761].
3.3. PackedAssert Mechanism 3.3. PackedAssert Mechanism
PackedAsserts do not change the [RFC7761] PIM assert state machine PackedAsserts do not change the PIM Assert state machine
specification. Instead, sending and receiving of PackedAssert specification [RFC7761]. Instead, sending and receiving of
messages as specified in the following subsections are logically new PackedAssert messages, as specified in the following subsections, are
packetization options for assert records in addition to the (not logically new packetization options for assert records in addition to
packed) [RFC7761] Assert Message. There is no change to the assert the (non-packed) Assert message [RFC7761]. There is no change to the
record information elements transmitted or their semantic. They are assert record information elements transmitted or their semantics.
just transmitted in fewer but larger packets and fewer total number They are just transmitted in fewer but larger packets, and a fewer
of bytes used to encode the information elements. In result, PIM total number of bytes is used to encode the information elements. As
routers should be able to send/receive assert records faster and/or a result, PIM routers should be able to send and receive assert
with less processing overhead. records faster and/or with less processing overhead.
3.3.1. Sending PackedAssert messages 3.3.1. Sending PackedAssert Messages
When using assert packing, the regular [RFC7761] Assert message When using assert packing, the regular Assert message encoding
encoding with A=0 and P=0 is still allowed to be sent. Routers are [RFC7761] with A=0 and P=0 is still allowed to be sent. Routers are
free to choose which PackedAssert message format they send - simple free to choose which PackedAssert message format they send -- simple
(Section 4.3) and/or aggregated (Section 4.4). (Section 4.3) and/or aggregated (Section 4.4).
* When any PIM routers on the LAN have not signaled support for * When any PIM routers on the LAN have not signaled support for
Assert Packing, implementations MUST send only Asserts and MUST assert packing, implementations MUST only send Asserts and MUST
NOT send PackedAsserts under any condition. NOT send PackedAsserts under any condition.
* Implementations SHOULD support sending of PackedAssert messages. * The protocol or system conditions for which an implementation
It is out of scope of this specification for which conditions, sends PackedAsserts instead of Asserts are out of scope for this
such as data-triggered asserts or Assert Timer (AT) expiry- specification. Protocol conditions include protocol triggers such
triggered asserts, or under which conditions (such as high load) as data-triggered asserts or Assert Timer (AT) expiry-triggered
an implementation will send PackedAsserts instead of Asserts. asserts, and system conditions include high or low load or control
plane packet reception rates.
* Implementations are expected to specify in documentation and/or * Implementations are expected to specify in documentation and/or
management interfaces (such as a YANG model), which PackedAssert management interfaces (such as a YANG data model) which
message formats they can send and under which conditions they will PackedAssert message formats they can send and under which
send them. conditions they will send them.
* Implementations SHOULD be able to indicate to the operator (such * Implementations SHOULD be able to indicate to the operator (such
as through a YANG model) how many Assert and PackedAssert messages as through a YANG data model) how many Assert and PackedAssert
were sent/received and how many assert records were sent/received. messages were sent/received and how many assert records were sent/
received.
* A configuration option SHOULD be available to disable PackedAssert * A configuration option SHOULD be available to disable PackedAssert
operations. Implementations that introduce support for assert operations. PIM-SM implementations [RFC7761] that introduce
packing from day one of their [RFC7761] implementation MAY omit support for assert packing from day one MAY omit this
this configuration option. configuration option.
When a PIM router has an assert record ready to send according to When a PIM router has an assert record ready to send according to
[RFC7761], it calls one of the following functions: [RFC7761], it calls one of the following functions:
* send Assert(S,G) / send Assert(*,G) ([RFC7761], Section 4.2), * send Assert(S,G) / send Assert(*,G) ([RFC7761], Section 4.2)
* Send Assert(S,G) / SendAssertCancel(S,G) ([RFC7761], * send Assert(S,G) / send AssertCancel(S,G) ([RFC7761],
Section 4.6.1), Section 4.6.1)
* Send Assert(*,G) / Send AssertCancel(*,G) ([RFC7761], * send Assert(*,G) / send AssertCancel(*,G) ([RFC7761],
Section 4.6.2) Section 4.6.2)
* send Assert(S,G) ([RFC7761], Section 4.8.2). * send Assert(S,G) ([RFC7761], Section 4.8.2)
If sending of PackedAsserts is possible on the network, instead of If sending of PackedAsserts is possible on the network, instead of
sending an Assert message with an assert record, any of these calls sending an Assert message with an assert record, any of these calls
MAY instead result in the PIM implementation remembering the assert MAY instead result in the PIM implementation remembering the assert
record, and continuing with further processing for other flows which record and continuing with further processing for other flows, which
may result in additional assert records. may result in additional assert records.
PIM MUST then create PackedAssert messages from the remembered assert PIM MUST then create PackedAssert messages from the remembered assert
records and schedule them for sending according to the considerations records and schedule them for sending according to the considerations
of the following subsections. in the following subsections.
3.3.1.1. Handling of reception-triggered assert records. 3.3.1.1. Handling of Reception-Triggered Assert Records
Avoiding additional delay because of assert packing compared to Avoiding additional delay because of assert packing compared to
immediate scheduling of Assert messages is most critical for assert immediately scheduling Assert messages is most critical for assert
records that are triggered by reception of data or reception of records that are triggered by reception of data or reception of
asserts against which the router is in the "I am Assert Winner" asserts against which the router is in the "I am Assert Winner"
state. In these cases the router SHOULD send out an Assert or state. In these cases, the router SHOULD send out an Assert or
PackedAssert message containing this assert record as soon as PackedAssert message containing this assert record as soon as
possible to minimize the time in which duplicate IP multicast packets possible to minimize the time in which duplicate IP multicast packets
can occur. can occur.
To avoid additional delay in this case, the router should employ To avoid additional delay in this case, the router should employ
appropriate assert packing and scheduling mechanisms, as explained appropriate assert packing and scheduling mechanisms, as explained
here. here.
Asserts/PackedAsserts created from reception-triggered assert records Asserts/PackedAsserts created from reception-triggered assert records
should be scheduled for serialization with a higher priority than should be scheduled for serialization with a higher priority than
those created from other reasons. They should also bypass other PIM those created because of other protocol or system conditions. They
messages that can create significant bursts, such as PIM join/prune should also bypass other PIM messages that can create significant
messages. bursts, such as PIM join/prune messages.
When there is no reception-triggered Assert/PackedAssert messages When there are no reception-triggered Assert/PackedAssert messages
currently being serialized on the interface or scheduled to be sent, currently being serialized on the interface or scheduled to be sent,
the router should immediately generate and schedule an Assert or the router should immediately generate and schedule an Assert or
PackedAssert message without further assert packing. PackedAssert message without further assert packing.
If there are one or more reception-triggered Assert/PackedAssert If one or more reception-triggered Assert/PackedAssert messages are
messages already serializing and/or scheduled to be serialized on the already serializing or are scheduled to be serialized on the outgoing
outgoing interface, then the router can use the time until the last interface, then the router can use the time until the last of those
of those messages will have finished serializing for PIM processing messages has finished serializing for PIM processing of further
of further conditions that may result in additional reception- conditions. This may result in additional reception-triggered assert
triggered assert records as well as packing of these assert records records and the packing of these assert records without introducing
without introducing additional delay. additional delay.
3.3.1.2. Handling of timer expiry-triggered assert records. 3.3.1.2. Handling of Timer Expiry-Triggered Assert Records
Asserts triggered by expiry of the AT on an assert winner are not Asserts triggered by expiry of the AT on an assert winner are not
time-critical because they can be scheduled in advance and because time-critical because they can be scheduled in advance and because
the Assert_Override_Interval parameter of [RFC7761] already creates a the Assert_Override_Interval parameter [RFC7761] already creates a
3 second window in which such assert records can be sent, received, 3-second window in which such assert records can be sent, received,
and processed before an assert loser's state would expire and and processed before an assert loser's state expires and duplicate IP
duplicate IP multicast packets could occur. multicast packets could occur.
An example mechanism to allow packing of AT expiry-triggered assert An example mechanism to allow packing of AT expiry-triggered assert
records on assert winners is to round the AT to an appropriate records on assert winners is to round the AT to an appropriate
granularity such as 100 msec. This will cause AT for multiple (S,G) granularity such as 100 msec. This will cause the AT for multiple
and/or (*,G) states to expire at the same time, thus allowing them to (S,G) and/or (*,G) states to expire at the same time, thus allowing
be easily packed without changes to the assert state machinery. them to be easily packed without changes to the Assert state
machinery.
AssertCancel messages have assert records with an infinite metric and AssertCancel messages have assert records with an infinite metric and
can use assert packing as any other Assert. They are sent on can use assert packing like any other Assert. They are sent on
Override Timer (OT) expiry and can be packed for example with the Override Timer (OT) expiry and can be packed, for example, with the
same considerations as AT expiry-triggered assert records. same considerations as AT expiry-triggered assert records.
3.3.1.3. Beneficial delay in sending PackedAssert messages 3.3.1.3. Beneficial Delay in Sending PackedAssert Messages
Delay in sending PackedAsserts beyond what was discussed in prior Delay in sending PackedAsserts beyond what was discussed in prior
subsections can still be beneficial when it causes the overall amount subsections can still be beneficial when it causes the overall number
of (possible) duplicate IP multicast packets to decrease in a of possible duplicate IP multicast packets to decrease in a situation
condition with large number of (S,G) and/or (*,G), compared to the with a large number of (S,G) and/or (*,G), compared to the situation
situation in which an implementation only sends Assert messages. where an implementation only sends Assert messages.
This delay can simply be used in implementations because it can not This delay can be used in implementations because it cannot support
support the (more advanced) mechanisms described above, and this the more advanced mechanisms described above, and this longer delay
longer delay can be achieved by some simpler mechanism (such as only can be achieved by some simpler mechanisms (such as only periodic
periodic generation of PackedAsserts) and still achieves an overall generation of PackedAsserts) and still achieves an overall reduction
reduction in duplicate IP multicast packets compared to sending only in duplicate IP multicast packets compared to sending only Asserts.
Asserts.
3.3.1.4. Handling Assert/PackedAssert message loss 3.3.1.4. Handling Assert/PackedAssert Message Loss
When Asserts are sent, a single packet loss will result only in When Asserts are sent, a single packet loss will result only in
continued or new duplicates from a single IP multicast flow. Loss of continued or new duplicates from a single IP multicast flow. Loss of
(non AssertCancel) PackedAssert impacts duplicates for all flows a (non-AssertCancel) PackedAssert impacts duplicates for all flows
packed into the PackedAssert and may result in the need for re- packed into the PackedAssert and may result in the need for resending
sending more than one Assert/PackedAssert, because of the possible more than one Assert/PackedAssert, because of the possible inability
inability to pack the assert records in this condition. Therefore, to pack the assert records in this condition. Therefore, routers
routers SHOULD support mechanisms allowing for PackedAsserts and SHOULD support mechanisms that allow PackedAsserts and Asserts to be
Asserts to be sent with an appropriate Differentiated Services Code sent with an appropriate Differentiated Services Code Point (DSCP)
Point (DSCP, [RFC2475]), such as Expedited Forwarding (EF), to [RFC2475] such as Expedited Forwarding (EF) to minimize their loss,
minimize their loss, especially when duplicate IP multicast packets especially when duplicate IP multicast packets could cause congestion
could cause congestion and loss. and loss.
Routers MAY support a configurable option for sending PackedAssert Routers MAY support a configurable option for sending PackedAssert
messages twice in short order (such as 50 msec apart), to overcome messages twice in short order (such as 50 msec apart) to overcome
possible loss, but only when the following two conditions are met. possible loss, but only when the following two conditions are met.
1. The total size of the two PackedAsserts is less than the total 1. The total size of the two PackedAsserts is less than the total
size of equivalent Assert messages, size of equivalent Assert messages.
2. The condition of the assert records flows in the PackedAssert is 2. The condition of the assert record flows in the PackedAssert is
such that the router can expect that their reception by PIM such that the router can expect that their reception by PIM
routers will not trigger Assert/PackedAsserts replies. This routers will not trigger Assert/PackedAsserts replies. This
condition is true for example when sending an assert record while condition is true, for example, when sending an assert record
becoming or being Assert Winner (Action A1/A3 in [RFC7761]). while becoming or being assert winner (Action A1/A3 in
[RFC7761]).
3.3.1.5. Optimal degree of assert record packing 3.3.1.5. Optimal Degree of Assert Record Packing
The optimal target packing size will vary depending on factors The optimal target packing size will vary depending on factors
including implementation characteristics and the required operating including implementation characteristics and the required operating
scale. At some point, as the target packing size is varied from the 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 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 expected to be found where the router can achieve the required
operating scale of (S,G) and (*,G) flows with minimum duplicates. operating scale of (S,G) and (*,G) flows with minimum duplicates.
Beyond this size, a further increase in the target packing size would Beyond this size, a further increase in the target packing size would
not produce further benefits, but might introduce possible negative not produce further benefits but might introduce possible negative
effects such as the incurrence of more duplicates on loss. effects such as the incurrence of more duplicates on loss.
For example, in some router implementations, the total number of For example, in some router implementations, the total number of
packets that a control plane function such as PIM can send/receive 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 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 data across these packets. As soon as the packet size is large
enough for the maximum possible payload throughput, increasing the enough for the maximum possible payload throughput, increasing the
packet size any further may still reduce the processing overhead of packet size any further may still reduce the processing overhead of
the router, but may increase latency incurred in creating the packet the router but may increase latency incurred in creating the packet
in a way that may increase duplicates compared to smaller packets. in a way that may increase duplicates compared to smaller packets.
3.3.2. Receiving PackedAssert messages 3.3.2. Receiving PackedAssert Messages
Upon reception of a PackedAssert message, the PIM router logically Upon reception of a PackedAssert message, the PIM router logically
converts its payload into a sequence of assert records that are then converts its payload into a sequence of assert records that are then
processed as if an equivalent sequence of Assert messages were processed as if an equivalent sequence of Assert messages were
received according to [RFC7761]. received according to [RFC7761].
4. Packet Formats 4. Packet Formats
This section describes the format of new PIM extensions introduced by This section describes the format of new PIM extensions introduced by
this document. this document.
4.1. PIM Assert Packing Hello Option 4.1. PIM Packed Assert Capability Hello Option
The PIM Packed Assert Capability Hello Option is a new option for PIM
Hello messages according to Section 4.9.2 of [RFC7761].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PIM Assert Packing Hello Option Figure 1: PIM Packed Assert Capability Hello Option
The PIM Assert Packing Hello Option is a new option for PIM Hello
Messages according to Section 4.9.2 of [RFC7761].
* OptionType TBD: PIM Packed Assert Capability Hello Option OptionType 40 (Packed Assert Capability):
Indicates support for the ability to receive and process all the
PackedAssert encodings defined in this document.
Including the PIM OptionType TBD indicates support for the ability to OptionLength 0:
receive and process all the PackedAssert encodings defined in this The Packet Assert Capability has no OptionValue.
document.
4.2. Assert Message Format 4.2. Assert Message Format
Figure 2 shows a PIM Assert message as specified in Section 4.9.6 of
[RFC7761]. The Encoded-Group and Encoded-Unicast address formats are
specified in Section 4.9.1 of [RFC7761] for IPv4 and IPv6.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Assert Message Format Figure 2: Assert Message Format
Figure 2 shows a PIM Assert message as specified in Section 4.9.6 of This common header shows the "7 6 5 4 3 2" flag bits (as defined in
[RFC7761]. The Encoded-Group and Encoded-Unicast address formats are Section 4 of [RFC9436]) and the location of the P and A flags (as
specified in Section 4.9.1 of [RFC7761] for IP and IPv6. described in Section 5). As specified in Section 3.2, both flags in
a (non-packed) PIM Assert message are required to be set to 0.
This common header is showing the "7 6 5 4 3 2" Flag Bits as defined
in Section 4 of [I-D.ietf-pim-rfc8736bis] and the location of the P
and A flags, as described in Section 5. As specified in
Section 3.2, both flags in a (non-packed) PIM Assert message are
required to be set to 0.
4.3. Simple PackedAssert Message Format 4.3. Simple PackedAssert Message Format
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 page 12, line 36 skipping to change at line 536
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Assert Record [M] . . Assert Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Simple PackedAssert Message Format Figure 3: Simple PackedAssert Message Format
* PIM Version, Type, Checksum: PIM Version, Type, Checksum:
As specified in Section 4.9.6 of [RFC7761]. As specified in Section 4.9.6 of [RFC7761].
* "7 6 5 4 3 2": IANA registry handled bits according to Section 4 "7 6 5 4 3 2":
of [I-D.ietf-pim-rfc8736bis]. Flag bits per Section 4 of [RFC9436].
* Zero: Set to zero on transmission. Serves to make non assert P:
packing capable PIM routers fail in parsing the message instead of Packed flag. MUST be 1.
possible mis-parsing if this field was used.
* Reserved: Set to zero on transmission. Ignored upon receipt. A:
Aggregated flag. MUST be 0.
* P: packed flag. MUST be 1. Zero:
Set to zero on transmission. Serves to make PIM routers that are
not capable of assert packing to fail in parsing the message
instead possible mis-parsing of the message as an Assert message
[RFC7761] if this field was not zero-filled.
* A: aggregated flag. MUST be 0. Reserved:
Set to zero on transmission. Ignored upon receipt.
* M: The number of Assert Records in the message. Derived from the M:
The number of Assert Records in the message. Derived from the
length of the packet carrying the message. length of the packet carrying the message.
* Assert Record: formatted according to {FIG-MESSAGE-SIMPLE}}, which Assert Record:
is the same as the PIM assert message body as specified in Formatted according to Figure 3, which is the same as the PIM
Section 4.9.6 of [RFC7761]. The number M of Assert Records is Assert message body as specified in Section 4.9.6 of [RFC7761].
determined from the packet size.
The format of each Assert Record is the same as the PIM assert The format of each Assert Record is the same as the PIM Assert
message body as specified in Section 4.9.6 of [RFC7761]. message body as specified in Section 4.9.6 of [RFC7761].
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 |
skipping to change at page 14, line 36 skipping to change at line 616
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Aggregated Assert Record [M] . . Aggregated Assert Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Aggregated PackedAssert Message Format Figure 5: Aggregated PackedAssert Message Format
* PIM Version, Type, Reserved, Checksum: PIM Version, Type, Reserved, Checksum:
As specified in Section 4.9.6 of [RFC7761]. As specified in Section 4.9.6 of [RFC7761].
* "7 6 5 4 3 2": IANA registry handled bits according to Section 4 "7 6 5 4 3 2":
of [I-D.ietf-pim-rfc8736bis]. Flag bits per Section 4 of [RFC9436].
* P: packed flag. MUST be 1. P:
Packed flag. MUST be 1.
* A: aggregated flag. MUST be 1. A:
Aggregated flag. MUST be 1.
* Zero: Set to zero on transmission. Serves to make non assert Zero:
packing capable PIM routers fail in parsing the message instead of Set to zero on transmission. Serves to make PIM routers that are
possible mis-parsing if this field was used. not capable of assert packing to fail in parsing the message
instead possible mis-parsing of the message as an Assert message
[RFC7761] if this field was not zero-filled.
* Aggregated Assert Record: formatted according to Figure 5. The Aggregated Assert Record:
number M of Aggregated Assert Records is determined from the Formatted according to Figure 5. The number M of Aggregated
packet size. Assert Records is determined from the packet size.
4.4.1. Source Aggregated Assert Record 4.4.1. Source Aggregated Assert Record
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 34 skipping to change at line 663
| Group Address 2 (Encoded-Group format) | | Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address N (Encoded-Group format) | | Group Address N (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Source Aggregated Assert Record Figure 6: Source Aggregated Assert Record
* Reserved: Set to zero on transmission. Ignored upon receipt. R:
MUST be 0.
* R: MUST be 0.
R indicates both that the encoding format of the record is that of R indicates both that the encoding format of the record is that of
a Source Aggregated Assert Record, but also that all assert a Source Aggregated Assert Record and that all assert records
records represented by the Source Aggregated Assert Record have represented by the Source Aggregated Assert Record have R=0 and
R=0 and are therefore (S,G) assert records according to the are therefore (S,G) assert records according to the definition of
definition of R in [RFC7761], Section 4.9.6. R in [RFC7761], Section 4.9.6.
* Source Address, Metric Preference, Metric:
Metric Preference, Metric, Source Address:
As specified in Section 4.9.6 of [RFC7761]. Source Address MUST As specified in Section 4.9.6 of [RFC7761]. Source Address MUST
NOT be zero. NOT be zero.
* Number of Groups: Number of Groups:
The number of Group Address fields. The number of Group Address fields.
* Group Address: Reserved:
Set to zero on transmission. Ignored upon receipt.
Group Address:
As specified in Section 4.9.6 of [RFC7761]. As specified in Section 4.9.6 of [RFC7761].
4.4.2. RP Aggregated Assert Record 4.4.2. RP Aggregated Assert Record
An RP Aggregation Assert record aggregates (*,G) assert records with An RP Aggregation Assert Record aggregates (*,G) assert records with
the same Metric Preference and Metric. Typically this is the case 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 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 only (*,G) using the same RP because the RP address is not encoded as
it is also not present in [RFC7761] assert records. it is also not present in assert records [RFC7761].
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 page 16, line 51 skipping to change at line 727
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Group Record [K] . . Group Record [K] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RP Aggregated Assert Record Figure 7: RP Aggregated Assert Record
* R: MUST be 1. R:
MUST be 1.
R indicates both that the encoding format of the record is that of R indicates both that the encoding format of the record is that of
an RP Aggregated Assert Record, and that all assert records an RP Aggregated Assert Record and that all assert records
represented by the RP Aggregated Assert Record have R=1 and are represented by the RP Aggregated Assert Record have R=1 and are
therefore (*,G) assert records according to the definition of R in therefore (*,G) assert records according to the definition of R in
[RFC7761], Section 4.9.6. [RFC7761], Section 4.9.6.
* Metric Preference, Metric: Metric Preference, Metric:
As specified in Section 4.9.6 of [RFC7761]. As specified in Section 4.9.6 of [RFC7761].
* Reserved: Set to zero on transmission. Ignored upon receipt. Number of Group Records (K):
* Number of Group Records (K):
The number of packed Group Records. A record consists of a Group The number of packed Group Records. A record consists of a Group
Address and a Source Address list with a number of sources. Address and a Source Address list with a number of sources.
Reserved:
Set to zero on transmission. Ignored upon receipt.
The format of each Group Record is: The format of each Group Record is:
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) |
skipping to change at page 17, line 43 skipping to change at line 767
| Source Address 2 (Encoded-Unicast format) | | Source Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address P (Encoded-Unicast format) | | Source Address P (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Group Record Figure 8: Group Record
* Group Address and Reserved: Group Address:
As specified in Section 4.9.6 of [RFC7761]. As specified in Section 4.9.6 of [RFC7761].
* Reserved: Set to zero on transmission. Ignored upon receipt. Reserved:
Set to zero on transmission. Ignored upon receipt.
* Number of Sources (P):
The Number of Sources is corresponding to the number of Source Number of Sources (P):
Address fields in the Group Record. If this number is 0, the The Number of Sources corresponds to the number of Source Address
Group Record indicates one assert record with a Source Address of fields in the Group Record. If this number is not 0 and one of
0. If this number is not 0 and one of the (*,G) assert records to the (*,G) assert records to be encoded has Source Address 0, then
be encoded should have the Source Address 0, then 0 needs to be 0 needs to be encoded as one of the Source Address fields.
encoded as one of the Source Address fields.
* Source Address: Reserved:
Set to zero on transmission. Ignored upon receipt.
Source Address:
As specified in Section 4.9.6 of [RFC7761]. But there can be As specified in Section 4.9.6 of [RFC7761]. But there can be
multiple Source Address fields in the Group Record. multiple Source Address fields in the Group Record.
5. IANA Considerations 5. IANA Considerations
IANA has assigned the following code point value to the "PIM-Hello IANA has updated the "PIM Message Types" registry as follows to
Options" registry for the Packed Assert Capability. include the Packed and Aggregated flag bits for the Assert message
type.
+=======+========+=========================+================+ +=======+========+==========================+===========+
| Value | Length | Name | Reference | | Value | Length | Name | Reference |
+=======+========+=========================+================+ +=======+========+==========================+===========+
| 40 | 0 | Packed Assert Capability| [This Document]| | 40 | 0 | Packed Assert Capability | RFC 9466 |
+=======+========+=========================+================+ +-------+--------+--------------------------+-----------+
Figure 9: IANA PIM-Hello Options Table 1: PIM-Hello Options
IANA has assigned the following two Flag Bits for PIM Assert messages IANA has assigned the following two flag bits for PIM Assert messages
to the "PIM Message Types" registry. in the "PIM Message Types" registry.
+======+========+=================+====================+ +======+========+=================+=====================+
| Type | Name | Flag Bits | Reference | | Type | Name | Flag Bits | Reference |
+======+========+=================+====================+ +======+========+=================+=====================+
| 5 | Assert | 0: Packed | [This Document] | | 5 | Assert | 0: Packed | RFC 9466 |
| | | 1: Aggregated | [This Document] | | | +-----------------+---------------------+
| | | 2-7: Unassigned | [RFC3973][RFC7761] | | | | 1: Aggregated | RFC 9466 |
+======+========+=================+====================+ | | +-----------------+---------------------+
| | | 2-7: Unassigned | [RFC3973] [RFC7761] |
+------+--------+-----------------+---------------------+
Figure 10: IANA PIM Message Types Table 2: PIM Message Types
6. Security Considerations 6. Security Considerations
The security considerations of [RFC7761] apply to the extensions The security considerations of [RFC7761] apply to the extensions
defined in this document. defined in this document.
This document packs multiple assert records in a single message. As This document packs multiple assert records in a single message. As
described in Section 6.1 of [RFC7761], a forged Assert message could described in Section 6.1 of [RFC7761], a forged Assert message could
cause the legitimate designated forwarder to stop forwarding traffic cause the legitimate designated forwarder to stop forwarding traffic
to the LAN. The effect may be amplified when using a PackedAssert to the LAN. The effect may be amplified when using a PackedAssert
message. message.
Like other optional extensions of [RFC7761] that are active only when Like other optional extensions of [RFC7761] that are active only when
all routers indicate support for them, a single misconfigured or all routers indicate support for them, a single misconfigured or
malicious router emitting forged PIM Hello messages can inhibit malicious router emitting forged PIM Hello messages can inhibit
operations of this extension. operations of this extension.
Authentication of PIM messages such as explained in [RFC7761], Authentication of PIM messages, such as that explained in Sections
Sections 6.2 and 6.3 can protect against the forged message attacks 6.2 and 6.3 of [RFC7761], can protect against forged message attacks
attacks. attacks.
7. Acknowledgments 7. References
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.
8. Working Group considerations
[RFC-Editor: please remove this section].
8.1. Open Issues
8.2. Changelog
This document is hosted starting with -06 on
https://github.com/toerless/pim-assert-packing.
8.2.1. draft-ietf-pim-assert-packing-12
Changed text of IANA considerations from request to assigned after
IANA has assigned the code points.
Fixed leftover nits from John Scudders review that where not done
right in -11.
8.2.2. draft-ietf-pim-assert-packing-11
Comprehensive 2 round AD review by John Scudder.
Functional enhancement: add requirement for existing implementation
to be able to disable assert packing so that any possible
compatibility issues introduced (which we think will not happen) can
be avoided when upgrading to a packedassert version of the software.
Also to allow performance comparison. No making a requirement for
day 0 implementations because they may want to save the work of
having a non-packed-assert code path.
Some rewrite to increase readibility, subdivided 3.3.1 into multiple
subsections to better structure it.
3.3.1 improved core requirements - added requirement for counters to
show assert/packedassert operations, documentation (e.g.: YANG) for
what/how it can send, config option to disable packedasserts.
Refined text: Bulletized cases of asserts in rfc7761,
Subdivided 3.3.1 into multiple subsections for readability improved
text based on review. Added reference for DSCP.
3.3.1.5 Added explicit example of improvement because of packet size/
throughput limits of router.
Added notion of attacks by wrong hellos to security section.
Eric Vyncke review:
Appendix A: Better elaboration of L2 ring vs L3 ring benefits. Nits.
Paul Wouter review:
Changed explanation of number "M" of records to be inline with
formatting of other data (sections 4.3 and 4.4).
Some nits.
8.2.3. draft-ietf-pim-assert-packing-10
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 ->
24 bit for this field.
8.2.4. draft-ietf-pim-assert-packing-09
For details of review discussion/replies, see review reply emails in
(https://github.com/toerless/pim-assert-packing/tree/main/emails)j
review Alvaro Retana: Reintroduced ref to PIM-DM, fixed typos,
downgraded MAY->may for "sufficient".
IANA Expert Review / Stig Venaas:
Removed Count field from message headers as it complicates parsing
and is unnecessary. Added "Zero" field to make packed asserts
received by a non-packed-assert-capable-router guaranteed to fail
("Reserved" address family type).
Changed from RFC8736 to RFC8736bis so that we can use the word
"Unassigned" in the IANA table.
Review Shuping Peng
Changed explanation of how assert packing works from "layer" to
"alternative to packetization via PIM Assert Message. Fixed various
typos, expanded term etc..
Review Robert Sparks:
Moved Intro explanations of how one could avoid asserts (but how its
problematic) to appendix. Applied textual nits found. Removed
quotes around term "sufficient" for easier readbility.
Review Tommy Paul:
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.
8.2.5. draft-ietf-pim-assert-packing-08
Included changes from review of Alvaro Retana
(https://mailarchive.ietf.org/arch/msg/pim/
GsKq9bB2a6yDdM9DvAUGCWthdEI)
Please see the following emails discussing the changes:
https://raw.githubusercontent.com/toerless/pim-assert-packing/main/
emails/07-alvaro-review-reply.txt
8.2.6. draft-ietf-pim-assert-packing-07
Included changes from review of Alvaro Retana
(https://mailarchive.ietf.org/arch/msg/pim/
Cp4o5glUFge2b84X9CQMwCWZjAk/)
Please see the following emails discussing the changes:
https://raw.githubusercontent.com/toerless/pim-assert-packing/main/
emails/05-alvaro-review-reply.txt
https://raw.githubusercontent.com/toerless/pim-assert-packing/main/
emails/07-pim-wg-announce.txt
8.2.7. draft-ietf-pim-assert-packing-06
This version was converted from txt format into markdown for better
editing later, but is otherwise text identical to -05. It was posted
to DataTracker to make diffs easier.
Functional changes:
9. References
9.1. Normative References
[I-D.ietf-pim-rfc8736bis] 7.1. Normative References
Venaas, S. and A. Retana, "PIM Message Type Space
Extension and Reserved Bits", Work in Progress, Internet-
Draft, draft-ietf-pim-rfc8736bis-00, 2 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim-
rfc8736bis-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References [RFC9436] Venaas, S. and A. Retana, "PIM Message Type Space
Extension and Reserved Bits", RFC 9436,
DOI 10.17487/RFC9436, August 2023,
<https://www.rfc-editor.org/info/rfc9436>.
7.2. Informative References
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>. January 2005, <https://www.rfc-editor.org/info/rfc3973>.
skipping to change at page 23, line 25 skipping to change at line 886
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431, Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015, DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>. <https://www.rfc-editor.org/info/rfc7431>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>. <https://www.rfc-editor.org/info/rfc7490>.
Appendix A. Use case examples Appendix A. Use Case Examples
The PIM Assert mechanism can only be avoided by designing the network The PIM Assert mechanism can only be avoided by designing the network
to be without transit subnets with multiple upstream routers. For to be without transit subnets with multiple upstream routers. For
example, an L2 ring between routers can sometimes be reconfigured to example, an L2 ring between routers can sometimes be reconfigured to
be a ring of point-to-point subnets connected by the routers. These be a ring of point-to-point subnets connected by the routers.
L2/L3 topology changes are undesirable though, when they are only However, these L2/L3 topology changes are undesirable when they are
done to enable IP multicast with PIM because they increase the cost only done to enable IP multicast with PIM because they increase the
of introducing IP multicast with PIM. cost of introducing IP multicast with PIM.
These L3 ring designs are specifically undesirable, when particular These L3 ring designs are specifically undesirable when particular L2
L2 technologies are needed. For example various L2 technologies for technologies are needed. For example, various L2 technologies for
rings provide sub 50 msec failover mechanisms that will benefit IP rings provide sub-50 msec failover mechanisms that will benefit IP
unicast and multicast alike without any added complexity to the IP unicast and multicast alike without any added complexity to the IP
layer (forwarding or routing). If such L2 rings where to be replaced 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 by L3 rings just to avoid PIM asserts, then this would result in the
need for a complex choice of of a sub 50 msec IP unicast failover need for a complex choice of a sub-50 msec IP unicast failover
solutions as well as a sub 50 msec IP multicast failover solution. solution (such as [RFC7490] with IP repair tunnels) as well as a
The mere fact that by operating at the IP layer, different solutions separate sub-50 msec IP multicast failover solution, (such as
for IP unicast and multicast are required makes them more difficult [RFC7431] with dedicated ring support). The mere fact that, by
to operate, they typically require more expensive hardware and running at the IP layer, different solutions for IP unicast and
therefore most often, they are not even available on the target multicast are required makes them more difficult to operate, and they
equipment, such as [RFC7490] with IP repair tunnels for IP unicast or typically require more expensive hardware. This often leads to non-
[RFC7431] for IP multicast. support of the IP multicast part.
Likewise, IEEE Time Sensitive Networking mechanisms would require an Likewise, IEEE Time-Sensitive Networking mechanisms would require an
L2 topology that can not simply be replaced by an L3 topology. L2 L2 topology that cannot simply be replaced by an L3 topology. L2
sub-topologies can also significantly reduce the cost of deployment. sub-topologies can also significantly reduce the cost of deployment.
The following subsections give examples of the type of network and The following subsections give examples of the type of network and
use-cases in which subnets with asserts have been observerd or are use cases in which subnets with asserts have been observed or are
expected to require scaling as provided by this specification. expected to require scaling as provided by this specification.
A.1. Enterprise network A.1. Enterprise Network
When an Enterprise network is connected through a layer-2 network, When an enterprise network is connected through an L2 network, the
the intra-enterprise runs layer-3 PIM multicast. The different sites intra-enterprise runs L3 PIM multicast. The different sites of the
of the enterprise are equivalent to the PIM connection through the enterprise are equivalent to the PIM connection through the shared
shared LAN network. Depending upon the locations and amount of LAN network. Depending upon the locations and number of groups,
groups there could be many asserts on the first-hop routers. there could be many asserts on the first-hop routers.
A.2. Video surveillance A.2. Video Surveillance
Video surveillance deployments have migrated from analog based Video surveillance deployments have migrated from analog-based
systems to IP-based systems oftentimes using multicast. In the systems to IP-based systems oftentimes using multicast. In the
shared LAN network deployments, when there are many cameras streaming shared LAN network deployments, when there are many cameras streaming
to many groups there may be issues with many asserts on first-hop to many groups, there may be issues with many asserts on first-hop
routers. routers.
A.3. Financial Services A.3. Financial Services
Financial services extensively rely on IP Multicast to deliver stock Financial services extensively rely on IP Multicast to deliver stock
market data and its derivatives, and current multicast solution PIM market data and its derivatives, and the current multicast solution
is usually deployed. As the number of multicast flows grow, there PIM is usually deployed. As the number of multicast flows grow, many
are many stock data with many groups may result in many PIM asserts stock data with many groups may result in many PIM asserts on a
on a shared LAN network from publisher to the subscribers. shared LAN network from the publisher to the subscribers.
A.4. IPTV broadcast Video A.4. IPTV Broadcast Video
PIM DR deployments are often used in host-side network for IPTV PIM DR deployments are often used in host-side network for IPTV
broadcast video services. Host-side access network failure scenario broadcast video services. Host-side access network failure scenarios
may be benefitted by assert packing when many groups are being used. may benefit from assert packing when many groups are being used.
According to [RFC7761] the DR will be elected to forward multicast According to [RFC7761], the DR will be elected to forward multicast
traffic in the shared access network. When the DR recovers from a traffic in the shared access network. When the DR recovers from a
failure, the original DR starts to send traffic, and the current DR failure, the original DR starts to send traffic, and the current DR
is still forwarding traffic. In the situation multicast traffic is still forwarding traffic. In this situation, multicast traffic
duplication maybe happen in the shared access network and can trigger duplication maybe happen in the shared access network and can trigger
the assert progress. the assert progress.
A.5. MVPN MDT A.5. MVPN MDT
As described in [RFC6037], MDT (Multicast Distribution Tree) is used As described in [RFC6037], Multicast Distribution Tree (MDT) is used
as tunnels for MVPN. The configuration of multicast-enabled VRF (VPN as tunnels for Multicast VPN (MVPN). The configuration of multicast-
routing and forwarding) or interface that is in a VRF changing may enabled VPN Routing and Forwarding (VRF) or changes to an interface
cause many assert packets to be sent in a same time. that is in a VRF may cause many assert packets to be sent at the same
time.
A.6. Special L2 services A.6. Special L2 Services
Additionally, future backhaul, or fronthaul, networks may want to Additionally, future backhaul, or fronthaul, networks may want to
connect L3 across an L2 underlay supporting Time Sensitive Networks connect L3 across an L2 underlay supporting Time-Sensitive Networks
(TSN). The infrastructure may run DetNet over TSN. These transit L2 (TSNs). The infrastructure may run Deterministic Networking (DetNet)
LANs would have multiple upstreams and downstreams. This document is over TSN. These transit L2 LANs would have multiple upstreams and
taking a proactive approach to prevention of possible future assert downstreams. This document takes a proactive approach to prevention
issues in these types of environments. of possible future assert issues in these types of environments.
Acknowledgments
The authors would like to thank the following individuals: 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, Éric 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.
Authors' Addresses Authors' Addresses
Yisong Liu (editor) Yisong Liu (editor)
China Mobile China Mobile
China China
Email: liuyisong@chinamobile.com Email: liuyisong@chinamobile.com
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Futurewei
United States of America United States of America
Email: tte@cs.fau.de Email: tte@cs.fau.de
Mike McBride Mike McBride
Futurewei Futurewei
United States of America United States of America
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Zheng(Sandy) Zhang Zheng (Sandy) Zhang
ZTE Corporation ZTE Corporation
China China
Email: zhang.zheng@zte.com.cn Email: zhang.zheng@zte.com.cn
 End of changes. 149 change blocks. 
556 lines changed or deleted 414 lines changed or added

This html diff was produced by rfcdiff 1.48.