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