idnits 2.17.1 draft-ali-spring-srv6-pm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2018) is 2249 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track R. Gandhi 5 Expires: August 31, 2018 N. Kumar 6 Cisco Systems, Inc. 7 D. Steinberg 8 Steinberg Consulting 9 S. Salsano 10 Universita di Roma "Tor Vergata" 11 P. L. Ventre 12 CNIT 13 G. Naik 14 Drexel University 15 D. Voyer 16 D. Bernier 17 Bell Canada 18 February 27, 2018 20 Performance Measurement in Segment Routing Networks with 21 IPv6 Data Plane (SRv6) 22 draft-ali-spring-srv6-pm-02.txt 24 Abstract 26 RFC 6374 specifies protocol mechanisms to enable efficient and 27 accurate measurement of packet loss, one-way and two-way delay, as 28 well as related metrics such as delay variation and channel 29 throughput in MPLS networks. This document describes how these 30 mechanisms can be used for performance measurement of delay and loss 31 in Segment Routing with IPv6 data plane (SRv6) networks. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 67 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 68 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 69 2.3. Terminology and Reference Topology . . . . . . . . . . . . 4 70 3. Performance Delay Measurement . . . . . . . . . . . . . . . . 5 71 3.1. One-Way Delay Measurement . . . . . . . . . . . . . . . . 5 72 3.2. Two-Way Delay Measurement . . . . . . . . . . . . . . . . 6 73 3.3. Delay Measurement Message Format . . . . . . . . . . . . . 6 74 3.3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . 8 75 3.4. Delay Measurement Query Procedure . . . . . . . . . . . . 8 76 3.4.1. Example Procedure . . . . . . . . . . . . . . . . . . 8 77 4. Performance Loss Measurement . . . . . . . . . . . . . . . . . 9 78 4.1. One-Way Loss Measurement . . . . . . . . . . . . . . . . . 9 79 4.2. Two-Way Loss Measurement . . . . . . . . . . . . . . . . . 10 80 4.3. Loss Measurement Message Format . . . . . . . . . . . . . 10 81 4.4. Loss Measurement Query Procedure . . . . . . . . . . . . . 12 82 4.4.1. Example Procedure . . . . . . . . . . . . . . . . . . 13 83 5. Probe Reply Message . . . . . . . . . . . . . . . . . . . . . 13 84 5.1. One-way Measurement Probe Reply . . . . . . . . . . . . . 13 85 5.1.1. Probe Reply Message to Controller . . . . . . . . . . 14 86 5.2. Two-way Measurement Probe Reply . . . . . . . . . . . . . 14 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 98 Service provider's requirements to satisfy Service Level Agreements 99 (SLAs) depend on the ability to measure and monitor performance 100 metrics for packet loss and one-way and two-way delay, as well as 101 related metrics such as delay variation and channel throughput. The 102 ability to monitor these performance metrics also provides operators 103 with greater visibility into the performance characteristics of their 104 networks, thereby facilitating planning, troubleshooting, and network 105 performance evaluation. 107 [RFC6374] specifies protocol mechanisms to enable the efficient and 108 accurate measurement of these performance metrics in MPLS networks. 109 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 110 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 111 provide capabilities for the measurement of various performance 112 metrics in IP networks. However, mechanisms defined in [RFC6374] are 113 more suitable for Segment Routing when using MPLS data plane 114 (SR-MPLS) [I-D.spring-sr-mpls-pm]. This document describes how the 115 mechanisms in [RFC6374] can be used for Performance Measurement (PM) 116 of delay and loss in Segment Routing with the IPv6 data plane (SRv6) 117 networks. 119 2. Conventions Used in This Document 121 2.1. Key Word Definitions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2.2. Abbreviations 131 DM: Delay Measurement. 133 LM: Loss Measurement. 135 PM: Performance Measurement. 137 SID: Segment ID. 139 SL: Segment Left. 141 SR: Segment Routing. 143 SRH: Segment Routing Header. 145 SRv6: Segment Routing with IPv6 Data plane. 147 TC: Traffic Class. 149 2.3. Terminology and Reference Topology 151 In this document, the simple topology shown in Figure 1 is used for 152 illustration. 154 -------- 155 +------------------------| N100 |------------------------+ 156 | -------- | 157 | | 158 ====== link1====== link3------ link5====== link9------ 159 ||N1||======||N2||======| N3 |======||N4||======| N5 | 160 || ||------|| ||------| |------|| ||------| | 161 ====== link2====== link4------ link6======link10------ 162 | | 163 | ------ | 164 +--------| N6 |--------+ 165 link7 | | link8 166 ------ 168 Figure 1: Reference Topology 170 In the reference topology: 172 Nodes N1, N2, and N4 are SRv6 capable nodes. 174 Nodes N3, N5 and N6 are classic IPv6 nodes. 176 Node 100 is a controller. 178 Node Nk has a classic IPv6 loopback address Bk::/128 180 Node Nk has Ak::/48 for its local SID space from which Local SIDs are 181 explicitly allocated. 183 The IPv6 address of the nth Link between node X and Y at the X side 184 is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address of link6 185 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 186 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 187 link between N3 and N4) at node N3 is 2001:DB8:3:4:31::. 189 Ak::0 is explicitly allocated as the END function at Node k. 191 Ak::Cij is explicitly allocated as the END.X function at node k 192 towards neighbor node i via jth Link between node i and node j. e.g., 193 A2::C31 represents END.X at N2 towards N3 via link3 (the 1st link 194 between N2 and N3). Similarly, A4::C52 represents the END.X at N4 195 towards N5 via link10. 197 represents a SID list where S1 is the first SID and S3 198 is the last SID. (S3, S2, S1; SL) represents the same SID list but 199 encoded in the SRH format where the rightmost SID (S1) in the SRH is 200 the first SID and the leftmost SID (S3) in the SRH is the last SID. 202 (SA, DA) (S3, S2, S1; SL) represents an IPv6 packet, SA is the IPv6 203 Source Address, DA the IPv6 Destination Address, (S3, S2, S1; SL) is 204 the SRH header that includes the SID list . 206 SR policy is defined in Section 3 of 207 [I-D.spring-segment-routing-policy]. 209 3. Performance Delay Measurement 211 3.1. One-Way Delay Measurement 213 The one-way delay measurement for Packet IP network is defined in 214 [RFC7679]. It is further exemplified using the following Figure 2. 216 ------ 217 |N100| 218 | | 219 ------ 220 ^ 221 | Response Option-2 222 T1 T2 | 223 +-------+/ Query \+-------+ 224 | | - - - - - - - - - ->| | 225 | N1 |=====================| N4 | 226 | |<- - - - - - - - - - | | 227 +-------+\ Response Option-1 /+-------+ 228 T4 T3 230 Figure 2: Delay Measurement Reference Model 232 Nodes N1 and N4 may not be directly connected, as shown in the 233 reference topology in Figure 1. When nodes N1 and N4 are not 234 directly connected, the one-way delay measurement reflects the delay 235 observed by the packet over an arbitrary SRv6 segment-list (SR 236 policy) [I-D.spring-segment-routing-policy]. In other words, the 237 one-way delay is associated with the forward (nodes N1 to N4) 238 direction of the SRv6 segment-list. 240 In Figure 2, T1 refers to the time when the packet is transmitted 241 from node N1. Timestamp is added as late as possible at the egress 242 pipeline (in hardware) at node N1. T2 refers to the time when the 243 packet is received at node N4. Timestamp at the receiver (node N4) 244 is added as soon as possible at the ingress pipeline (in hardware). 246 The one-way delay metric can be computed as follows [RFC7679], 247 [RFC6374]: 249 One-way delay = T2 - T1 251 3.2. Two-Way Delay Measurement 253 For simplified processing in hardware, the responder copies 254 timestamps T1 to T3 and T2 to T4 in the DM TLV before replying, such 255 that timestamps T1 and T2 are added at the same location in the DM 256 TLV for the reverse direction by node N4 and node N1, respectively 257 [RFC6374]. 259 The two-way delay metric can be computed as follows [RFC6374]: 261 Two-way delay = (T4 - T3) + (T2 - T1) 263 3.3. Delay Measurement Message Format 265 [I-D.6man-segment-routing-header] defines Segment Routing Header 266 (SRH) for SRv6. SRH can contain TLVs, as specified in 267 [I-D.6man-segment-routing-header]. This document defines Delay 268 Measurement (DM) TLV that is carried in SRH for delay measurement. 269 The DM TLV uses a modified DM message format specified in [RFC6374] 270 and is defined as follows: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length | RESERVED | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |Version| Flags | Control Code | RESERVED | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | QTF | RTF | RPTF | Reserved | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Session Identifier | TC | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Timestamp 1 | 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 . . 287 . . 288 . . 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Timestamp 4 | 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 ~ SUB-TLV Block ~ 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 3: Delay Measurement TLV Format 298 The meanings of the fields are summarized in the following table. 300 Field Meaning 301 ------------------- ---------------------------------------------- 302 Type SRH DM TLV type (Value TBA1 by IANA) 303 Length Total length of the TLV in bytes 304 Version Protocol version 305 Flags Message control flags 306 Control Code Code identifying the query or response type 307 QTF Querier timestamp format 308 RTF Responder timestamp format 309 RPTF Responder's preferred timestamp format 310 Reserved Reserved for future specification 311 Session Identifier Set arbitrarily by the querier 312 Traffic Traffic Class being measured 313 Class (TC) Field 314 Timestamp 1-4 64-bit timestamp values 315 (see Section 3.4 in [RFC6374]) 316 SUB-TLV Block Optional block of Type-Length-Value fields 318 Reserved fields MUST be set to 0 and ignored upon receipt. The 319 possible values for the remaining fields are as follows. 321 Version: Set to 1. 323 Flags: As specified in [RFC6374]. The T flag in a DM message is set 324 to 1 to indicate the DM is for the given Traffic Class. 326 Control Code: As specified in [RFC6374]. 328 Message Length: Set to the total length of this message in bytes, 329 including the Version, Flags, Control Code, and Message Length fields 330 as well as the TLV Block, if any. 332 Querier Timestamp Format: The format of the timestamp values written 333 by the querier, as specified in Section 3.4 of [RFC6374]. 335 Responder Timestamp Format: The format of the timestamp values 336 written by the responder, as specified in Section 3.4 of [RFC6374]. 338 Responder's Preferred Timestamp Format: The timestamp format 339 preferred by the responder, as specified in Section 3.4 of [RFC6374]. 341 Session Identifier: Set arbitrarily in a query and copied in the 342 response, if any. This field uniquely identifies a measurement 343 operation (also called a session) that consists of a sequence of 344 messages. All messages in the sequence have the same Session 345 Identifier [RFC6374]. 347 TC: Traffic Class being measured. 349 Timestamp 1-4 (T1-T4): The mapping of timestamps to the Timestamp 1-4 350 fields is designed to ensure that transmit timestamps are always 351 written at the same fixed offset in the packet, and likewise for 352 receive timestamps. This property is important for hardware 353 processing. 355 SUB-TLV Block: Zero or more TLV fields. This document assumes the 356 use of the DM message TLVs defined in [RFC6374]. 358 3.3.1. Timestamps 360 [RFC6374], Section 3.4 defines timestamp format that can be used for 361 delay measurement. The IEEE 1588 Precision Time Protocol (PTP) 362 timestamp format [IEEE1588] is used by default as described in 363 Appendix A of [RFC6374], but it may require hardware support. As an 364 alternative, Network Time Protocol (NTP) timestamp format is also 365 supported in [RFC6374]. 367 Note that for one-way delay measurement, Clock synchronization 368 between the querier and responder nodes using methods detailed in 369 [RFC6374] is required. Two-way delay measurement does not require 370 clock to be synchronized between the querier and responder nodes. 372 3.4. Delay Measurement Query Procedure 374 For delay measurement using synthetic probes, a DM TLV is inserted in 375 the SRH to record timestamps and SID function END.OTP as described in 376 the pseudo code in [I-D.spring-srv6-network-programming] is used to 377 punt probe packets. 379 3.4.1. Example Procedure 380 To measure delay from node N1 over an SRv6 Policy 381 [I-D.spring-segment-routing-policy] that goes through a segment-list 382 to node N4, the following procedure is defined for 383 sending queries: 385 o Node N1 constructs a DM probe packet with (B1::0, 386 A2::C31)(A4::C52, A2::C31, SL=1; NH=NONE, DM TLV). To punt the DM 387 probe packet at node N4, node N1 inserts the SID function END.OTP 388 [I-D.spring-srv6-network-programming] just before the target SID 389 A4::C52 in the SRH. Hence, the packet as it leaves node N1 looks 390 like (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; NH=NONE, DM 391 TLV (with T1 from node N1)). The PM synthetic probe query message 392 does not contain any payload data. 394 o When node N4 receives the packet (B1::0, A4::OTP)(A4::C52, 395 A4::OTP, A2::C31; SL=1; NH=NONE, DM TLV), it processes the SID 396 function END.OTP, as described in the pseudo code in 397 [I-D.spring-srv6-network-programming]. In doing so, it punts the 398 timestamped packet (with T2 from node N4) to the Performance 399 Measurement (PM) process in control plane for processing. 401 4. Performance Loss Measurement 403 4.1. One-Way Loss Measurement 405 The one-way loss measurement is exemplified using the following 406 Figure 4. 408 ------ 409 |N100| 410 | | 411 ------ 412 ^ 413 | Response Option-2 414 C1 C2 | 415 +-------+/ Query \+-------+ 416 | | - - - - - - - - - ->| | 417 | N1 |=====================| N4 | 418 | |<- - - - - - - - - - | | 419 +-------+\ Response Option-1 /+-------+ 420 C4 C3 422 Figure 4: Loss Measurement Reference Model 424 Nodes N1 and N4 may not be directly connected, as shown in the 425 reference topology in Figure 1. When nodes N1 and N4 are not 426 directly connected, the one-way loss measurement reflects the loss 427 observed by the packets over an arbitrary SRv6 segment-list (SR 428 policy) [I-D.spring-segment-routing-policy]. In other words, the 429 one-way loss is associated with the forward (nodes N1 to N4) 430 direction of the SRv6 segment-list. 432 In Figure 4, C1[n] refers to the packet (or byte) count of traffic 433 transmitted from node N1 for color C in the nth probe message. C2[n] 434 refers to the packet (or byte) count of the traffic received at node 435 N4 for the same color C in the nth probe message. 437 The one-way receive loss metric using counters for the same color can 438 be computed as follows [RFC6374]: 440 One-way receive loss[n-1, n] = (C2[n] - C2[n-1]) - (C1[n] - C1[n-1]) 442 4.2. Two-Way Loss Measurement 444 For simplified processing in hardware, the responder copies counter 445 C1 to C3 and C2 to C4 in the LM TLV before replying, such that 446 counters C1 and C2 for the same color are added at the same location 447 in the LM TLV for the reverse direction by node N4 and node N1, 448 respectively [RFC6374]. 450 The two-way receive loss metric using counters for the same color can 451 be computed as follows [RFC6374]: 453 Two-way receive loss[n-1, n] = (C4[n] - C4[n-1]) - (C3[n] - C3[n-1]) 454 + (C2[n] - C2[n-1]) - (C1[n] - C1[n-1]) 456 4.3. Loss Measurement Message Format 458 [I-D.6man-segment-routing-header] defines Segment Routing Header 459 (SRH) for SRv6. SRH can contain TLVs, as specified in 460 [I-D.6man-segment-routing-header]. This document defines Loss 461 Measurement (LM) TLV for SRH. The LM TLV uses a modified LM message 462 format specified in [RFC6374] and is defined as follows: 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Type | Length | RESERVED |C| 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 |Version| Flags | Control Code | RESERVED | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | DFLags| OTF | RESERVED | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Session Identifier | TC | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Origin Timestamp | 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Counter 1 | 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 . . 482 . . 483 . . 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Counter 4 | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 ~ SUB-TLV Block ~ 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 5: Loss Measurement TLV Format 493 The meanings of the fields are summarized in the following table. 495 Field Meaning 496 ------------------- ---------------------------------------------- 497 Type SRH LM TLV type (Value TBA2 by IANA) 498 Length Total length of the TLV in bytes 499 Color (C) Color flag of the Counters 1-4 500 Version Protocol version 501 Flags Message control flags 502 Control Code Code identifying the query or response type 503 Data Format Flags Flags specifying the format of message data 504 (DFlags) 505 Origin Timestamp Format of the Origin Timestamp field 506 Format (OTF) 507 Reserved Reserved for future specification 508 Session Identifier Set arbitrarily by the querier 509 Traffic Traffic Class being measured 510 Class (TC) Field 511 Counters 1-4 64-bit counter values for the same Color C 512 SUB-TLV Block Optional block of Type-Length-Value fields 514 Reserved fields MUST be set to 0 and ignored upon receipt. The 515 possible values for the remaining fields are as follows. 517 Version: Set to 1. 519 Flags: As specified in [RFC6374]. The T flag in a LM message is set 520 to 1 to indicate the LM is for the given Traffic Class. 522 Control Code: As specified in [RFC6374]. 524 Message Length: Set to the total length of this message in bytes, 525 including the Version, Flags, Control Code, and Message Length fields 526 as well as the TLV Block, if any. 528 DFlags: The format of the DFlags field is shown below. 530 +-+-+-+-+ 532 |X|B|0|0| 534 +-+-+-+-+ 536 Data Format Flags 538 The meanings of the DFlags bits are: 540 X: Extended counter format indicator. Set to 0 when the LM message 541 is transmitted or received over an interface that writes 32-bit 542 counter values. It is set to 1 for 64-bit counter values. 544 B: Octet (byte) count. When set to 1, indicates that the Counter 1- 545 4 fields represent octet counts. When set to 0, indicates that the 546 Counter 1-4 fields represent packet counts. 548 Origin Timestamp: The timestamp value written by the querier, as 549 specified in Section 3.4 of [RFC6374]. 551 Session Identifier: Set arbitrarily in a query and copied in the 552 response, if any. This field uniquely identifies a measurement 553 operation (also called a session) that consists of a sequence of 554 messages. All messages in the sequence have the same Session 555 Identifier [RFC6374]. 557 TC: Traffic Class being measured. 559 Counter 1-4 (C1-C4): 64-bit fields for LM counter values for the same 560 color C. 562 SUB-TLV Block: Zero or more TLV fields. This document assumes the 563 use of the LM message TLVs defined in [RFC6374]. 565 4.4. Loss Measurement Query Procedure 567 For loss measurement using synthetic probes, an LM TLV in the SRH is 568 used to record packet (or byte) counters per color and SID function 569 END.OTP as described in the pseudo code in 570 [I-D.spring-srv6-network-programming] is used to punt probe packets. 572 4.4.1. Example Procedure 574 To measure packet loss from node N1 over an SRv6 Policy 575 [I-D.spring-segment-routing-policy] that goes through a segment-list 576 (A2::C31, A4::C52) to node N4, following procedure is defined for 577 sending queries: 579 o Node N1 constructs a LM probe packet with (B1::0, 580 A2::C31)(A4::C52, A2::C31, SL=1; NH=NONE, LM TLV). To punt the LM 581 probe packet at node N4, node N1 inserts the SID function END.OTP 582 [I-D.spring-srv6-network-programming] just before the target SID 583 A4::C52 in the SRH. Hence, the packet as it leaves node N1 looks 584 like (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; NH=NONE, LM 585 TLV (with C1 from node N1 for Color C)). The PM synthetic probe 586 query message does not contain any payload data. 588 o When node N4 receives the packet (B1::0, A4::OTP)(A4::C52, 589 A4::OTP, A2::C31; SL=1; NH=NONE, LM TLV), it processes the SID 590 function END.OTP, as described in the pseudo code in 591 [I-D.spring-srv6-network-programming]. In doing so, it punts the 592 packet (with C2 from node N4 for Color C) to the Performance 593 Measurement (PM) process in control plane for processing. 595 5. Probe Reply Message 597 For one-way measurement, the receiver (node N4 in Figure 2 and Figure 598 4) may send a response to the sender or to a controller (N100 in 599 Figure 2 and Figure 4). For two-way measurement, the receiver sends 600 a response to the sender. 602 5.1. One-way Measurement Probe Reply 604 For one-way performance measurement [RFC7679], the PM querier node 605 can receive "out-of-bands" probe replies by properly setting the UDP 606 Return Object (URO) TLV in the probe message. The URO TLV (Type=131) 607 is defined in [RFC7876] and includes the UDP-Destination-Port and IP 608 Address. In particular, if the querier sets its own IP address in 609 the URO TLV the probe response is sent back by the responder node to 610 the querier node as shown in Figure 2 and Figure 4 as option-1. 612 The PM process in the control plane on the responder node copies the 613 content of the DM or LM TLV from SRH into the payload of the PM reply 614 message. 616 5.1.1. Probe Reply Message to Controller 618 As shown in Figure 2 and Figure 4 as option-2, if the querier node N1 619 requires the probe reply to be sent to the controller N100, it sets 620 the IP address of N100 in the Address field of the URO TLV of the PM 621 probe query message. 623 The PM process in the control plane on the responder node copies the 624 content of the DM or LM TLV from SRH into the payload of the PM reply 625 message. 627 5.2. Two-way Measurement Probe Reply 629 For two-way performance measurement [RFC6374], when using a 630 bidirectional channel, the probe reply message is sent back to the 631 querier node using a message similar to the probe query message as an 632 SRv6 packet. In this case, the "control code" in the probe message 633 is set to "in-band response requested" [RFC6374]. 635 6. Security Considerations 637 This document defines procedures for performance delay and loss 638 measurement for SRv6 networks using the message formats defined in 639 [RFC6374]. This document does not introduce any additional security 640 considerations other than those covered in [RFC6374]. 642 7. IANA Considerations 644 IANA is requested to allocate values for the new SRH TLV Types for 645 Delay Measurement TLV (TBA1) and Loss Measurement TLV (TBA2). 647 8. References 649 8.1. Normative References 651 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 652 Synchronization Protocol for Networked Measurement and 653 Control Systems", March 2008. 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", RFC 2119, March 1997. 658 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 659 Measurement for MPLS networks', RFC 6374, September 2011. 661 [RFC7876] Bryant, S., Sivabalan, S., and Soni, S., "UDP Return Path 662 for Packet Loss and Delay Measurement for MPLS Networks", 663 RFC 7876, July 2016. 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", RFC 8174, May 2017. 668 [I-D.spring-srv6-network-programming] Filsfils, C. et al. "SRv6 669 Network Programming", 670 draft-filsfils-spring-srv6-network-programming, work in 671 progress. 673 [I-D.6man-segment-routing-header] Previdi, S., Filsfils, et al, 674 "IPv6 Segment Routing Header (SRH)", 675 draft-ietf-6man-segment-routing-header, work in progress. 677 8.2. Informative References 679 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 680 Zekauskas, "A One-way Active Measurement Protoco (OWAMP)", 681 RFC 4656, September 2006. 683 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 684 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 685 RFC 5357, October 2008. 687 [RFC7679] Almes, G., et al, "A One-Way Delay Metric for IP 688 Performance Metrics (IPPM)', RFC 7679, January 2016. 690 [I-D.spring-segment-routing-policy] Filsfils, C., et al. "Segment 691 Routing Policy for Traffic Engineering", 692 draft-filsfils-spring-segment-routing-policy, work in 693 progress. 695 [I-D.spring-sr-mpls-pm] Filsfils, C., et al. "Performance 696 Measurement in Segment Routing Networks with MPLS Data 697 Plane", draft-gandhi-spring-sr-mpls-pm, work in progress. 699 Acknowledgments 701 To be added. 703 Contributors 705 Faisal Iqbal 706 Cisco Systems, Inc. 707 Email: faiqbal@cisco.com 709 Carlos Pignataro 710 Cisco Systems, Inc. 711 Email: cpignata@cisco.com 713 Authors' Addresses 715 Clarence Filsfils 716 Cisco Systems, Inc. 717 Email: cfilsfil@cisco.com 719 Zafar Ali 720 Cisco Systems, Inc. 721 Email: zali@cisco.com 723 Rakesh Gandhi 724 Cisco Systems, Inc. 725 Canada 726 Email: rgandhi@cisco.com 728 Nagendra Kumar 729 Cisco Systems, Inc. 730 Email: naikumar@cisco.com 732 Dirk Steinberg 733 Steinberg Consulting 734 Germany 735 Email: dws@dirksteinberg.de 737 Stefano Salsano 738 Universita di Roma "Tor Vergata" 739 Italy 740 Email: stefano.salsano@uniroma2.it 742 Pier Luigi Ventre 743 CNIT 744 Italy 745 Email: pierluigi.ventre@cnit.it 747 Gaurav Naik 748 Drexel University 749 USA 750 Email: gn@drexel.edu 752 Daniel Voyer 753 Bell Canada 754 Email: daniel.voyer@bell.ca 756 Daniel Bernier 757 Bell Canada 758 Email: daniel.bernier@bell.ca