<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6374 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC7876 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7876.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC5481 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5481.xml">
<!ENTITY RFC6790 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml">
<!ENTITY RFC7679 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml">
<!ENTITY RFC7471 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8321 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8321.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC8570 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml">
<!ENTITY RFC8571 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8571.xml">
<!ENTITY RFC8668 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8668.xml">
<!ENTITY I-D.ietf-spring-segment-routing-policy SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-policy.xml">
<!ENTITY I-D.ietf-pim-sr-p2mp-policy SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pim-sr-p2mp-policy.xml">
<!ENTITY I-D.ietf-spring-sr-replication-segment SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-replication-segment.xml">
<!ENTITY I-D.shen-spring-p2mp-transport-chain SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.shen-spring-p2mp-transport-chain.xml">
<!ENTITY I-D.ietf-pce-binding-label-sid SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-binding-label-sid.xml">
<!ENTITY I-D.ietf-spring-mpls-path-segment SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-mpls-path-segment.xml">
<!ENTITY I-D.gandhi-mpls-ioam-sr SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.gandhi-mpls-ioam-sr.xml">
<!ENTITY I-D.ietf-lsr-ospf-l2bundles SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lsr-ospf-l2bundles.xml">
<!ENTITY I-D.ietf-pce-sr-bidir-path SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-sr-bidir-path.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-mpls-rfc6374-sr-01" category="std" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2020-03-06T17:47:05Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="no"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
	<front>
	<title abbrev="Using RFC 6374 for SR-MPLS">Performance Measurement Using RFC 6374 for Segment Routing Networks with MPLS Data Plane</title>
	<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>

	<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
	<organization>Cisco Systems, Inc.</organization>
	<address>
        <email>cfilsfil@cisco.com</email>
	</address>
	</author>

	<author fullname="Daniel Voyer" initials="D." surname="Voyer">
	<organization>Bell Canada</organization>
	<address>
	<email>daniel.voyer@bell.ca</email>
	</address>
	</author>

	<author fullname="Stefano Salsano" initials="S." surname="Salsano">
	<organization>Universita di Roma "Tor Vergata"</organization>
	<address><postal><street>Italy</street>
	</postal>
	<email>stefano.salsano@uniroma2.it</email>
	</address>
	</author>

	<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
	<organization>Huawei</organization>
	<address>
        <email>mach.chen@huawei.com</email>
	</address>
	</author>

	<date day="06" month="January" year="2021"/>
	<workgroup>MPLS Working Group</workgroup>
	<abstract><t>
   Segment Routing (SR) leverages the source routing paradigm.  RFC 6374
   specifies protocol mechanisms to enable the efficient and accurate
   measurement of packet loss, one-way and two-way delay, as well as
   related metrics such as delay variation in MPLS networks using probe
   messages.  This document utilizes these mechanisms for Performance
   Delay and Loss Measurements in Segment Routing networks with
   MPLS data plane (SR-MPLS), for both SR-MPLS links and end-to-end 
   paths including SR-MPLS Policies.  In addition, this document defines Return Path TLV for
   two-way performance measurement and Block Number TLV for loss
   measurement.</t>

	</abstract>
	</front>

	<middle>
	<section title="Introduction" anchor="sect-1"><t>
   Service provider's ability to satisfy 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.  The ability to monitor these performance
   metrics also provides operators with greater visibility into the
   performance characteristics of their networks, thereby facilitating
   planning, troubleshooting, and network performance evaluation.</t>

	<t>
   Segment Routing (SR) leverages the source routing paradigm and
   greatly simplifies network operations for Software Defined Networks
   (SDNs).  SR is applicable to both Multiprotocol Label Switching
   (SR-MPLS) and IPv6 (SRv6) data planes.  SR takes advantage of the
   Equal-Cost Multipaths (ECMPs) between source and transit nodes,
   between transit nodes and between transit and destination nodes.  SR
   Policies as defined in <xref target="I-D.ietf-spring-segment-routing-policy"/> are used
   to steer traffic through a specific, user-defined paths using a stack
   of Segments.  Built-in SR Performance Measurement (PM) is one of the
   essential requirements to provide Service Level Agreements (SLAs).</t>

	<t>
   <xref target="RFC6374"/> specifies protocol mechanisms to enable the efficient and
   accurate measurement of performance metrics in MPLS networks using
   probe messages. These mechanisms are also well-suited for Segment Routing networks when
   using MPLS data plane (SR-MPLS).  <xref target="RFC6374"/> also supports 
   "direct mode" Loss Measurement (LM), which is required in SR networks.</t>

	<t>
   <xref target="RFC7876"/> specifies the procedures to be used when sending and
   processing out-of-band performance measurement probe responses over an
   UDP return path when receiving RFC 6374 based probe queries.  These
   procedures can be used to send out-of-band probe responses for both
   SR-MPLS links and Policies for one-way measurement.</t>

	<t>
   This document utilizes the probe-based mechanisms defined in
   <xref target="RFC6374"/> for Performance Delay and Loss Measurements in SR networks
   with MPLS data plane, for both SR-MPLS links and end-to-end paths including SR-MPLS Policies.
   In addition, this document defines Return Path TLV for two-way
   performance measurement and Block Number TLV for loss measurement.
   The Performance Measurements (PM) for SR-MPLS links are used to compute
   extended Traffic Engineering (TE) metrics for delay and loss and can
   be advertised in the network using the routing protocol extensions
   defined in <xref target="RFC7471"/>, <xref target="RFC8570"/>, and <xref target="RFC8571"/>.</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", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"/> <xref target="RFC8174"/>
   when, and only when, they appear in all capitals, as shown here.</t>

	</section>

	<section title="Abbreviations" anchor="sect-2.2"><t>
   ACH: Associated Channel Header.</t>

	<t>
   DM: Delay Measurement.</t>

	<t>
   ECMP: Equal Cost Multi-Path.</t>

	<t>
   G-ACh: Generic Associated Channel (G-ACh).</t>

	<t>
   GAL: Generic Associated Channel (G-ACh) Label.</t>

	<t>
   LM: Loss Measurement.</t>

	<t>
   MPLS: Multiprotocol Label Switching.</t>

	<t>
   NTP: Network Time Protocol.</t>

	<t>
   PM: Performance Measurement.</t>

	<t>
   PSID: Path Segment Identifier.</t>

	<t>
   PTP: Precision Time Protocol.</t>

	<t>
   SID: Segment ID.</t>

	<t>
   SL: Segment List.</t>

	<t>
   SR: Segment Routing.</t>

	<t>
   SR-MPLS: Segment Routing with MPLS data plane.</t>

	<t>
   TC: Traffic Class.</t>

	<t>
   TE: Traffic Engineering.</t>

	<t>
   URO: UDP Return Object.</t>

	</section>

	<section title="Reference Topology" anchor="sect-2.3"><t>
   In the reference topology shown in Figure 1, the querier node R1
   initiates a performance measurement probe query and the responder
   node R3 sends a probe response message for the query message received.  The
   probe response message is sent back to the querier node R1.</t> 

   <t>SR is enabled with MPLS data plane on nodes R1 and R3.
   The nodes R1 and R3 may be directly connected via a link enabled with MPLS 
   or there exists a Point-to-Point (P2P) SR-MPLS path e.g. Policy
   <xref target="I-D.ietf-spring-segment-routing-policy"/> on node R1 
   (called head-end) with destination to
   node R3 (called tail-end).</t>  
 
	<figure title="Reference Topology" anchor="ure-reference-topology"><artwork><![CDATA[

                       T1                T2
                      /                   \
             +-------+       Query         +-------+
             |       | - - - - - - - - - ->|       |
             |   R1  |=====================|   R3  |
             |       |<- - - - - - - - - - |       |
             +-------+       Response      +-------+
                      \                   /
                       T4                T3
              Querier                       Responder
]]></artwork>
	</figure>
	</section>

	</section>

	<section title="Overview" anchor="sect-3"><t>
   For one-way, two-way and round-trip delay measurements, the procedures defined in
   Section 2.4 and Section 2.6 of <xref target="RFC6374"/> are used.  For transmit and receive packet loss
   measurements, the procedures defined in Section 2.2 and Section 2.6 of
   <xref target="RFC6374"/> are used.</t>

	<t>
   For Performance Measurement, probe query and response messages are
   sent as following:</t>

	<t><list style="symbols"><t>For delay measurement, the probe messages are sent in-band (on the
      same path as the data traffic) by the querier node, and are
      used to measure the delay experienced by the actual data traffic
      flowing on the SR-MPLS links and Policies.</t>

	<t>For loss measurement, the probe messages are sent in-band (on the same
      path as the data traffic) by the querier node, and are used to
      collect the receive traffic counters for the incoming link or
      incoming SID where the probe query messages are received at the
      responder node (using incoming link or incoming SID avoids additional 
      state on the responder.</t>

	</list>
	</t>

	<t>
   The In-Situ Operations, Administration, and Maintenance (IOAM)
   mechanisms for SR-MPLS defined in <xref target="I-D.gandhi-mpls-ioam-sr"/> are used to
   carry PM information in-band as part of the data traffic packets, and
   are outside the scope of this document.</t>

	</section>


	<section title="Probe Query and Response Messages" anchor="sect-4">
		
	<section title="Probe Message for SR-MPLS Links" anchor="sect-4.2"><t>
   As described in Section 2.9.1 of <xref target="RFC6374"/>, probe query and
   response messages flow over the MPLS Generic Associated Channel
   (G-ACh).  A probe message for SR-MPLS links contains G-ACh Label (GAL)
   (with S=1).  The GAL is followed by an Associated Channel Header
   (ACH), which identifies the message type, and the message payload
   following the ACH as shown in Figure 2. The probe messages are routed over the links
   for both delay and loss measurement using the same procedure described in <xref target="RFC6374"/>. 
   For SR-MPLS links, the TTL value is set to 1 in the SR-MPLS header for one-way and two-way measurement modes.</t>

	<figure title="Probe Message Header for an SR-MPLS Link" anchor="ure-probe-packet-header-for-an-sr-mpls-link"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             GAL (value 13)            | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      | GAL Channel Type              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	</section>
		
        <section title="Probe Message for SR-MPLS Policies" anchor="sect-4.1"><t>
   As described in Section 2.9.1 of <xref target="RFC6374"/>, probe query and
   response messages flow over the MPLS Generic Associated Channel
   (G-ACh).  A probe message for an end-to-end SR-MPLS Policy measurement
   contains SR-MPLS label stack <xref target="I-D.ietf-spring-segment-routing-policy"/>,
   with the G-ACh Label (GAL) at the bottom of the stack (with S=1).
   The GAL is followed by an Associated Channel Header (ACH), which
   identifies the message type, and the message payload following the
   ACH as shown in Figure 3.
   For SR-MPLS Policies, the TTL value is set to 255 in the SR-MPLS header.</t>

	<figure title="Example Probe Message Header for an End-to-end SR-MPLS Policy" anchor="ure-probe-packet-header-for-an-end-to-end-sr-mpls-policy"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Label(1)             | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Label(n)             | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  GAL (value 13)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      | GAL Channel Type              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   The SR-MPLS label stack can be empty (as shown in Figure 2) to
   indicate Implicit NULL label case.</t>

	<t>For SR-MPLS Policy performance measurement, in order to ensure that the
      probe query message is processed by the intended responder node,
      Destination Address TLV (Type 129) <xref target="RFC6374"/> MAY be sent in the probe query
      message.  The responder node only returns Success in Control Code if it is the intended
      destination for the probe query. 
      Otherwise, it MUST return 0x15: Error - Invalid Destination Node Identifier <xref target="RFC6374"/>.</t>

	</section>

	<section title="Probe Response Message for SR-MPLS Links and Policies" anchor="sect-4.3"><section title="One-way Measurement Mode" anchor="sect-4.3.1"><t>
   In one-way performance measurement mode <xref target="RFC7679"/>, the querier node
   can receive "out-of-band" probe responses by properly setting the UDP
   Return Object (URO) TLV in the probe query message.  The URO TLV
   (Type=131) is defined in <xref target="RFC7876"/> and includes the
   UDP-Destination-Port and IP Address.  In particular, if the querier node
   sets its own IP address in the URO TLV, the probe response is sent
   back by the responder node to the querier node.  In addition, the
   "control code" in the probe query message is set to "out-of-band response requested".
   In this delay measurement mode, as per	
   Reference Topology, timestamps T1 and T2 are collected	
   by the probes to measure one-way delay. The one-way mode is applicable to both SR-MPLS links and Policies.</t>

	</section>

	<section title="Two-way Measurement Mode" anchor="sect-4.3.2"><t>
   In two-way performance measurement mode <xref target="RFC6374"/>, when using a
   bidirectional SR path <xref target="I-D.ietf-pce-sr-bidir-path"/>, 
   the probe response message is sent back to the
   querier node in-band (on the same path as the data traffic) on the reverse
   direction SR-MPLS link or associated SR-MPLS Policy <xref target="I-D.ietf-pce-sr-bidir-path"/> using a
   message with format similar to their probe query message.  In this
   case, the "control code" in the probe query message is set to "in-band response requested".
   In this delay measurement mode, as per	
   Reference Topology, all timestamps T1, T2, T3, and T4 are collected	
   by the probes. All four timestamps are used to measure two-way delay. 
   The two-way mode is applicable to both SR-MPLS links and Policies.</t>

   <t>Specifically, the probe response message is sent back on the incoming	
   physical interface where the probe query message is received.  This	
   is useful for example, in case of two-way measurement mode for link delay.</t>

   <t>
   The Path Segment Identifier (PSID) <xref target="I-D.ietf-spring-mpls-path-segment"/> 
   of the forward SR-MPLS Policy in the
   probe query can be used to find the associated reverse SR-MPLS Policy <xref target="I-D.ietf-pce-sr-bidir-path"/> 
   to send the probe response message for
   two-way measurement of SR-MPLS Policy unless when using the Return Path TLV.</t>

	</section>

	<section title="Loopback Measurement Mode" anchor="sect-4.3.3"><t>
   The Loopback measurement mode defined in Section 2.8 of <xref target="RFC6374"/> can
   be used to measure round-trip delay for a bidirectional SR-MPLS path
   <xref target="I-D.ietf-pce-sr-bidir-path"/>.  The probe query messages in this case carries the
   return Path label stack as part of the MPLS header.  The GAL is
   still carried at the bottom of the label stack (with S=1).  The
   responder node does not process the probe messages and generate
   response messages, and hence Loopback Request object (Type 3)
   is not required for SR.  In this delay
   measurement mode, as per Reference Topology, the timestamps T1 and T4
   are collected by the probes.  Both these timestamps are used to
   measure round-trip delay.</t>

	</section>

	</section>

	<section title="Return Path TLV Extensions" anchor="sect-4.4"><t>
   For two-way performance measurement, the responder node needs to send
   the probe response message on a specific return path.  The querier
   node can request in the probe query message to the responder node to
   send a response message back on a given return path (e.g. co-routed
   path for two-way measurement). This way the responder 
   does not require any additional state for return path.</t>

	<t>
   For one-way performance measurement, the querier node address may not
   be reachable via IP route from the responder node.  The querier node
   in this case needs to send its reachability path information to the
   responder node.</t>

	<t>
   <xref target="RFC6374"/> defines DM and LM probe query messages that can include one
   or more optional TLVs.  New TLV Type (TBA1) is defined in this
   document for Return Path to carry return path information in the probe query
   messages (in the payload).  The format of the Return
   Path TLV is shown in Figure 4:</t>

	<figure title="Return Path TLV" anchor="ure-return-path-tlv"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type = TBA1  |    Length     |      Reserved                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Return Path Sub-TLV                        |
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>

   <t>The Return Path TLV contains a Sub-TLV to carry the return path. 
   The format of the Segment-List Sub-TLV is shown in Figure 5. The Label entries MUST be in network order. The Segment List Sub-TLV in the Return Path TLV can be one of the
   following Types:</t>

	<t><list style="symbols"><t>Type (value 1): SR-MPLS Label Stack of the Return Path</t>

	<t>Type (value 2): SR-MPLS Binding SID <xref target="I-D.ietf-pce-binding-label-sid"/> of
                      the Reverse SR Policy</t>

	</list>
	</t>

	<figure title="Segment List Sub-TLV in Return Path TLV" anchor="ure-segment-list-sub-tlv-in-return-path-tlv"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |      Reserved                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Label(1)                                   |
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Label(n) (bottom of stack)                 |
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>

	<t>
   The Return Path TLV is a Mandatory TLV Type.  The querier node MUST only insert
   one Return Path TLV in the probe query message. 
   The Return Path TLV MUST carry only one Return Path Sub-TLV. 
   The responder node MUST only process the first Return Path TLV and first 
   Return Path Sub-TLV in the probe query
   message and ignore other Return Path TLVs if present.  The responder
   node MUST send probe response message back on the return path
   specified in the Return Path TLV and MUST NOT add Return Path TLV in
   the probe response message.  </t>
	</section>

	</section>

	<section title="Delay Measurement" anchor="sect-5"><section title="Delay Measurement Message Format" anchor="sect-5.1"><t>
   As defined in <xref target="RFC6374"/>, MPLS DM probe query and response messages
   use Associated Channel Header (ACH) (value 0x000C for delay
   measurement) <xref target="RFC6374"/>, which identifies the message type, and the
   message payload following the ACH.  For both SR-MPLS links and end-to-end
   Policies measurements, the same MPLS DM ACH value is used.</t>

	<t>
   The DM message payload as defined in Section 3.2 of <xref target="RFC6374"/> is used
   for SR-MPLS delay measurement, for both SR-MPLS links and end-to-end Policies.</t>

	</section>

	<section title="Timestamps" anchor="sect-5.2"><t>
   The Section 3.4 of <xref target="RFC6374"/> defines timestamp format that can be
   used for delay measurement.  The IEEE 1588 Precision Time Protocol
   (PTP) timestamp format <xref target="IEEE1588"/> is used by default as described in
   Appendix A of <xref target="RFC6374"/>, with hardware support recommended in Segment
   Routing networks.</t>

	</section>

	</section>

	<section title="Loss Measurement" anchor="sect-6"><t>
   The LM protocol can perform two distinct kinds of loss measurement as
   described in Section 2.9.8 of <xref target="RFC6374"/>.</t>

	<t><list style="symbols"><t>In inferred mode, LM will measure the loss of specially generated
      test messages in order to infer the approximate data plane loss
      level.  Inferred mode LM provides only approximate loss
      accounting.</t>

	<t>In direct mode, LM will directly measure data plane packet loss.
      Direct mode LM provides perfect loss accounting, but may require
      hardware support.</t>

	</list>
	</t>

	<t>
   For both of these modes of LM, Path Segment Identifier (PSID)
   <xref target="I-D.ietf-spring-mpls-path-segment"/> is used for accounting received
   traffic on the egress node of the SR-MPLS Policy as shown in Figure
   6.  Different values of PSID can be used to measure packet loss per
   SR-MPLS Policy, per Candidate Path or per Segment List of the SR
   Policy.</t>

	<figure title="Example With Path Segment Identifier for SR-MPLS Policy" anchor="ure-with-path-segment-identifier-for-sr-mpls-policy"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  PSID                 | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  GAL (value 13)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      | GAL Channel Type              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<section title="Loss Measurement Message Format" anchor="sect-6.1"><t>
   As defined in <xref target="RFC6374"/>, MPLS LM probe query and response messages
   use Associated Channel Header (ACH) (value 0x000A for direct loss
   measurement or value 0x000B for inferred loss measurement), which
   identifies the message type, and the message payload following the
   ACH.  For both SR-MPLS links and end-to-end 
   Policies measurements, the same MPLS LM ACH value is used.</t>

	<t>
   The LM message payload as defined in Section 3.1 of <xref target="RFC6374"/> is used
   for SR-MPLS loss measurement, for both SR-MPLS links and end-to-end 
   Policies.</t>

	</section>

	<section title="Block Number TLV Extensions" anchor="sect-6.2"><t>
   The loss measurement using Alternate-Marking method defined in
   <xref target="RFC8321"/> requires to color the data traffic.  To be able to correlate
   the transmit and receive traffic counters of the matching color, the
   Block Number (or color) of the traffic counters is carried by the
   probe query and response messages for loss measurement.</t>

	<t>
   <xref target="RFC6374"/> defines probe query and response messages that can include
   one or more optional TLVs.  New TLV Type (value TBA2) is defined in
   this document to carry the Block Number (8-bit) of the traffic
   counters in the probe query and response messages for loss
   measurement.  The format of the Block Number TLV is shown in Figure
   7:</t>

	<figure title="Block Number TLV" anchor="ure-block-number-tlv"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type TBA2   |    Length     | Reserved      | Block Number  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   The Block Number TLV is a Mandatory TLV Type. 
   The querier node MUST only
   insert one Block Number TLV in the probe query message and the
   responder node in the probe response message MUST return the first
   Block Number TLV from the probe query messages and ignore other Block
   Number TLVs if present.</t>

	</section>

	<section title="Combined Loss/Delay Measurement Message Format" anchor="sect-6.3"><t>
   As defined in <xref target="RFC6374"/>, Combined DM+LM probe query and response messages
   use Associated Channel Header (ACH) (value 0x000D for direct loss
   and delay measurement or value 0x000E for inferred loss and delay measurement), which
   identifies the message type, and the message payload following the
   ACH.  For both SR-MPLS links and end-to-end 
   Policies measurements, the same MPLS ACH value is used.</t>

	<t>
   The message payload as defined in Section 3.3 of <xref target="RFC6374"/> is used
   for SR-MPLS combined delay and loss measurement, for both SR-MPLS links and end-to-end 
   Policies.</t>
        </section>

	</section>

	<section title="Performance Measurement for P2MP SR-MPLS Policies" anchor="sect-7"><t>
   The Point-to-Multipoint (P2MP) SR-MPLS path
   that originates from a root node terminates on multiple destinations called leaf nodes 
   (e.g. P2MP SR-MPLS Policy <xref target="I-D.ietf-pim-sr-p2mp-policy"/> 
   or P2MP Transport <xref target="I-D.shen-spring-p2mp-transport-chain"/>).</t>

   <t>The procedures for delay and loss measurement described in this
   document for P2P SR-MPLS Policies  
   are also equally applicable to the P2MP SR-MPLS Policies. 
   The procedure for one-way measurement is defined as following:</t>

	<t><list style="symbols"><t>The querier root node sends probe query messages using the
      Tree-SID defined in <xref target="I-D.ietf-pim-sr-p2mp-policy"/> for the
      P2MP SR-MPLS Policy as shown in Figure 8.</t>

        <t>The probe query messages can contain
      the replication SID as defined in <xref target="I-D.ietf-spring-sr-replication-segment"/>.</t>

	<t>Each responder leaf node adds the "Source Address" TLV (Type 130)
      <xref target="RFC6374"/> with its IP address in the probe response messages.
      This TLV allows the querier root node to identify the responder
      leaf nodes of the P2MP SR-MPLS Policy.</t>

	<t>The P2MP root node measures the delay and loss
      performance for each P2MP leaf node of the end-to-end P2MP SR-MPLS Policy.</t>

	</list>
	</t>

	<figure title="Example Probe Query with Tree-SID for SR-MPLS Policy" anchor="ure-with-replication-segment-for-sr-mpls-policy"><artwork><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Tree-SID                 | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              GAL (value 13)           | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 1|Version| Reserved      | GAL Channel Type              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>


    <t>
   The probe query messages can also be sent using
   the scheme defined for P2MP Transport using Chain Replication that may contain Bud SID as defined in 
   <xref target="I-D.shen-spring-p2mp-transport-chain"/>.</t>

    <t>
   The considerations for two-way mode for performance measurement for 
   P2MP SR-MPLS Policy (e.g. for bidirectional SR-MPLS path) are outside the scope of this document.</t>

	</section>

	<section title="ECMP for SR-MPLS Policies" anchor="sect-8"><t>
   An SR-MPLS Policy can have ECMPs between the source and transit nodes,
   between transit nodes and between transit and destination nodes.
   Usage of Anycast SID <xref target="RFC8402"/> by an SR-MPLS Policy can result in ECMP
   paths via transit nodes part of that Anycast group.  The probe
   messages need to be sent to traverse different ECMP paths to measure
   performance delay of each of the ECMP path of an SR-MPLS Policy.</t>

	<t>
   Forwarding plane has various hashing functions available to forward
   packets on specific ECMP paths.  For SR-MPLS Policy, sweeping of
   entropy label <xref target="RFC6790"/> values can be used in probe messages to
   take advantage of the hashing function in forwarding plane to
   influence the ECMP path taken by them.</t>

	<t>
   The considerations for performance loss measurement for different
   ECMP paths of an SR-MPLS Policy are outside the scope of this document.</t>

	</section>

	<section title="SR-MPLS Link Extended TE Metrics Advertisements" anchor="sect-9"><t>
   The extended TE metrics for SR-MPLS link delay and loss computed using the
   performance measurement procedures described in this document can be
   advertised in the routing domain as follows:</t>

	<t><list style="symbols"><t>For OSPF, ISIS, and BGP-LS, protocol extensions defined in
      <xref target="RFC7471"/>, <xref target="RFC8570"/>, and <xref target="RFC8571"/> are used, respectively for
      advertising the extended TE link metrics in the network.</t>

	<t>The advertised delay-variance metric is computed as specified in
      Section 4.2 of <xref target="RFC5481"/>.</t>

	<t>The extended TE link one-way delay metrics can also be computed using
      two-way delay measurement or round-trip delay measurement from
      loopback mode by dividing the measured delay values by 2.</t>

	<t>The extended TE link delay and loss metrics are advertised for
      Layer 2 bundle members in OSPF <xref target="I-D.ietf-lsr-ospf-l2bundles"/> and ISIS
      <xref target="RFC8668"/> using the same mechanisms defined in
      <xref target="RFC7471"/> and <xref target="RFC8570"/>, respectively.</t>

	</list>
	</t>

	</section>

	<section title="Backwards Compatibility" anchor="sect-10"><t>
   The procedures defined in this document are backwards compatible with 
   the procedures defined in <xref target="RFC6374"/> at both querier and responder nodes. 
   If the responder does not support the new Mandatory 
   TLV Types defined in this document, 
   it MUST return Error 0x17: Unsupported Mandatory TLV Object as per <xref target="RFC6374"/>.
   </t>

	</section>

	<section title="Security Considerations" anchor="sect-11"><t>
   This document describes the procedures for performance delay and loss
   measurement for SR-MPLS networks, for both SR-MPLS links and end-to-end 
   Policies using the mechanisms defined in <xref target="RFC6374"/> and <xref target="RFC7876"/>.
   This document does not introduce any additional security
   considerations other than those covered in <xref target="RFC6374"/>, <xref target="RFC7471"/>,
   <xref target="RFC8570"/>, <xref target="RFC8571"/>, and <xref target="RFC7876"/>.</t>

	</section>

	<section title="IANA Considerations" anchor="sect-12">
	<t>IANA is requested to allocate a value for the following Mandatory
   Block Number TLV Type for  <xref target="RFC6374"/> to be carried in the probe
   query and response messages from the "MPLS Loss/Delay Measurement TLV Object" 
   registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry set:</t>

	<t><list style="symbols"><t>Type TBA2: Block Number TLV</t>

	</list>
	</t>
		
   <t>IANA is also requested to allocate a value for the following Mandatory
   Return Path TLV Type for <xref target="RFC6374"/> to be carried in the probe query
   messages from the "MPLS Loss/Delay Measurement TLV Object" registry 
   contained within the "Generic Associated Channel (G-ACh) Parameters" registry set:</t>

	<t><list style="symbols"><t>Type TBA1: Return Path TLV</t>

	</list>
	</t>

   <t>IANA is requested to create the “Return Path Sub-TLV” sub-registry as part of
   the Return Path TLV registry.  All code points in the range 1 through
   127 in this registry shall be allocated according to the "IETF
   Review" procedure as specified in <xref target="RFC8126"/>. Code points in the
   range 128 through 239 in this registry shall be allocated according
   to the "First Come First Served" procedure as specified in <xref target="RFC8126"/>.
   Remaining code points are allocated according to <xref target="iana-return-path-tbl"/>:</t>

     <texttable anchor="iana-return-path-tbl" title="Return Path Sub-TLV Type Sub-Registry">
    <ttcol align="left">Value</ttcol>
    <ttcol align="center">Description</ttcol>
    <ttcol align="left">Reference</ttcol>
     <c>0</c>
    <c>Reserved</c>
    <c>This document</c>
     <c>1 - 127</c>
    <c>Unassigned</c>
    <c>This document</c>
     <c>128 - 239</c>
    <c>Unassigned</c>
    <c>This document</c>
     <c>240 - 249</c>
    <c>Experimental</c>
    <c>This document</c>

     <c>250 - 254</c>
    <c>Private Use</c>
    <c>This document</c>
         <c>255</c>
    <c>Reserved</c>
    <c>This document</c>
   </texttable>
 

   <t>This document defines the following new values in the Return Path Sub-TLV sub-registry:</t>

     <texttable anchor="iana-return-path-type-tbl" title="Return Path Sub-TLV Types ">
    <ttcol align="left">Value</ttcol>
    <ttcol align="center">Description</ttcol>
    <ttcol align="left">Reference</ttcol>
     <c>1</c>
    <c>SR-MPLS Label Stack of the Return Path</c>
    <c>This document</c>
     <c>2</c>
    <c>SR-MPLS Binding SID of the Reverse SR Policy</c>
    <c>This document</c>
   </texttable>



	</section>

	</middle>

	<back>
	<references title="Normative References">
	&RFC2119;
	&RFC6374;
	&RFC7876;
	&RFC8174;
	</references>
	<references title="Informative References">
	<reference anchor="IEEE1588"><front>
	<title>1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</title>
	<author>
	<organization>IEEE</organization>
	</author>

	<date month="March" year="2008"/>
	</front>

	</reference>
	&RFC5481;
	&RFC6790;
	&RFC7679;
	&RFC7471;
	&RFC8126;
	&RFC8321;
	&RFC8402;
	&RFC8570;
	&RFC8571;
	&RFC8668;
	&I-D.ietf-spring-segment-routing-policy;
	&I-D.ietf-pim-sr-p2mp-policy;
	&I-D.ietf-spring-sr-replication-segment;
	&I-D.ietf-pce-binding-label-sid;
	&I-D.ietf-spring-mpls-path-segment;
	&I-D.ietf-lsr-ospf-l2bundles;
	&I-D.ietf-pce-sr-bidir-path;
	&I-D.shen-spring-p2mp-transport-chain;
	&I-D.gandhi-mpls-ioam-sr;
	</references>
	<section title="Acknowledgments" numbered="no" anchor="acknowledgments"><t>
   The authors would like to thank Thierry Couture for the discussions
   on the use-cases for the performance measurement in segment routing
   networks.  Authors would like to thank Patrick Khordoc for 
   implementing the mechanisms defined in this document.
   The authors would like to thank Greg Mirsky for providing
   many useful comments and suggestions.  The authors would also like to
   thank Stewart Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for
   their review comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert review.</t>

	</section>

	<section title="Contributors" numbered="no" anchor="contributors"><figure><artwork><![CDATA[
Sagar Soni
Cisco Systems, Inc.
Email: sagsoni@cisco.com

Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com

Pier Luigi Ventre
CNIT
Italy
Email: pierluigi.ventre@cnit.it
]]></artwork>
	</figure>
	</section>

	</back>

	</rfc>
