<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-mpls-rfc6374-sfl-10" number="9571" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2024-05-29T14:17:00" indexInclude="true" scripts="Common,Greek,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-sfl-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9571" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SFL">Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels</title>
    <seriesInfo name="RFC" value="9571" stream="IETF"/>
    <author initials="S." surname="Bryant" fullname="Stewart Bryant" role="editor">
      <organization showOnFrontPage="true">University of Surrey</organization>
      <address>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author initials="G." surname="Swallow" fullname="George Swallow">
      <organization showOnFrontPage="true">Independent</organization>
      <address>
        <email>swallow.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="Chen" fullname="Mach(Guoyi) Chen">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>
    <author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <email>giuseppe.fioccola@huawei.com</email>
      </address>
    </author>
    <author initials="G." surname="Mirsky" fullname="Gregory Mirsky">
      <organization showOnFrontPage="true">ZTE Corp.</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <date month="05" year="2024"/>
    <workgroup>MPLS</workgroup>
    <keyword>Performance Measurement</keyword>
    <keyword>OAM</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">RFC 6374 describes methods of making loss and delay measurements on
      Label Switched Paths (LSPs) primarily as they are used in MPLS Transport
      Profile (MPLS-TP) networks.  This document describes a method of
      extending the performance measurements (specified in RFC 6374) from
      flows carried over MPLS-TP to flows carried over generic MPLS LSPs.  In
      particular, it extends the technique to allow loss and delay
      measurements to be made on multipoint-to-point LSPs and introduces some
      additional techniques to allow more sophisticated measurements to be
      made in both MPLS-TP and generic MPLS networks.</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/rfc9571" 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>
          </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-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" 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-packet-loss-measurement-usi">Packet Loss Measurement Using SFL</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-single-packet-delay-measure">Single Packet Delay Measurement Using SFL</xref></t>
          </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-data-service-packet-delay-m">Data Service Packet Delay Measurement</xref></t>
          </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-some-simplifying-rules">Some Simplifying Rules</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-multiple-packet-delay-chara">Multiple Packet Delay Characteristics</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-method-1-time-buckets">Method 1: Time Buckets</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-method-2-classic-standard-d">Method 2: Classic Standard Deviation</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2">
                  <li pn="section-toc.1-1.7.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.1.1"><xref derivedContent="7.2.1" format="counter" sectionFormat="of" target="section-7.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-packet-delay-measurem">Multi-packet Delay Measurement Message Format</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-packet-delay-measuremen">Per-Packet Delay Measurement</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-average-delay">Average Delay</xref></t>
              </li>
            </ul>
          </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-sampled-measurement">Sampled Measurement</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-carrying-packets-over-an-ls">Carrying Packets over an LSP Using an SFL</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extending-rfc-6374-with-sfl">Extending RFC 6374 with SFL TLV</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-combined-loss-delay-measure">Combined Loss/Delay Measurement Using SFL</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-allocation-of-mpls-generali">Allocation of MPLS Generalized Associated Channel (G-ACh) Types</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-allocation-of-mpls-loss-del">Allocation of MPLS Loss/Delay TLV Object</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="counter" sectionFormat="of" target="section-14"/>. <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.14.2">
              <li pn="section-toc.1-1.14.2.1">
                <t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent="14.1" format="counter" sectionFormat="of" target="section-14.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.14.2.2">
                <t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent="14.2" format="counter" sectionFormat="of" target="section-14.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.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.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.17">
            <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"><xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> was originally designed for use as an Operations, Administration, and
Maintenance (OAM) protocol
for use with MPLS Transport Profile (MPLS-TP) <xref target="RFC5921" format="default" sectionFormat="of" derivedContent="RFC5921"/> LSPs. MPLS-TP only
supports point-to-point and point-to-multipoint LSPs. This document describes 
how to use <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> in the generic MPLS case and also introduces a number
of more sophisticated measurements of applicability to both cases.</t>
      <t indent="0" pn="section-1-2"><xref target="RFC8372" format="default" sectionFormat="of" derivedContent="RFC8372"/> describes the requirement for introducing
flow identities when using packet loss measurements described in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.  

In summary, <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> describes use of the loss measurement (LM) message as the
packet accounting
demarcation point. Unfortunately, this gives rise to a number of
problems that may lead to significant packet accounting errors in
certain situations.  For example:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-3"><li pn="section-1-3.1" derivedCounter="1.">Where a flow is subjected to Equal-Cost Multipath (ECMP)
treatment, packets can arrive out of order with respect to the LM
packet.</li>
        <li pn="section-1-3.2" derivedCounter="2.">Where a flow is subjected to ECMP treatment, packets can arrive
at different hardware interfaces, thus requiring reception of an
LM packet on one interface to trigger a packet accounting action
on a different interface that may not be co-located with it.
This is a difficult technical problem to address with the
required degree of accuracy.</li>
        <li pn="section-1-3.3" derivedCounter="3.">Even where there is no ECMP (for example, on RSVP-TE, MPLS-TP LSPs,
and pseudowires (PWs)), local processing may be distributed over a number of
processor cores, leading to synchronization problems.</li>
        <li pn="section-1-3.4" derivedCounter="4.">Link aggregation techniques <xref target="RFC7190" format="default" sectionFormat="of" derivedContent="RFC7190"/> may also lead to synchronization
issues.</li>
        <li pn="section-1-3.5" derivedCounter="5.">Some forwarder implementations have a long pipeline between
processing a packet and incrementing the associated counter, again
leading to synchronization difficulties.</li>
      </ol>
      <t indent="0" pn="section-1-4">An approach to mitigating these synchronization issues is described in
<xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> -- the packets are
batched by the sender, and each batch is marked in some way such that
adjacent batches can be easily recognized by the receiver.</t>
      <t indent="0" pn="section-1-5">An additional problem arises where the LSP is a multipoint-to-point
LSP since MPLS does not include a source address in the packet.
Network management operations require the measurement of packet loss
between a source and destination.  It is thus necessary to introduce
some source-specific information into the packet to identify packet
batches from a specific source.</t>
      <t indent="0" pn="section-1-6"><xref target="RFC8957" format="default" sectionFormat="of" derivedContent="RFC8957"/> describes a method of encoding per-flow
instructions in an MPLS label stack using a technique called
Synonymous Flow Labels (SFLs), in which labels that mimic the
behavior of other labels provide the packet batch identifiers and
enable the per-batch packet accounting.  This memo specifies how SFLs
are used to perform packet loss and delay measurements as described in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.</t>
      <t indent="0" pn="section-1-7">
  When the terms "performance measurement method," "Query," "packet," or "message" are used in this document,
  they refer to a performance measurement method, Query, packet, or message as specified in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.  </t>
    </section>
    <section anchor="requirements-language" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-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 anchor="rfc6374-packet-loss-measurement-with-sfl" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-packet-loss-measurement-usi">Packet Loss Measurement Using SFL</name>
      <t indent="0" pn="section-3-1">The data service packets of the flow being instrumented are grouped
into batches, and all the packets within a batch are marked with
the SFL <xref target="RFC8372" format="default" sectionFormat="of" derivedContent="RFC8372"/> corresponding to that batch.
The sender counts the number of packets in the batch. When the
batch has completed and the sender is confident that all of the
packets in that batch will have been received, the sender issues
a Query message to determine the number actually
received and hence the number of packets lost. The 
Query message is sent using the same SFL as the corresponding batch of
data service packets. The format of the Query and Response packets is
described in <xref target="sec-RFC6374SFL" format="default" sectionFormat="of" derivedContent="Section 9"/>.</t>
    </section>
    <section anchor="SPD" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-single-packet-delay-measure">Single Packet Delay Measurement Using SFL</name>
      <t indent="0" pn="section-4-1"><xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> describes how to measure the packet delay by measuring the
transit time of a packet over an LSP. Such a packet may not 
need to be carried over an SFL since the delay over a particular LSP 
should be a function of the Traffic Class (TC) bits.</t>
      <t indent="0" pn="section-4-2">However, where SFLs are being used to monitor packet loss or where
label-inferred scheduling is used <xref target="RFC3270" format="default" sectionFormat="of" derivedContent="RFC3270"/>, then
the SFL would be <bcp14>REQUIRED</bcp14> to ensure that the packet
that was being used as a proxy for a data service packet experienced
a representative delay. The format of a packet carried over the LSP using an SFL is shown in <xref target="sec-RFC6374SFL" format="default" sectionFormat="of" derivedContent="Section 9"/>.</t>
    </section>
    <section anchor="data-service-packet-delay-measurement" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-data-service-packet-delay-m">Data Service Packet Delay Measurement</name>
      <t indent="0" pn="section-5-1">Where it is desired to more thoroughly instrument a packet flow and to
determine the delay of a number of packets, it is undesirable to
send a large number of packets acting as proxy data service
packets (see <xref target="SPD" format="default" sectionFormat="of" derivedContent="Section 4"/>). A method of directly measuring the delay characteristics
of a batch of packets is therefore needed.</t>
      <t indent="0" pn="section-5-2">Given the long intervals over which it is necessary to measure packet
loss, it is not necessarily the case that the batch times for the two
measurement types would be identical. Thus, we use a technique that
permits the two measurements to be made concurrently and yet relatively
independently from each other. The notion that they are relatively
independent arises from the potential for the two batches to overlap in time,
in which case either the delay batch time will need to be cut short or the loss
time will need to be extended to allow correct reconciliation of the
various counters.</t>
      <t indent="0" pn="section-5-3">The problem is illustrated in <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
      <figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-query-packet-with-sfl">Query Packet with SFL</name>
        <artwork align="left" pn="section-5-4.1">
(Case 1)  AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB

          SFL marking of a packet batch for loss measurement

(Case 2)  AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB

          SFL marking of a subset of the packets for delay

(Case 3)  AAAAAAAADDDDBBBBBBBBAAAAAAAAAABBBBBBBBBB

          SFL marking of a subset of the packets across a packet loss
          measurement boundary

(Case 4)  AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB

          A case of multiple delay measurements within a packet loss
          measurement

where
   A and B are packets where loss is being measured.
   C and D are packets where loss and delay are being measured.
</artwork>
      </figure>
      <t indent="0" pn="section-5-5">In Case 1, we show where loss measurement alone
is being carried out on the flow under analysis. For illustrative
purposes, consider that 10 packets are used in each flow in the
time interval being analyzed.</t>
      <t indent="0" pn="section-5-6">Now consider Case 2, where a small batch of
packets need to be analyzed for delay. These are marked with a different
SFL type, indicating that they are to be monitored for both loss
and delay. The SFL=A indicates loss batch A, and SFL=D indicates a batch
of packets that are to be instrumented for delay, but SFL D is
synonymous with SFL A, which in turn is synonymous with the underlying
Forwarding Equivalence Class (FEC). Thus, a packet marked "D" will be accumulated into the A loss
batch, into the delay statistics, and will be forwarded as normal.
Whether the packet is actually counted twice (for loss and delay)
or whether the two counters are reconciled during reporting is
a local matter.</t>
      <t indent="0" pn="section-5-7">Now consider Case 3, where a small batch of packets
is marked for delay across a loss batch boundary. These packets
need to be considered as a part of batch A or a part of batch B, and
any Query needs to take place after all packets
A or D (whichever option is chosen) have arrived at the receiving Label Switching Router (LSR).</t>
      <t indent="0" pn="section-5-8">Now consider Case 4. Here, we have a case where
it is required to take a number of delay measurements within
a batch of packets that we are measuring for loss. To do this,
we need two SFLs for delay (C and D) and alternate between
them (on a delay-batch-by-delay-batch basis) for the purposes of
measuring the delay characteristics of the different batches of packets.</t>
    </section>
    <section anchor="some-simplifying-rules" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-some-simplifying-rules">Some Simplifying Rules</name>
      <t indent="0" pn="section-6-1">It is possible to construct a large set of overlapping measurement
types in terms of loss, delay, loss and delay, and batch overlap. If
we allow all combinations of cases, this leads to configuration,
testing, and implementation complexity and, hence, increased costs.
The following simplifying rules represent the
default case:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6-2"><li pn="section-6-2.1" derivedCounter="1.">Any system that needs to measure delay <bcp14>MUST</bcp14> be able to
measure loss.</li>
        <li pn="section-6-2.2" derivedCounter="2.">Any system that is to measure delay <bcp14>MUST</bcp14> be configured to
measure loss. Whether the loss statistics are collected
or not is a local matter.</li>
        <li pn="section-6-2.3" derivedCounter="3.">A delay measurement <bcp14>MAY</bcp14> start at any point during a loss measurement
batch, subject to rule 4.</li>
        <li pn="section-6-2.4" derivedCounter="4.">A delay measurement interval <bcp14>MUST</bcp14> be short enough that it
will complete before the enclosing loss batch completes.</li>
        <li pn="section-6-2.5" derivedCounter="5.">The duration of a second delay batch (D in <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/>) must be such
that all packets from the packets belonging to a first
delay batch (C in <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/>) will have been received before
the second delay batch completes. This condition is satisfied
when the time to send a batch is long compared to the network
propagation time and is a parameter that can be established
by the network operator.</li>
      </ol>
      <t indent="0" pn="section-6-3">Given that the sender controls both the start and duration of
a loss and a delay packet batch, these rules are readily implemented
in the control plane.</t>
    </section>
    <section anchor="multiple-packet-delay-characteristics" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-multiple-packet-delay-chara">Multiple Packet Delay Characteristics</name>
      <t indent="0" pn="section-7-1">A number of methods are described that add to the set of measurements
originally specified in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>. Each of these methods has different
characteristics and different processing demands on the packet forwarder.
The choice of method will depend on the type of diagnostic that the operator seeks.</t>
      <t indent="0" pn="section-7-2">Three methods are discussed:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7-3"><li pn="section-7-3.1" derivedCounter="1.">Time Buckets</li>
        <li pn="section-7-3.2" derivedCounter="2.">Classic Standard Deviation</li>
        <li pn="section-7-3.3" derivedCounter="3.">Average Delay</li>
      </ol>
      <section anchor="method-1-time-buckets" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-method-1-time-buckets">Method 1: Time Buckets</name>
        <t indent="0" pn="section-7.1-1">In this method, the receiving LSR measures the inter-packet gap, classifies the
  delay into a number of delay buckets, and records the number of packets
  in each bucket. 
  As an example, if the operator were concerned about packets with a delay of 
  up to 1 μs, 2 μs, 4 μs, 8 μs, and over 8 μs, then there would be five 
  buckets, and packets that arrived up to 1 μs would cause the "up to 1 μs" 
  bucket counter to increase.  Likewise, for those that arrived between 1 μs and 2 μs, the "2 μs" bucket counter would increase, etc. In practice, it
  might be better in terms of processing and potential parallelism if both the "up to 1 μs" and "2 μs" counters were incremented when a packet had
a delay relative to its predecessor of 2 μs, and any more detailed information was calculated in the analytics
system.</t>
        <t indent="0" pn="section-7.1-2">This method allows the operator to see more structure in the jitter characteristics
than simply measuring the average jitter and avoids the complication of needing
to perform a per-packet multiply but will probably need the time intervals between
buckets to be programmable by the operator.</t>
        <t indent="0" pn="section-7.1-3">The packet format of a Time Bucket Jitter Measurement message
is shown below:</t>
        <figure anchor="FIGBucket" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-time-bucket-jitter-measurem">Time Bucket Jitter Measurement Message Format</name>
          <artwork name="" type="" align="left" alt="" pn="section-7.1-4.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags |  Control Code |        Message Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  QTF  |  RTF  | RPTF  |              Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session Identifier          |    DS     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of     |      Reserved 1                               |
| Buckets       |                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Interval (in 10 ns units)                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Number of Pkts in Bucket 1                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Number of Pkts in Bucket N                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
~                           TLV Block                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
</artwork>
        </figure>
        <t indent="0" pn="section-7.1-5">The Version, Flags, Control Code, Message Length, Querier Timestamp Format (QTF), Responder Timestamp Format (RTF), Responder's Preferred Timestamp Format (RPTF),
Session Identifier, Reserved, and Differentiated Services (DS) fields are as defined in <xref target="RFC6374" sectionFormat="of" section="3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-3.2" derivedContent="RFC6374"/>. The remaining fields, which are unsigned integers, are as follows:</t>
        <ul empty="false" bare="false" indent="3" spacing="normal" pn="section-7.1-6">
          <li pn="section-7.1-6.1">Number of Buckets in the measurement.</li>
          <li pn="section-7.1-6.2">Reserved 1 must be sent as zero and ignored on receipt.</li>
          <li pn="section-7.1-6.3">Interval (in 10 ns units) is the inter-packet interval for
  this bucket.</li>
          <li pn="section-7.1-6.4">Number of Pkts in Bucket 1 is the number of packets found in
  the first bucket.</li>
          <li pn="section-7.1-6.5">Number of Pkts in Bucket N is the number of packets found in
  the Nth bucket, where N is the value in the Number of Buckets field.</li>
        </ul>
        <t indent="0" pn="section-7.1-7">There will be a number of Interval/Number pairs depending on the
number of buckets being specified by the Querier. If a message is being used to configure the buckets (i.e., the responder 
is creating or modifying the buckets according to the intervals in
the Query message), then the responder
<bcp14>MUST</bcp14> respond with 0 packets in each bucket until it has been
configured for a full measurement period. This indicates that it was configured
at the time of the last response message, and thus, the response
is valid for the whole interval. 

As per the convention in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>,
the Number of Pkts in Bucket fields are included in the Query message and set
to zero.</t>
        <t indent="0" pn="section-7.1-8">Out-of-band configuration is permitted by this mode of operation.</t>
        <t indent="0" pn="section-7.1-9">Note this is a departure from the normal fixed format used in
<xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.</t>
        <t indent="0" pn="section-7.1-10">The Time Bucket Jitter Measurement message is carried over an LSP in the way described in
<xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> and over an LSP with an SFL as described in <xref target="sec-RFC6374SFL" format="default" sectionFormat="of" derivedContent="Section 9"/>.</t>
      </section>
      <section anchor="method-2-classic-standard-deviation" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-method-2-classic-standard-d">Method 2: Classic Standard Deviation</name>
        <t indent="0" pn="section-7.2-1">In this method, provision is made for reporting the following delay
characteristics:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.2-2"><li pn="section-7.2-2.1" derivedCounter="1.">Number of packets in the batch (n)</li>
          <li pn="section-7.2-2.2" derivedCounter="2.">Sum of delays in a batch (S)</li>
          <li pn="section-7.2-2.3" derivedCounter="3.">Maximum delay</li>
          <li pn="section-7.2-2.4" derivedCounter="4.">Minimum delay</li>
          <li pn="section-7.2-2.5" derivedCounter="5.">Sum of squares of inter-packet delay (SumS)</li>
        </ol>
        <t indent="0" pn="section-7.2-3">Characteristics 1 and 2 give the mean delay. Measuring the delay of each
pair in the batch is discussed in <xref target="PPDM" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.</t>
        <t indent="0" pn="section-7.2-4">Characteristics 3 and 4 give the outliers.</t>
        <t indent="0" pn="section-7.2-5">Characteristics 1, 2, and 5 can be used to calculate the variance of the
inter-packet gap, hence the standard deviation giving a view of
the distribution of packet delays and hence the jitter. The equation
for the variance (var) is given by:</t>
        <artwork align="left" pn="section-7.2-6">
var = (SumS - S*S/n)/(n-1) 
</artwork>
        <t indent="0" pn="section-7.2-7">There is some concern over the use of this algorithm for measuring
variance because SumS and S*S/n can be similar numbers, particularly
where variance is low. However, the method is acceptable because it does
not require a division in the hardware.</t>
        <section anchor="multi-packet-delay-measurement-message-format" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1">
          <name slugifiedName="name-multi-packet-delay-measurem">Multi-packet Delay Measurement Message Format</name>
          <t indent="0" pn="section-7.2.1-1">The packet format of a  Multi-packet Delay Measurement message
is shown below:</t>
          <figure anchor="FIGMPM" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-multi-packet-delay-measureme">Multi-packet Delay Measurement Message Format</name>
            <artwork name="" type="" align="left" alt="" pn="section-7.2.1-2.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags |  Control Code |        Message Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  QTF  |  RTF  | RPTF  |              Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session Identifier          |    DS     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number of Packets                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Sum of Delays for Batch                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Minimum Delay                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Maximum Delay                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Sum of squares of Inter-packet delay           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
~                           TLV Block                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure>
          <t indent="0" pn="section-7.2.1-3">The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
Session Identifier, Reserved, and DS fields are as defined in <xref target="RFC6374" sectionFormat="of" section="3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-3.2" derivedContent="RFC6374"/>. The remaining fields are as follows:</t>
          <ul empty="false" bare="false" indent="3" spacing="normal" pn="section-7.2.1-4">
            <li pn="section-7.2.1-4.1">Number of Packets is the number of packets in this batch.</li>
            <li pn="section-7.2.1-4.2">Sum of Delays for Batch is the duration of the batch in the
  time measurement format specified in the RTF field.</li>
            <li pn="section-7.2.1-4.3">Minimum Delay is the minimum inter-packet gap observed during
  the batch in the time format specified in the RTF field.</li>
            <li pn="section-7.2.1-4.4">Maximum Delay is the maximum inter-packet gap observed during
  the batch in the time format specified in the RTF field.</li>
          </ul>
          <t indent="0" pn="section-7.2.1-5">The Multi-packet Delay Measurement message is carried over an LSP in the way described in
<xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> and over an LSP with an SFL as described in <xref target="sec-RFC6374SFL" format="default" sectionFormat="of" derivedContent="Section 9"/>.</t>
        </section>
      </section>
      <section anchor="PPDM" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-per-packet-delay-measuremen">Per-Packet Delay Measurement</name>
        <t indent="0" pn="section-7.3-1">If detailed packet delay measurement is required, then it might be
possible to record the inter-packet gap for each packet pair. 
   In cases other than the exceptions of slow flows or small batch sizes,
   this would create a large (per-packet) demand on storage in the
   instrumentation system, a large bandwidth for such a storage system and
   large bandwidth for the analytics system.
Such a measurement technique is outside the scope of this document.</t>
      </section>
      <section anchor="average-delay" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-average-delay">Average Delay</name>
        <t indent="0" pn="section-7.4-1">Introduced in <xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> is the concept of a one-way delay measurement in which the average time of arrival of a
set of packets is measured. In this approach, the packet is timestamped
at arrival, and the responder returns the sum of the timestamps
and the number of timestamps. From this, the analytics engine can
determine the mean delay. An alternative model is that the responder
returns the timestamp of the first and last packet and the
number of packets. This latter method has the advantage of allowing the
average delay to be determined at a number of points along the
packet path and allowing the components of the delay to be
characterized. Unless specifically configured otherwise, the
responder may return either or both types of response, and
the analytics engine should process the response appropriately.</t>
        <t indent="0" pn="section-7.4-2">The packet format of an Average Delay Measurement message
is shown below:</t>
        <figure anchor="FIGAD" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-average-delay-measurement-m">Average Delay Measurement Message Format</name>
          <artwork name="" type="" align="left" alt="" pn="section-7.4-3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags |  Control Code |        Message Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  QTF  |  RTF  | RPTF  |              Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session Identifier          |    DS     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number of Packets                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Time of First Packet                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Time of Last Packet                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Sum of Timestamps of Batch                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                                                               ~
~                           TLV Block                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t indent="0" pn="section-7.4-4">The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
Session Identifier, and DS fields are as defined in <xref target="RFC6374" sectionFormat="of" section="3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-3.2" derivedContent="RFC6374"/>. The remaining fields are as follows:</t>
        <ul empty="false" bare="false" indent="3" spacing="normal" pn="section-7.4-5">
          <li pn="section-7.4-5.1">Number of Packets is the number of packets in this batch.</li>
          <li pn="section-7.4-5.2">Time of First Packet is the time of arrival of the first
  packet in the batch.</li>
          <li pn="section-7.4-5.3">Time of Last Packet is the time of arrival of the last
  packet in the batch.</li>
          <li pn="section-7.4-5.4">Sum of Timestamps of Batch.</li>
        </ul>
        <t indent="0" pn="section-7.4-6">The Average Delay Measurement message
is carried over an LSP in the way described in
<xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> and over an LSP with an SFL as described in <xref target="sec-RFC6374SFL" format="default" sectionFormat="of" derivedContent="Section 9"/>.
As is the convention with <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, the Query message contains placeholders
for the Response message. The placeholders are sent as zero.</t>
      </section>
    </section>
    <section anchor="sampled-measurement" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-sampled-measurement">Sampled Measurement</name>
      <t indent="0" pn="section-8-1">In the discussion so far, it has been assumed that we would measure
the delay characteristics of every packet in a delay measurement
interval defined by an SFL of constant color.
In <xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/>, the concept of a sampled
measurement is considered. That is, the responder only measures a packet
at the start of a group of packets being marked for delay measurement
by a particular color, rather than every packet in the marked batch.
A measurement
interval is not defined by the duration of a marked batch of packets
but the interval between a pair of packets taking a readout
of the delay characteristic. This approach has the advantage that
the measurement is not impacted by ECMP effects.</t>
      <t indent="0" pn="section-8-2">This sampled approach may be used if supported by the responder and
configured by the operator.</t>
    </section>
    <section anchor="sec-RFC6374SFL" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-carrying-packets-over-an-ls">Carrying Packets over an LSP Using an SFL</name>
      <t indent="0" pn="section-9-1">We illustrate the packet format of a Query message using SFLs
for the case of an MPLS Direct Loss Measurement in
<xref target="Figure1" format="default" sectionFormat="of" derivedContent="Figure 5"/>.</t>
      <figure anchor="Figure1" align="left" suppress-title="false" pn="figure-5">
        <name slugifiedName="name-query-packet-with-sfl-2">Query Packet with SFL</name>
        <artwork name="" type="" align="left" alt="" pn="section-9-2.1">
+-------------------------------+
|                               |
|             LSP               |
|            Label              |
+-------------------------------+
|                               |
|        Synonymous Flow        |
|            Label              |
+-------------------------------+
|                               |
|            GAL                |
|                               |
+-------------------------------+
|                               |
|      ACH Type = 0xA           |
|                               |
+-------------------------------+
|                               |
|      Measurement Message      |
|                               |
|  +-------------------------+  |
|  |                         |  |
|  |      Fixed-format       |  |
|  |      portion of msg     |  |
|  |                         |  |
|  +-------------------------+  |
|  |                         |  |
|  |      Optional SFL TLV   |  |
|  |                         |  |
|  +-------------------------+  |
|  |                         |  |
|  |      Optional Return    |  |
|  |      Information        |  |
|  |                         |  |
|  +-------------------------+  |
|                               |
+-------------------------------+
</artwork>
      </figure>
      <t indent="0" pn="section-9-3">The MPLS label stack is exactly the same as that used for the user
data service packets being instrumented except for the inclusion
of the Generic Associated Channel Label (GAL) <xref target="RFC5586" format="default" sectionFormat="of" derivedContent="RFC5586"/> to allow the receiver to distinguish between
normal data packets and OAM packets. Since the packet loss
measurements are being made on the data service packets,
an MPLS Direct Loss Measurement is being made,
which is indicated by the type field in the Associated Channel Header (ACH) (Type = 0x000A).</t>
      <t indent="0" pn="section-9-4">The measurement message consists of up to three components as follows.</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-9-5">
        <li pn="section-9-5.1">
          <t indent="0" pn="section-9-5.1.1">The fixed-format portion of the message is carried over the ACH
	  channel. The ACH channel type specifies the type of measurement
	  being made (currently: loss, delay, or loss and delay).</t>
        </li>
        <li pn="section-9-5.2">
          <t indent="0" pn="section-9-5.2.1">(Optional) The SFL TLV specified in <xref target="sfltlv" format="default" sectionFormat="of" derivedContent="Section 9.1"/> <bcp14>MAY</bcp14> be carried if needed. It is
	  used to provide the implementation with a reminder of the SFL that
	  was used to carry the message.  This is needed because a number of
	  MPLS implementations do not provide the MPLS label stack to the MPLS
	  OAM handler.  This TLV is required if messages are sent over UDP
	  <xref target="RFC7876" format="default" sectionFormat="of" derivedContent="RFC7876"/>.  This TLV
	  <bcp14>MUST</bcp14> be included unless, by some method outside the
	  scope of this document, it is known that this information is not
	  needed by the responder.</t>
        </li>
        <li pn="section-9-5.3">
          <t indent="0" pn="section-9-5.3.1">(Optional) The Return Information <bcp14>MAY</bcp14> be carried if
	needed. It allows the responder send the response to the Querier.  This is not needed if the
	response is requested in band and the MPLS construct being measured is
	a point-to-point LSP, but it otherwise <bcp14>MUST</bcp14> be carried.
	The Return Address TLV is defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, and the optional UDP Return Object is defined in
	<xref target="RFC7876" format="default" sectionFormat="of" derivedContent="RFC7876"/>.</t>
        </li>
      </ul>
      <t indent="0" pn="section-9-6">Where a measurement other than an MPLS Direct Loss Measurement is to be
made, the appropriate measurement message is used (for example, one of the
new types defined in this document), and this is indicated to the receiver
by the use of the corresponding ACH type.</t>
      <section anchor="sfltlv" numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-extending-rfc-6374-with-sfl">Extending RFC 6374 with SFL TLV</name>
        <t indent="0" pn="section-9.1-1">The <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> SFL TLV is shown in <xref target="Figure2" format="default" sectionFormat="of" derivedContent="Figure 6"/>. 
   This contains the SFL that was carried in the label stack, the FEC that was
   used to allocate the SFL, and the index (into the batch of SFLs that were
   allocated for the FEC) that corresponds to this SFL.</t>
        <figure anchor="Figure2" align="left" suppress-title="false" pn="figure-6">
          <name slugifiedName="name-sfl-tlv">SFL TLV</name>
          <artwork name="" type="" align="left" alt="" pn="section-9.1-2.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |    Length     |MBZ| SFL Batch |    SFL Index  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 SFL                   |        Reserved       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 FEC                                           |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t indent="0" pn="section-9.1-3">Where:</t>
        <dl indent="15" newline="false" spacing="normal" pn="section-9.1-4">
          <dt pn="section-9.1-4.1">Type</dt>
          <dd pn="section-9.1-4.2">      Set to Synonymous Flow Label (SFL-TLV).</dd>
          <dt pn="section-9.1-4.3">Length</dt>
          <dd pn="section-9.1-4.4">    The length of the TLV is as specified in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.</dd>
          <dt pn="section-9.1-4.5">MBZ</dt>
          <dd pn="section-9.1-4.6">
            <bcp14>MUST</bcp14> be sent as zero and ignored on receive.</dd>
          <dt pn="section-9.1-4.7">SFL Batch</dt>
          <dd pn="section-9.1-4.8"> An identifier for a collection of SFLs grouped together for management and control purposes. </dd>
          <dt pn="section-9.1-4.9">SFL Index</dt>
          <dd pn="section-9.1-4.10">
            <t indent="0" pn="section-9.1-4.10.1">The index of this SFL within the list of SFLs that were assigned
          for the FEC.</t>
            <t indent="0" pn="section-9.1-4.10.2">       Multiple SFLs can be assigned to a FEC, each
          with different actions. This index is an optional
          convenience for use in mapping between the TLV
          and the associated data structures in the LSRs.
          The use of this feature is agreed upon between the
          two parties during configuration. It is not required
          but is a convenience for the receiver if both parties
          support the facility.</t>
          </dd>
          <dt pn="section-9.1-4.11">SFL</dt>
          <dd pn="section-9.1-4.12">The SFL used to deliver this packet.  This is an MPLS
          label that is a component of a label stack entry as
          defined in <xref target="RFC3032" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3032#section-2.1" derivedContent="RFC3032"/>.</dd>
          <dt pn="section-9.1-4.13">Reserved</dt>
          <dd pn="section-9.1-4.14">
            <bcp14>MUST</bcp14> be sent as zero and ignored on receive.</dd>
          <dt pn="section-9.1-4.15">FEC</dt>
          <dd pn="section-9.1-4.16">       The Forwarding Equivalence Class that was used to
          request this SFL.  This is encoded as per
          <xref target="RFC5036" sectionFormat="of" section="3.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5036#section-3.4.1" derivedContent="RFC5036"/>.</dd>
        </dl>
        <t indent="0" pn="section-9.1-5">This information is needed to allow for operation with hardware that
discards the MPLS label stack before passing the remainder of the
stack to the OAM handler.  By providing both the SFL and the FEC plus
index into the array of allocated SFLs, a number of implementation
types are supported.</t>
      </section>
    </section>
    <section anchor="rfc6374-combined-loss-delay-measurement" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-combined-loss-delay-measure">Combined Loss/Delay Measurement Using SFL</name>
      <t indent="0" pn="section-10-1">This mode of operation is not currently supported by this specification.</t>
    </section>
    <section anchor="PCSEC" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-11-1">The inclusion of originating and/or flow information in a packet
provides more identity information and hence potentially degrades the
privacy of the communication.  While the inclusion of the additional
granularity does allow greater insight into the flow characteristics,
it does not specifically identify which node originated the packet
other than by inspection of the network at the point of ingress or
inspection of the control protocol packets.  This privacy threat may
be mitigated by encrypting the control protocol packets, regularly
changing the synonymous labels, and by concurrently using a number of
such labels.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-12-1">The security considerations documented in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> and <xref target="RFC8372" format="default" sectionFormat="of" derivedContent="RFC8372"/>
(which in turn calls up <xref target="RFC5920" format="default" sectionFormat="of" derivedContent="RFC5920"/> and <xref target="RFC7258" format="default" sectionFormat="of" derivedContent="RFC7258"/>) are applicable to this
protocol.</t>
      <t indent="0" pn="section-12-2">The issue noted in <xref target="PCSEC" format="default" sectionFormat="of" derivedContent="Section 11"/> is a security consideration.  There are
no other new security issues associated with the MPLS data plane.  Any
control protocol used to request SFLs will need to ensure the
legitimacy of the request.</t>
      <t indent="0" pn="section-12-3">An attacker that manages to corrupt the <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> SFL TLV in <xref target="sfltlv" format="default" sectionFormat="of" derivedContent="Section 9.1"/> could
disrupt the measurements in a way that the <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> responder is unable to
detect. However, the network operator is likely to notice the
anomalous network performance measurements, and in any case,
normal MPLS network security procedures make this type of attack extremely unlikely.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-13">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="allocation-of-mpls-generalized-associated-channel-g-ach-types" numbered="true" toc="include" removeInRFC="false" pn="section-13.1">
        <name slugifiedName="name-allocation-of-mpls-generali">Allocation of MPLS Generalized Associated Channel (G-ACh) Types</name>
        <t indent="0" pn="section-13.1-1">As per the IANA considerations in <xref target="RFC5586" format="default" sectionFormat="of" derivedContent="RFC5586"/> updated by <xref target="RFC7026" format="default" sectionFormat="of" derivedContent="RFC7026"/> and <xref target="RFC7214" format="default" sectionFormat="of" derivedContent="RFC7214"/>, IANA has
allocated the following values in the "MPLS Generalized Associated Channel 
(G-ACh) Types" registry, in the "Generic Associated Channel (G-ACh) Parameters"
registry group:</t>
        <table anchor="tab-1" align="center" pn="table-1">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</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">0x0010</td>
              <td align="left" colspan="1" rowspan="1">Time Bucket Jitter Measurement</td>
              <td align="left" colspan="1" rowspan="1">RFC 9571</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x0011</td>
              <td align="left" colspan="1" rowspan="1">Multi-packet Delay Measurement</td>
              <td align="left" colspan="1" rowspan="1">RFC 9571</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">0x0012</td>
              <td align="left" colspan="1" rowspan="1">Average Delay Measurement</td>
              <td align="left" colspan="1" rowspan="1">RFC 9571</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="allocation-of-mpls-lossdelay-tlv-object" numbered="true" toc="include" removeInRFC="false" pn="section-13.2">
        <name slugifiedName="name-allocation-of-mpls-loss-del">Allocation of MPLS Loss/Delay TLV Object</name>
        <t indent="0" pn="section-13.2-1">IANA has allocated the following TLV from the 0-127 range of the
"MPLS Loss/Delay Measurement TLV Object" registry in the
"Generic Associated Channel (G-ACh) Parameters" registry group:</t>
        <table anchor="tab-2" align="center" pn="table-2">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type</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">4</td>
              <td align="left" colspan="1" rowspan="1">Synonymous Flow Label</td>
              <td align="left" colspan="1" rowspan="1">RFC 9571</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-14">
      <name slugifiedName="name-references">References</name>
      <references pn="section-14.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="RFC3032" target="https://www.rfc-editor.org/info/rfc3032" quoteTitle="true" derivedAnchor="RFC3032">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
        <reference anchor="RFC5036" target="https://www.rfc-editor.org/info/rfc5036" quoteTitle="true" derivedAnchor="RFC5036">
          <front>
            <title>LDP Specification</title>
            <author fullname="L. Andersson" initials="L." role="editor" surname="Andersson"/>
            <author fullname="I. Minei" initials="I." role="editor" surname="Minei"/>
            <author fullname="B. Thomas" initials="B." role="editor" surname="Thomas"/>
            <date month="October" year="2007"/>
            <abstract>
              <t indent="0">The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5036"/>
          <seriesInfo name="DOI" value="10.17487/RFC5036"/>
        </reference>
        <reference anchor="RFC5586" target="https://www.rfc-editor.org/info/rfc5586" quoteTitle="true" derivedAnchor="RFC5586">
          <front>
            <title>MPLS Generic Associated Channel</title>
            <author fullname="M. Bocci" initials="M." role="editor" surname="Bocci"/>
            <author fullname="M. Vigoureux" initials="M." role="editor" surname="Vigoureux"/>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <date month="June" year="2009"/>
            <abstract>
              <t indent="0">This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5586"/>
          <seriesInfo name="DOI" value="10.17487/RFC5586"/>
        </reference>
        <reference anchor="RFC6374" target="https://www.rfc-editor.org/info/rfc6374" quoteTitle="true" derivedAnchor="RFC6374">
          <front>
            <title>Packet Loss and Delay Measurement for MPLS Networks</title>
            <author fullname="D. Frost" initials="D." surname="Frost"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <date month="September" year="2011"/>
            <abstract>
              <t indent="0">Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6374"/>
          <seriesInfo name="DOI" value="10.17487/RFC6374"/>
        </reference>
        <reference anchor="RFC7026" target="https://www.rfc-editor.org/info/rfc7026" quoteTitle="true" derivedAnchor="RFC7026">
          <front>
            <title>Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel</title>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <date month="September" year="2013"/>
            <abstract>
              <t indent="0">The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs</t>
              <t indent="0">No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.</t>
              <t indent="0">This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7026"/>
          <seriesInfo name="DOI" value="10.17487/RFC7026"/>
        </reference>
        <reference anchor="RFC7214" target="https://www.rfc-editor.org/info/rfc7214" quoteTitle="true" derivedAnchor="RFC7214">
          <front>
            <title>Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry</title>
            <author fullname="L. Andersson" initials="L." surname="Andersson"/>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586.</t>
              <t indent="0">This document also updates RFCs 6374, 6378, 6427, and 6428.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7214"/>
          <seriesInfo name="DOI" value="10.17487/RFC7214"/>
        </reference>
        <reference anchor="RFC7876" target="https://www.rfc-editor.org/info/rfc7876" quoteTitle="true" derivedAnchor="RFC7876">
          <front>
            <title>UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks</title>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="S. Soni" initials="S." surname="Soni"/>
            <date month="July" year="2016"/>
            <abstract>
              <t indent="0">RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7876"/>
          <seriesInfo name="DOI" value="10.17487/RFC7876"/>
        </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="RFC8957" target="https://www.rfc-editor.org/info/rfc8957" quoteTitle="true" derivedAnchor="RFC8957">
          <front>
            <title>Synonymous Flow Label Framework</title>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <date month="January" year="2021"/>
            <abstract>
              <t indent="0">RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8957"/>
          <seriesInfo name="DOI" value="10.17487/RFC8957"/>
        </reference>
      </references>
      <references pn="section-14.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3270" target="https://www.rfc-editor.org/info/rfc3270" quoteTitle="true" derivedAnchor="RFC3270">
          <front>
            <title>Multi-Protocol Label Switching (MPLS) Support of Differentiated Services</title>
            <author fullname="F. Le Faucheur" initials="F." role="editor" surname="Le Faucheur"/>
            <author fullname="L. Wu" initials="L." surname="Wu"/>
            <author fullname="B. Davie" initials="B." surname="Davie"/>
            <author fullname="S. Davari" initials="S." surname="Davari"/>
            <author fullname="P. Vaananen" initials="P." surname="Vaananen"/>
            <author fullname="R. Krishnan" initials="R." surname="Krishnan"/>
            <author fullname="P. Cheval" initials="P." surname="Cheval"/>
            <author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
            <date month="May" year="2002"/>
            <abstract>
              <t indent="0">This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3270"/>
          <seriesInfo name="DOI" value="10.17487/RFC3270"/>
        </reference>
        <reference anchor="RFC5920" target="https://www.rfc-editor.org/info/rfc5920" quoteTitle="true" derivedAnchor="RFC5920">
          <front>
            <title>Security Framework for MPLS and GMPLS Networks</title>
            <author fullname="L. Fang" initials="L." role="editor" surname="Fang"/>
            <date month="July" year="2010"/>
            <abstract>
              <t indent="0">This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5920"/>
          <seriesInfo name="DOI" value="10.17487/RFC5920"/>
        </reference>
        <reference anchor="RFC5921" target="https://www.rfc-editor.org/info/rfc5921" quoteTitle="true" derivedAnchor="RFC5921">
          <front>
            <title>A Framework for MPLS in Transport Networks</title>
            <author fullname="M. Bocci" initials="M." role="editor" surname="Bocci"/>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <author fullname="D. Frost" initials="D." role="editor" surname="Frost"/>
            <author fullname="L. Levrau" initials="L." surname="Levrau"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <date month="July" year="2010"/>
            <abstract>
              <t indent="0">This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.</t>
              <t indent="0">This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.</t>
              <t indent="0">This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5921"/>
          <seriesInfo name="DOI" value="10.17487/RFC5921"/>
        </reference>
        <reference anchor="RFC7190" target="https://www.rfc-editor.org/info/rfc7190" quoteTitle="true" derivedAnchor="RFC7190">
          <front>
            <title>Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)</title>
            <author fullname="C. Villamizar" initials="C." surname="Villamizar"/>
            <date month="March" year="2014"/>
            <abstract>
              <t indent="0">Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.</t>
              <t indent="0">Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7190"/>
          <seriesInfo name="DOI" value="10.17487/RFC7190"/>
        </reference>
        <reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7258" quoteTitle="true" derivedAnchor="RFC7258">
          <front>
            <title>Pervasive Monitoring Is an Attack</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="188"/>
          <seriesInfo name="RFC" value="7258"/>
          <seriesInfo name="DOI" value="10.17487/RFC7258"/>
        </reference>
        <reference anchor="RFC8372" target="https://www.rfc-editor.org/info/rfc8372" quoteTitle="true" derivedAnchor="RFC8372">
          <front>
            <title>MPLS Flow Identification Considerations</title>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8372"/>
          <seriesInfo name="DOI" value="10.17487/RFC8372"/>
        </reference>
        <reference anchor="RFC9341" target="https://www.rfc-editor.org/info/rfc9341" quoteTitle="true" derivedAnchor="RFC9341">
          <front>
            <title>Alternate-Marking Method</title>
            <author fullname="G. Fioccola" initials="G." role="editor" surname="Fioccola"/>
            <author fullname="M. Cociglio" initials="M." surname="Cociglio"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <author fullname="T. Zhou" initials="T." surname="Zhou"/>
            <date month="December" year="2022"/>
            <abstract>
              <t indent="0">This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9341"/>
          <seriesInfo name="DOI" value="10.17487/RFC9341"/>
        </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 thank <contact fullname="Benjamin Kaduk"/> and <contact fullname="Elwyn Davies"/> for their thorough and thoughtful
review of this document.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Zhenbin Li">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <email>lizhenbin@huawei.com</email>
        </address>
      </contact>
      <contact fullname="Siva Sivabalan">
        <organization showOnFrontPage="true">Ciena Corporation</organization>
        <address>
          <email>ssivabal@ciena.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="S." surname="Bryant" fullname="Stewart Bryant" role="editor">
        <organization showOnFrontPage="true">University of Surrey</organization>
        <address>
          <email>sb@stewartbryant.com</email>
        </address>
      </author>
      <author initials="G." surname="Swallow" fullname="George Swallow">
        <organization showOnFrontPage="true">Independent</organization>
        <address>
          <email>swallow.ietf@gmail.com</email>
        </address>
      </author>
      <author initials="M." surname="Chen" fullname="Mach(Guoyi) Chen">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <email>mach.chen@huawei.com</email>
        </address>
      </author>
      <author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <email>giuseppe.fioccola@huawei.com</email>
        </address>
      </author>
      <author initials="G." surname="Mirsky" fullname="Gregory Mirsky">
        <organization showOnFrontPage="true">ZTE Corp.</organization>
        <address>
          <email>gregimirsky@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
