<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-mboned-multicast-telemetry-12" number="9630" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2024-08-27T09:54:40" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mboned-multicast-telemetry-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9630" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Multicast Telemetry">Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM)</title>
    <seriesInfo name="RFC" value="9630" stream="IETF"/>
    <author fullname="Haoyu Song" initials="H." surname="Song">
      <organization showOnFrontPage="true">Futurewei Technologies</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>hsong@futurewei.com</email>
      </address>
    </author>
    <author fullname="Mike McBride" initials="M." surname="McBride">
      <organization showOnFrontPage="true">Futurewei Technologies</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>mmcbride@futurewei.com</email>
      </address>
    </author>
    <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <author fullname="Gyan Mishra" initials="G." surname="Mishra">
      <organization showOnFrontPage="true">Verizon Inc.</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
    <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
      <organization abbrev="NICT" showOnFrontPage="true">National Institute of Information and Communications Technology</organization>
      <address>
        <postal>
          <country>Japan</country>
        </postal>
        <email>asaeda@nict.go.jp</email>
      </address>
    </author>
    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <date month="08" year="2024"/>
    <area>OPS</area>
    <workgroup>mboned</workgroup>
    <keyword>Multicast</keyword>
    <keyword>Telemetry</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies two solutions to meet the requirements of
      on-path telemetry for multicast traffic using IOAM.  While
      IOAM is advantageous for multicast traffic telemetry, some unique
      challenges are present.  This document provides the solutions based on
      the IOAM trace option and direct export option to support the
      telemetry data correlation and the multicast tree reconstruction without
      incurring data redundancy.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9630" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-multicast-">Requirements for Multicast Traffic Telemetry</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issues-of-existing-techniqu">Issues of Existing Techniques</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-modifications-and-extension">Modifications and Extensions Based on Existing Solutions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-hop-postcard-using-ioam">Per-Hop Postcard Using IOAM DEX</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-section-postcard-for-io">Per-Section Postcard for IOAM Trace</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-considerations-">Application Considerations for Multicast Protocols</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mtrace-version-2">Mtrace Version 2</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-in-pim">Application in PIM</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-of-mvpn-pmsi-tu">Application of MVPN PMSI Tunnel Attribute</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">IP multicast has had many useful applications for several decades. 
	    <xref target="I-D.ietf-pim-multicast-lessons-learned" format="default" sectionFormat="of" derivedContent="MULTICAST-LESSONS-LEARNED"/> provides a thorough historical perspective about the design and
      deployment of many of the multicast routing protocols in use with various applications. We will mention of few of these throughout this 
      document and in the Application Considerations section (<xref target="application-considerations" format="default" sectionFormat="of" derivedContent="Section 5"/>). IP multicast has been used by residential broadband customers across operator networks, 
      private MPLS customers, and internal customers within corporate intranets.  IP multicast has provided real-time interactive online meetings or 
      podcasts, IPTV, and financial markets' real-time data, all of which rely  on UDP's unreliable transport. End-to-end QoS, therefore, 
      should be a critical component of multicast deployments in order to provide a good end-user experience within a specific operational domain. 
      In multicast real-time media streaming, if a single packet is lost within a keyframe and 
      cannot be recovered using forward error correction, many receivers will be unable to decode subsequent frames 
      within the Group of Pictures (GoP), which results in video freezes or black pictures until another keyframe is delivered. Unexpectedly long 
      delays in delivery of packets can cause timeouts with similar results. Multicast packet loss and delays can therefore affect application 
      performance and the user experience within a domain.</t>
      <t indent="0" pn="section-1-2">It is essential to monitor the performance of multicast traffic. New on-path telemetry techniques, such as 
		   IOAM <xref target="RFC9197" format="default" sectionFormat="of" derivedContent="RFC9197"/>, 
		   IOAM Direct Export (DEX) <xref target="RFC9326" format="default" sectionFormat="of" derivedContent="RFC9326"/>,
        IOAM Postcard-Based Telemetry - Marking (PBT-M) <xref target="I-D.song-ippm-postcard-based-telemetry" format="default" sectionFormat="of" derivedContent="POSTCARD-TELEMETRY"/>, and
	       Hybrid Two-Step (HTS) <xref target="I-D.ietf-ippm-hybrid-two-step" format="default" sectionFormat="of" derivedContent="HYBRID-TWO-STEP"/>, 
		   complement existing active OAM performance monitoring methods like ICMP ping <xref target="RFC0792" format="default" sectionFormat="of" derivedContent="RFC0792"/>. However, multicast traffic's unique characteristics 
		   present challenges in applying these techniques efficiently.</t>
      <t indent="0" pn="section-1-3">The IP multicast packet data for a particular (S,G) state remains identical across different branches to multiple receivers <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/>. 
		When IOAM trace data is added to multicast packets, each replicated packet retains telemetry data for its entire forwarding path. 
		This results in redundant data collection for common path segments, unnecessarily consuming extra network bandwidth. 
		For large multicast trees, this redundancy is substantial. Using solutions like IOAM DEX could be more efficient by eliminating data redundancy, 
		but IOAM DEX lacks a branch identifier, complicating telemetry data correlation and multicast tree reconstruction.</t>
      <t indent="0" pn="section-1-4">This document provides two solutions to the IOAM data-redundancy problem based on the IOAM standards. The requirements for multicast traffic telemetry
           are discussed along with the issues of the existing on-path telemetry techniques. We propose modifications and extensions 
           to make these techniques adapt to multicast in order for the original multicast tree to be correctly reconstructed while
           eliminating redundant data. This document does not cover the operational considerations such as how to enable the telemetry on a subset of the traffic to avoid overloading 
		   the network or the data collector.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-for-multicast-">Requirements for Multicast Traffic Telemetry</name>
      <t indent="0" pn="section-2-1"> Multicast traffic is forwarded through a multicast tree. With PIM <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> and Point-to-Multipoint (P2MP), the forwarding
	    tree is established and maintained by the multicast routing protocol. </t>
      <t indent="0" pn="section-2-2"> The requirements for multicast traffic telemetry that are addressed by the solutions in this document are:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-3">
        <li pn="section-2-3.1">
          <t indent="0" pn="section-2-3.1.1"> Reconstruct and visualize the multicast tree through data-plane monitoring.</t>
        </li>
        <li pn="section-2-3.2">
          <t indent="0" pn="section-2-3.2.1"> Gather the multicast packet delay and jitter performance on each path. </t>
        </li>
        <li pn="section-2-3.3">
          <t indent="0" pn="section-2-3.3.1"> Find the multicast packet-drop location and reason. </t>
        </li>
      </ul>
      <t indent="0" pn="section-2-4"> In order to meet all of these requirements, we need the ability to directly monitor the multicast traffic and derive data from the multicast packets. 
	    The conventional OAM mechanisms, such as multicast ping <xref target="RFC6450" format="default" sectionFormat="of" derivedContent="RFC6450"/>, trace <xref target="RFC8487" format="default" sectionFormat="of" derivedContent="RFC8487"/>, and 
	    RTCP <xref target="RFC3605" format="default" sectionFormat="of" derivedContent="RFC3605"/>, are not sufficient to meet all of these requirements. The telemetry methods in this document meet
	    these requirements by providing granular hop-by-hop network monitoring along with the reduction of data redundancy.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-issues-of-existing-techniqu">Issues of Existing Techniques</name>
      <t indent="0" pn="section-3-1"> On-path telemetry techniques that directly retrieve data from multicast traffic's live network experience are ideal for
		addressing the aforementioned requirements. The representative techniques include  
	       IOAM Trace option <xref target="RFC9197" format="default" sectionFormat="of" derivedContent="RFC9197"/>, 
		   IOAM DEX option <xref target="RFC9326" format="default" sectionFormat="of" derivedContent="RFC9326"/>, and 
	       PBT-M <xref target="I-D.song-ippm-postcard-based-telemetry" format="default" sectionFormat="of" derivedContent="POSTCARD-TELEMETRY"/>. However, 
	       unlike unicast, multicast poses some unique challenges to applying these techniques. </t>
      <t indent="0" pn="section-3-2"> Multicast packets are replicated at each branch fork node in the corresponding multicast tree. Therefore, there are 
            multiple copies of the original multicast packet in the network.</t>
      <t indent="0" pn="section-3-3"> When the IOAM trace option is utilized for on-path data collection, partial trace data is replicated into the packet 
		copy for each branch of the multicast tree. Consequently, at the leaves of the multicast tree, each copy of the multicast packet 
		contains a complete trace. This results in data redundancy, as most of the data (except from the final leaf branch) appears in multiple copies, 
		where only one is sufficient. This redundancy introduces unnecessary header overhead, wastes network bandwidth, and complicates data processing. 
		The larger the multicast tree or the longer the multicast path, the more severe the redundancy problem becomes.</t>
      <t indent="0" pn="section-3-4"> The postcard-based solutions (e.g., IOAM DEX) can eliminate data redundancy because each 
	        node on the multicast tree sends a postcard with only local data. However, these methods cannot accurately track and correlate the tree branches due to the absence of branching 
	        information. For instance, in the multicast tree shown in <xref target="figure_1" format="default" sectionFormat="of" derivedContent="Figure 1"/>, 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 (not shown). When applying postcard-based methods, it is impossible to determine whether Node E 
	        is the next hop of Node C or Node D from the received postcards alone, unless one correlates the exporting nodes with knowledge about the tree collected by other 
	        means (e.g., mtrace). Such correlation is undesirable because it introduces extra work and complexity. </t>
      <t indent="0" pn="section-3-5"> The fundamental reason for this problem is that there is not an identifier (either implicit or explicit) to correlate the 
		data on each branch. </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-modifications-and-extension">Modifications and Extensions Based on Existing Solutions</name>
      <t indent="0" pn="section-4-1">We provide two solutions to address the above issues. One is based on IOAM DEX and requires an extension to the DEX Option-Type header. 
	    The second solution combines the IOAM trace option and postcards for redundancy removal.</t>
      <section numbered="true" toc="include" anchor="per-hop-postcard-using-ioam-dex" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-per-hop-postcard-using-ioam">Per-Hop Postcard Using IOAM DEX</name>
        <t indent="0" pn="section-4.1-1">One way to mitigate the postcard-based telemetry's tree-tracking weakness is to augment it with a branch identifier field. This works for
	       the IOAM DEX option because the DEX Option-Type header can be used to hold 
		   the branch identifier. To make the branch identifier 
	       globally unique, the Branching Node ID plus an index is used. For example, as shown in <xref target="figure_1" format="default" sectionFormat="of" derivedContent="Figure 1"/>, Node B 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] for the branch to D. The identifier is carried with the multicast packet until the 
	       next branch fork node. Each node <bcp14>MUST</bcp14> export the branch identifier in the received IOAM DEX header in the postcards it sends. 
	       The branch identifier, along with the other fields such as Flow ID and Sequence Number, is sufficient for the data collector to 
	       reconstruct the topology of the multicast tree.</t>
        <t indent="0" pn="section-4.1-2"><xref target="figure_1" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows an example of this solution. "P" stands for the postcard packet. The square brackets contains the branch identifier. The 
            curly braces contain the telemetry data about a specific node. </t>
        <figure anchor="figure_1" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-per-hop-postcard">Per-Hop Postcard</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-3.1">
P:[A,0]{A}  P:[A,0]{B} P:[B,1]{D}  P:[B,0]{C}   P:[B,0]{E}
     ^            ^          ^        ^           ^
     :            :          :        :           :
     :            :          :        :           :
     :            :          :      +-:-+       +-:-+  
     :            :          :      |   |       |   |
     :            :      +---:-----&gt;| C |------&gt;| E |-...
   +-:-+        +-:-+    |   :      |   |       |   |
   |   |        |   |----+   :      +---+       +---+
   | A |-------&gt;| B |        :               
   |   |        |   |--+   +-:-+             
   +---+        +---+  |   |   |
                       +--&gt;| D |--...
                           |   |
                           +---+
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-4"> Each branch fork node needs to generate a unique branch identifier (i.e., Multicast Branch ID) for each branch in its multicast tree instance and include 
	       it in the IOAM DEX Option-Type header. The Multicast Branch ID remains unchanged until the next branch fork node. The Multicast Branch ID contains two parts: 
		   the Branching Node ID and an Interface Index. </t>
        <t indent="0" pn="section-4.1-5"> Conforming to the node ID specification in IOAM <xref target="RFC9197" format="default" sectionFormat="of" derivedContent="RFC9197"/>, the Branching Node ID is a 3-octet unsigned integer. 
	       The Interface Index is a two-octet unsigned integer. As shown in <xref target="figure_2" format="default" sectionFormat="of" derivedContent="Figure 2"/>, the Multicast Branch ID consumes 8 octets in total. The three unused octets <bcp14>MUST</bcp14> be set to 0; 
		   otherwise, the header is considered malformed and the packet <bcp14>MUST</bcp14> be dropped. </t>
        <figure anchor="figure_2" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-multicast-branch-id-format">Multicast Branch ID Format</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-6.1">
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Branching Node ID                       |     unused    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       Interface Index         |           unused              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-7"> <xref target="figure_3" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows that the Multicast Branch ID is carried as an optional field 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 in the Extension-Flags field) are reserved to indicate the presence of 
			the optional Multicast Branch ID field. "N" stands for the Branching Node ID, and "I" stands for the Interface Index. If "N" and "I" are both set to 1, the optional Multicast 
			Branch ID field is present. Two Extension-Flag bits are used because <xref target="RFC9326" format="default" sectionFormat="of" derivedContent="RFC9326"/> specifies that each extension flag only indicates the presence of a 4-octet optional data field, 
			while we need more than 4 octets to encode the Multicast Branch ID. 
			The two flag bits <bcp14>MUST</bcp14> be both set or cleared; otherwise, the header is considered malformed and the packet <bcp14>MUST</bcp14> be dropped. </t>
        <figure anchor="figure_3" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-carrying-the-multicast-bran">Carrying the Multicast Branch ID in the IOAM DEX Option-Type Header</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-8.1">
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Namespace-ID           |     Flags     |F|S|N|I|E-Flags|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               IOAM-Trace-Type                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Flow ID (optional)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Sequence Number (optional)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          Multicast Branch ID (as shown in Figure 2)           |
 |                            (optional)                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-9"> Once a node gets the branch ID information from the upstream node, it <bcp14>MUST</bcp14> carry this information in its 
	   telemetry data export postcards so the original multicast tree can be correctly reconstructed based on the postcards. </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-per-section-postcard-for-io">Per-Section Postcard for IOAM Trace</name>
        <t indent="0" pn="section-4.2-1">The second solution is a combination of the IOAM trace option <xref target="RFC9197" format="default" sectionFormat="of" derivedContent="RFC9197"/> and the postcard-based telemetry <xref target="I-D.song-opsawg-ifit-framework" format="default" sectionFormat="of" derivedContent="IFIT-FRAMEWORK"/>. 
		 To avoid data redundancy, at each branch fork node, the trace data accumulated up to this node is exported
		by a postcard before the packet is replicated. In this solution, each branch also needs to maintain some identifier to help correlate the postcards
		for each tree section. The natural way to accomplish this is to simply carry the branch fork node's data (including its ID) in the trace of each branch. 
		This is also necessary because each replicated multicast packet can have different telemetry data pertaining to this particular copy (e.g., node 
		delay, egress timestamp, and egress interface). As a consequence,  the local data exported by each branch fork node can only contain the common 
		data shared by all the replicated packets (e.g., ingress interface and ingress timestamp). </t>
        <t indent="0" pn="section-4.2-2"><xref target="figure_4" format="default" sectionFormat="of" derivedContent="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 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 
	     postcard.</t>
        <figure anchor="figure_4" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-per-section-postcard">Per-Section Postcard</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.2-3.1">
             P:{A,B'}            P:{B1,C,D'} 
                ^                     ^
                :                     :
                :                     :
                :                     :    {D1}
                :                     :    +--...
                :        +---+      +---+  |
                :   {B1} |   |{B1,C}|   |--+ {D2}
                :    +--&gt;| C |-----&gt;| D |-----...
    +---+     +---+  |   |   |      |   |--+
    |   | {A} |   |--+   +---+      +---+  |
    | A |----&gt;| B |                        +--...
    |   |     |   |--+   +---+             {D3} 
    +---+     +---+  |   |   |{B2,E}
                     +--&gt;| E |--...
                    {B2} |   |
                         +---+
</artwork>
        </figure>
        <t indent="0" pn="section-4.2-4">There is no need to modify the IOAM trace option header format as specified in <xref target="RFC9197" format="default" sectionFormat="of" derivedContent="RFC9197"/>. We just need to configure the branch fork nodes, as well as the leaf nodes, to 
	   export the postcards that contain the trace data collected so far and refresh the IOAM header and data in the packet (e.g., clear the node data list to all zeros and reset the RemainingLen field to the initial value).</t>
      </section>
    </section>
    <section numbered="true" toc="include" anchor="application-considerations" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-application-considerations-">Application Considerations for Multicast Protocols</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-mtrace-version-2">Mtrace Version 2</name>
        <t indent="0" pn="section-5.1-1">Mtrace version 2 (Mtrace2) <xref target="RFC8487" format="default" sectionFormat="of" derivedContent="RFC8487"/> is a protocol that allows the tracing of an IP multicast routing path. Mtrace2 provides 
	  additional information such as the packet rates and losses, as well as other diagnostic information. Unlike unicast traceroute, Mtrace2 traces the path 
	  that the tree-building messages follow from the receiver to 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 towards the source or a Rendezvous Point (RP) after appending a response block. Each router along the 
	  path proceeds with the same operations. When the First-Hop Router (FHR) receives the Request packet, it appends its own response block, turns the 
	  Request packet into a Reply, and unicasts the Reply back to the Mtrace2 client. </t>
        <t indent="0" pn="section-5.1-2">New on-path telemetry techniques will enhance Mtrace2, and other existing OAM solutions, with more granular and real-time network status data through 
	  direct measurements. There are various multicast protocols that are used to forward the multicast data. Each will require its own unique on-path telemetry solution. 
	  Mtrace2 doesn't integrate with IOAM directly, but network management systems may use Mtrace2 to learn about routers of interest. </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-application-in-pim">Application in PIM</name>
        <t indent="0" pn="section-5.2-1">PIM - Sparse Mode (PIM-SM) <xref target="RFC7761" format="default" sectionFormat="of" derivedContent="RFC7761"/> is the most widely used 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 PIM, control plane state is established in the network in order to forward multicast 
      UDP data packets. PIM utilizes network-based source discovery. PIM-SSM, however, utilizes application-based 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. The telemetry solution will need to work within these IP address ranges and provide telemetry data for this UDP traffic. </t>
        <t indent="0" pn="section-5.2-2">A proposed solution for encapsulating the telemetry instruction header and metadata in IPv6 packets is described in 
	  <xref target="RFC9486" format="default" sectionFormat="of" derivedContent="RFC9486"/>. </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-application-of-mvpn-pmsi-tu">Application of MVPN PMSI Tunnel Attribute</name>
        <t indent="0" pn="section-5.3-1">IOAM, and the recommendations of this document, are equally applicable to multicast MPLS forwarded packets as described in <xref target="RFC6514" format="default" sectionFormat="of" derivedContent="RFC6514"/>.
      Multipoint Label Distribution Protocol (mLDP), P2MP RSVP-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 in MPLS/BGP IP VPNs <xref target="RFC6513" format="default" sectionFormat="of" derivedContent="RFC6513"/> 
      and BGP encoding and procedures for multicast in MPLS/BGP IP VPNs <xref target="RFC6514" format="default" sectionFormat="of" derivedContent="RFC6514"/>. mLDP LDP
      extensions for P2MP and multipoint-to-multipoint (MP2MP) label switched paths (LSPs) <xref target="RFC6388" format="default" sectionFormat="of" derivedContent="RFC6388"/> provide extensions to LDP to establish point-to-multipoint (P2MP) and
      MP2MP LSPs in MPLS networks. The telemetry solution will need to be able to follow these P2MP and MP2MP paths.  
      The telemetry instruction header and data should be encapsulated into MPLS packets on P2MP and MP2MP paths. </t>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">The schemes discussed in this document share the same security considerations for the IOAM trace option <xref target="RFC9197" format="default" sectionFormat="of" derivedContent="RFC9197"/> and the IOAM DEX 
      option <xref target="RFC9326" format="default" sectionFormat="of" derivedContent="RFC9326"/>. In particular, since multicast has a built-in nature for packet amplification, the possible amplification risk for the DEX-based 
      scheme is greater than the case of unicast. Hence, stricter mechanisms for protections need to be applied. In addition to selecting packets to enable DEX and to limit the exported traffic 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 branching nodes in the 
      multicast tree are configured to process the option). </t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">IANA has registered two Extension-Flags, as described in <xref target="per-hop-postcard-using-ioam-dex" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, in the "IOAM DEX Extension-Flags" registry.</t>
      <table anchor="ioam-dex-extension-flags-registry" align="center" pn="table-1">
        <name slugifiedName="name-ioam-dex-extension-flags">IOAM DEX Extension-Flags</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Bit</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">2</td>
            <td align="left" colspan="1" rowspan="1">Multicast Branching Node ID</td>
            <td align="left" colspan="1" rowspan="1">This RFC</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">Multicast Branching Interface Index</td>
            <td align="left" colspan="1" rowspan="1">This RFC</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.song-ippm-postcard-based-telemetry" to="POSTCARD-TELEMETRY"/>
    <displayreference target="I-D.ietf-ippm-hybrid-two-step" to="HYBRID-TWO-STEP"/>
    <displayreference target="I-D.ietf-pim-multicast-lessons-learned" to="MULTICAST-LESSONS-LEARNED"/>
    <displayreference target="I-D.song-opsawg-ifit-framework" to="IFIT-FRAMEWORK"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6388" target="https://www.rfc-editor.org/info/rfc6388" quoteTitle="true" derivedAnchor="RFC6388">
          <front>
            <title>Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei"/>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="B. Thomas" initials="B." surname="Thomas"/>
            <date month="November" year="2011"/>
            <abstract>
              <t indent="0">This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6388"/>
          <seriesInfo name="DOI" value="10.17487/RFC6388"/>
        </reference>
        <reference anchor="RFC6513" target="https://www.rfc-editor.org/info/rfc6513" quoteTitle="true" derivedAnchor="RFC6513">
          <front>
            <title>Multicast in MPLS/BGP IP VPNs</title>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="R. Aggarwal" initials="R." role="editor" surname="Aggarwal"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6513"/>
          <seriesInfo name="DOI" value="10.17487/RFC6513"/>
        </reference>
        <reference anchor="RFC6514" target="https://www.rfc-editor.org/info/rfc6514" quoteTitle="true" derivedAnchor="RFC6514">
          <front>
            <title>BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs</title>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="T. Morin" initials="T." surname="Morin"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6514"/>
          <seriesInfo name="DOI" value="10.17487/RFC6514"/>
        </reference>
        <reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7761" quoteTitle="true" derivedAnchor="RFC7761">
          <front>
            <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
            <author fullname="B. Fenner" initials="B." surname="Fenner"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="H. Holbrook" initials="H." surname="Holbrook"/>
            <author fullname="I. Kouvelas" initials="I." surname="Kouvelas"/>
            <author fullname="R. Parekh" initials="R." surname="Parekh"/>
            <author fullname="Z. Zhang" initials="Z." surname="Zhang"/>
            <author fullname="L. Zheng" initials="L." surname="Zheng"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t>
              <t indent="0">This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="83"/>
          <seriesInfo name="RFC" value="7761"/>
          <seriesInfo name="DOI" value="10.17487/RFC7761"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9197" target="https://www.rfc-editor.org/info/rfc9197" quoteTitle="true" derivedAnchor="RFC9197">
          <front>
            <title>Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)</title>
            <author fullname="F. Brockners" initials="F." role="editor" surname="Brockners"/>
            <author fullname="S. Bhandari" initials="S." role="editor" surname="Bhandari"/>
            <author fullname="T. Mizrahi" initials="T." role="editor" surname="Mizrahi"/>
            <date month="May" year="2022"/>
            <abstract>
              <t indent="0">In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9197"/>
          <seriesInfo name="DOI" value="10.17487/RFC9197"/>
        </reference>
        <reference anchor="RFC9326" target="https://www.rfc-editor.org/info/rfc9326" quoteTitle="true" derivedAnchor="RFC9326">
          <front>
            <title>In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting</title>
            <author fullname="H. Song" initials="H." surname="Song"/>
            <author fullname="B. Gafni" initials="B." surname="Gafni"/>
            <author fullname="F. Brockners" initials="F." surname="Brockners"/>
            <author fullname="S. Bhandari" initials="S." surname="Bhandari"/>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <date month="November" year="2022"/>
            <abstract>
              <t indent="0">In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9326"/>
          <seriesInfo name="DOI" value="10.17487/RFC9326"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-ippm-hybrid-two-step" target="https://datatracker.ietf.org/doc/html/draft-ietf-ippm-hybrid-two-step-01" quoteTitle="true" derivedAnchor="HYBRID-TWO-STEP">
          <front>
            <title>Hybrid Two-Step Performance Measurement Method</title>
            <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
              <organization showOnFrontPage="true">Ericsson</organization>
            </author>
            <author initials="W." surname="Lingqiang" fullname="Wang Lingqiang">
              <organization showOnFrontPage="true">ZTE Corporation</organization>
            </author>
            <author initials="G." surname="Zhui" fullname="Guo Zhui">
              <organization showOnFrontPage="true">ZTE Corporation</organization>
            </author>
            <author initials="H." surname="Song" fullname="Haoyu Song">
              <organization showOnFrontPage="true">Futurewei Technologies</organization>
            </author>
            <author initials="P." surname="Thubert" fullname="Pascal Thubert">
              <organization showOnFrontPage="true">Independent</organization>
            </author>
            <date month="July" day="5" year="2024"/>
            <abstract>
              <t indent="0">   The development and advancements in network operation automation have
   brought new measurement methodology requirements.  mong them is the
   ability to collect instant network state as the packet being
   processed by the networking elements along its path through the
   domain.  That task can be solved using on-path telemetry, also called
   hybrid measurement.  An on-path telemetry method allows the
   collection of essential information that reflects the operational
   state and network performance experienced by the packet.  This
   document introduces a method complementary to on-path telemetry that
   causes the generation of telemetry information.  This method,
   referred to as Hybrid Two-Step (HTS), separates the act of measuring
   and/or calculating the performance metric from collecting and
   transporting network state.  The HTS packet traverses the same set of
   nodes and links as the trigger packet, thus simplifying the
   correlation of informational elements originating on nodes traversed
   by the trigger packet.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ippm-hybrid-two-step-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.song-opsawg-ifit-framework" target="https://datatracker.ietf.org/doc/html/draft-song-opsawg-ifit-framework-21" quoteTitle="true" derivedAnchor="IFIT-FRAMEWORK">
          <front>
            <title>Framework for In-situ Flow Information Telemetry</title>
            <author initials="H." surname="Song" fullname="Haoyu Song">
              <organization showOnFrontPage="true">Futurewei</organization>
            </author>
            <author initials="F." surname="Qin" fullname="Fengwei Qin">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="H." surname="Chen" fullname="Huanan Chen">
              <organization showOnFrontPage="true">China Telecom</organization>
            </author>
            <author initials="J." surname="Jin" fullname="Jaewhan Jin">
              <organization showOnFrontPage="true">LG U+</organization>
            </author>
            <author initials="J." surname="Shin" fullname="Jongyoon Shin">
              <organization showOnFrontPage="true">SK Telecom</organization>
            </author>
            <date month="October" day="23" year="2023"/>
            <abstract>
              <t indent="0">   As network scale increases and network operation becomes more
   sophisticated, existing Operation, Administration, and Maintenance
   (OAM) methods are no longer sufficient to meet the monitoring and
   measurement requirements.  Emerging data-plane on-path telemetry
   techniques, such as IOAM and AltMrk, which provide high-precision
   flow insight and issue notifications in real time can supplement
   existing proactive and reactive methods that run in active and
   passive modes.  They enable quality of experience for users and
   applications, and identification of network faults and deficiencies.
   This document describes a reference framework, named as In-situ Flow
   Information Telemetry, for the on-path telemetry techniques.

   The high-level framework outlines the system architecture for
   applying the on-path telemetry techniques to collect and correlate
   performance measurement information from the network.  It identifies
   the components that coordinate existing protocol tools and telemetry
   mechanisms, and addresses deployment challenges for flow-oriented on-
   path telemetry techniques, especially in carrier networks.

   The document is a guide for system designers applying the referenced
   techniques.  It is also intended to motivate further work to enhance
   the OAM ecosystem.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-song-opsawg-ifit-framework-21"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-pim-multicast-lessons-learned" target="https://datatracker.ietf.org/doc/html/draft-ietf-pim-multicast-lessons-learned-04" quoteTitle="true" derivedAnchor="MULTICAST-LESSONS-LEARNED">
          <front>
            <title>Multicast Lessons Learned from Decades of Deployment Experience</title>
            <author initials="D." surname="Farinacci" fullname="Dino Farinacci">
              <organization showOnFrontPage="true">lispers.net</organization>
            </author>
            <author initials="L." surname="Giuliano" fullname="Lenny Giuliano">
              <organization showOnFrontPage="true">Juniper</organization>
            </author>
            <author initials="M." surname="McBride" fullname="Mike McBride">
              <organization showOnFrontPage="true">Futurewei</organization>
            </author>
            <author initials="N." surname="Warnke" fullname="Nils Warnke">
              <organization showOnFrontPage="true">Deutsche Telekom</organization>
            </author>
            <date month="July" day="22" year="2024"/>
            <abstract>
              <t indent="0">   This document gives a historical perspective about the design and
   deployment of multicast routing protocols.  The document describes
   the technical challenges discovered from building these protocols.
   Even though multicast has enjoyed success of deployment in special
   use-cases, this draft discusses what were, and are, the obstacles for
   mass deployment across the Internet.  Individuals who are working on
   new multicast related protocols will benefit by knowing why certain
   older protocols are no longer in use today.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pim-multicast-lessons-learned-04"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.song-ippm-postcard-based-telemetry" target="https://datatracker.ietf.org/doc/html/draft-song-ippm-postcard-based-telemetry-16" quoteTitle="true" derivedAnchor="POSTCARD-TELEMETRY">
          <front>
            <title>On-Path Telemetry using Packet Marking to Trigger Dedicated OAM Packets</title>
            <author initials="H." surname="Song" fullname="Haoyu Song">
              <organization showOnFrontPage="true">Futurewei Technologies</organization>
            </author>
            <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
              <organization showOnFrontPage="true">Ericsson</organization>
            </author>
            <author initials="T." surname="Zhou" fullname="Tianran Zhou">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenbin Li">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="T." surname="Graf" fullname="Thomas Graf">
              <organization showOnFrontPage="true">Swisscom</organization>
            </author>
            <author initials="G." surname="Mishra" fullname="Gyan Mishra">
              <organization showOnFrontPage="true">Verizon Inc.</organization>
            </author>
            <author initials="J." surname="Shin" fullname="Jongyoon Shin">
              <organization showOnFrontPage="true">SK Telecom</organization>
            </author>
            <author initials="K." surname="Lee" fullname="Kyungtae Lee">
              <organization showOnFrontPage="true">LG U+</organization>
            </author>
            <date month="June" day="2" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-song-ippm-postcard-based-telemetry-16"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC0792" target="https://www.rfc-editor.org/info/rfc792" quoteTitle="true" derivedAnchor="RFC0792">
          <front>
            <title>Internet Control Message Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="792"/>
          <seriesInfo name="DOI" value="10.17487/RFC0792"/>
        </reference>
        <reference anchor="RFC3605" target="https://www.rfc-editor.org/info/rfc3605" quoteTitle="true" derivedAnchor="RFC3605">
          <front>
            <title>Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)</title>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/>
            <date month="October" year="2003"/>
            <abstract>
              <t indent="0">The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3605"/>
          <seriesInfo name="DOI" value="10.17487/RFC3605"/>
        </reference>
        <reference anchor="RFC6450" target="https://www.rfc-editor.org/info/rfc6450" quoteTitle="true" derivedAnchor="RFC6450">
          <front>
            <title>Multicast Ping Protocol</title>
            <author fullname="S. Venaas" initials="S." surname="Venaas"/>
            <date month="December" year="2011"/>
            <abstract>
              <t indent="0">The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6450"/>
          <seriesInfo name="DOI" value="10.17487/RFC6450"/>
        </reference>
        <reference anchor="RFC8487" target="https://www.rfc-editor.org/info/rfc8487" quoteTitle="true" derivedAnchor="RFC8487">
          <front>
            <title>Mtrace Version 2: Traceroute Facility for IP Multicast</title>
            <author fullname="H. Asaeda" initials="H." surname="Asaeda"/>
            <author fullname="K. Meyer" initials="K." surname="Meyer"/>
            <author fullname="W. Lee" initials="W." role="editor" surname="Lee"/>
            <date month="October" year="2018"/>
            <abstract>
              <t indent="0">This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8487"/>
          <seriesInfo name="DOI" value="10.17487/RFC8487"/>
        </reference>
        <reference anchor="RFC9486" target="https://www.rfc-editor.org/info/rfc9486" quoteTitle="true" derivedAnchor="RFC9486">
          <front>
            <title>IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)</title>
            <author fullname="S. Bhandari" initials="S." role="editor" surname="Bhandari"/>
            <author fullname="F. Brockners" initials="F." role="editor" surname="Brockners"/>
            <date month="September" year="2023"/>
            <abstract>
              <t indent="0">In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9486"/>
          <seriesInfo name="DOI" value="10.17487/RFC9486"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Gunter Van de Velde"/>, <contact fullname="Brett Sheffield"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Frank Brockners"/>, <contact fullname="Nils Warnke"/>, <contact fullname="Jake Holland"/>, 
      <contact fullname="Dino Farinacci"/>, <contact fullname="Henrik Nydell"/>, <contact fullname="Zaheduzzaman Sarker"/>, and <contact fullname="Toerless Eckert"/> for their comments and suggestions.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Haoyu Song" initials="H." surname="Song">
        <organization showOnFrontPage="true">Futurewei Technologies</organization>
        <address>
          <postal>
            <street>2330 Central Expressway</street>
            <city>Santa Clara</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>hsong@futurewei.com</email>
        </address>
      </author>
      <author fullname="Mike McBride" initials="M." surname="McBride">
        <organization showOnFrontPage="true">Futurewei Technologies</organization>
        <address>
          <postal>
            <street>2330 Central Expressway</street>
            <city>Santa Clara</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>mmcbride@futurewei.com</email>
        </address>
      </author>
      <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>gregimirsky@gmail.com</email>
        </address>
      </author>
      <author fullname="Gyan Mishra" initials="G." surname="Mishra">
        <organization showOnFrontPage="true">Verizon Inc.</organization>
        <address>
          <postal>
            <country>United States of America</country>
          </postal>
          <email>gyan.s.mishra@verizon.com</email>
        </address>
      </author>
      <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
        <organization abbrev="NICT" showOnFrontPage="true">National Institute of Information and Communications Technology</organization>
        <address>
          <postal>
            <country>Japan</country>
          </postal>
          <email>asaeda@nict.go.jp</email>
        </address>
      </author>
      <author fullname="Tianran Zhou" initials="T." surname="Zhou">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <city>Beijing</city>
            <country>China</country>
          </postal>
          <email>zhoutianran@huawei.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
