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]