<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8200 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml">
<!ENTITY RFC8762 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml">
<!ENTITY RFC8972 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8972.xml">
<!ENTITY RFC9197 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml">
<!ENTITY RFC9326 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml">
<!ENTITY I-D.ietf-ippm-ioam-ipv6-options SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ippm-ioam-ipv6-options.xml">
<!ENTITY I-D.ietf-mpls-mna-hdr SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-mna-hdr.xml">
<!ENTITY I-D.gandhi-mpls-ioam SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.gandhi-mpls-ioam.xml">
]>
<rfc submissionType="IETF" docName="draft-gandhi-ippm-stamp-ioam-00" category="std" ipr="trust200902" consensus="true">
    <!-- Generated by id2xml 1.5.0 on 2020-02-06T01:41:26Z -->
    <?rfc compact="yes"?>
    <?rfc text-list-symbols="oo*+-"?>
    <?rfc subcompact="no"?>
    <?rfc sortrefs="no"?>
    <?rfc symrefs="yes"?>
    <?rfc strict="yes"?>
    <?rfc toc="yes"?>
    <front>
    <title abbrev="STAMP for HBH and E2E Measurements">Simple TWAMP (STAMP) Extensions for Hop-By-Hop and Edge-To-Edge Measurements</title>
    <seriesInfo name="Internet-Draft" value="draft-gandhi-ippm-stamp-ioam-00"/>    
    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
    <organization>Cisco Systems, Inc.</organization>
    <address>
    <postal><street>Canada</street>
    </postal>
        <email>rgandhi@cisco.com</email>
    </address>
    </author>

    <date day="16" month="August" year="2023"/>
    <workgroup>IPPM Working Group</workgroup>
    <abstract>
    <t>
Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields defined in RFC 9197 and RFC 9326 can be used for recording and collecting Hop-By-Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to carry IOAM data fields for HBH and E2E two-way active measurement and telemetry. The STAMP extensions are generic and allow to carry and reflect any type of IPv6 option and MPLS Network Action Sub-Stacks for two-way active measurement.
    </t>
    </abstract>
    </front>

    <middle>

   <section title="Introduction" anchor="sect-1">
   <t>
The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for the measurement of various performance metrics in IP networks <xref target="RFC8762" format="default"/> without the use of a control channel to pre-signal session parameters. <xref target="RFC8972" format="default"/> defines optional extensions, in the form of TLVs, for STAMP.  The STAMP test packets are transmitted along a path between a Session-Sender and a Session-Reflector to measure Edge-To-Edge (E2E) performance delay and packet loss along that path.  
   </t>

   <t>
In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. The term "in-situ" refers to the fact that the IOAM data fields are added to the data packets rather than being sent within the probe packets specifically dedicated to OAM.  The IOAM data fields are defined in <xref target="RFC9197" format="default"/>.  The IOAM data fields are further updated in <xref target="RFC9326" format="default"/> for direct export use-cases. Examples of data recorded by IOAM Trace Options includes per-hop information, e.g., node ID, timestamp, queue depth, interface ID, interface load, etc. The information collected can be used, for example, monitoring ECMP paths, proof-of-transit (POT) and troubleshooting failures in the network. Currently there is no accepted method defined to send the collected IOAM data fields back to the Sender where the Sender can use that information to support the IOAM use-cases. In addition, there is a limit on how large the IOAM data fields can be added in the packet header such that the hardware with limited capability for read and write depth can still process the IOAM data fields.
   </t>

   <t>
   IPv6 packets can carry IPv6 options of Hop-By-Hop (HBH) and Destination types as defined in <xref target="RFC8200" format="default"/>.  
   <xref target="I-D.ietf-ippm-ioam-ipv6-options"/> defines types for HBH and destination options to carry various IOAM data fields for IPv6 data plane.  
   </t>

   <t>
   MPLS packets can carry MPLS Network Action (MNA) Sub-Stack as defined in <xref target="I-D.ietf-mpls-mna-hdr"/>.
   <xref target="I-D.gandhi-mpls-ioam"/> defines extensions to carry various IOAM data fields for MPLS data plane. 
   </t>

   <t>
It may be desired to record and collect HBH and E2E operational and telemetry information using two-way active measurement packets between two nodes in a network. This is achieved by extending the STAMP <xref target="RFC8762" format="default"/> to carry extension headers with IOAM data fields and by augmenting the optional STAMP extensions defined in <xref target="RFC8972" format="default"/> to reflect them as specified in this document. 
The procedure leverages the implementation of IOAM data fields on the midpoint nodes with IPv6 and MPLS data planes without any additional requirements.
   </t>
   <t>
The procedure and STAMP extensions defined in this document are generic and allow to carry any IPv6 options and MPLS Network Action Sub-Stacks in Session-Sender test packets and reflect them in Session-Reflector test packets for HBH and E2E two-way active measurement.
   </t>
   </section>

   <section title="Conventions Used in This Document" anchor="sect-2">
       
   <section title="Requirements Language" anchor="sect-2.1">
   <t>
   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  <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
   when, and only when, they appear in all capitals, as shown here.
   </t>
    </section>

    <section title="Abbreviations" anchor="sect-2.2">

    <t>
    AMM:  Alternate Marking Method</t>
    <t>
    ECMP:  Equal Cost Multi-Path</t>
    <t>
    E2E:  Edge-To-Edge</t>
    <t>
    HBH:  Hop-By-Hop</t>
    <t>
    IOAM:  In Situ Operations, Administration, and Maintenance</t>
    <t>
    MPLS:  Multiprotocol Label Switching</t>
    <t>
    MNA:  MPLS Network Action</t>
    <t>
    OAM:  Operations, Administration, and Maintenance</t>
    <t>
    STAMP:  Simple Two-way Active Measurement Protocol.</t>

    </section>

    <section title="STAMP Reference Topology" anchor="sect-2.3">
    <t>
    In the "STAMP Reference Topology" shown in Figure 1, the STAMP Session-Sender S1 initiates a Session-Sender test packet and the STAMP Session-Reflector R1 transmits a reply Session-Reflector test packet.  The T1 is a transmit timestamp and T4 is a receive timestamp, both added by node S1. The T2 is a receive timestamp and T3 is a transmit timestamp, both added by node R1. Node M1 is a midpoint node that does not perform any STAMP processing.
    </t>

        <figure anchor="stamp-reference-topology">
        <name>STAMP Reference Topology</name>
  <artwork name="" type="" align="left" alt=""><![CDATA[
          T1                                       T2   
         /                                           \   
+-------+    Test Packet  +-------+                   +-------+
|       | - - - - - - - - |       | - - - - - - - - ->|       |
|   S1  |=================|   M1  |===================|   R1  |
|       |<- - - - - - - - |       | - - - - - - - - - |       |
+-------+                 +-------+ Reply Test Packet +-------+
         \                                           /
          T4                                       T3

STAMP Session-Sender                    STAMP Session-Reflector
]]></artwork>
    </figure>

    </section>
    </section>
 
    <section title="Overview" anchor="sect-3">
    <t>
    <xref target="RFC8972" format="default"/> defines optional extensions for STAMP. The optional extensions are added in base STAMP test packet defined in <xref target="RFC8762" format="default"/> in the form of TLVs. As specified in <xref target="RFC8972" format="default"/>, both Session-Sender and Session-Reflector test packets are symmetric in size when including all optional TLVs. Session-Reflector reflects all received STAMP TLVs from the Session-Sender test packets.
    </t>

    <section title="IPv6 Data plane" anchor="sect-3.1">
    <t>
    <xref target="I-D.ietf-ippm-ioam-ipv6-options"/> defines types for HBH and destination options to carry the IOAM option-types defined in <xref target="RFC9197" format="default"/> and <xref target="RFC9326" format="default"/> for IPv6 data plane. The STAMP Session-Sender and Session-Reflector test packets carry these IPv6 options with IOAM option-types for recording and collecting HBH and E2E operational and telemetry information for two-way active measurement as shown in Figure 2. 
    The Session-Sender, midpoints, and Session-Reflector nodes process the IOAM data fields as defined in <xref target="I-D.ietf-ippm-ioam-ipv6-options"/>.
    </t>

    <t>
    This document defines a new TLV option for STAMP, called "Reflected IPv6 Option Data" (value TBA1). When a STAMP Session-Sender adds an IPv6 option in IPv6 header for IOAM defined in <xref target="I-D.ietf-ippm-ioam-ipv6-options"/>, it also adds "Reflected IPv6 Option Data" STAMP TLV in the Session-Sender test packet with size of the IPv6 option length including IPv6 option header bytes and the value field in the TLV initialized to zeros. When adding multiple IPv6 options in the Session-Sender test packet, multiple "Reflected IPv6 Option Data" TLVs MUST be added, each one with matching length with the IPv6 option and in the same order.
    </t>

        <figure anchor="stamp-reflected-ipv6-option-tlv">
        <name>Example STAMP Test Packet with Reflected IPv6 Option Data TLV</name>
    <artwork name="" type="" align="left" alt=""><![CDATA[
    +-------------------------------------+
    | IPv6 Header                         |
    +-------------------------------------+
    | HBH IOAM IPv6 Option RFC 9197, 9326 |
    +-------------------------------------+
    | UDP Header                          |
    +-------------------------------------+
    | STAMP Packet RFC 8972               |
    +-------------------------------------+
    | IPv6 Option Data STAMP TLV (TBA1)   |
    +-------------------------------------+
]]></artwork>
    </figure>

    <t>
    When Session-Reflector receives STAMP test packet with IPv6 option and STAMP TLV of "Reflected IPv6 Option Data", the Session-Reflector that supports this STAMP TLV, MUST copy the entire IPv6 option including the header into the STAMP "Reflected IPv6 Option Data" TLV in Session-Reflector payload. The Session-Reflector also MUST add the matching IPv6 option in the IPv6 header of the Session-Reflector test packet for the reverse direction for two-way measurement.  When there are multiple IPv6 options in the Session-Sender test packet, all IPv6 options MUST be copied in the STAMP "Reflected IPv6 Option Data" TLVs and MUST add all IPv6 options in the IPv6 header of the Session-Reflector test packet and in the same order.
    </t>

    <t>
When Session-Reflector received STAMP test packet with IPv6 option but it does not carry STAMP TLV of "Reflected IPv6 Option Data", the Session-Reflector does not copy the IPv6 option into the Session-Reflector test packet.</t>

    <t>
Note that the use-case where the IPv6 option length changes in the packet along the path is outside the scope of this document.
    </t>
    <t>
Note that use-case where IPv6 options are added or removed in the packet along the path is outside the scope of this document.
    </t>

    </section>

    <section title="MPLS Data plane" anchor="sect-3.2">
    <t>
    <xref target="I-D.ietf-mpls-mna-hdr"/> defines MPLS Network Action (MNA) Sub-Stack to carry various Network Actions with Ancillary data.
    <xref target="I-D.gandhi-mpls-ioam"/> defines extensions using MNA to carry various IOAM data fields for MPLS data plane. 
    The STAMP Session-Sender and Session-Reflector test packets carry the MNA Sub-Stack with IOAM option-types for recording and collecting HBH and E2E operational and telemetry information for two-way active measurement as shown in Figure 3. 
    The Session-Sender, midpoints, and Session-Reflector nodes process the IOAM data fields as defined in <xref target="I-D.gandhi-mpls-ioam"/>.
    </t>

    <t>
    This document also defines a new TLV option for STAMP, called "Reflected MNA Sub-Stack Data" (value TBA2). When a STAMP Session-Sender adds an MNA Sub-Stack in the test packet, it also adds "Reflected MNA Sub-Stack Data" STAMP TLV in the Session-Sender test packet with size of the MNA Sub-Stack length (NASL) including In-Stack Ancillary Data (ISD) and Post-Stack Ancillary Data (PSD) and MNA header and the value field in the TLV initialized to zeros. When adding multiple MNA Sub Stacks in the Session-Sender test packet, multiple "Reflected MNA Sub-Stack Data" TLVs MUST be added, each one with matching length with the MNA Sub-Stack and Ancillary Data and in the same order.
    </t>

        <figure anchor="stamp-reflected-mna-data-tlv">
        <name>Example STAMP Test Packet with Reflected MNA Sub-Stack Data TLV</name>
    <artwork name="" type="" align="left" alt=""><![CDATA[
    +---------------------------------------+
    | MPLS Header                           |
    +---------------------------------------+
    | HBH IOAM MNA Sub-Stack RFC 9197, 9326 |
    +---------------------------------------+
    | IP Header                             |
    +---------------------------------------+
    | UDP Header                            |
    +---------------------------------------+
    | STAMP Packet RFC 8972                 |
    +---------------------------------------+
    | MNA Sub-Stack Data STAMP TLV (TBA2)   |
    +---------------------------------------+
]]></artwork>
    </figure>

    <t>
    When Session-Reflector receives STAMP test packet with MNA and STAMP TLV of "Reflected MNA Sub-Stack Data", the Session-Reflector that supports this STAMP TLV, MUST copy the entire MNA Sub-Stack, Ancillary Data including the header into the "Reflected MNA Sub-Stack Data" TLV in Session-Reflector payload. The Session-Reflector also MUST add the matching MNA Sub-Stacks and Ancillary Data in the MPLS header of the Session-Reflector test packet for the reverse direction for two-way measurement. When there are multiple MNA Sub-Stacks in the Session-Sender test packet, all MNA Sub-Stacks including Ancillary Data MUST be copied in the STAMP TLVs and MUST add all MNA Sub-Stacks including Ancillary Data in the Session-Reflector test packet and in the same order.
    </t>

    <t>
When Session-Reflector received STAMP test packet with MNA Sub-Stack but it does not carry STAMP TLV of "Reflected MNA Sub-Stack Data", the Session-Reflector does not copy the MNA Sub-Stack into the Session-Reflector test packet. </t>

    <t>
Note that the use-case where the MNA Sub-Stack length changes in the packet along the path is outside the scope of this document.
    </t>
    <t>
Note that use-case where MNA Sub-Stacks are added or removed in the packet along the path is outside the scope of this document.
    </t>


    </section>
    </section>

    <section title="STAMP Extensions" anchor="sect-4">

    <section title="Reflected IPv6 Option Data TLV" anchor="sect-4.1">

    <t>
    The Reflected IPv6 Option Data STAMP TLV is carried by Session-Sender and Session-Reflector test packets. STAMP test packets may carry multiple TLVs of this type. The same Reflected IPv6 Option Data STAMP TLV is used for reflecting both HBH and Destination IPv6 options. The format of the Reflected IPv6 Option Data TLV is shown in Figure 4.
    </t>

        <figure anchor="stamp-reflected-ipv6-option">
        <name>Reflected IPv6 Option Data TLV</name>
    <artwork name="" type="" align="left" alt=""><![CDATA[
 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |STAMP TLV Flags|  Type=TBA1    |         Length                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Reflected IPv6 Option Data                 |
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
    </figure>

<t>
The TLV fields are defined as follows:
</t>
<t>
Type : Type (value TBA1) 
</t>
<t>
STAMP TLV Flags : The STAMP TLV Flags follow the procedures described in <xref target="RFC8972" format="default"/>.
</t>
<t>
Length : A two-octet field equal to the length of the Data in octets.
</t>    

<t>
The Session-Reflector MUST return an error in STAMP TLV Flags when it determines that the length of the TLV does not match the length of the corresponding IPv6 option when processing in the same order as IPv6 options in the IPv6 header.
</t>

    </section>

    <section title="Reflected MNA Sub-Stack Data TLV" anchor="sect-4.2">

    <t>
    The Reflected MNA Sub-Stack Data STAMP TLV is carried by Session-Sender and Session-Reflector test packets. STAMP test packets may carry multiple TLVs of this type. The format of the Reflected MNA Sub-Stack Data TLV is shown in Figure 5.
    </t>

        <figure anchor="stamp-reflected-mna-data">
        <name>Reflected MNA Sub-Stack Data TLV</name>
    <artwork name="" type="" align="left" alt=""><![CDATA[
 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |STAMP TLV Flags|  Type=TBA2    |         Length                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Reflected MNA Sub-Stack Data               |
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
    </figure>

<t>
The TLV fields are defined as follows:
</t>
<t>
Type : Type (value TBA2) 
</t>
<t>
STAMP TLV Flags : The STAMP TLV Flags follow the procedures described in <xref target="RFC8972" format="default"/>.
</t>
<t>
Length : A two-octet field equal to the length of the Data in octets.
</t>

<t>
The Session-Reflector MUST return an error in STAMP TLV Flags when it determines that the length of the TLV does not match the length of the corresponding MNA Sub-Stack when processing in the same order as MNA Sub-Stacks in the MPLS header.
</t>
    </section>
    </section>

    <section title="Generic Applicability" anchor="sect-5">
    <t>
The procedure and extensions defined in this document for STAMP for IPv6 data plane are generic and can be used by Session-Sender and Session-Reflector test packets to reflect any IPv6 option (not just limited to the IPv6 options with IOAM data fields) for HBH and E2E two-way active measurement as shown in Figure 6. For example, using the Alternate Marking Method (AMM) IPv6 destination option defined in RFC 9343, Performance and Diagnostic Metrics (PDM) IPv6 option defined in RFC 8250, Maximum Path MTU IPv6 option defined in RFC 9268, and any other IPv6 option that may be defined in future.
    </t>

        <figure anchor="stamp-generic-reflected-ipv6-data">
        <name>Example STAMP Test Packet with Generic Reflected IPv6 Option Data</name>
    <artwork name="" type="" align="left" alt=""><![CDATA[
    +------------------------------------+
    | IPv6 Header                        |
    +------------------------------------+
    | IPv6 Option1 RFC 8200              |
    +------------------------------------+
    | IPv6 Option2 RFC 8200              |
    +------------------------------------+
    | IPv6 Option3 RFC 8200              |
    +------------------------------------+
    | UDP Header                         |
    +------------------------------------+
    | STAMP Packet RFC 8972              |
    +------------------------------------+
    | IPv6 Option1 Data STAMP TLV (TBA1) |
    +------------------------------------+
    | IPv6 Option2 Data STAMP TLV (TBA1) |
    +------------------------------------+
    | IPv6 Option3 Data STAMP TLV (TBA1) |
    +------------------------------------+
]]></artwork>
    </figure>

    <t>
The procedure and extensions defined in this document for STAMP for MPLS data plane are generic and can be used by Session-Sender and Session-Reflector test packets to reflect any MNA Sub-Stack for HBH and E2E two-way active measurement as shown in Figure 7.
    </t>

        <figure anchor="stamp-generic-reflected-mna-data">
        <name>Example STAMP Test Packet with Generic Reflected MNA Sub-Stack Data</name>
    <artwork name="" type="" align="left" alt=""><![CDATA[
    +--------------------------------------+
    | MPLS Header                          |
    +--------------------------------------+
    | MNA Sub-Stack1 I-D.ietf-mpls-mna-hdr |
    +--------------------------------------+
    | MNA Sub-Stack2 I-D.ietf-mpls-mna-hdr |
    +--------------------------------------+
    | MNA Sub-Stack3 I-D.ietf-mpls-mna-hdr |
    +--------------------------------------+
    | IP Header                            |
    +--------------------------------------+
    | UDP Header                           |
    +--------------------------------------+
    | STAMP Packet RFC 8972                |
    +--------------------------------------+
    | MNA Sub-Stack1 Data STAMP TLV (TBA2) |
    +--------------------------------------+
    | MNA Sub-Stack2 Data STAMP TLV (TBA2) |
    +--------------------------------------+
    | MNA Sub-Stack3 Data STAMP TLV (TBA2) |
    +--------------------------------------+
]]></artwork>
    </figure>

    </section>

    <section title="Security Considerations" anchor="sect-6">
    <t>
    The security considerations specified in <xref target="RFC8762" format="default"/>, <xref target="RFC8972" format="default"/>, <xref target="RFC8200" format="default"/>, <xref target="RFC9197" format="default"/>, and <xref target="RFC9326" format="default"/> also apply to the procedure and extensions defined in this document.
    </t>
    </section>

    <section title="IANA Considerations" anchor="sect-7">
    <t>
    IANA has created the "STAMP TLV Types" registry for <xref target="RFC8972" format="default"/>. 
    IANA is requested to allocate a value for the "Reflected IPv6 Option Data" TLV Type and a value for the "Reflected MNA Sub-Stack Data" TLV Type from the IETF Review TLV range of the same registry.
    </t>

    <table anchor="iana-tlv-type-tbl" align="center">
       <name>STAMP TLV Types</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="center">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBA1 </td>
            <td align="center">Reflected IPv6 Option Data</td>
            <td align="left">This document</td>
          </tr>
          <tr>
            <td align="left">TBA2 </td>
            <td align="center">Reflected MNA Sub-Stack Data</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
    </table>

    </section>

    </middle>

    <back>
    <references title="Normative References">
    &RFC2119; 
    &RFC8174; 
    &RFC8762;
    &RFC8972;
    </references>
    <references title="Informative References">
    &RFC8200;
    &RFC9197;
    &RFC9326;
    &I-D.ietf-ippm-ioam-ipv6-options;
    &I-D.ietf-mpls-mna-hdr;
    &I-D.gandhi-mpls-ioam;
        
    </references>
    <section title="Acknowledgments" numbered="no" anchor="acknowledgments">
    <t>
   TBA 
    </t>
    </section>

    </back>

    </rfc>
