Skip to main content

Performance Measurement for Segment Routing Networks with MPLS Data Plane
draft-ietf-mpls-rfc6374-sr-09

Document Type Active Internet-Draft (mpls WG)
Authors Rakesh Gandhi , Clarence Filsfils , Daniel Voyer , Stefano Salsano , Mach Chen
Last updated 2024-02-26 (Latest revision 2024-02-09)
Replaces draft-gandhi-mpls-rfc6374-sr
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Awaiting Expert Review/Resolution of Issues Raised
Document shepherd Tony Li
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to tsaad@cisco.com, tony.li@tony.li
draft-ietf-mpls-rfc6374-sr-09
MPLS Working Group                                        R. Gandhi, Ed.
Internet-Draft                                               C. Filsfils
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: 12 August 2024                                         D. Voyer
                                                             Bell Canada
                                                              S. Salsano
                                        Universita di Roma "Tor Vergata"
                                                                 M. Chen
                                                                  Huawei
                                                         9 February 2024

  Performance Measurement for Segment Routing Networks with MPLS Data
                                 Plane
                     draft-ietf-mpls-rfc6374-sr-09

Abstract

   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to Multiprotocol Label Switching data plane (SR-MPLS) as
   specified in RFC 8402.  RFC 6374 and RFC 7876 specify protocol
   mechanisms to enable 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.  RFC 9341 defines Alternate-Marking
   Method using Block Number (BN) for data correlation mechanism for
   packet loss measurement.  This document utilizes these mechanisms for
   Performance Delay and Loss Measurements in SR-MPLS networks, for both
   links and end-to-end SR-MPLS paths including Policies.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 12 August 2024.

Gandhi, et al.           Expires 12 August 2024                 [Page 1]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Reference Topology  . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Query and Response Messages . . . . . . . . . . . . . . . . .   6
     4.1.  Query Message for Links and Policies  . . . . . . . . . .   6
       4.1.1.  Query Message for Links . . . . . . . . . . . . . . .   6
       4.1.2.  Query Message for SR-MPLS Policies  . . . . . . . . .   6
     4.2.  Response Message for Links and Policies . . . . . . . . .   7
       4.2.1.  One-way Measurement Mode  . . . . . . . . . . . . . .   7
       4.2.2.  Two-way Measurement Mode  . . . . . . . . . . . . . .   7
       4.2.3.  Loopback Measurement Mode . . . . . . . . . . . . . .   8
   5.  Delay Measurement . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Delay Measurement Message Format  . . . . . . . . . . . .   8
   6.  Loss Measurement  . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Loss Measurement Message Format . . . . . . . . . . . . .   9
     6.2.  Combined Loss/Delay Measurement Message Format  . . . . .   9
     6.3.  Counters  . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  TLV Extensions  . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Return Path TLV Extension . . . . . . . . . . . . . . . .  10
       7.1.1.  Return Path Sub-TLV Extension . . . . . . . . . . . .  11
     7.2.  Block Number TLV Extension  . . . . . . . . . . . . . . .  12
   8.  ECMP for SR-MPLS Policies . . . . . . . . . . . . . . . . . .  12
   9.  Extended TE Link Metrics Advertisements . . . . . . . . . . .  13
   10. Backwards Compatibility . . . . . . . . . . . . . . . . . . .  13
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     13.2.  Informative References . . . . . . . . . . . . . . . . .  16

Gandhi, et al.           Expires 12 August 2024                 [Page 2]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Segment Routing (SR) leverages the source routing paradigm for
   Software Defined Networks (SDNs).  SR is applicable to both
   Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes
   [RFC8402].  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 [RFC9256]
   are used to steer traffic through a specific, user-defined paths
   using a list of Segments.  A comprehensive SR Performance Measurement
   toolset is one of the essential requirements to measure network
   performance to provide Service Level Agreements (SLAs).

   [RFC6374] specifies protocol mechanisms to enable the efficient and
   accurate measurement of performance metrics in MPLS networks using
   query and response messages.  [RFC7876] specifies mechanisms for
   sending and processing out-of-band responses over an UDP return path
   when receiving query messages defined in [RFC6374].  These mechanisms
   are also well-suited in SR-MPLS networks.

   [RFC9341] defines Alternate-Marking Method using Block Number (BN)
   for data correlation for packet loss measurement.

   This document utilizes the mechanisms defined in [RFC6374], [RFC7876]
   and [RFC9341] for Performance Delay and Loss Measurements in SR-MPLS
   networks, for both links and end-to-end SR-MPLS paths including
   Policies.

2.  Conventions Used in This Document

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Abbreviations

   ACH: Associated Channel Header.

   DM: Delay Measurement.

Gandhi, et al.           Expires 12 August 2024                 [Page 3]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   ECMP: Equal Cost Multi-Path.

   G-ACh: Generic Associated Channel (G-ACh).

   GAL: Generic Associated Channel (G-ACh) Label.

   LM: Loss Measurement.

   MPLS: Multiprotocol Label Switching.

   PSID: Path Segment Identifier.

   SID: Segment Identifier.

   SL: Segment List.

   SR: Segment Routing.

   SR-MPLS: Segment Routing with MPLS data plane.

   TC: Traffic Class.

   TE: Traffic Engineering.

   TTL: Time-To-Live.

   URO: UDP Return Object.

2.3.  Reference Topology

   In the Reference Topology shown in Figure 1, the querier node Q1
   initiates a query message and the responder node R1 transmits a
   response message for the query message received.  The response
   message may be sent back to the querier node Q1 on the same path
   (same set of links and nodes) or a different path in the reverse
   direction from the path taken towards the responder R1.

   The T1 is a transmit timestamp and T4 is a receive timestamp, both
   added by node Q1.  The T2 is a receive timestamp and T3 is a transmit
   timestamp, both added by node R1.

   SR is enabled with MPLS data plane on nodes Q1 and R1.  The nodes Q1
   and R1 may be directly connected via a link enabled with MPLS
   (Section 2.9.1 of [RFC6374]) or a Point-to-Point (P2P) SR-MPLS path
   [RFC8402].  The link may be a physical interface, virtual link, or
   Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link.  The
   SR-MPLS path may be an SR-MPLS Policy [RFC9256] on node Q1 (called
   head-end) with destination to node R1 (called tail-end).

Gandhi, et al.           Expires 12 August 2024                 [Page 4]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

                          T1                T2
                         /                   \
                +-------+       Query         +-------+
                |       | - - - - - - - - - ->|       |
                |   Q1  |=====================|   R1  |
                |       |<- - - - - - - - - - |       |
                +-------+       Response      +-------+
                         \                   /
                          T4                T3
                 Querier                       Responder

                        Figure 1: Reference Topology

3.  Overview

   For delay and loss measurement in SR-MPLS networks, the procedures
   defined in [RFC6374], [RFC7876] and [RFC9341] are used in this
   document.  Note that the one-way, two-way and round-trip delay
   measurements are defined in Section 2.4 of [RFC6374] and are further
   described in this document for SR-MPLS networks.  Similarly, the
   packet loss measurement is defined in Section 2.2 of [RFC6374] and is
   further described in this document for SR-MPLS networks.

   The packet loss measurement using Alternate-Marking Method defined in
   [RFC9341] MAY use Block Number (BN) for data correlation.  This is
   achieved by using the Block Number TLV extension defined in this
   document for MPLS networks.

   In SR-MPLS networks, the query and response messages defined in
   [RFC6374] are sent as following:

   *  For delay measurement, the query messages MUST be sent on the same
      path as data traffic for links and end-to-end SR-MPLS paths to
      collect transmit and receive timestamps.

   *  For loss measurement, the query messages MUST be sent on the same
      path as data traffic for links and end-to-end SR-MPLS paths to
      collect transmit and receive traffic counters (e.g., for traffic
      received on the incoming link for the link packet loss and for the
      incoming Path Segment Identifier (PSID)
      [I-D.ietf-spring-mpls-path-segment] for the end-to-end SR-MPLS
      path packet loss).

   If it is desired in SR-MPLS networks that the same path (same set of
   links and nodes) between the querier and responder be used in both
   directions of the measurement, it is achieved by using the SR-MPLS
   Return Path TLV extension defined in this document.

Gandhi, et al.           Expires 12 August 2024                 [Page 5]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   The performance measurement procedure for links can be used to
   compute extended Traffic Engineering (TE) metrics for delay and loss
   as described in this document.  The metrics are advertised in the
   network using the routing protocol extensions defined in [RFC7471],
   [RFC8570], and [RFC8571].

4.  Query and Response Messages

4.1.  Query Message for Links and Policies

4.1.1.  Query Message for Links

   The query message as defined in [RFC6374] is sent over the links for
   both delay and loss measurement.  For links, the TTL value MUST be
   set to 255 in the SR-MPLS header.

4.1.2.  Query Message for SR-MPLS Policies

   An SR-MPLS Policy Candidate-Path may contain a number of Segment
   Lists (SLs) (i.e., stack of MPLS labels) [RFC9256].  The query
   messages MUST be transmitted using each SL of the SR-MPLS Policy
   Candidate-Path.  A query message for an end-to-end SR-MPLS Policy,
   used for delay and/or loss measurement, contains SR-MPLS label stack
   of the Segment List(s) of the Candidate-Path, with the G-ACh Label
   (GAL) at the bottom of the stack (with S=1) as shown in Figure 2.
   For SR-MPLS, the TTL value MUST be set to 255 in the SR-MPLS header.

    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  |1|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version| Reserved      |       Channel Type            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: Example Query Message Header for an End-to-end SR-MPLS
                                   Policy

   The SR-MPLS label stack can be empty in the case of one hop SR-MPLS
   Policy with Implicit NULL label.

Gandhi, et al.           Expires 12 August 2024                 [Page 6]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   For an SR-MPLS Policy, to ensure that the query message is processed
   by the intended responder, Destination Address TLV (Type 129)
   [RFC6374] containing the address of the responder can be sent in the
   query messages.  The responder that supports this TLV MUST return
   Success in "Control Code" [RFC6374] if it is the intended destination
   for the query.  Otherwise, it MUST return 0x15: Error - Invalid
   Destination Node Identifier [RFC6374].

4.2.  Response Message for Links and Policies

4.2.1.  One-way Measurement Mode

   In one-way measurement mode defined in Section 2.4 of [RFC6374], the
   querier can receive "out-of-band" response messages with IP/UDP
   header by properly setting the UDP Return Object (URO) TLV in the
   query message.  The URO TLV (Type=131) is defined in [RFC7876] and
   includes the UDP-Destination-Port and IP Address.  When the querier
   sets an IP address and an UDP port in the URO TLV, the response
   message MUST be sent to that IP address as the destination address
   and UDP port as the destination port.  In addition, the "Control
   Code" in the query message MUST be set to "out-of-band response
   requested" [RFC6374].

4.2.2.  Two-way Measurement Mode

   In two-way measurement mode defined in Section 2.4 of [RFC6374], the
   response messages are preferred to be sent back in-band on the same
   link or the same end-to-end SR-MPLS path (same set of links and
   nodes) in the reverse direction to the querier.

   For links, the response message as defined in [RFC6374] is sent back
   on the same incoming link where the query message is received.  In
   this case, the "Control Code" in the query message MUST be set to
   "in-band response requested" [RFC6374].

   For end-to-end SR-MPLS paths, the responder transmits the response
   message (example as shown in Figure 2) on a specific return SR-MPLS
   path [I-D.ietf-pce-sr-bidir-path].  The querier can request in the
   query message to the responder to send the response message back on a
   given return path using the SR-MPLS Segment List sub-TLV in the
   Return Path TLV defined in this document.

Gandhi, et al.           Expires 12 August 2024                 [Page 7]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

4.2.3.  Loopback Measurement Mode

   The Loopback measurement mode defined in Section 2.8 of [RFC6374] is
   used to measure round-trip delay for a bidirectional circular SR-MPLS
   path [I-D.ietf-pce-sr-bidir-path].  In this mode, the received query
   messages MUST NOT be punted out of the fast path in forwarding (i.e.,
   to slow path or control- plane) at the responder.  In other words,
   the responder does not process the payload and generate response
   messages.  The loopback function simply returns the received query
   message to the querier without responder modifications [RFC6374].

   The loopback mode is done by generating "queries" with the Response
   flag set to 1 and adding the Loopback Request object (Type 3)
   [RFC6374].  The label stack in query messages in this case carry both
   the forward and reverse paths in the MPLS header.  The GAL is still
   carried at the bottom of the label stack (with S=1) (example as shown
   in Figure 2).

5.  Delay Measurement

5.1.  Delay Measurement Message Format

   As defined in [RFC6374], MPLS DM query and response messages use
   Associated Channel Header (ACH) (value 0x000C for delay measurement)
   [RFC6374], which identifies the message type, and the message payload
   as defined in Section 3.2 [RFC6374] following the ACH.  For both
   links and end-to-end SR-MPLS Policies, the same MPLS DM ACH value
   MUST be used.

6.  Loss Measurement

   The LM protocol can perform two distinct kinds of loss measurement as
   described in Section 2.9.8 of [RFC6374].

   *  In inferred mode, LM will measure the loss of specially generated
      test messages to infer the approximate data plane loss level.
      Inferred mode LM provides only approximate loss accounting.

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

Gandhi, et al.           Expires 12 August 2024                 [Page 8]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

6.1.  Loss Measurement Message Format

   As defined in [RFC6374], MPLS LM 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 defined in
   Section 3.1 [RFC6374] following the ACH.  For both links and end-to-
   end SR-MPLS Policies, the same MPLS LM ACH value MUST be used.

6.2.  Combined Loss/Delay Measurement Message Format

   As defined in [RFC6374], Combined DM+LM 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 defined in Section 3.3 [RFC6374] following the ACH.  For both
   links and end-to-end SR-MPLS Policies, the same MPLS DM+LM ACH value
   MUST be used.

6.3.  Counters

   The PSID [I-D.ietf-spring-mpls-path-segment] is carried in the
   received data packet for the traffic flow under measurement for
   accounting received traffic on the egress node of the SR-MPLS Policy.
   In direct mode, the PSID in the received query message as shown in
   Figure 3 can be used to associate the receive traffic counter on the
   responder to detect the transmit packet loss for the end-to-end SR-
   MPLS Policy.

   In inferred mode, the PSID in the received query messages as shown in
   Figure 3 can be used to count the received query messages on the
   responder to detect the transmit packet loss for an end-to-end SR-
   MPLS Policy.

    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  |1|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version| Reserved      |       Channel Type            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: Example with Path Segment Identifier for SR-MPLS Policy

Gandhi, et al.           Expires 12 August 2024                 [Page 9]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   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-MPLS
   Policy [RFC9256].

7.  TLV Extensions

7.1.  Return Path TLV Extension

   In two-way measurement mode, the responder may transmit the response
   message on a specific return path, for example, in an ECMP
   environment.  The querier can request in the query message to the
   responder to send a response message back on a given return path
   (e.g., co-routed SR-MPLS bidirectional path).  This allows the
   responder to avoid creating and maintaining additional states
   (containing return paths) for the sessions.

   The querier may not be directly reachable from the responder in a
   network.  The querier in this case MUST send its reachability path
   information to the responder using the Return Path TLV.

   [RFC6374] defines query and response messages those can include or
   more optional TLVs.  New TLV Type (TBA1) is defined in this document
   for Return Path TLV to carry return path information in query
   messages.  The format of the Return Path TLV is shown in Figure 4:

    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                        |
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: Return Path TLV

   The Length is a one-byte field and is equal to the length of the
   Return Path Sub-TLV and the Reserved field in bytes.  Length MUST NOT
   be 0.

   The Return Path TLV is a Mandatory TLV Type.  The querier MUST only
   insert one Return Path TLV in the query message.  The responder that
   supports this TLV, MUST only process the first Return Path TLV and
   ignore the other Return Path TLVs if present.  The responder that
   supports this TLV, also MUST send response message back on the return
   path specified in the Return Path TLV.  The responder also MUST NOT
   add Return Path TLV in the response message.  The Reserved field MUST
   be set to 0 and MUST be ignored on the receive side.

Gandhi, et al.           Expires 12 August 2024                [Page 10]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

7.1.1.  Return Path Sub-TLV Extension

   The Return Path TLV contains a Sub-TLV to carry the return path.  The
   format of the SR-MPLS Segment List Sub-TLV is shown in Figure 5.  The
   SR-MPLS Segment List Sub-TLV contains SR-MPLS Label Stack.  The Label
   entries in the Segment List MUST be in network order.  The SR-MPLS
   Segment List Sub-TLV in the Return Path TLV is of the following Type:

   *  Type (value 1): SR-MPLS Segment List of the Return Path

    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=1     |    Length     |      Reserved                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(n)             | TC  |1|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 5: SR-MPLS Segment List Sub-TLV in Return Path TLV

   The SR-MPLS Label Stack contains a list of 32-bit Label Stack Entry
   (LSE) that includes a 20-bit label value, 8-bit TTL value, 3-bit TC
   value and 1-bit EOS (S) field.  An SR-MPLS Segment List Sub-TLV may
   carry only Binding SID label [I-D.ietf-pce-binding-label-sid] of the
   Return SR-MPLS Policy.

   The Length is a one-byte field and is equal to the length of the
   label stack field and the Reserved field in bytes.  Length MUST NOT
   be 0.

   The Return Path TLV MUST carry only one Return Path Sub-TLV and
   Segment List in Return Path Sub-TLV MUST contain at least one
   Segment.  The responder that supports this Sub-TLV, MUST only process
   the first Return Path Sub-TLV and ignore the other Return Path Sub-
   TLVs if present.  The responder that supports this Sub-TLV, MUST send
   response message back on the return path specified in the Return Path
   Sub-TLV.  The Reserved field MUST be set to 0 and MUST be ignored on
   the receive side.

Gandhi, et al.           Expires 12 August 2024                [Page 11]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

7.2.  Block Number TLV Extension

   The packet loss measurement using Alternate-Marking Method defined in
   [RFC9341] MAY use Block Number (BN) for data correlation for the data
   traffic flow under measurement.  To be able to correlate the transmit
   and receive traffic counters of the matching Block Number, the Block
   Number of the traffic counters is carried in the LM query and
   response messages.

   [RFC6374] defines query and response messages those 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 LM query and response messages.  The format of the Block Number
   TLV is shown in Figure 6:

    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    |R| Block Number  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 6: Block Number TLV

   The Length is a one-byte field and is equal to 2 bytes.

   The Block Number TLV is a Mandatory TLV Type.  The querier MUST only
   insert one Block Number TLV in the query message to identify the
   Block Number for the traffic counters in the forward direction.  The
   responder that supports this TLV, MUST only inert one Block Number
   TLV in the response message to identify the Block Number for the
   traffic counters in the reverse direction.  The responder also MUST
   return the first Block Number TLV from the query message and ignore
   the other Block Number TLVs if present.  The R Flag MUST be clear in
   the query message and set in the response message.  The Reserved
   field MUST be set to 0 and MUST be ignored on the receive side.

8.  ECMP for SR-MPLS Policies

   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 [RFC8402] by an SR-MPLS Policy can
   result in ECMP paths via transit nodes part of that Anycast group.
   The query and response messages SHOULD be sent to traverse different
   ECMP paths to measure delay of each of the ECMP path of a Segment
   List of an SR-MPLS Policy Candidate-Path.

Gandhi, et al.           Expires 12 August 2024                [Page 12]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   Forwarding plane has various hashing functions available to forward
   packets on specific ECMP paths.  For SR-MPLS Policy, sweeping of
   entropy label [RFC6790] values can be used in query and response
   messages to take advantage of the hashing function in forwarding
   plane to influence the ECMP path taken by them.

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

9.  Extended TE Link Metrics Advertisements

   The extended TE metrics for link delay and loss can be computed using
   the performance measurement procedures described in this document and
   advertised in the routing domain as follows:

   *  For OSPF, ISIS, and BGP-LS, protocol extensions defined in
      [RFC7471], [RFC8570], and [RFC8571], respectively, are used for
      advertising the extended TE link delay and loss metrics in the
      network.

   *  The extended TE link delay and loss metrics are advertised for
      Layer-2 LAG bundle member links in OSPF [RFC9356] and ISIS
      [RFC8668] using the same protocol extensions defined in [RFC7471]
      and [RFC8570], respectively.

   *  The advertised delay-variance metric, Packet Delay Variation (PDV)
      is computed as described in Section 4.2 of [RFC5481].

10.  Backwards Compatibility

   The procedures defined in this document are backwards compatible with
   the procedures defined in [RFC6374] at both querier and responder.
   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 [RFC6374].

11.  Security Considerations

   The security considerations specified in [RFC6374], [RFC7471],
   [RFC8570], [RFC8571], [RFC7876], and [RFC9341] also apply to the
   procedures described in this document.

   The procedure defined in this document is intended for deployment in
   a single operator administrative domain.  As such, querier node,
   responder node, forward and return paths are provisioned by the
   operator for the probe session.  It is assumed that the operator has
   verified the integrity of the forward and return paths of the probe
   packets.

Gandhi, et al.           Expires 12 August 2024                [Page 13]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   The "Return Path" TLV extensions defined in this document may be used
   for potential address spoofing.  For example, a query message may
   carry a return path that has destination not local at the querier.
   To prevent such possible attacks, the responder MAY drop the query
   messages when it cannot determine whether the return path has the
   destination local at the querier.  The querier may send a proper
   source address in the "Source Address" TLV that responder can use to
   make that determination, for example, by checking the access control
   list provisioned by the operator.

12.  IANA Considerations

   IANA is requested to allocate values for the following Mandatory TLV
   Types for [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object"
   registry contained within the "Generic Associated Channel (G-ACh)
   Parameters" registry set:

               +=======+==================+===============+
               | Value |   Description    | Reference     |
               +=======+==================+===============+
               | TBA1  | Return Path TLV  | This document |
               +-------+------------------+---------------+
               | TBA2  | Block Number TLV | This document |
               +-------+------------------+---------------+

                 Table 1: MPLS Loss/Delay Measurement TLV
                                  Types

   The Block Number TLV is carried in the query and response messages
   and Return Path TLV is carried in the query messages.

   IANA is requested to create a sub-registry for "Return Path Sub-TLV
   Type".  All code points in the range 0 through 175 in this registry
   shall be allocated according to the "IETF Review" procedure as
   specified in [RFC8126].  Code points in the range 176 through 239 in
   this registry shall be allocated according to the "First Come, First
   Served" procedure as specified in [RFC8126].  Remaining code points
   are allocated according to Table 2:

Gandhi, et al.           Expires 12 August 2024                [Page 14]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

          +===========+=========================+===============+
          | Value     |       Description       | Reference     |
          +===========+=========================+===============+
          | 0 - 175   |       IETF Review       | This document |
          +-----------+-------------------------+---------------+
          | 176 - 239 | First Come First Served | This document |
          +-----------+-------------------------+---------------+
          | 240 - 251 |     Experimental Use    | This document |
          +-----------+-------------------------+---------------+
          | 252 - 255 |       Private Use       | This document |
          +-----------+-------------------------+---------------+

                 Table 2: Return Path Sub-TLV Type Registry

   This document defines the following values in the Return Path Sub-TLV
   Type sub-registry:

    +=======+=========================================+===============+
    | Value |               Description               | Reference     |
    +=======+=========================================+===============+
    | 0     |                 Reserved                | This document |
    +-------+-----------------------------------------+---------------+
    | 1     | SR-MPLS Segment List of the Return Path | This document |
    +-------+-----------------------------------------+---------------+
    | 255   |                 Reserved                | This document |
    +-------+-----------------------------------------+---------------+

                     Table 3: Return Path Sub-TLV Types

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC7876]  Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path
              for Packet Loss and Delay Measurement for MPLS Networks",
              RFC 7876, DOI 10.17487/RFC7876, July 2016,
              <https://www.rfc-editor.org/info/rfc7876>.

Gandhi, et al.           Expires 12 August 2024                [Page 15]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2.  Informative References

   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
              Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
              March 2009, <https://www.rfc-editor.org/info/rfc5481>.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., and T.
              Mizrahi, "Alternate-Marking Method", RFC 9341,
              DOI 10.17487/RFC9341, December 2022,
              <https://www.rfc-editor.org/info/rfc9341>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

   [RFC8571]  Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
              C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
              IGP Traffic Engineering Performance Metric Extensions",
              RFC 8571, DOI 10.17487/RFC8571, March 2019,
              <https://www.rfc-editor.org/info/rfc8571>.

Gandhi, et al.           Expires 12 August 2024                [Page 16]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   [RFC8668]  Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
              M., and E. Aries, "Advertising Layer 2 Bundle Member Link
              Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
              December 2019, <https://www.rfc-editor.org/info/rfc8668>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [I-D.ietf-pce-binding-label-sid]
              Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
              and C. L. (editor), "Carrying Binding Label/Segment
              Identifier (SID) in PCE-based Networks.", Work in
              Progress, Internet-Draft, draft-ietf-pce-binding-label-
              sid-16, 27 March 2023, <https://www.ietf.org/archive/id/
              draft-ietf-pce-binding-label-sid-16.txt>.

   [I-D.ietf-spring-mpls-path-segment]
              Cheng, W., Li, H., Li, C., Ed., Gandhi, R., and R. Zigler,
              "Path Segment in MPLS Based Segment Routing Network", Work
              in Progress, Internet-Draft, draft-ietf-spring-mpls-path-
              segment-22, 30 November 2024,
              <https://www.ietf.org/archive/id/draft-ietf-spring-mpls-
              path-segment-22.txt>.

   [RFC9356]  Talaulikar, K. and P. Psenak, "Advertising L2 Bundle
              Member Link Attributes in OSPF", RFC 9356, January 2023,
              <https://www.rfc-editor.org/info/rfc9356>.

   [I-D.ietf-pce-sr-bidir-path]
              Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
              "Path Computation Element Communication Protocol (PCEP)
              Extensions for Associated Bidirectional Segment Routing
              (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
              pce-sr-bidir-path-12, 9 September 2023,
              <https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
              path-12.txt>.

   [IEEE802.1AX]
              IEEE Std. 802.1AX, "IEEE Standard for Local and
              metropolitan area networks - Link Aggregation", November
              2008.

Gandhi, et al.           Expires 12 August 2024                [Page 17]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

Acknowledgments

   The authors would like to thank Thierry Couture and Ianik Semco for
   the discussions on the use-cases for the performance measurement in
   segment routing networks.  Authors would like to thank Patrick
   Khordoc, Ruby Lin and Haowei Shi 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 and
   Zhaohui Zhang for RTGDIR early review.

Contributors

   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

Authors' Addresses

   Rakesh Gandhi (editor)
   Cisco Systems, Inc.
   Canada
   Email: rgandhi@cisco.com

   Clarence Filsfils
   Cisco Systems, Inc.
   Email: cfilsfil@cisco.com

   Daniel Voyer
   Bell Canada
   Email: daniel.voyer@bell.ca

Gandhi, et al.           Expires 12 August 2024                [Page 18]
Internet-Draft     Performance Measurement for SR-MPLS     February 2024

   Stefano Salsano
   Universita di Roma "Tor Vergata"
   Italy
   Email: stefano.salsano@uniroma2.it

   Mach(Guoyi) Chen
   Huawei
   Email: mach.chen@huawei.com

Gandhi, et al.           Expires 12 August 2024                [Page 19]