Performance Measurement in Segment Routing Networks with MPLS Data Plane
draft-gandhi-spring-sr-mpls-pm-00

SPRING Working Group                                      R. Gandhi, Ed.
Internet-Draft                                               C. Filsfils
Intended Status: Informational                                   S. Soni
                                                              P. Khordoc
                                                                  Z. Ali
                                                     Cisco Systems, Inc.
                                                                D. Voyer
                                                              D. Bernier
                                                             Bell Canada
                                                              S. Salsano
                                        Universita di Roma "Tor Vergata"
                                                               P. Ventre
                                                                    CNIT
                                                       February 14, 2018

        Performance Measurement in Segment Routing Networks with 
                            MPLS Data Plane
                 draft-gandhi-spring-sr-mpls-pm-00.txt

Abstract

   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 and channel
   throughput in MPLS networks.  This document reviews how these
   mechanisms can be used for Performance Measurements in Segment
   Routing with MPLS data plane (SR-MPLS) networks. 

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 http://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."

Copyright Notice

 

Gandhi, et al.          Expires August 18, 2018                 [Page 1]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

   Copyright (c) 2018 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
   (http://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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
     2.1.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Terminology and Reference Topology . . . . . . . . . . . .  4
   3.  Probe Packets  . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Probe Packets for SR-MPLS Policies . . . . . . . . . . . .  4
     3.2.  Probe Packets for SR-MPLS Links  . . . . . . . . . . . . .  5
     3.3.  Probe Reply Message  . . . . . . . . . . . . . . . . . . .  5
       3.3.1.  One-way Measurement Probe Reply  . . . . . . . . . . .  5
         3.3.1.1.  Probe Reply Message to Controller  . . . . . . . .  6
       3.3.2.  Two-way Measurement Probe Reply  . . . . . . . . . . .  6
   4.  Performance Delay Measurement  . . . . . . . . . . . . . . . .  6
     4.1.  Delay Measurement Message Format . . . . . . . . . . . . .  6
     4.2.  Timestamping . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Performance Loss Measurement . . . . . . . . . . . . . . . . .  8
     5.1.  Loss Measurement Message Format  . . . . . . . . . . . . .  8
   6.  SR-MPLS Link Metrics Advertisements  . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

 

Gandhi, et al.          Expires August 18, 2018                 [Page 2]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

1.  Introduction

   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 and channel throughput.  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.

   [RFC6374] specifies protocol mechanisms to enable the efficient and
   accurate measurement of these performance metrics in MPLS networks. 
   The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656]
   and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357]
   provide capabilities for the measurement of various performance
   metrics in IP networks.  However, mechanisms in [RFC6374] are more
   suitable for Segment Routing when using MPLS data plane.  This
   document reviews how these mechanisms can be used for performance
   measurements (PM) in Segment Routing with the MPLS data plane (SR-
   MPLS) networks.

2.  Conventions Used in This Document

2.1.  Abbreviations

   ACH: Associated Channel Header.

   DM: Delay Measurement.

   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.

   PM: Performance Measurement.

   PTP: Precision Time Protocol.

   SID: Segment ID.

   TC: Traffic Class.
 

Gandhi, et al.          Expires August 18, 2018                 [Page 3]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

   UCMP: Unequal Cost Multi-Path.

2.2.  Terminology and Reference Topology

   In this document, the following simple topology is used for
   illustration.

                               --------
       +-----------------------| N100 |-----------------------+
       |                       --------                       |
       |                                                      |
        ----- link1 ----- link3 ----- link5 ----- link9 ------
        | N1 |------| N2 |------| N3 |------| N4 |------| N5 |
        |    |------|    |------|    |------|    |------|    |
        ----- link2 ----- link4 ----- link6 ----- link10------
                       |                      |
                       |        ------        |
                       +--------| N6 |--------+
                         link7  |    |  link8
                                ------

                    Figure 1: Reference Topology

   In the reference topology in Figure 1:

    Nodes N1, N2, N3, N4, N5 and N6 are SR-MPLS capable nodes.

    N100 is a controller.

    <L1, L2, ..., Ln> represents a MPLS Label stack for an SR policy
    where L1 is the first Label and Ln is the last Label as defined in
    Section 4 of [I-D.spring-segment-routing-policy].

    SR policy is defined in Section 3 of
    [I-D.spring-segment-routing-policy].

3.  Probe Packets

3.1.  Probe Packets for SR-MPLS Policies

   As described in [RFC6374], Section 2.9.1, MPLS PM probe messages flow
   over the MPLS Generic Associated Channel (G-ACh).  A probe packet for
   an SR policy contains SR-MPLS label stack
   [I-D.spring-segment-routing-policy], with the G-ACh Label (GAL) at
   the bottom of the stack.  The GAL is followed by an Associated
   Channel Header (ACH), which identifies the message type, and the
 

Gandhi, et al.          Expires August 18, 2018                 [Page 4]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

   message body following the ACH as shown in Figure 2.

    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(0)             | EXP |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(n)             | EXP |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  GAL                  | EXP |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|  Reserved     | GAL Channel Type              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Probe Packet Header for an SR-MPLS Policy

3.2.  Probe Packets for SR-MPLS Links

    As described in [RFC6374], Section 2.9.1, MPLS PM probe messages
    flow over the MPLS Generic Associated Channel (G-ACh).  A probe
    packet for SR-MPLS links contains G-ACh Label (GAL).  The GAL is
    followed by an Associated Channel Header (ACH), which identifies the
    message type, and the message body following the ACH as shown in
    Figure 3.

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

            Figure 3: Probe Packet Header for an SR-MPLS Link

3.3.  Probe Reply Message

3.3.1.  One-way Measurement Probe Reply

   For one-way performance measurement [RFC7679], the PM querier node
   can receive "out-of-bands" probe replies by properly setting the UDP
   Return Object (URO) TLV in the probe message.  The URO TLV (Type=131)
 

Gandhi, et al.          Expires August 18, 2018                 [Page 5]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

   is defined in [RFC7876] and includes the UDP-Destination-Port and IP
   Address.  In particular, if the querier sets its own IP address in
   the URO TLV the probe response is sent back by the responder node to
   the querier node.

3.3.1.1.  Probe Reply Message to Controller

   As shown in Figure 1, if the querier node N1 requires the probe reply
   to be sent to the controller N100, it sets the IP address of N100 in
   the Address field of the URO TLV of the PM probe query message.

3.3.2.  Two-way Measurement Probe Reply

   For two-way performance measurement [RFC6374], when using a
   bidirectional channel, the probe reply message is sent back to the
   querier node using a message similar to the probe query message as an
   SR-MPLS packet.  In this case, the "control code" in the probe
   message is set to "in-band response requested".

4.  Performance Delay Measurement

4.1.  Delay Measurement Message Format

   As defined in [RFC6374], MPLS DM probe messages use Associated
   Channel Header (ACH) (value 0x000C for delay measurement) [RFC6374],
   which identifies the message type, and the message body following the
   ACH.  For both SR-MPLS policies and links, the same MPLS DM ACH value
   is used.

   The DM message payload as defined in [RFC6374] is used for SR-MPLS
   delay measurement, for both SR-MPLS policies and SR-MPLS links.  The
   DM message payload format is defined as following in [RFC6374]:

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

Gandhi, et al.          Expires August 18, 2018                 [Page 6]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Timestamp 4                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           TLV Block                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: Delay Measurement Message Format

   The meanings of the fields are summarized in the following table, see
   [RFC6374] for details.

    Field                 Meaning
    -------------------  ----------------------------------------------
    Version               Protocol version

    Flags                 Message control flags

    Control Code          Code identifying the query or response type

    QTF                   Querier timestamp format 
                          (see Section 3.4 in [RFC6374])

    RTF                   Responder timestamp format 
                          (see Section 3.4 in [RFC6374])

    RPTF                  Responder's preferred timestamp format

    Reserved              Reserved for future specification

    Session Identifier    Set arbitrarily by the querier

    Differentiated        Differentiated Services Code Point (DSCP) 
    Services (DS) Field   being measured

    Timestamp 1-4         64-bit timestamp values 
                          (see Section 3.4 in [RFC6374])

    TLV Block             Optional block of Type-Length-Value fields

4.2.  Timestamping

   [RFC6374], Section 3.4 defines timestamp format that can be used for
   delay measurement.  The IEEE 1588 Precision Time Protocol (PTP)
   timestamp format [IEEE1588] is used by default as described in
   Appendix A of [RFC6374], but it may require hardware support.  As an
 

Gandhi, et al.          Expires August 18, 2018                 [Page 7]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

   alternative, Network Time Protocol (NTP) timestamp format is also
   supported in [RFC6374].

   Note that for one-way delay measurement, Clock synchronization
   between the querier and responder nodes using methods detailed in
   [RFC6374] is required.  Two-way delay measurement does not require
   clock to be synchronized between the querier and responder nodes.

5.  Performance Loss Measurement

   The performance LM protocol can perform two distinct kinds of loss
   measurement as described in [RFC6374], Section 2.9.8.  In inferred
   mode, LM will measure the loss of specially generated test messages
   in order to infer the approximate data plane loss level.  Inferred
   loss measurement provides only approximate loss accounting.  In
   direct mode, LM will directly measure data plane packet loss.  Direct
   loss measurement provides perfect loss accounting, but may require
   hardware support.

5.1.  Loss Measurement Message Format

   As defined in [RFC6374], MPLS LM probe 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 body following the ACH.  For both SR-
   MPLS policies and SR-MPLS links, the same MPLS LM ACH value is used.

   The LM message payload as defined in [RFC6374] is used for SR-MPLS
   delay measurement, for both SR-MPLS policies and SR-MPLS links.  The
   LM message payload format is defined as following in [RFC6374]:

     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         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | DFlags|  OTF  |                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Session Identifier          |    DS     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Origin Timestamp                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Counter 1                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
 

Gandhi, et al.          Expires August 18, 2018                 [Page 8]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Counter 4                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           TLV Block                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 5: Loss Measurement Message Format

   The meanings of the fields are summarized in the following table, see
   [RFC6374] for details.

    Field                 Meaning
    --------------------  ----------------------------------------------
    Version               Protocol version

    Flags                 Message control flags

    Control Code          Code identifying the query or response type

    Message Length        Total length of this message in bytes

    Data Format Flags     Flags specifying the format of message data
    (DFlags)              

    Origin Timestamp      Format of the Origin Timestamp field
    Format (OTF)

    Reserved              Reserved for future specification

    Session Identifier    Set arbitrarily by the querier

    Differentiated        Differentiated Services Code Point (DSCP) 
    Services (DS) Field   being measured

    Origin Timestamp      64-bit field for query message transmission
                          timestamp

    Counter 1-4           64-bit fields for LM counter values

    TLV Block             Optional block of Type-Length-Value fields

6.  SR-MPLS Link Metrics Advertisements

   Performance metrics for link delay and packet loss calculated using
   the performance measurement procedures reviewed in this document can
 

Gandhi, et al.          Expires August 18, 2018                 [Page 9]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

   be advertised in the routing domain.  For OSPF, ISIS and BGP-LS,
   protocol extensions defined in [RFC7471], [RFC7810] and
   [I-D.idr-te-pm-bgp] are used, respectively for advertising the link
   delay metrics (minimum-delay, maximum-delay, average-delay, delay-
   variance) and loss metric in the network.

7.  Security Considerations

   This document reviews the procedures for performance measurement for
   SR-MPLS networks, for both SR-MPLS policies and SR-MPLS links, using
   the mechanisms defined in [RFC6374].  This document does not
   introduce any additional security considerations other than those
   covered in [RFC6374].

8.  IANA Considerations

   This document does not require any IANA actions.

9.  References

9.1.  Normative References

   [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems", March 2008.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS networks', RFC 6374, September 2011.

   [RFC7876]  Bryant, S., Sivabalan, S., and Soni, S., "UDP Return Path
              for Packet Loss and Delay Measurement for MPLS Networks",
              RFC 7876, July 2016.

9.2.  Informative References

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protoco (OWAMP)",
              RFC 4656, September 2006.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, October 2008.

   [RFC7679]  Almes, G., et al., "A One-Way Delay Metric for IP
              Performance Metrics (IPPM)', RFC 7679, January 2016.

   [RFC7471]  Giacalone, S., et al., "OSPF Traffic Engineering (TE)
 

Gandhi, et al.          Expires August 18, 2018                [Page 10]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

              Metric Extensions", RFC 7471, March 2015.

   [RFC7810]  Previdi, S., et al., "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 7810, May 2016.

   [I-D.idr-te-pm-bgp]  Ginsberg, L. Ed., et al., "BGP-LS Advertisement
              of IGP Traffic Engineering Performance Metric Extensions",
              draft-ietf-idr-te-pm-bgp, work in progress.

   [I-D.spring-segment-routing-policy]  Filsfils, C., et al., "Segment
              Routing Policy for Traffic Engineering",
              draft-filsfils-spring-segment-routing-policy, work in
              progress.

 

Gandhi, et al.          Expires August 18, 2018                [Page 11]
Internet-Draft      SR-MPLS Performance Measurement    February 14, 2018

Acknowledgments

   To be added.

Contributors

   To be added.

Authors' Addresses

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

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

   Sagar Soni
   Cisco Systems, Inc.
   Email: sagsoni@cisco.com

   Patrick Khordoc
   Cisco Systems, Inc.
   Email: pkhordoc@cisco.com

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

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

   Daniel Bernier
   Bell Canada
   Email: daniel.bernier@bell.ca

 

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

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

   Pier Luigi Ventre
   CNIT 
   Italy
   Email: pierluigi.ventre@cnit.it

Gandhi, et al.          Expires August 18, 2018                [Page 13]