< draft-ali-spring-srv6-pm-01.txt   draft-ali-spring-srv6-pm-02.txt >
SPRING Working Group Z. Ali SPRING Working Group Z. Ali
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track R. Gandhi Intended status: Standards Track R. Gandhi
Expires: August 30, 2018 N. Kumar Expires: August 31, 2018 N. Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
S. Salsano S. Salsano
Universita di Roma "Tor Vergata" Universita di Roma "Tor Vergata"
P. L. Ventre P. L. Ventre
CNIT CNIT
G. Naik G. Naik
Drexel University Drexel University
D. Voyer D. Voyer
D. Bernier D. Bernier
Bell Canada Bell Canada
February 26, 2018 February 27, 2018
Performance Measurement in Segment Routing Networks with Performance Measurement in Segment Routing Networks with
IPv6 Data Plane (SRv6) IPv6 Data Plane (SRv6)
draft-ali-spring-srv6-pm-01.txt draft-ali-spring-srv6-pm-02.txt
Abstract Abstract
RFC 6374 specifies protocol mechanisms to enable efficient and RFC 6374 specifies protocol mechanisms to enable efficient and
accurate measurement of packet loss, one-way and two-way delay, as accurate measurement of packet loss, one-way and two-way delay, as
well as related metrics such as delay variation and channel well as related metrics such as delay variation and channel
throughput in MPLS networks. This document describes how these throughput in MPLS networks. This document describes how these
mechanisms can be used for performance measurement of delay and loss mechanisms can be used for performance measurement of delay and loss
in Segment Routing with IPv6 data plane (SRv6) networks. in Segment Routing with IPv6 data plane (SRv6) networks.
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Terminology and Reference Topology . . . . . . . . . . . . 4 2.3. Terminology and Reference Topology . . . . . . . . . . . . 4
3. Performance Delay Measurement . . . . . . . . . . . . . . . . 5 3. Performance Delay Measurement . . . . . . . . . . . . . . . . 5
3.1. One-Way Delay Measurement . . . . . . . . . . . . . . . . 5 3.1. One-Way Delay Measurement . . . . . . . . . . . . . . . . 5
3.2. Two-Way Delay Measurement . . . . . . . . . . . . . . . . 6 3.2. Two-Way Delay Measurement . . . . . . . . . . . . . . . . 6
3.3. Delay Measurement Message Format . . . . . . . . . . . . . 6 3.3. Delay Measurement Message Format . . . . . . . . . . . . . 6
3.3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Delay Measurement Query Procedure . . . . . . . . . . . . 8 3.4. Delay Measurement Query Procedure . . . . . . . . . . . . 8
3.4.1. Example Procedure . . . . . . . . . . . . . . . . . . 9 3.4.1. Example Procedure . . . . . . . . . . . . . . . . . . 8
4. Performance Loss Measurement . . . . . . . . . . . . . . . . . 9 4. Performance Loss Measurement . . . . . . . . . . . . . . . . . 9
4.1. One-Way Loss Measurement . . . . . . . . . . . . . . . . . 9 4.1. One-Way Loss Measurement . . . . . . . . . . . . . . . . . 9
4.2. Two-Way Loss Measurement . . . . . . . . . . . . . . . . . 10 4.2. Two-Way Loss Measurement . . . . . . . . . . . . . . . . . 10
4.3. Loss Measurement Message Format . . . . . . . . . . . . . 10 4.3. Loss Measurement Message Format . . . . . . . . . . . . . 10
4.4. Loss Measurement Query Procedure . . . . . . . . . . . . . 12 4.4. Loss Measurement Query Procedure . . . . . . . . . . . . . 12
4.4.1. Example Procedure . . . . . . . . . . . . . . . . . . 12 4.4.1. Example Procedure . . . . . . . . . . . . . . . . . . 13
5. Probe Reply Message . . . . . . . . . . . . . . . . . . . . . 13 5. Probe Reply Message . . . . . . . . . . . . . . . . . . . . . 13
5.1. One-way Measurement Probe Reply . . . . . . . . . . . . . 13 5.1. One-way Measurement Probe Reply . . . . . . . . . . . . . 13
5.1.1. Probe Reply Message to Controller . . . . . . . . . . 13 5.1.1. Probe Reply Message to Controller . . . . . . . . . . 14
5.2. Two-way Measurement Probe Reply . . . . . . . . . . . . . 13 5.2. Two-way Measurement Probe Reply . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Service provider's requirements to satisfy Service Level Agreements Service provider's requirements to satisfy Service Level Agreements
(SLAs) depend on the ability to measure and monitor performance (SLAs) depend on the ability to measure and monitor performance
metrics for packet loss and one-way and two-way delay, as well as metrics for packet loss and one-way and two-way delay, as well as
related metrics such as delay variation and channel throughput. The related metrics such as delay variation and channel throughput. The
skipping to change at page 3, line 22 skipping to change at page 3, line 22
with greater visibility into the performance characteristics of their with greater visibility into the performance characteristics of their
networks, thereby facilitating planning, troubleshooting, and network networks, thereby facilitating planning, troubleshooting, and network
performance evaluation. performance evaluation.
[RFC6374] specifies protocol mechanisms to enable the efficient and [RFC6374] specifies protocol mechanisms to enable the efficient and
accurate measurement of these performance metrics in MPLS networks. accurate measurement of these performance metrics in MPLS networks.
The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656]
and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357]
provide capabilities for the measurement of various performance provide capabilities for the measurement of various performance
metrics in IP networks. However, mechanisms defined in [RFC6374] are metrics in IP networks. However, mechanisms defined in [RFC6374] are
more suitable for Segment Routing when using MPLS data plane (SR- more suitable for Segment Routing when using MPLS data plane
MPLS) [I-D.spring-sr-mpls-pm]. This document describes how the (SR-MPLS) [I-D.spring-sr-mpls-pm]. This document describes how the
mechanisms in [RFC6374] can be used for Performance Measurement (PM) mechanisms in [RFC6374] can be used for Performance Measurement (PM)
of delay and loss in Segment Routing with the IPv6 data plane (SRv6) of delay and loss in Segment Routing with the IPv6 data plane (SRv6)
networks. networks.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Abbreviations 2.2. Abbreviations
DM: Delay Measurement. DM: Delay Measurement.
ECMP: Equal Cost Multi-Path.
LM: Loss Measurement. LM: Loss Measurement.
PM: Performance Measurement. PM: Performance Measurement.
SID: Segment ID. SID: Segment ID.
SL: Segment Left. SL: Segment Left.
SR: Segment Routing. SR: Segment Routing.
SRH: Segment Routing Header. SRH: Segment Routing Header.
SRv6: Segment Routing with IPv6 Data plane. SRv6: Segment Routing with IPv6 Data plane.
TC: Traffic Class. TC: Traffic Class.
UCMP: Unequal Cost Multi-Path.
2.3. Terminology and Reference Topology 2.3. Terminology and Reference Topology
In this document, the simple topology shown in Figure 1 is used for In this document, the simple topology shown in Figure 1 is used for
illustration. illustration.
-------- --------
+------------------------| N100 |------------------------+ +------------------------| N100 |------------------------+
| -------- | | -------- |
| | | |
====== link1====== link3------ link5====== link9------ ====== link1====== link3------ link5====== link9------
skipping to change at page 5, line 49 skipping to change at page 5, line 45
+-------+/ Query \+-------+ +-------+/ Query \+-------+
| | - - - - - - - - - ->| | | | - - - - - - - - - ->| |
| N1 |=====================| N4 | | N1 |=====================| N4 |
| |<- - - - - - - - - - | | | |<- - - - - - - - - - | |
+-------+\ Response Option-1 /+-------+ +-------+\ Response Option-1 /+-------+
T4 T3 T4 T3
Figure 2: Delay Measurement Reference Model Figure 2: Delay Measurement Reference Model
Nodes N1 and N4 may not be directly connected, as shown in the Nodes N1 and N4 may not be directly connected, as shown in the
reference topology in Figure 1. When N1 and N4 are not directly reference topology in Figure 1. When nodes N1 and N4 are not
connected, the one-way delay measurement reflects the delay observed directly connected, the one-way delay measurement reflects the delay
by the packet over an arbitrary SRv6 segment-list (SR policy) observed by the packet over an arbitrary SRv6 segment-list (SR
policy) [I-D.spring-segment-routing-policy]. In other words, the
[I-D.spring-segment-routing-policy]. In other words, the one-way one-way delay is associated with the forward (nodes N1 to N4)
delay is associated with the forward (N1 to N4) direction of the SRv6 direction of the SRv6 segment-list.
segment-list.
In Figure 2, T1 refers to the time when the packet is transmitted In Figure 2, T1 refers to the time when the packet is transmitted
from N1. Timestamp is added as late as possible at the egress from node N1. Timestamp is added as late as possible at the egress
pipeline (in hardware) at N1. T2 refers to the time when the packet pipeline (in hardware) at node N1. T2 refers to the time when the
is received at N4. Timestamp at the receiver (N4) is added as soon packet is received at node N4. Timestamp at the receiver (node N4)
as possible at the ingress pipeline (in hardware). is added as soon as possible at the ingress pipeline (in hardware).
The one-way delay metric can be computed as follow [RFC7679], The one-way delay metric can be computed as follows [RFC7679],
[RFC6374]: [RFC6374]:
One-way delay = T2 - T1 One-way delay = T2 - T1
3.2. Two-Way Delay Measurement 3.2. Two-Way Delay Measurement
Similarly to the timestamps T1 and T2 in the forward direction, For simplified processing in hardware, the responder copies
timestamps T3 and T4 are added in the DM packet in the reverse timestamps T1 to T3 and T2 to T4 in the DM TLV before replying, such
direction. T3 refers to the time the packet is transmitted from N4. that timestamps T1 and T2 are added at the same location in the DM
T4 refers to the time the packet is received at N1. TLV for the reverse direction by node N4 and node N1, respectively
[RFC6374].
The two-way delay metric can be computed as follows [RFC6374]: The two-way delay metric can be computed as follows [RFC6374]:
Two-way delay = (T4 - T3) + (T2 - T1) Two-way delay = (T4 - T3) + (T2 - T1)
3.3. Delay Measurement Message Format 3.3. Delay Measurement Message Format
[I-D.6man-segment-routing-header] defines Segment Routing Header [I-D.6man-segment-routing-header] defines Segment Routing Header
(SRH) for SRv6. SRH can contain TLVs, as specified in (SRH) for SRv6. SRH can contain TLVs, as specified in
[I-D.6man-segment-routing-header]. This document defines Delay [I-D.6man-segment-routing-header]. This document defines Delay
skipping to change at page 7, line 23 skipping to change at page 7, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SUB-TLV Block ~ ~ SUB-TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Delay Measurement TLV Format Figure 3: Delay Measurement TLV Format
The meanings of the fields are summarized in the following table. The meanings of the fields are summarized in the following table.
Field Meaning Field Meaning
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
Type SRH DM TLV type (Value TBA by IANA) Type SRH DM TLV type (Value TBA1 by IANA)
Length Total length of the TLV in bytes Length Total length of the TLV in bytes
Version Protocol version Version Protocol version
Flags Message control flags Flags Message control flags
Control Code Code identifying the query or response type Control Code Code identifying the query or response type
QTF Querier timestamp format QTF Querier timestamp format
RTF Responder timestamp format RTF Responder timestamp format
RPTF Responder's preferred timestamp format RPTF Responder's preferred timestamp format
Reserved Reserved for future specification Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier Session Identifier Set arbitrarily by the querier
Traffic Traffic Class being measured Traffic Traffic Class being measured
Class (TC) Field Class (TC) Field
Timestamp 1-4 64-bit timestamp values Timestamp 1-4 64-bit timestamp values
(see Section 3.4 in [RFC6374]) (see Section 3.4 in [RFC6374])
SUB-TLV Block Optional block of Type-Length-Value fields SUB-TLV Block Optional block of Type-Length-Value fields
Reserved fields MUST be set to 0 and ignored upon receipt. The Reserved fields MUST be set to 0 and ignored upon receipt. The
possible values for the remaining fields are as follows. possible values for the remaining fields are as follows.
Version: Currently set to 1 (to identify definition of TC field in Version: Set to 1.
[RFC6374])
Flags: As specified in [RFC6374]. The T flag in a DM message is set Flags: As specified in [RFC6374]. The T flag in a DM message is set
to 1. to 1 to indicate the DM is for the given Traffic Class.
Control Code: As specified in [RFC6374]. Control Code: As specified in [RFC6374].
Message Length: Set to the total length of this message in bytes, Message Length: Set to the total length of this message in bytes,
including the Version, Flags, Control Code, and Message Length fields including the Version, Flags, Control Code, and Message Length fields
as well as the TLV Block, if any. as well as the TLV Block, if any.
Querier Timestamp Format: The format of the timestamp values written Querier Timestamp Format: The format of the timestamp values written
by the querier, as specified in Section 3.4 of [RFC6374]. by the querier, as specified in Section 3.4 of [RFC6374].
skipping to change at page 9, line 8 skipping to change at page 9, line 4
clock to be synchronized between the querier and responder nodes. clock to be synchronized between the querier and responder nodes.
3.4. Delay Measurement Query Procedure 3.4. Delay Measurement Query Procedure
For delay measurement using synthetic probes, a DM TLV is inserted in For delay measurement using synthetic probes, a DM TLV is inserted in
the SRH to record timestamps and SID function END.OTP as described in the SRH to record timestamps and SID function END.OTP as described in
the pseudo code in [I-D.spring-srv6-network-programming] is used to the pseudo code in [I-D.spring-srv6-network-programming] is used to
punt probe packets. punt probe packets.
3.4.1. Example Procedure 3.4.1. Example Procedure
To measure delay from node N1 over an SRv6 Policy To measure delay from node N1 over an SRv6 Policy
[I-D.spring-segment-routing-policy] that goes through a segment-list [I-D.spring-segment-routing-policy] that goes through a segment-list
<A2::C31, A4::C52> to node N4, the following procedure is defined for <A2::C31, A4::C52> to node N4, the following procedure is defined for
sending queries: sending queries:
o Node N1 constructs a DM probe packet with (B1::0, o Node N1 constructs a DM probe packet with (B1::0,
A2::C31)(A4::C52, A2::C31, SL=1; NH=NONE, DM TLV). To punt the DM A2::C31)(A4::C52, A2::C31, SL=1; NH=NONE, DM TLV). To punt the DM
probe packet at node N4, node N1 inserts the END.OTP SID probe packet at node N4, node N1 inserts the SID function END.OTP
[I-D.spring-srv6-network-programming] just before the target SID [I-D.spring-srv6-network-programming] just before the target SID
A4::C52 in the SRH. Hence, the packet as it leaves node N1 looks A4::C52 in the SRH. Hence, the packet as it leaves node N1 looks
like (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; NH=NONE, DM like (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; NH=NONE, DM
TLV (with T1 from N1)). The PM synthetic probe query message does TLV (with T1 from node N1)). The PM synthetic probe query message
not contain any payload data. does not contain any payload data.
o When node N4 receives the packet (B1::0, A4::OTP)(A4::C52, o When node N4 receives the packet (B1::0, A4::OTP)(A4::C52,
A4::OTP, A2::C31; SL=1; NH=NONE, DM TLV), it processes the SID A4::OTP, A2::C31; SL=1; NH=NONE, DM TLV), it processes the SID
function END.OTP, as described in the pseudo code in function END.OTP, as described in the pseudo code in
[I-D.spring-srv6-network-programming]. In doing so, it punts the [I-D.spring-srv6-network-programming]. In doing so, it punts the
timestamped packet (with T2 from N4) to the Performance timestamped packet (with T2 from node N4) to the Performance
Measurement (PM) process in control plane for processing. Measurement (PM) process in control plane for processing.
4. Performance Loss Measurement 4. Performance Loss Measurement
4.1. One-Way Loss Measurement 4.1. One-Way Loss Measurement
The one-way loss measurement is exemplified using the following The one-way loss measurement is exemplified using the following
Figure 4. Figure 4.
------ ------
skipping to change at page 10, line 8 skipping to change at page 9, line 49
+-------+/ Query \+-------+ +-------+/ Query \+-------+
| | - - - - - - - - - ->| | | | - - - - - - - - - ->| |
| N1 |=====================| N4 | | N1 |=====================| N4 |
| |<- - - - - - - - - - | | | |<- - - - - - - - - - | |
+-------+\ Response Option-1 /+-------+ +-------+\ Response Option-1 /+-------+
C4 C3 C4 C3
Figure 4: Loss Measurement Reference Model Figure 4: Loss Measurement Reference Model
Nodes N1 and N4 may not be directly connected, as shown in the Nodes N1 and N4 may not be directly connected, as shown in the
reference topology in Figure 1. When N1 and N4 are not directly reference topology in Figure 1. When nodes N1 and N4 are not
connected, the one-way loss measurement reflects the loss observed by directly connected, the one-way loss measurement reflects the loss
the packet over an arbitrary SRv6 segment-list (SR policy) observed by the packets over an arbitrary SRv6 segment-list (SR
[I-D.spring-segment-routing-policy]. In other words, the one-way policy) [I-D.spring-segment-routing-policy]. In other words, the
loss is associated with the forward (N1 to N4) direction of the SRv6 one-way loss is associated with the forward (nodes N1 to N4)
segment-list. direction of the SRv6 segment-list.
In Figure 4, C1 refers to the packet (or byte) count of traffic In Figure 4, C1[n] refers to the packet (or byte) count of traffic
transmitted from N1. C2 refers to the packet (or byte) count of the transmitted from node N1 for color C in the nth probe message. C2[n]
traffic received at N4. refers to the packet (or byte) count of the traffic received at node
N4 for the same color C in the nth probe message.
The one-way loss metric can be computed as follow [RFC6374]: The one-way receive loss metric using counters for the same color can
be computed as follows [RFC6374]:
One-way delay = C2 - C1 One-way receive loss[n-1, n] = (C2[n] - C2[n-1]) - (C1[n] - C1[n-1])
4.2. Two-Way Loss Measurement 4.2. Two-Way Loss Measurement
Similarly to the counters C1 and C2 in the forward direction, For simplified processing in hardware, the responder copies counter
counters C3 and C4 are added in the LM packet in the reverse C1 to C3 and C2 to C4 in the LM TLV before replying, such that
direction. C3 refers to the packet (or byte) count of traffic counters C1 and C2 for the same color are added at the same location
transmitted from N4. C4 refers to the packet (or byte) count of in the LM TLV for the reverse direction by node N4 and node N1,
traffic received at N1. respectively [RFC6374].
The two-way loss metric can be computed as follows [RFC6374]: The two-way receive loss metric using counters for the same color can
be computed as follows [RFC6374]:
Two-way loss = (C4 - C3) + (C2 - C1) Two-way receive loss[n-1, n] = (C4[n] - C4[n-1]) - (C3[n] - C3[n-1])
+ (C2[n] - C2[n-1]) - (C1[n] - C1[n-1])
4.3. Loss Measurement Message Format 4.3. Loss Measurement Message Format
[I-D.6man-segment-routing-header] defines Segment Routing Header [I-D.6man-segment-routing-header] defines Segment Routing Header
(SRH) for SRv6. SRH can contain TLVs, as specified in (SRH) for SRv6. SRH can contain TLVs, as specified in
[I-D.6man-segment-routing-header]. This document defines Loss [I-D.6man-segment-routing-header]. This document defines Loss
Measurement (LM) TLV for SRH. The LM TLV uses a modified LM message Measurement (LM) TLV for SRH. The LM TLV uses a modified LM message
format specified in [RFC6374] and is defined as follows: format specified in [RFC6374] and is defined as follows:
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED |C| | Type | Length | RESERVED |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | RESERVED | |Version| Flags | Control Code | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved | | DFLags| OTF | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | TC | | Session Identifier | TC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Timestamp | | Origin Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 | | Counter 1 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
skipping to change at page 11, line 27 skipping to change at page 11, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SUB-TLV Block ~ ~ SUB-TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Loss Measurement TLV Format Figure 5: Loss Measurement TLV Format
The meanings of the fields are summarized in the following table. The meanings of the fields are summarized in the following table.
Field Meaning Field Meaning
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
Type SRH LM TLV type (Value TBA by IANA) Type SRH LM TLV type (Value TBA2 by IANA)
Length Total length of the TLV in bytes Length Total length of the TLV in bytes
Color (C) Color flag of the Counters 1-4 Color (C) Color flag of the Counters 1-4
Version Protocol version Version Protocol version
Flags Message control flags Flags Message control flags
Control Code Code identifying the query or response type Control Code Code identifying the query or response type
QTF Querier timestamp format Data Format Flags Flags specifying the format of message data
RTF Responder timestamp format (DFlags)
RPTF Responder's preferred timestamp format Origin Timestamp Format of the Origin Timestamp field
Format (OTF)
Reserved Reserved for future specification Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier Session Identifier Set arbitrarily by the querier
Traffic Traffic Class being measured Traffic Traffic Class being measured
Class (TC) Field Class (TC) Field
Counters 1-4 64-bit counter values Counters 1-4 64-bit counter values for the same Color C
SUB-TLV Block Optional block of Type-Length-Value fields SUB-TLV Block Optional block of Type-Length-Value fields
Reserved fields MUST be set to 0 and ignored upon receipt. The Reserved fields MUST be set to 0 and ignored upon receipt. The
possible values for the remaining fields are as follows. possible values for the remaining fields are as follows.
Version: Currently set to 1 (to identify definition of TC field in Version: Set to 1.
[RFC6374])
Flags: As specified in [RFC6374]. The T flag in a LM message is set Flags: As specified in [RFC6374]. The T flag in a LM message is set
to 1. to 1 to indicate the LM is for the given Traffic Class.
Control Code: As specified in [RFC6374]. Control Code: As specified in [RFC6374].
Message Length: Set to the total length of this message in bytes, Message Length: Set to the total length of this message in bytes,
including the Version, Flags, Control Code, and Message Length fields including the Version, Flags, Control Code, and Message Length fields
as well as the TLV Block, if any. as well as the TLV Block, if any.
Querier Timestamp Format: The format of the timestamp values written DFlags: The format of the DFlags field is shown below.
by the querier, as specified in Section 3.4 of [RFC6374].
Responder Timestamp Format: The format of the timestamp values +-+-+-+-+
written by the responder, as specified in Section 3.4 of [RFC6374].
Responder's Preferred Timestamp Format: The timestamp format |X|B|0|0|
preferred by the responder, as specified in Section 3.4 of [RFC6374].
+-+-+-+-+
Data Format Flags
The meanings of the DFlags bits are:
X: Extended counter format indicator. Set to 0 when the LM message
is transmitted or received over an interface that writes 32-bit
counter values. It is set to 1 for 64-bit counter values.
B: Octet (byte) count. When set to 1, indicates that the Counter 1-
4 fields represent octet counts. When set to 0, indicates that the
Counter 1-4 fields represent packet counts.
Origin Timestamp: The timestamp value written by the querier, as Origin Timestamp: The timestamp value written by the querier, as
specified in Section 3.4 of [RFC6374]. specified in Section 3.4 of [RFC6374].
Session Identifier: Set arbitrarily in a query and copied in the Session Identifier: Set arbitrarily in a query and copied in the
response, if any. This field uniquely identifies a measurement response, if any. This field uniquely identifies a measurement
operation (also called a session) that consists of a sequence of operation (also called a session) that consists of a sequence of
messages. All messages in the sequence have the same Session messages. All messages in the sequence have the same Session
Identifier [RFC6374]. Identifier [RFC6374].
TC: Traffic Class being measured. TC: Traffic Class being measured.
Counter 1-4 (C1-C4): 64-bit fields for LM counter values. Counter 1-4 (C1-C4): 64-bit fields for LM counter values for the same
color C.
SUB-TLV Block: Zero or more TLV fields. This document assumes the SUB-TLV Block: Zero or more TLV fields. This document assumes the
use of the LM message TLVs defined in [RFC6374]. use of the LM message TLVs defined in [RFC6374].
4.4. Loss Measurement Query Procedure 4.4. Loss Measurement Query Procedure
For loss measurement using synthetic probes, an LM TLV in the SRH is For loss measurement using synthetic probes, an LM TLV in the SRH is
used to record packet (or byte) counters and SID function END.OTP as used to record packet (or byte) counters per color and SID function
described in the pseudo code in [I-D.spring-srv6-network-programming] END.OTP as described in the pseudo code in
is used to punt probe packets. [I-D.spring-srv6-network-programming] is used to punt probe packets.
4.4.1. Example Procedure 4.4.1. Example Procedure
To measure packet loss from node N1 over an SRv6 Policy To measure packet loss from node N1 over an SRv6 Policy
[I-D.spring-segment-routing-policy] that goes through a segment-list [I-D.spring-segment-routing-policy] that goes through a segment-list
(A2::C31, A4::C52) to node N4, following procedure is defined for (A2::C31, A4::C52) to node N4, following procedure is defined for
sending queries: sending queries:
o Node N1 constructs a LM probe packet with (B1::0, o Node N1 constructs a LM probe packet with (B1::0,
A2::C31)(A4::C52, A2::C31, SL=1; NH=NONE, LM TLV). To punt the LM A2::C31)(A4::C52, A2::C31, SL=1; NH=NONE, LM TLV). To punt the LM
probe packet at node N4, node N1 inserts the END.OTP SID probe packet at node N4, node N1 inserts the SID function END.OTP
[I-D.spring-srv6-network-programming] just before the target SID [I-D.spring-srv6-network-programming] just before the target SID
A4::C52 in the SRH. Hence, the packet as it leaves node N1 looks A4::C52 in the SRH. Hence, the packet as it leaves node N1 looks
like (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; NH=NONE, LM like (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; NH=NONE, LM
TLV (with C1 from N1)). The PM synthetic probe query message does TLV (with C1 from node N1 for Color C)). The PM synthetic probe
not contain any payload data. query message does not contain any payload data.
o When node N4 receives the packet (B1::0, A4::OTP)(A4::C52, o When node N4 receives the packet (B1::0, A4::OTP)(A4::C52,
A4::OTP, A2::C31; SL=1; NH=NONE, LM TLV), it processes the END.OTP A4::OTP, A2::C31; SL=1; NH=NONE, LM TLV), it processes the SID
SID function, as described in the pseudo code in function END.OTP, as described in the pseudo code in
[I-D.spring-srv6-network-programming]. In doing so, it punts the [I-D.spring-srv6-network-programming]. In doing so, it punts the
packet (with C2 from N4) to the Performance Measurement (PM) packet (with C2 from node N4 for Color C) to the Performance
process in control plane for processing. Measurement (PM) process in control plane for processing.
5. Probe Reply Message 5. Probe Reply Message
For one-way measurement, the receiver (node N4 in Figure 2) may send For one-way measurement, the receiver (node N4 in Figure 2 and Figure
a response to the sender or to a controller (N100 in Figure 2). For 4) may send a response to the sender or to a controller (N100 in
two-way measurement, the receiver sends a response to the sender. Figure 2 and Figure 4). For two-way measurement, the receiver sends
a response to the sender.
5.1. One-way Measurement Probe Reply 5.1. One-way Measurement Probe Reply
For one-way performance measurement [RFC7679], the PM querier node For one-way performance measurement [RFC7679], the PM querier node
can receive "out-of-bands" probe replies by properly setting the UDP 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) Return Object (URO) TLV in the probe message. The URO TLV (Type=131)
is defined in [RFC7876] and includes the UDP-Destination-Port and IP is defined in [RFC7876] and includes the UDP-Destination-Port and IP
Address. In particular, if the querier sets its own IP address in 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 URO TLV the probe response is sent back by the responder node to
the querier node. the querier node as shown in Figure 2 and Figure 4 as option-1.
The PM process in the control plane on the responder node copies the The PM process in the control plane on the responder node copies the
content of the DM TLV into the payload of the PM reply message. content of the DM or LM TLV from SRH into the payload of the PM reply
message.
5.1.1. Probe Reply Message to Controller 5.1.1. Probe Reply Message to Controller
As shown in Figure 1, if the querier node N1 requires the probe reply As shown in Figure 2 and Figure 4 as option-2, if the querier node N1
to be sent to the controller N100, it sets the IP address of N100 in requires the probe reply to be sent to the controller N100, it sets
the Address field of the URO TLV of the PM probe query message. the IP address of N100 in the Address field of the URO TLV of the PM
probe query message.
The PM process in the control plane on the responder node copies the The PM process in the control plane on the responder node copies the
content of the DM TLV into the payload of the PM reply message. content of the DM or LM TLV from SRH into the payload of the PM reply
message.
5.2. Two-way Measurement Probe Reply 5.2. Two-way Measurement Probe Reply
For two-way performance measurement [RFC6374], when using a For two-way performance measurement [RFC6374], when using a
bidirectional channel, the probe reply message is sent back to the bidirectional channel, the probe reply message is sent back to the
querier node using a message similar to the probe query message as an querier node using a message similar to the probe query message as an
SRv6 packet. In this case, the "control code" in the probe message SRv6 packet. In this case, the "control code" in the probe message
is set to "in-band response requested" [RFC6374]. is set to "in-band response requested" [RFC6374].
6. Security Considerations 6. Security Considerations
This document defines procedures for performance delay and loss This document defines procedures for performance delay and loss
measurement for SRv6 networks using the message formats defined in measurement for SRv6 networks using the message formats defined in
[RFC6374]. This document does not introduce any additional security [RFC6374]. This document does not introduce any additional security
considerations other than those covered in [RFC6374]. considerations other than those covered in [RFC6374].
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate values for the new SRH TLV Types for IANA is requested to allocate values for the new SRH TLV Types for
Delay Measurement TLV and Loss Measurement TLV. Delay Measurement TLV (TBA1) and Loss Measurement TLV (TBA2).
8. References 8. References
8.1. Normative References 8.1. Normative References
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", March 2008. Control Systems", March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 15, line 21 skipping to change at page 15, line 39
RFC 5357, October 2008. RFC 5357, October 2008.
[RFC7679] Almes, G., et al, "A One-Way Delay Metric for IP [RFC7679] Almes, G., et al, "A One-Way Delay Metric for IP
Performance Metrics (IPPM)', RFC 7679, January 2016. Performance Metrics (IPPM)', RFC 7679, January 2016.
[I-D.spring-segment-routing-policy] Filsfils, C., et al. "Segment [I-D.spring-segment-routing-policy] Filsfils, C., et al. "Segment
Routing Policy for Traffic Engineering", Routing Policy for Traffic Engineering",
draft-filsfils-spring-segment-routing-policy, work in draft-filsfils-spring-segment-routing-policy, work in
progress. progress.
[I-D.spring-sr-mpls-pm] Filsfils, C., et al. "Segment Routing Policy [I-D.spring-sr-mpls-pm] Filsfils, C., et al. "Performance
for Traffic Engineering", draft-gandhi-spring-sr-mpls-pm, Measurement in Segment Routing Networks with MPLS Data
work in progress. Plane", draft-gandhi-spring-sr-mpls-pm, work in progress.
Acknowledgments Acknowledgments
To be added. To be added.
Contributors Contributors
Faisal Iqbal Faisal Iqbal
Cisco Systems, Inc. Cisco Systems, Inc.
Email: faiqbal@cisco.com Email: faiqbal@cisco.com
 End of changes. 50 change blocks. 
98 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/