rfc9630v1.txt   rfc9630.txt 
skipping to change at line 69 skipping to change at line 69
1. Introduction 1. Introduction
1.1. Requirements Language 1.1. Requirements Language
2. Requirements for Multicast Traffic Telemetry 2. Requirements for Multicast Traffic Telemetry
3. Issues of Existing Techniques 3. Issues of Existing Techniques
4. Modifications and Extensions Based on Existing Solutions 4. Modifications and Extensions Based on Existing Solutions
4.1. Per-Hop Postcard Using IOAM DEX 4.1. Per-Hop Postcard Using IOAM DEX
4.2. Per-Section Postcard for IOAM Trace 4.2. Per-Section Postcard for IOAM Trace
5. Application Considerations for Multicast Protocols 5. Application Considerations for Multicast Protocols
5.1. Mtrace Version 2 5.1. Mtrace Version 2
5.2. Application in PIM 5.2. Application in PIM
5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute 5.3. Application of MVPN PMSI Tunnel Attribute
6. Security Considerations 6. Security Considerations
7. IANA Considerations 7. IANA Considerations
8. References 8. References
8.1. Normative References 8.1. Normative References
8.2. Informative References 8.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
skipping to change at line 111 skipping to change at line 111
It is essential to monitor the performance of multicast traffic. New It is essential to monitor the performance of multicast traffic. New
on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct
Export (DEX) [RFC9326], IOAM Postkcard-Based Telemetry - Marking Export (DEX) [RFC9326], IOAM Postkcard-Based Telemetry - Marking
(PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS) (PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS)
[HYBRID-TWO-STEP], complement existing active OAM performance [HYBRID-TWO-STEP], complement existing active OAM performance
monitoring methods like ICMP ping [RFC0792]. However, multicast monitoring methods like ICMP ping [RFC0792]. However, multicast
traffic's unique characteristics present challenges in applying these traffic's unique characteristics present challenges in applying these
techniques efficiently. techniques efficiently.
The IP multicast packet data for a particular (S, G) state remains The IP multicast packet data for a particular (S,G) state remains
identical across different branches to multiple receivers. When IOAM identical across different branches to multiple receivers [RFC4601].
trace data is added to multicast packets, each replicated packet When IOAM trace data is added to multicast packets, each replicated
retains telemetry data for its entire forwarding path. This results packet retains telemetry data for its entire forwarding path. This
in redundant data collection for common path segments, unnecessarily results in redundant data collection for common path segments,
consuming extra network bandwidth. For large multicast trees, this unnecessarily consuming extra network bandwidth. For large multicast
redundancy is substantial. Using solutions like IOAM DEX could be trees, this redundancy is substantial. Using solutions like IOAM DEX
more efficient by eliminating data redundancy, but IOAM DEX lacks a could be more efficient by eliminating data redundancy, but IOAM DEX
branch identifier, complicating telemetry data correlation and lacks a branch identifier, complicating telemetry data correlation
multicast tree reconstruction. and multicast tree reconstruction.
This document provides two solutions to the IOAM data-redundancy This document provides two solutions to the IOAM data-redundancy
problem based on the IOAM standards. The requirements for multicast problem based on the IOAM standards. The requirements for multicast
traffic telemetry are discussed along with the issues of the existing traffic telemetry are discussed along with the issues of the existing
on-path telemetry techniques. We propose modifications and on-path telemetry techniques. We propose modifications and
extensions to make these techniques adapt to multicast in order for extensions to make these techniques adapt to multicast in order for
the original multicast tree to be correctly reconstructed while the original multicast tree to be correctly reconstructed while
eliminating redundant data. This document does not cover the eliminating redundant data. This document does not cover the
operational considerations such as how to enable the telemetry on a operational considerations such as how to enable the telemetry on a
subset of the traffic to avoid overloading the network or the data subset of the traffic to avoid overloading the network or the data
skipping to change at line 212 skipping to change at line 212
mtrace). Such correlation is undesirable because it introduces extra mtrace). Such correlation is undesirable because it introduces extra
work and complexity. work and complexity.
The fundamental reason for this problem is that there is not an The fundamental reason for this problem is that there is not an
identifier (either implicit or explicit) to correlate the data on identifier (either implicit or explicit) to correlate the data on
each branch. each branch.
4. Modifications and Extensions Based on Existing Solutions 4. Modifications and Extensions Based on Existing Solutions
We provide two solutions to address the above issues. One is based We provide two solutions to address the above issues. One is based
on IOAM DEX and requires an extension to the instruction header of on IOAM DEX and requires an extension to the DEX Option-Type header.
the IOAM DEX Option. The second solution combines the IOAM trace The second solution combines the IOAM trace option and postcards for
option and postcards for redundancy removal. redundancy removal.
4.1. Per-Hop Postcard Using IOAM DEX 4.1. Per-Hop Postcard Using IOAM DEX
One way to mitigate the postcard-based telemetry's tree-tracking One way to mitigate the postcard-based telemetry's tree-tracking
weakness is to augment it with a branch identifier field. This works weakness is to augment it with a branch identifier field. This works
for the IOAM DEX option because the IOAM DEX option has an for the IOAM DEX option because the DEX Option-Type header can be
instruction header which can be used to hold the branch identifier. used to hold the branch identifier. To make the branch identifier
To make the branch identifier globally unique, the branch fork node globally unique, the Branching Node ID plus an index is used. For
ID plus an index is used. For example, as shown in Figure 1, Node B example, as shown in Figure 1, Node B has two branches: one to Node C
has two branches: one to Node C and the other to Node D. Node B may and the other to Node D. Node B may use [B, 0] as the branch
use [B, 0] as the branch identifier for the branch to C, and [B, 1] identifier for the branch to C, and [B, 1] for the branch to D. The
for the branch to D. The identifier is carried with the multicast identifier is carried with the multicast packet until the next branch
packet until the next branch fork node. Each node MUST export the fork node. Each node MUST export the branch identifier in the
branch identifier in the received IOAM DEX header in the postcards it received IOAM DEX header in the postcards it sends. The branch
sends. The branch identifier, along with the other fields such as identifier, along with the other fields such as Flow ID and Sequence
Flow ID and Sequence Number, is sufficient for the data collector to Number, is sufficient for the data collector to reconstruct the
reconstruct the topology of the multicast tree. topology of the multicast tree.
Figure 1 shows an example of this solution. "P" stands for the Figure 1 shows an example of this solution. "P" stands for the
postcard packet. The square brackets contains the branch identifier. postcard packet. The square brackets contains the branch identifier.
The curly braces contain the telemetry data about a specific node. The curly braces contain the telemetry data about a specific node.
P:[A,0]{A} P:[A,0]{B} P:[B,1]{D} P:[B,0]{C} P:[B,0]{E} P:[A,0]{A} P:[A,0]{B} P:[B,1]{D} P:[B,0]{C} P:[B,0]{E}
^ ^ ^ ^ ^ ^ ^ ^ ^ ^
: : : : : : : : : :
: : : : : : : : : :
: : : +-:-+ +-:-+ : : : +-:-+ +-:-+
skipping to change at line 256 skipping to change at line 256
| A |------->| B | : | A |------->| B | :
| | | |--+ +-:-+ | | | |--+ +-:-+
+---+ +---+ | | | +---+ +---+ | | |
+-->| D |--... +-->| D |--...
| | | |
+---+ +---+
Figure 1: Per-Hop Postcard Figure 1: Per-Hop Postcard
Each branch fork node needs to generate a unique branch identifier Each branch fork node needs to generate a unique branch identifier
(i.e., branch ID) for each branch in its multicast tree instance and (i.e., Multicast Branch ID) for each branch in its multicast tree
include it in the IOAM DEX option header. The branch ID remains instance and include it in the IOAM DEX Option-Type header. The
unchanged until the next branch fork node. The branch ID contains Multicast Branch ID remains unchanged until the next branch fork
two parts: the branch fork node ID and an interface index. node. The Multicast Branch ID contains two parts: the Branching Node
ID and an Interface Index.
Conforming to the node ID specification in IOAM [RFC9197], the node Conforming to the node ID specification in IOAM [RFC9197], the
ID is a 3-octet unsigned integer. The interface index is a two-octet Branching Node ID is a 3-octet unsigned integer. The Interface Index
unsigned integer. As shown in Figure 2, the branch ID consumes 8 is a two-octet unsigned integer. As shown in Figure 2, the Multicast
octets in total. The three unused octets MUST be set to 0; Branch ID consumes 8 octets in total. The three unused octets MUST
otherwise, the header is considered malformed and the packet MUST be be set to 0; otherwise, the header is considered malformed and the
dropped. packet MUST be dropped.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node_id | unused | | Branching Node ID | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | unused | | Interface Index | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multicast Branch ID Format Figure 2: Multicast Branch ID Format
Figure 3 shows that the branch ID is carried as an optional field Figure 3 shows that the Multicast Branch ID is carried as an optional
after the Flow ID and Sequence Number optional fields in the IOAM DEX field after the Flow ID and Sequence Number optional fields in the
option header. Two bits "N" and "I" (i.e., the third and fourth bits IOAM DEX option header. Two bits "N" and "I" (i.e., the third and
in the Extension-Flags field) are reserved to indicate the presence fourth bits in the Extension-Flags field) are reserved to indicate
of the optional branch ID field. "N" stands for the Node ID, and "I" the presence of the optional Multicast Branch ID field. "N" stands
stands for the interface index. If "N" and "I" are both set to 1, for the Branching Node ID, and "I" stands for the Interface Index.
the optional multicast branch ID field is present. Two Extension- If "N" and "I" are both set to 1, the optional Multicast Branch ID
Flag bits are used because [RFC9326] specifies that each extension field is present. Two Extension-Flag bits are used because [RFC9326]
flag only indicates the presence of a 4-octet optional data field, specifies that each extension flag only indicates the presence of a
while we need more than 4 octets to encode the branch ID. The two 4-octet optional data field, while we need more than 4 octets to
flag bits MUST be both set or cleared; otherwise, the header is encode the Multicast Branch ID. The two flag bits MUST be both set
considered malformed and the packet MUST be dropped. or cleared; otherwise, the header is considered malformed and the
packet MUST be dropped.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Flags |F|S|N|I|E-Flags| | Namespace-ID | Flags |F|S|N|I|E-Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved | | IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID (optional) | | Flow ID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) | | Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Branch ID (as shown in Figure 2) | | Multicast Branch ID (as shown in Figure 2) |
| (optional) | | (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Carrying the Branch ID in IOAM DEX Option Header Figure 3: Carrying the Multicast Branch ID in the IOAM DEX
Option-Type Header
Once a node gets the branch ID information from the upstream node, it Once a node gets the branch ID information from the upstream node, it
MUST carry this information in its telemetry data export postcards so MUST carry this information in its telemetry data export postcards so
the original multicast tree can be correctly reconstructed based on the original multicast tree can be correctly reconstructed based on
the postcards. the postcards.
4.2. Per-Section Postcard for IOAM Trace 4.2. Per-Section Postcard for IOAM Trace
The second solution is a combination of the IOAM trace option The second solution is a combination of the IOAM trace option
[RFC9197] and the postcard-based telemetry [IFIT-FRAMEWORK]. To [RFC9197] and the postcard-based telemetry [IFIT-FRAMEWORK]. To
skipping to change at line 361 skipping to change at line 364
{B2} | | {B2} | |
+---+ +---+
Figure 4: Per-Section Postcard Figure 4: Per-Section Postcard
There is no need to modify the IOAM trace option header format as There is no need to modify the IOAM trace option header format as
specified in [RFC9197]. We just need to configure the branch fork specified in [RFC9197]. We just need to configure the branch fork
nodes, as well as the leaf nodes, to export the postcards that nodes, as well as the leaf nodes, to export the postcards that
contain the trace data collected so far and refresh the IOAM header contain the trace data collected so far and refresh the IOAM header
and data in the packet (e.g., clear the node data list to all zeros and data in the packet (e.g., clear the node data list to all zeros
and reset the Remaining Length field to the initial value). and reset the RemainingLen field to the initial value).
5. Application Considerations for Multicast Protocols 5. Application Considerations for Multicast Protocols
5.1. Mtrace Version 2 5.1. Mtrace Version 2
Mtrace version 2 (Mtrace2) [RFC8487] is a protocol that allows the Mtrace version 2 (Mtrace2) [RFC8487] is a protocol that allows the
tracing of an IP multicast routing path. Mtrace2 provides additional tracing of an IP multicast routing path. Mtrace2 provides additional
information such as the packet rates and losses, as well as other information such as the packet rates and losses, as well as other
diagnostic information. Unlike unicast traceroute, Mtrace2 traces diagnostic information. Unlike unicast traceroute, Mtrace2 traces
the path that the tree-building messages follow from the receiver to the path that the tree-building messages follow from the receiver to
skipping to change at line 405 skipping to change at line 408
forward multicast UDP data packets. PIM utilizes network-based forward multicast UDP data packets. PIM utilizes network-based
source discovery. PIM-SSM, however, utilizes application-based source discovery. PIM-SSM, however, utilizes application-based
source discovery. IP multicast packets fall within the range of source discovery. IP multicast packets fall within the range of
224.0.0.0 through 239.255.255.255 for IPv4 and ff00::/8 for IPv6. 224.0.0.0 through 239.255.255.255 for IPv4 and ff00::/8 for IPv6.
The telemetry solution will need to work within these IP address The telemetry solution will need to work within these IP address
ranges and provide telemetry data for this UDP traffic. ranges and provide telemetry data for this UDP traffic.
A proposed solution for encapsulating the telemetry instruction A proposed solution for encapsulating the telemetry instruction
header and metadata in IPv6 packets is described in [RFC9486]. header and metadata in IPv6 packets is described in [RFC9486].
5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute 5.3. Application of MVPN PMSI Tunnel Attribute
IOAM, and the recommendations of this document, are equally IOAM, and the recommendations of this document, are equally
applicable to multicast MPLS forwarded packets. Multipoint Label applicable to multicast MPLS forwarded packets as described in
Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress Replication (IR), [RFC6514]. Multipoint Label Distribution Protocol (mLDP), P2MP RSVP-
and PIM Multicast Distribution Tree (MDT) SAFI with GRE Transport are TE, Ingress Replication (IR), and PIM Multicast Distribution Tree
all commonly used within a Multicast VPN (MVPN) environment utilizing (MDT) SAFI with GRE Transport are all commonly used within a
MVPN procedures such as multicast in MPLS/BGP IP VPNs [RFC6513] and Multicast VPN (MVPN) environment utilizing MVPN procedures such as
BGP encoding and procedures for multicast in MPLS/BGP IP VPNs multicast in MPLS/BGP IP VPNs [RFC6513] and BGP encoding and
[RFC6514]. mLDP LDP extensions for P2MP and multipoint-to-multipoint procedures for multicast in MPLS/BGP IP VPNs [RFC6514]. mLDP LDP
(MP2MP) label switched paths (LSPs) [RFC6388] provide extensions to extensions for P2MP and multipoint-to-multipoint (MP2MP) label
LDP to establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS switched paths (LSPs) [RFC6388] provide extensions to LDP to
networks. The telemetry solution will need to be able to follow establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS networks.
these P2MP and MP2MP paths. The telemetry instruction header and The telemetry solution will need to be able to follow these P2MP and
data should be encapsulated into MPLS packets on P2MP and MP2MP MP2MP paths. The telemetry instruction header and data should be
paths. encapsulated into MPLS packets on P2MP and MP2MP paths.
6. Security Considerations 6. Security Considerations
The schemes discussed in this document share the same security The schemes discussed in this document share the same security
considerations for the IOAM trace option [RFC9197] and the IOAM DEX considerations for the IOAM trace option [RFC9197] and the IOAM DEX
option [RFC9326]. In particular, since multicast has a built-in option [RFC9326]. In particular, since multicast has a built-in
nature for packet amplification, the possible amplification risk for nature for packet amplification, the possible amplification risk for
the DEX-based scheme is greater than the case of unicast. Hence, the DEX-based scheme is greater than the case of unicast. Hence,
stricter mechanisms for protections need to be applied. In addition stricter mechanisms for protections need to be applied. In addition
to selecting packets to enable DEX and to limit the exported traffic to selecting packets to enable DEX and to limit the exported traffic
skipping to change at line 540 skipping to change at line 543
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003,
<https://www.rfc-editor.org/info/rfc3605>. <https://www.rfc-editor.org/info/rfc3605>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<https://www.rfc-editor.org/info/rfc4601>.
[RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450, [RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450,
DOI 10.17487/RFC6450, December 2011, DOI 10.17487/RFC6450, December 2011,
<https://www.rfc-editor.org/info/rfc6450>. <https://www.rfc-editor.org/info/rfc6450>.
[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2: [RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
Traceroute Facility for IP Multicast", RFC 8487, Traceroute Facility for IP Multicast", RFC 8487,
DOI 10.17487/RFC8487, October 2018, DOI 10.17487/RFC8487, October 2018,
<https://www.rfc-editor.org/info/rfc8487>. <https://www.rfc-editor.org/info/rfc8487>.
[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for [RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
 End of changes. 14 change blocks. 
66 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.48.