rfc9630.original   rfc9630.txt 
MBONED H. Song Internet Engineering Task Force (IETF) H. Song
Internet-Draft M. McBride Request for Comments: 9630 M. McBride
Intended status: Standards Track Futurewei Technologies Category: Standards Track Futurewei Technologies
Expires: 28 December 2024 G. Mirsky ISSN: 2070-1721 G. Mirsky
Ericsson Ericsson
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
H. Asaeda H. Asaeda
NICT NICT
T. Zhou T. Zhou
Huawei Technologies Huawei Technologies
26 June 2024 August 2024
Multicast On-path Telemetry using IOAM Multicast On-Path Telemetry Using In Situ Operations, Administration,
draft-ietf-mboned-multicast-telemetry-12 and Maintenance (IOAM)
Abstract Abstract
This document specifies the solutions to meet the requirements of on- This document specifies two solutions to meet the requirements of on-
path telemetry for multicast traffic using In-situ OAM. While In- path telemetry for multicast traffic using IOAM. While IOAM is
situ OAM is advantageous for multicast traffic telemetry, some unique advantageous for multicast traffic telemetry, some unique challenges
challenges are present. This document provides the solutions based are present. This document provides the solutions based on the IOAM
on the In-situ OAM trace option and direct export option to support trace option and direct export option to support the telemetry data
the telemetry data correlation and the multicast tree reconstruction correlation and the multicast tree reconstruction without incurring
without incurring data redundancy. data redundancy.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 28 December 2024. 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/rfc9630.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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
2. Requirements for Multicast Traffic Telemetry . . . . . . . . 4 1.1. Requirements Language
3. Issues of Existing Techniques . . . . . . . . . . . . . . . . 4 2. Requirements for Multicast Traffic Telemetry
4. Modifications and Extensions based on Existing Solutions . . 5 3. Issues of Existing Techniques
4.1. Per-hop postcard using IOAM DEX . . . . . . . . . . . . . 5 4. Modifications and Extensions Based on Existing Solutions
4.2. Per-section postcard for IOAM Trace . . . . . . . . . . . 7 4.1. Per-Hop Postcard Using IOAM DEX
5. Application Considerations for Multicast Protocols . . . . . 8 4.2. Per-Section Postcard for IOAM Trace
5.1. Mtrace version 2 . . . . . . . . . . . . . . . . . . . . 9 5. Application Considerations for Multicast Protocols
5.2. Application in PIM . . . . . . . . . . . . . . . . . . . 9 5.1. Mtrace Version 2
5.3. Application of MVPN X-PMSI Tunnel Encapsulation 5.2. Application in PIM
Attribute . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses
1. Introduction 1. Introduction
IP Multicast has had many useful applications for several decades. IP multicast has had many useful applications for several decades.
[I-D.ietf-pim-multicast-lessons-learned] provides a thorough [MULTICAST-LESSONS-LEARNED] provides a thorough historical
historical perspective about the design and deployment of many of the perspective about the design and deployment of many of the multicast
multicast routing protocols in use with the various applications. We routing protocols in use with various applications. We will mention
will mention of few of these throughout this document and in the of few of these throughout this document and in the Application
Applications Considerations section. IP Multicast has been used by Considerations section (Section 5). IP multicast has been used by
residential broadband customers across operator networks, private residential broadband customers across operator networks, private
MPLS customers and internal customers within corporate intranets. IP MPLS customers, and internal customers within corporate intranets.
Multicast has provided real time interactive online meetings or IP multicast has provided real-time interactive online meetings or
podcasts, IPTV, and financial markets real-time data, which all have podcasts, IPTV, and financial markets' real-time data, all of which
a reliance on UDP's unreliable transport. End-to-end QOS, therefore, rely on UDP's unreliable transport. End-to-end QoS, therefore,
should be a critical component of multicast deployment in order to should be a critical component of multicast deployments in order to
provide a good end user experience within a specific operational provide a good end-user experience within a specific operational
domain. In multicast real-time media streaming, if a single packet domain. In multicast real-time media streaming, if a single packet
is lost within a keyframe and cannot be recovered using forward error is lost within a keyframe and cannot be recovered using forward error
correction, this can result in many receivers being unable to decode correction, many receivers will be unable to decode subsequent frames
subsequent frames within the Group of Pictures (GoP), resulting in within the Group of Pictures (GoP), which results in video freezes or
video freezes or black pictures until another keyframe is delivered. black pictures until another keyframe is delivered. Unexpectedly
Unexpectedly long delays in delivery of packets can result in long delays in delivery of packets can cause timeouts with similar
timeouts within similar results. Multicast packet loss and delays results. Multicast packet loss and delays can therefore affect
can therefore affect application performance and the user experience application performance and the user experience within a domain.
within a domain.
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 In-situ OAM (IOAM) [RFC9197], on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct
IOAM Direct Export (DEX) [RFC9326] IOAM Marking-based Postcard Export (DEX) [RFC9326], IOAM Postkcard-Based Telemetry - Marking
(PBT-M) [I-D.song-ippm-postcard-based-telemetry], and Hybrid Two-Step (PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS)
(HTS) [I-D.ietf-ippm-hybrid-two-step], complement existing active OAM [HYBRID-TWO-STEP], complement existing active OAM performance
performance monitoring methods like ICMP ping [RFC0792]. However, monitoring methods like ICMP ping [RFC0792]. However, multicast
multicast traffic's unique characteristics present challenges in traffic's unique characteristics present challenges in applying these
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. When IOAM
trace data is added to multicast packets, each replicated packet trace data is added to multicast packets, each replicated packet
retains telemetry data for its entire forwarding path. This results retains telemetry data for its entire forwarding path. This results
in redundant data collection for common path segments, unnecessarily in redundant data collection for common path segments, unnecessarily
consuming extra network bandwidth. For large multicast trees, this consuming extra network bandwidth. For large multicast trees, this
redundancy is substantial. Using solutions like IOAM DEX could be redundancy is substantial. Using solutions like IOAM DEX could be
more efficient by eliminating data redundancy, but IOAM DEX lacks a more efficient by eliminating data redundancy, but IOAM DEX lacks a
branch identifier, complicating telemetry data correlation and branch identifier, complicating telemetry data correlation and
multicast tree reconstruction. multicast tree reconstruction.
This draft provides two solutions to the IOAM data redundancy problem This document provides two solutions to the IOAM data-redundancy
based on the IOAM standards. The requirements for multicast traffic problem based on the IOAM standards. The requirements for multicast
telemetry are discussed along with the issues of the existing on-path traffic telemetry are discussed along with the issues of the existing
telemetry techniques. We propose modifications and extensions to on-path telemetry techniques. We propose modifications and
make these techniques adapt to multicast in order for the original extensions to make these techniques adapt to multicast in order for
multicast tree to be correctly reconstructed while eliminating the original multicast tree to be correctly reconstructed while
redundant data. This document does not cover the operational eliminating redundant data. This document does not cover the
considerations such as how to enable the telemetry on a subset of the operational considerations such as how to enable the telemetry on a
traffic to avoid overloading the network or the data collector. subset of the traffic to avoid overloading the network or the data
collector.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Requirements for Multicast Traffic Telemetry 2. Requirements for Multicast Traffic Telemetry
Multicast traffic is forwarded through a multicast tree. With PIM Multicast traffic is forwarded through a multicast tree. With PIM
[RFC7761] and P2MP, the forwarding tree is established and maintained [RFC7761] and Point-to-Multipoint (P2MP), the forwarding tree is
by the multicast routing protocol. established and maintained by the multicast routing protocol.
The requirements for multicast traffic telemetry which are addressed The requirements for multicast traffic telemetry that are addressed
by the solutions in this document are: by the solutions in this document are:
* Reconstruct and visualize the multicast tree through data plane * Reconstruct and visualize the multicast tree through data-plane
monitoring. monitoring.
* Gather the multicast packet delay and jitter performance on each * Gather the multicast packet delay and jitter performance on each
path. path.
* Find the multicast packet drop location and reason. * Find the multicast packet-drop location and reason.
In order to meet all of these requirements, we need the ability to In order to meet all of these requirements, we need the ability to
directly monitor the multicast traffic and derive data from the directly monitor the multicast traffic and derive data from the
multicast packets. The conventional OAM mechanisms, such as multicast packets. The conventional OAM mechanisms, such as
multicast ping [RFC6450] trace [RFC8487], and RTCP [RFC3605] are not multicast ping [RFC6450], trace [RFC8487], and RTCP [RFC3605], are
sufficient to meet all of these requirements. The telemetry methods, not sufficient to meet all of these requirements. The telemetry
in this draft, do meet these requirements by providing granular hop methods in this document meet these requirements by providing
by hop network monitoring along with the reduction of data granular hop-by-hop network monitoring along with the reduction of
redundancy. data redundancy.
3. Issues of Existing Techniques 3. Issues of Existing Techniques
On-path Telemetry techniques that directly retrieve data from On-path telemetry techniques that directly retrieve data from
multicast traffic's live network experience are ideal for addressing multicast traffic's live network experience are ideal for addressing
the aforementioned requirements. The representative techniques the aforementioned requirements. The representative techniques
include In-situ OAM (IOAM) Trace option [RFC9197], IOAM Direct Export include IOAM Trace option [RFC9197], IOAM DEX option [RFC9326], and
(DEX) option [RFC9326], and PBT-M PBT-M [POSTCARD-TELEMETRY]. However, unlike unicast, multicast poses
[I-D.song-ippm-postcard-based-telemetry]. However, unlike unicast, some unique challenges to applying these techniques.
multicast poses some unique challenges to applying these techniques.
Multicast packets are replicated at each branch fork node in the Multicast packets are replicated at each branch fork node in the
corresponding multicast tree. Therefore, there are multiple copies corresponding multicast tree. Therefore, there are multiple copies
of the original multicast packet in the network. of the original multicast packet in the network.
When the IOAM trace option is utilized for on-path data collection, When the IOAM trace option is utilized for on-path data collection,
partial trace data is replicated into the packet copy for each branch partial trace data is replicated into the packet copy for each branch
of the multicast tree. Consequently, at the leaves of the multicast of the multicast tree. Consequently, at the leaves of the multicast
tree, each copy of the multicast packet contains a complete trace. tree, each copy of the multicast packet contains a complete trace.
This results in data redundancy, as most of the data (except from the This results in data redundancy, as most of the data (except from the
final leaf branch) appears in multiple copies, where only one is final leaf branch) appears in multiple copies, where only one is
sufficient. This redundancy introduces unnecessary header overhead, sufficient. This redundancy introduces unnecessary header overhead,
wastes network bandwidth, and complicates data processing. The wastes network bandwidth, and complicates data processing. The
larger the multicast tree or the longer the multicast path, the more larger the multicast tree or the longer the multicast path, the more
severe the redundancy problem becomes. severe the redundancy problem becomes.
The postcard-based solutions (e.g., IOAM DEX), can eliminate data The postcard-based solutions (e.g., IOAM DEX) can eliminate data
redundancy because each node on the multicast tree sends a postcard redundancy because each node on the multicast tree sends a postcard
with only local data. However, these methods cannot accurately track with only local data. However, these methods cannot accurately track
and correlate the tree branches due to the absence of branching and correlate the tree branches due to the absence of branching
information. For instance, in a multicast tree shown in Figure 1, information. For instance, in the multicast tree shown in Figure 1,
Node B has two branches, one to Node C and the other to node D; Node B has two branches, one to Node C and the other to node D;
further, Node C leads to Node E and Node D leads to Node F. When further, Node C leads to Node E, and Node D leads to Node F (not
applying postcard-based methods, it is impossible to determine shown). When applying postcard-based methods, it is impossible to
whether Node E is the next hop of Node C or Node D from the received determine whether Node E is the next hop of Node C or Node D from the
postcards alone, unless one correlates the exporting nodes with received postcards alone, unless one correlates the exporting nodes
knowledge about the tree collected by other means (e.g., mtrace). with knowledge about the tree collected by other means (e.g.,
Such correlation is undesirable because it introduces extra work and mtrace). Such correlation is undesirable because it introduces extra
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 instruction header of
the IOAM DEX Option. The second solution combines the IOAM trace the IOAM DEX Option. The second solution combines the IOAM trace
option and postcards for redundancy removal. option and postcards for 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 IOAM DEX option has an
instruction header which can be used to hold the branch identifier. instruction header which can be used to hold the branch identifier.
To make the branch identifier globally unique, the branch fork node To make the branch identifier globally unique, the branch fork node
ID plus an index is used. For example, as shown in Figure 1, Node B ID plus an index is used. For example, as shown in Figure 1, Node B
has two branches: one to Node C and the other to Node D. Node B may has two branches: one to Node C and the other to Node D. Node B may
use [B, 0] as the branch identifier for the branch to C, and [B, 1] use [B, 0] as the branch identifier for the branch to C, and [B, 1]
for the branch to D. The identifier is carried with the multicast for the branch to D. The identifier is carried with the multicast
packet until the next branch fork node. Each node MUST export the packet until the next branch fork node. Each node MUST export the
branch identifier in the received IOAM DEX header in the postcards it branch identifier in the received IOAM DEX header in the postcards it
sends. The branch identifier, along with the other fields such as sends. The branch identifier, along with the other fields such as
flow ID and sequence number, is sufficient for the data collector to Flow ID and Sequence Number, is sufficient for the data collector to
reconstruct the topology of the multicast tree. reconstruct the 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 brace contains 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}
^ ^ ^ ^ ^ ^ ^ ^ ^ ^
: : : : : : : : : :
: : : : : : : : : :
: : : +-:-+ +-:-+ : : : +-:-+ +-:-+
: : : | | | | : : : | | | |
: : +---:----->| C |------>| E |-... : : +---:----->| C |------>| E |-...
+-:-+ +-:-+ | : | | | | +-:-+ +-:-+ | : | | | |
| | | |----+ : +---+ +---+ | | | |----+ : +---+ +---+
| 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., branch ID) for each branch in its multicast tree instance and
include it in the IOAM DEX option header. The branch ID remains include it in the IOAM DEX option header. The branch ID remains
unchanged until the next branch fork node. The branch ID contains unchanged until the next branch fork node. The branch ID contains
two parts: the branch fork node ID and an interface index. two parts: the branch fork 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 node
ID is a 3-octet unsigned integer. The interface index is a two-octet ID is a 3-octet unsigned integer. The interface index is a two-octet
unsigned integer. As shown in Figure 2, the branch ID consumes 8 unsigned integer. As shown in Figure 2, the branch ID consumes 8
octets in total. The three unused octets MUST be set to 0; otherwise octets in total. The three unused octets MUST be set to 0;
the header is considered malformatted and the packet MUST be dropped. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node_id | unused | | 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 branch ID is carried as an optional field
after the flow ID and sequence number optional fields in the IOAM DEX after the Flow ID and Sequence Number optional fields in the IOAM DEX
option header. Two bits "N" and "I" (i.e., the third and fourth bits option header. Two bits "N" and "I" (i.e., the third and fourth bits
in the Extension-Flags field) are reserved to indicate the presence in the Extension-Flags field) are reserved to indicate the presence
of the optional branch ID field. "N" stands for the Node ID and "I" of the optional branch ID field. "N" stands for the Node ID, and "I"
stands for the interface index. If "N" and "I" are both set to 1, stands for the interface index. If "N" and "I" are both set to 1,
the optional multicast branch ID field is present. Two Extension- the optional multicast branch ID field is present. Two Extension-
Flag bits are used because [RFC9326] specifies that each extension Flag bits are used because [RFC9326] specifies that each extension
flag only indicates the presence of a 4-octet optional data, while we flag only indicates the presence of a 4-octet optional data field,
need more than 4 octets to encode the branch ID. The two flag bits while we need more than 4 octets to encode the branch ID. The two
MUST be both set or cleared; otherwise the header is considered flag bits MUST be both set or cleared; otherwise, the header is
malformatted and the packet MUST be dropped. 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: Carry Branch ID in IOAM DEX option header Figure 3: Carrying the Branch ID in IOAM DEX Option Header
Once a node gets the branch ID information from the upstream, it MUST Once a node gets the branch ID information from the upstream node, it
carry this information in its telemetry data export postcards, so the MUST carry this information in its telemetry data export postcards so
original multicast tree can be correctly reconstructed based on the the original multicast tree can be correctly reconstructed based on
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 [RFC9197] and the postcard-based telemetry [IFIT-FRAMEWORK]. To
[I-D.song-opsawg-ifit-framework]. To avoid data redundancy, at each avoid data redundancy, at each branch fork node, the trace data
branch fork node, the trace data accumulated up to this node is accumulated up to this node is exported by a postcard before the
exported by a postcard before the packet is replicated. In this packet is replicated. In this solution, each branch also needs to
solution, each branch also needs to maintain some identifier to help maintain some identifier to help correlate the postcards for each
correlate the postcards for each tree section. The natural way to tree section. The natural way to accomplish this is to simply carry
accomplish this is to simply carry the branch fork node's data the branch fork node's data (including its ID) in the trace of each
(including its ID) in the trace of each branch. This is also branch. This is also necessary because each replicated multicast
necessary because each replicated multicast packet can have different packet can have different telemetry data pertaining to this
telemetry data pertaining to this particular copy (e.g., node delay, particular copy (e.g., node delay, egress timestamp, and egress
egress timestamp, and egress interface). As a consequence, the local interface). As a consequence, the local data exported by each branch
data exported by each branch fork node can only contain the common fork node can only contain the common data shared by all the
data shared by all the replicated packets (e.g., ingress interface replicated packets (e.g., ingress interface and ingress timestamp).
and ingress timestamp).
Figure 4 shows an example in a segment of a multicast tree. Node B Figure 4 shows an example in a segment of a multicast tree. Node B
and D are two branch fork nodes and they will export a postcard and D are two branch fork nodes, and they will export a postcard
covering the trace data for the previous section. The end node of covering the trace data for the previous section. The end node of
each path will also need to export the data of the last section as a each path will also need to export the data of the last section as a
postcard. postcard.
P:{A,B'} P:{B1,C,D'} P:{A,B'} P:{B1,C,D'}
^ ^ ^ ^
: : : :
: : : :
: : {D1} : : {D1}
: : +--... : : +--...
skipping to change at page 8, line 37 skipping to change at line 354
: +-->| C |----->| D |-----... : +-->| C |----->| D |-----...
+---+ +---+ | | | | |--+ +---+ +---+ | | | | |--+
| | {A} | |--+ +---+ +---+ | | | {A} | |--+ +---+ +---+ |
| A |---->| B | +--... | A |---->| B | +--...
| | | |--+ +---+ {D3} | | | |--+ +---+ {D3}
+---+ +---+ | | |{B2,E} +---+ +---+ | | |{B2,E}
+-->| E |--... +-->| E |--...
{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 which nodes, as well as the leaf nodes, to export the postcards that
contains 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 zero 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 Remaining Length 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 receiver to the path that the tree-building messages follow from the receiver to
source. An Mtrace2 client sends an Mtrace2 Query to a Last-Hop the source. An Mtrace2 client sends an Mtrace2 Query to a Last-Hop
Router (LHR) and the LHR forwards the packet as an Mtrace2 Request Router (LHR), and the LHR forwards the packet as an Mtrace2 Request
towards the source or a Rendezvous Point (RP) after appending a towards the source or a Rendezvous Point (RP) after appending a
response block. Each router along the path proceeds the same response block. Each router along the path proceeds with the same
operations. When the First-Hop Router (FHR) receives the Request operations. When the First-Hop Router (FHR) receives the Request
packet, it appends its own response block, turns the Request packet packet, it appends its own response block, turns the Request packet
into a Reply, and unicasts the Reply back to the Mtrace2 client.. into a Reply, and unicasts the Reply back to the Mtrace2 client.
New on-path telemetry techniques will enhance Mtrace2, and other New on-path telemetry techniques will enhance Mtrace2, and other
existing OAM solutions, with more granular and realtime network existing OAM solutions, with more granular and real-time network
status data through direct measurements. There are various multicast status data through direct measurements. There are various multicast
protocols that are used to forward the multicast data. Each will protocols that are used to forward the multicast data. Each will
require their own unique on-path telemetry solution. Mtrace2 doesn't require its own unique on-path telemetry solution. Mtrace2 doesn't
integrate with IOAM directly, but network management systems may use integrate with IOAM directly, but network management systems may use
Mtrace2 to learn about routers of interest. Mtrace2 to learn about routers of interest.
5.2. Application in PIM 5.2. Application in PIM
PIM-SM [RFC7761] is the most widely used multicast routing protocol PIM - Sparse Mode (PIM-SM) [RFC7761] is the most widely used
deployed today. PIM-SSM, however, is the preferred method due to its multicast routing protocol deployed today. PIM - Source-Specific
Multicast (PIM-SSM), however, is the preferred method due to its
simplicity and removal of network source discovery complexity. With simplicity and removal of network source discovery complexity. With
PIM, control plane state is established in the network in order to PIM, control plane state is established in the network in order to
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 header and metadata in IPv6 packets is described in [RFC9486].
[I-D.ietf-ippm-ioam-ipv6-options].
5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute 5.3. Application of MVPN X-PMSI Tunnel Encapsulation 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. Multipoint Label
Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress Replication (IR) Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress Replication (IR),
and PIM MDT SAFI with GRE Transport are all commonly used within a and PIM Multicast Distribution Tree (MDT) SAFI with GRE Transport are
Multicast VPN (MVPN) environment utilizing MVPN procedures such as all commonly used within a Multicast VPN (MVPN) environment utilizing
Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encoding and MVPN procedures such as multicast in MPLS/BGP IP VPNs [RFC6513] and
Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514]. MLDP LDP BGP encoding and procedures for multicast in MPLS/BGP IP VPNs
Extension for P2MP and MP2MP LSPs [RFC6388] provides extensions to [RFC6514]. mLDP LDP extensions for P2MP and multipoint-to-multipoint
LDP to establish point-to-multipoint (P2MP) and multipoint-to- (MP2MP) label switched paths (LSPs) [RFC6388] provide extensions to
multipoint (MP2MP) label switched paths (LSPs) in MPLS networks. The LDP to establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS
telemetry solution will need to be able to follow these P2MP and networks. The telemetry solution will need to be able to follow
MP2MP paths. The telemetry instruction header and data should be these P2MP and MP2MP paths. The telemetry instruction header and
encapsulated into MPLS packets on P2MP and MP2MP paths. data should be 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 limiting the exported traffic to selecting packets to enable DEX and to limit the exported traffic
rate, we can also allows only a subset of the nodes in a multicast rate, we can also allow only a subset of the nodes in a multicast
tree to process the option and export the data (e.g., only the tree to process the option and export the data (e.g., only the
branching nodes in the multicast tree are configured to process the branching nodes in the multicast tree are configured to process the
option). option).
7. IANA Considerations 7. IANA Considerations
The document requests two new extension flag registrations in the IANA has registered two Extension-Flags, as described in Section 4.1,
"IOAM DEX Extension-Flags" registry, as described in Section 4.1. in the "IOAM DEX Extension-Flags" registry.
Bit 2 "Multicast Branching Node ID [RFC XXXX] [RFC Editor: please
replace with the RFC number of the current document]".
Bit 3 "Multicast Branching Interface Index [RFC XXXX] [RFC Editor:
please replace with the RFC number of the current document]".
8. Acknowledgments +=====+=====================================+===========+
| Bit | Description | Reference |
+=====+=====================================+===========+
| 2 | Multicast Branching Node ID | This RFC |
+-----+-------------------------------------+-----------+
| 3 | Multicast Branching Interface Index | This RFC |
+-----+-------------------------------------+-----------+
The authors would like to thank Gunter Van de Velde, Brett Sheffield, Table 1: IOAM DEX Extension-Flags
Eric Vyncke, Frank Brockners, Nils Warnke, Jake Holland, Dino
Farinacci, Henrik Nydell, Zaheduzzaman Sarker and Toerless Eckert for
their comments and suggestions.
9. References 8. References
9.1. Normative References 8.1. Normative References
[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>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point- Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
skipping to change at page 11, line 41 skipping to change at line 496
Ed., "Data Fields for In Situ Operations, Administration, Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>. May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326, Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022, DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>. <https://www.rfc-editor.org/info/rfc9326>.
9.2. Informative References 8.2. Informative References
[I-D.ietf-ippm-hybrid-two-step] [HYBRID-TWO-STEP]
Mirsky, G., Lingqiang, W., Zhui, G., Song, H., and P. Mirsky, G., Lingqiang, W., Zhui, G., Song, H., and P.
Thubert, "Hybrid Two-Step Performance Measurement Method", Thubert, "Hybrid Two-Step Performance Measurement Method",
Work in Progress, Internet-Draft, draft-ietf-ippm-hybrid- Work in Progress, Internet-Draft, draft-ietf-ippm-hybrid-
two-step-00, 4 October 2023, two-step-01, 5 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm- <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
hybrid-two-step-00>. hybrid-two-step-01>.
[I-D.ietf-ippm-ioam-ipv6-options] [IFIT-FRAMEWORK]
Bhandari, S. and F. Brockners, "IPv6 Options for In Situ Song, H., Qin, F., Chen, H., Jin, J., and J. Shin,
Operations, Administration, and Maintenance (IOAM)", Work "Framework for In-situ Flow Information Telemetry", Work
in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6- in Progress, Internet-Draft, draft-song-opsawg-ifit-
options-12, 7 May 2023, framework-21, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm- <https://datatracker.ietf.org/doc/html/draft-song-opsawg-
ioam-ipv6-options-12>. ifit-framework-21>.
[I-D.ietf-pim-multicast-lessons-learned] [MULTICAST-LESSONS-LEARNED]
Farinacci, D., Giuliano, L., McBride, M., and N. Warnke, Farinacci, D., Giuliano, L., McBride, M., and N. Warnke,
"Multicast Lessons Learned from Decades of Deployment "Multicast Lessons Learned from Decades of Deployment
Experience", Work in Progress, Internet-Draft, draft-ietf- Experience", Work in Progress, Internet-Draft, draft-ietf-
pim-multicast-lessons-learned-03, 4 March 2024, pim-multicast-lessons-learned-04, 22 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pim- <https://datatracker.ietf.org/doc/html/draft-ietf-pim-
multicast-lessons-learned-03>. multicast-lessons-learned-04>.
[I-D.song-ippm-postcard-based-telemetry] [POSTCARD-TELEMETRY]
Song, H., Mirsky, G., Zhou, T., Li, Z., Graf, T., Mishra, Song, H., Mirsky, G., Zhou, T., Li, Z., Graf, T., Mishra,
G. S., Shin, J., and K. Lee, "On-Path Telemetry using G., Shin, J., and K. Lee, "On-Path Telemetry using Packet
Packet Marking to Trigger Dedicated OAM Packets", Work in Marking to Trigger Dedicated OAM Packets", Work in
Progress, Internet-Draft, draft-song-ippm-postcard-based- Progress, Internet-Draft, draft-song-ippm-postcard-based-
telemetry-16, 2 June 2023, telemetry-16, 2 June 2023,
<https://datatracker.ietf.org/doc/html/draft-song-ippm- <https://datatracker.ietf.org/doc/html/draft-song-ippm-
postcard-based-telemetry-16>. postcard-based-telemetry-16>.
[I-D.song-opsawg-ifit-framework]
Song, H., Qin, F., Chen, H., Jin, J., and J. Shin,
"Framework for In-situ Flow Information Telemetry", Work
in Progress, Internet-Draft, draft-song-opsawg-ifit-
framework-21, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-song-opsawg-
ifit-framework-21>.
[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>.
[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
In Situ Operations, Administration, and Maintenance
(IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
<https://www.rfc-editor.org/info/rfc9486>.
Acknowledgments
The authors would like to thank Gunter Van de Velde, Brett Sheffield,
Éric Vyncke, Frank Brockners, Nils Warnke, Jake Holland, Dino
Farinacci, Henrik Nydell, Zaheduzzaman Sarker, and Toerless Eckert
for their comments and suggestions.
Authors' Addresses Authors' Addresses
Haoyu Song Haoyu Song
Futurewei Technologies Futurewei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, Santa Clara, CA
United States of America United States of America
Email: hsong@futurewei.com Email: hsong@futurewei.com
Mike McBride Mike McBride
Futurewei Technologies Futurewei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, Santa Clara, CA
United States of America United States of America
Email: mmcbride@futurewei.com Email: mmcbride@futurewei.com
Greg Mirsky Greg Mirsky
Ericsson Ericsson
United States of America United States of America
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Gyan Mishra Gyan Mishra
Verizon Inc. Verizon Inc.
 End of changes. 72 change blocks. 
227 lines changed or deleted 228 lines changed or added

This html diff was produced by rfcdiff 1.48.