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 PMSI Tunnel 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 [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 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 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 MDT SAFI with GRE Transport are all commonly used within a | TE, Ingress Replication (IR), and PIM Multicast Distribution Tree | |||
(MDT) SAFI with GRE Transport are all commonly used within a | ||||
Multicast VPN (MVPN) environment utilizing MVPN procedures such as | Multicast VPN (MVPN) environment utilizing MVPN procedures such as | |||
Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encoding and | multicast in MPLS/BGP IP VPNs [RFC6513] and BGP encoding and | |||
Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514]. MLDP LDP | procedures for multicast in MPLS/BGP IP VPNs [RFC6514]. mLDP LDP | |||
Extension for P2MP and MP2MP LSPs [RFC6388] provides extensions to | extensions for P2MP and multipoint-to-multipoint (MP2MP) label | |||
LDP to establish point-to-multipoint (P2MP) and multipoint-to- | switched paths (LSPs) [RFC6388] provide extensions to LDP to | |||
multipoint (MP2MP) label switched paths (LSPs) in MPLS networks. The | establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS networks. | |||
telemetry solution will need to be able to follow these P2MP and | The telemetry solution will need to be able to follow these P2MP and | |||
MP2MP paths. The telemetry instruction header and data should be | MP2MP paths. The telemetry instruction header and data should be | |||
encapsulated into MPLS packets on P2MP and MP2MP 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 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>. | |||
[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 | ||||
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. 76 change blocks. | ||||
236 lines changed or deleted | 243 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |