idnits 2.17.1 draft-li-spring-passive-pm-for-srv6-np-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2242 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) == Missing Reference: 'SL' is mentioned on line 631, but not defined == Missing Reference: 'ID.TBA' is mentioned on line 335, but not defined -- Looks like a reference, but probably isn't: '0' on line 635 == Unused Reference: 'I-D.ietf-ippm-alt-mark' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 763, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei 5 Expires: September 6, 2018 March 5, 2018 7 Passive Performance Measurement for SRv6 Network Programming 8 draft-li-spring-passive-pm-for-srv6-np-00 10 Abstract 12 This document defines a passive performance measurement method for 13 SRv6 network programming. In this method, performance measurement 14 information can be carried in data packets by two ways. One way is 15 carrying measurement information by used SIDs. Another way is 16 carrying measurement information via related SRH TLVs. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Passive SRv6 Performace Measurement . . . . . . . . . . . . . 4 61 4. SRH Flags for PM . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. DM-bit for Delay Measurement . . . . . . . . . . . . . . 5 63 4.2. LM-bit for Loss Measurement . . . . . . . . . . . . . . . 6 64 5. Optional TLVs . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Path ID TLV . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Block ID TLV . . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. DM TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.4. LM TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.1. Delay Measurement procedures . . . . . . . . . . . . . . 12 71 6.1.1. Using SIDs . . . . . . . . . . . . . . . . . . . . . 12 72 6.1.2. Using DM TLV . . . . . . . . . . . . . . . . . . . . 13 73 6.2. Loss Measurement procedures . . . . . . . . . . . . . . . 14 74 6.2.1. Using SIDs . . . . . . . . . . . . . . . . . . . . . 14 75 6.2.2. Using LM TLV . . . . . . . . . . . . . . . . . . . . 15 76 6.3. End.IOAM . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 10.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 Segment routing (SR) [I-D.ietf-spring-segment-routing] is a source 88 routing paradigm that explicitly indicates the forwarding path for 89 packets at the ingress node by inserting an ordered list of 90 instructions, called segments. A segment can represent a topological 91 or service-based instruction. Segment routing allows a node to steer 92 packets based on segments. 94 When segment routing is deployed on IPv6 dataplane, called 95 SRv6[I-D.ietf-6man-segment-routing-header], a segment is a 128 bit 96 value, and it can be an IPv6 address of a local interface but it does 97 not have to. As defined at 98 [I-D.filsfils-spring-srv6-network-programming], a segment has the 99 format of LOC: FUNCT. The most significant L bits is LOC that is 100 routable and leads packets to the SID originating node. The least 101 significant 128-L bits is the value of FUNCT that defines the local 102 actions of SID. L is the length of LOC and it is flexible. For 103 supporting SR, an extended header called Segment Routing Header 104 (SRH), which contains a list of SIDs and several needed information 105 such as Segment Left, has been defined in 106 [I-D.ietf-6man-segment-routing-header]. 108 In most cases, a SRv6 segment will not be reused for routing again 109 after it has been updated to IPv6 destination address. But these 110 used SIDs will be carried in the packet to the egress node unless PSP 111 is enable. Therefore, these SIDs can be reused for other purposes 112 such as carring performance measurement information or IOAM 113 [I-D.ietf-ippm-ioam-data] information. 115 This document introduces a passive SRv6 network programming based 116 performance measurement. In this method, the performance measurement 117 information can be carried in data packets without extra OAM packets. 118 There are two options to carry the performance measurement 119 information in the data packets: using SIDs and using TLVs. Using 120 SIDs to carry performance measurement information will reuse the SID 121 space and does no require any extra space. Therefore, it is a light 122 weight SRv6 network programming based performance measurement method 123 or even a light weight SRv6 network programming based IOAM. 125 2. Terminology 127 This memo makes use of the terms defined in 128 [I-D.ietf-spring-segment-routing], [I-D.ietf-ippm-ioam-data] and 129 [I-D.filsfils-spring-srv6-network-programming]. It also introduces 130 the following terminologies. 132 PM: Performance measurement. 134 DM: Delay measurement. 136 LM: Packet Loss measurement. 138 DA: Destination Address 140 MI: Measurement Information 142 PMI: Performance Measurement Information 144 NMS: Network Management System 146 3. Passive SRv6 Performace Measurement 148 This document defines a passive SRv6 performance measurement method 149 including delay measurement and packet loss measurement. 151 For delay measurement (DM), timestamp will be carried in the data 152 packet. For end-to-end DM, only the ingress node sending timestamp 153 needs to be carried in the data packet while all the timestamps of 154 each endpoint node along the path need to be carried for per-hop DM. 155 The timestamp will be used for calculating the delay by the egress 156 node or a controller, and the algorithm is the same as defined at 157 [RFC6374]. This documents proposes two options to carry timestamps: 158 using SIDs and using DM TLV. For achieving DM, this document defines 159 a new SRH flag DM bit. 161 For LM, counters associated with block[RFC8321] should be set. The 162 packets coloring and counting mechanism are the same as defined at 163 [RFC8321]. For identifying a block which the packet belongs to, a 164 Block ID TLV is proposed by this document. There are two options to 165 collect counters.The first one is sending counter values to NMS or 166 controller by nodes periodically. This option will be discussed at 167 later version of this document or another document. This document 168 will describe the second option, carrying counter values by packets 169 to the egress node and sending to controller or calculating by the 170 egress node. For achieving LM, this document defines a new SRH flag 171 LM bit. 173 A Block ID TLV should be carried by each data packets for packet 174 accounting when packet loss measurement is enable. The LM bit can be 175 set periodically at packets of a flow, so that corresponding counter 176 values can be obtained. Some packets without payload MUST be sent so 177 that the counter of last block can be obtained if there is no data 178 packet to carry PMI. This meachanism will be discussed at the later 179 version of this document. 181 For solving the problem of packet misorder, a data packet can carry 182 the counter value of the previous block, which means a sufficient 183 margin should be considered between the end of the block and reading 184 of counter. For solving the problem of lossing the data packets with 185 LM data, multiple data packets with LM data can be sent in a block. 186 These meachanisms will be discussed at the future version. 188 For end-to-end LM, only the ingress node counter value needs to be 189 carried in data packets. But counter values of each endpoint node 190 along the path need to be carried for per-hop LM. The counter value 191 will be used for calculating the packet loss by the egress node or a 192 controller, and the algorithm is the same as defined at [RFC6374]. 194 As well as DM, LM has two options to carry performance measurement 195 information(PMI): using SIDs and using LM TLV. 197 For option of using SIDs, PMI can be carried by the last 64 bits of 198 SIDs. In SRv6, a SID will not be used for routing after it has been 199 updated to IPv6 destination address (DA), so it can be rewrote with 200 metadata such as PMI. But for identifying nodes of SR path, the LOC 201 part of SID needs to remain still if there is no path ID to identify 202 a path, so only the non-LOC part can be rewrote with PMI. In this 203 draft, we assume the value of length of LOC is 64 or less when there 204 is no path ID in SRH since PMI need to meet the accuracy requirement 205 as defined at [I-D.ietf-ippm-ioam-data]. For getting rid of the 206 limitation of keeping LOC part of SIDs, a Path ID TLV is defined at 207 this documents. Using SID to carry PMI is a light weight passive PM 208 method for SRv6, and it also can be a light weight IOAM for SRv6. 210 For options of using TLVs, this documents defines DM TLV and LM TLV 211 in SRH to carry the PMI. 213 Futhermore, for punting a copied packet at a specific node, a new SID 214 is proposed at Section 6.3, called End.IOAM. 216 4. SRH Flags for PM 218 For measuring delay and packet loss, this draft defines 2 new flags 219 in SRH: 221 o DM-bit (Delay Measurement): Flag for Delay Measurement. 223 o LM-bit (Loss Measurement): Flag for Loss Measurement.. 225 The recommended locations of DM-bit and LM-bit in SRH.Flag shows 226 below. 228 0 1 2 3 4 5 6 7 229 +--+--+--+--+--+--+--+--+ 230 | U| P| O| A| H|DM|LM| U| 231 +--+--+--+--+--+--+--+--+ 233 The rest of this section will describe more detailed information of 234 these two flags. 236 4.1. DM-bit for Delay Measurement 238 The "Delay Measurement bit (DM-bit for short)" is a new flag in SRH. 239 The SRH.Flags.DM implements the "record timestamp and punt the copied 240 packet at the egress node" behavior. When a node N receives an SRv6 241 packet, N does following actions for processing DM-bit: 243 1.If DM-bit = 1: 244 2. Get the receving timestamp T1 ASAP. 245 3. If SL=1 and DA is End.S or if SL=0: ;;Ref1 246 4. Punt a copied packet with T1 to CPU for further processing;;Ref2 247 5. Else: 248 6. If DM TLV: 249 7 If I-flag = 1: 250 8. Write T1 into DM TLV 251 9. Else: 252 10. Insert following code after the instruction of updating DA: 253 11. Update SRH[SL][64:] with the T1 ;;Ref3 255 o Ref1: If SL is 0 or SL is 1 and the DA is an End.S 256 [I-D.filsfils-spring-srv6-network-programming], meaning the 257 current node is the egress node, the node will punt a copied 258 packet with the timestamp to CPU for further processing. Else, 259 the node, which a middle node only inserts "updates the SID with 260 current timestamp" after the instruction of "update DA with 261 SRH[SL]" or write the timestamp into DM TLV if the I-flag is set. 262 The ralated timestamp at the ingress node should be wrote into SID 263 or DM TLV accordingly before sending the data packet. 265 o Ref2: At the egress node, in order to not affect the packet 266 forwarding, a copied data packet should be punted instead of the 267 datda packet itself. But this document does not limit 268 implementation to punt the entire packet or only headers of 269 packet. 271 o Ref3: If no DM TLV appears in SRH, the last 64 bits of SID SRH[SL] 272 is rewrote with current timestamp after updating SID SRH[SL] to 273 IPv6 DA. If there is no Path ID TLV in SRH, the locator part 274 needs to remain for identifying a SID. The 64-bits timestamp 275 meets the accuracy requirement of IOAM [I-D.ietf-ippm-ioam-data]. 277 If a node does not support the DM-bit, then it simply ignores it upon 278 reception. If a node supports the DM-bit, it SHOULD advertise its 279 capability via node capability advertisement in IGP [ID.TBA]. 281 When DM-bit is set, PSP flavor can not be enable since the SRH needs 282 to be punted at the egress node. Likewise, implementation of USP 283 should be executed after DM-flag's implementation because of the same 284 reason. 286 4.2. LM-bit for Loss Measurement 288 The "Loss Measurement bit (LM-bit for short)" is a new flag in SRH. 289 The SRH.Flags.LM implements the"record value of counter and punt the 290 copied packet at the egress node" behavior. When a node N receives 291 an SRv6 packet, N does following actions for processing LM-bit: 293 1.If LM-bit = 1: 294 2. Record the value of corresponding counter as C1 295 3. If SL=1 and DA is End.S or if SL=0: ;;Ref1 296 4. Punt a copied packet with C1 to CPU for further processing;;Ref2 297 5. Else: 298 6. If LM TLV: 299 7 If I-flag = 1: 300 8. Write C1 into LM TLV 301 9. Else: 302 10. Insert following code after the instruction of updating DA: 303 11. Update SRH[SL][64:] with the C1 ;;Ref3 305 o Ref1: If SL is 0 or SL is 1 and the DA is an End.S 306 [I-D.filsfils-spring-srv6-network-programming], meaning the 307 current node is the egress node, the node will punt a copied 308 packet with the related counter's value to CPU for further 309 processing. Else, the node, which is a middle node only inserts 310 "updates the SID with current value of counter" after the 311 instruction of "update DA with SRH[SL]" or or write the counter 312 value into LM TLV if the I-flag is set. The related counter value 313 at the ingress node should be wrote into SID or DM TLV accordingly 314 before sending the data packet. 316 o Ref2: At the egress node, in order to not affect the packet 317 forwarding, a copied data packet should be punted instead of the 318 data packet itself. But this document does not limit 319 implementation to punt the entire packet or only headers of 320 packet. For measuring correctly, a Block ID TLV SHALL be carried 321 in SRH. 323 o Ref3: If no LM TLV appears in SRH, the last 64 bits of SID SRH[SL] 324 is rewrote with current value of counter associated to a path or a 325 flow after updating the SID SRH[SL] to IPv6 DA. If there is no 326 Path ID TLV in SRH, the locator part needs to remain for 327 identifying a SID. The key of counter can be SID list or path ID 328 or other ID such as flow label 329 [I-D.fioccola-spring-flow-label-alt-mark] that can identify a SID 330 path or a flow. However, a SID can be the key for a single hop 331 packet loss measurement. 333 If a node does not support the LM-bit, then it simply ignores it upon 334 reception. If a node supports the LM-bit, it SHOULD advertise its 335 capability via node capability advertisement in IGP [ID.TBA]. 337 When LM-bit is set, PSP flavor can not be enable since the SRH needs 338 to be punted at the egress node. Likewise, implementation of USP 339 should be executed after LM-flag's implementation because of the same 340 reason. 342 5. Optional TLVs 344 5.1. Path ID TLV 346 For easier identifying an SR path, this document defines a new Path 347 ID TLV, which identifies an SR path beginning from the ingress node. 349 If the path ID is a global ID, it can identfiy a path within an SR 350 domain then. If the path ID is a local ID assigned by an ingress 351 node, a tuple can identify a single path within 352 an SR domain. The Ingress ID can be the ingress node SID or other ID 353 that can identify ingress uniquely within an SR domain. With a Path 354 ID TLV, the whole SID space can be reused for carrying metadata since 355 the path information will be indicated by the path ID. The global 356 path ID or tuple of can be the key of counter 357 for packet loss measurement. The Path ID TLV has the following 358 format: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | Flag | RESERVED | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Path ID (4 octets) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Where: 370 o Type: to be assigned by IANA (suggested value 7). 372 o Length: 6. 374 o Flag: 8 bits of flags. Following flags are defined: 376 0 1 2 3 4 5 6 7 377 +--+--+--+--+--+--+--+--+ 378 | Reserved | G| 379 +--+--+--+--+--+--+--+--+ 381 G-Flag: Global flag. Set when the path ID is a global path ID. 383 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 384 ignored on receipt. 386 o Path ID: 32 bits. Defines a unique path beginning from the 387 ingress node. 389 With a Path ID TLV, the entire SID space can be reused without 390 limitation of keeping LOC part. 392 5.2. Block ID TLV 394 Marking packets with difference colors as a block is a packet loss 395 measurement method proposed at [RFC8321]. A block ID describes a 396 block which the packet belongs to. This document defines a new Block 397 ID TLV, and it has the following format: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length | RESERVED | Block ID | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Where: 407 o Type: to be assigned by IANA (suggested value 8). 409 o Length: 2. 411 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 412 ignored on receipt. 414 o Block ID: 8 bits. Defines a block which the packet belongs to. 416 5.3. DM TLV 418 Delay measurement information can be carried by DM TLV. The 419 timestamp type is the same as defined at [I-D.ietf-ippm-ioam-data]. 420 DM TLV will appear only once in SRH, the first one will be processed 421 while the rests will be ignored. The DM TLV has the following 422 format: 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 |Type | length | Flag | Reserved | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Timestamp 1 | 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | .... | 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Timestamp n | 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Where: 441 o Type: to be assigned by IANA (suggested value 9). 443 o Length: 8-bit unsigned integer. This field specifies the length 444 of data added by each node in multiples of 4-octets. 446 o Flag: 8 bits of flags. Following flags are defined: 448 0 1 2 3 4 5 6 7 449 +--+--+--+--+--+--+--+--+ 450 | Reserved | I| 451 +--+--+--+--+--+--+--+--+ 453 I-Flag: IOAM flag. Set when the the measurment mode is IOAM mode. 454 If it is not set, only one timestamp will be carried at this DM TLV, 455 which is a 64 bits sending timestamp at the ingress node. Thus, the 456 middle nodes will not write the timestamp into DM TLV. 458 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 459 ignored on receipt. 461 o Timestamp 1: 64 bits sending timestamp at the ingress node. 463 o Timestamp n: 64 bits receving timestamp at a specific node n. 465 5.4. LM TLV 467 Loss measurement information can be carried by LM TLV. LM TLV will 468 appear only once in SRH, the first one will be processed while the 469 rests will be ignored. The LM TLV has the following format: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 |Type | length | Flag | Reserved | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Coutner 1 | 477 | | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | .... | 480 | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Counter n | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Where: 488 o Type: to be assigned by IANA (suggested value 10). 490 o Length: 8-bit unsigned integer. This field specifies the length 491 of data added by each node in multiples of 4-octets. 493 o Flag: 8 bits of flags. Following flags are defined: 495 0 1 2 3 4 5 6 7 496 +--+--+--+--+--+--+--+--+ 497 | Reserved | I| 498 +--+--+--+--+--+--+--+--+ 500 I-Flag: IOAM flag. Set when the the measurment mode is IOAM mode. 501 If it is not set, only one counter will be carried at this LM TLV, 502 which is a 64 bit counter value of pakcets in corresponding block at 503 the ingress node. Thus, the middle nodes will not write the counter 504 value into DM TLV. 506 o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 507 ignored on receipt. 509 o Counter 1: 64 bits counter value of packets in corresponding block 510 at the ingress node. 512 o Counter n: 64 bits counter value of packets in corresponding block 513 at the ingress node at a specific node n. 515 6. Operations 517 This section will describe detailed operations of passive SRv6 518 network programming based performance measurement. For easy 519 understanding, the following simple topology is used for 520 illustration. 522 CE-A ---- N1-----N2-----N3---- CE-B 524 Reference Topology 526 In the reference topology: 528 o Nodes N1, N2, and N3 are all SRv6 capable nodes. 530 o Node N1 and N3 are configured with a tenant 10, each connected to 531 CE-A and CE-B respectively. 533 o Node Nk has Ak::/68 for its local SID space from which Local SIDs 534 are explicitly allocated. 536 o A2::1 is an End function allocated by N2 538 o A3::D10 is an End.DT4 function bound to tenant IPv4 table 10 539 allocated by N3. 541 o Bk::/64 is the loopback address of node K for IGP. 543 Assuming that the measured flow from CE-A to CE-B will travel path 544 . The ingress node N1 will insert a SRH with SID list 545 into the IPv6 header when it receives a IPv4 packet 546 with SA is CE-A, and DA is CE-B, so the packet header is (B1, DA) 547 (A3::D10, A2::1, SL=2)(CE-A, CE-B). The DA of IPv6 header is waiting 548 to be reworte by the active segment. 550 6.1. Delay Measurement procedures 552 For measuring delay, there are two options. In both options, DM-bit 553 needs to be set. If there is a DM TLV in SRH, PMI will be carried by 554 DM TLV. Otherwise, the PMI will be carried by SIDs. 556 6.1.1. Using SIDs 558 If choosing the option of using SIDs to carry delay MI, the 559 SRH.Flag.DM-bit needs to be set, and DM TLV MUST NOT appear in SRH. 561 After updating IPv6 DA with A2::1, the ingress node N1 updates SID 562 A2::1 in SRH with current timestamp and then forwards packet to N2 563 according to matched FIB entries. Assuming that the timestamp value 564 is T1, then the updated packet header becomes (B1, A2::1) (A3::D10, 565 A2::T1, SL=1) (CE-A, CE-B). 567 When N2 receives the packet with DA A2::1 which is an End SID 568 originated by N2, N2 will insert "Update SRH[SL][64:] with the 569 current timestamp" after instruction of "update DA with SRH[SL]", and 570 then process this End SID. 572 After updating IPv6 DA with SRH[0] A::D10, the current timestamp will 573 be recorded at the last 64 bits of End SID A3::D10. Assuming that 574 the timestamp value is T2, the updated packet header becomes (B1, 575 A3::D10) (A3::T2, A2::T1, SL=0) (CE-A, CE-B). According to the 576 updated DA A3::D10, the packet will be forwarded to N3. 578 When the egress node N3 receives the packet with header (B1, A3::D10) 579 (A3::T2, A2::T1, SL=0) (CE-A, CE-B), N3 should timestamp the copied 580 packet and punt it to CPU for further processing since SRH.SL is 0 581 meaning the packet has reached the egress node. Then, N3 582 decapsulates the outer header and forwards the inner packet to CE-B 583 based on the routes in tenant-10 IPv4 table since the DA is a local 584 End.DT4 SID. 586 Measurement can be implemented by node or a remote controller. The 587 algorithm of delay measurement is the same as defined at [RFC6374]. 588 However, in this solution, only one receiving timestamp or sending 589 timestamp can be recorded in SID at each endpoint node. Therefore, 590 it is RECOMMENDED that the ingress node records the sending timestamp 591 while the other nodes record the receiving timestamp. Therefore, 592 end-to-end delay measurement can be measured accurately. But for 593 middle nodes, the delay for a single hop is the sum of previous 594 node's processing delay and link delay between two nodes instead of 595 link delay only. 597 6.1.2. Using DM TLV 599 If choosing the option of using DM TLV to carry delay MI, and the 600 SRH.Flag.DM-bit needs to be set, and a DM TLV needs to be inserted in 601 SRH with the flag set accordingly. 603 Using the DM TLV will not affect the processing of SIDs. But before 604 sending a data packet, the ingress node N1 will write the sending 605 timestamp into DM TLV. When a middle node N2 receives a data packet, 606 it will inspect the existence of DM TLV. If there is a DM TLV in SRH 607 and the SRH.DM.I-flag is set, then a timestamp Tn will be wrote into 608 DM TLV. Otherwise, the DM TLV will contain an ingress sending 609 timestamp only. When the packet arrives at the egress node N3, a 610 copied packet with its timestamp will be punted to CPU for further 611 processing. 613 6.2. Loss Measurement procedures 615 For measuring packet loss, there are two options. In both options, 616 LM-bit needs to be set. If there is a LM TLV in SRH, PMI will be 617 carried by LM TLV. Otherwise, the PMI will be carried by SIDs. 619 6.2.1. Using SIDs 621 If choosing the option of using SIDs to carry packet loss MI, the 622 SRH.Flag.LM-bit needs to be set, and LM TLV MUST NOT appear in SRH. 624 After updating IPv6 DA with A2::1, the ingress node N1 updates A2::1 625 with the current counter value and then forwards packet to N2 626 according to matched FIB entries. Assuming that the corresponding 627 counter value is C1, then the updated packet header becomes (B1, 628 A2::1) (A3::D10, A2::C1, SL=1) (CE-A, CE-B). 630 When node N2 receives the packet with DA A2::1 which is an End SID 631 originated by N2, node N2 will insert "Update SRH[SL][64:] with the 632 current counter value" after instruction of "update DA with SRH[SL]", 633 and then process End SID. 635 After updating IPv6 DA with SRH[0] A::D10, the current counter value 636 will be recorded at the last 64 bits of End SID A3::D10. Assuming 637 that the value of corresponding counter is C2, then the updated 638 packet header becomes (B1, A3::D10) (A3::C2, A2::C1, SL=0) (CE-A, CE- 639 B). According to the updated DA A3::D10, the packet will be 640 forwarded to N3. 642 When the egress node N3 receives the packet with header (B1, A3::D10) 643 (A3::C2, A2::C1, SL=0) (CE-A, CE-B), node N3 punts a copied packet 644 with its corresponding counter value to CPU for further processing 645 since the packet has reached the egress node. Then, N3 decapsulates 646 the outer header and forwards the inner packet to CE-B based on the 647 routes in tenant-10 IPv4 table since the DA is a local End.DT4 SID. 649 Measurement can be implemented by node or a remote controller. The 650 algorithm of packet loss measurement is the same as defined at 651 [RFC6374]. Per-hop packet loss or end-to-end packet loss can be 652 measured by data packets without additional OAM packets. 654 6.2.2. Using LM TLV 656 If choosing the option of using LM TLV to carry packet loss MI, and 657 the SRH.Flag.LM-bit needs to be set, and a LM TLV needs to be 658 inserted in SRH with the flag set accordingly. 660 Using the LM TLV will not affect the processing of SIDs. But before 661 sending a data packet, the ingress node N1 should write the counter 662 value into LM TLV. When the middle node N2 receives a data packet, 663 it should inspect the existence of LM TLV. If there is a LM TLV in 664 SRH and the SRH.LM.I-flag is set, then a counter value Cn will be 665 wrote into LM TLV. Otherwise, the LM TLV will contain the counter 666 value at the ingress node only. When the packet arrives at the 667 egress node N3, a copied packet with its counter value will be punted 668 to CPU for further processing. 670 6.3. End.IOAM 672 In many scenarios, such as In-situ OAM, a copied packet with 673 corresponding metadata needs to be punted to CPU at a node in the 674 network. This document proposes a new SID function called End.IOAM 675 to implement it. This Function uses the reseved opcode which is TBA. 676 It can be inserted in any location of SIDs list to punt a copied data 677 packet at any node along the SRv6 path. 679 When N receives a packet destined to S and S is a local End.IOAM SID, 680 N does: 682 1.Punt a copied packet with metadata to CPU for further processing ;;Ref1 684 o Ref1: The corresponding metadata should be obtained according to 685 the IOAM data type. In this draft, IOAM data such as timestamp 686 can be indicated by SRH flags. 688 If the last SID is a End.IOAM SID, two copied packets will be punted 689 since the another packet will be punted as well by SL=0. The 690 solution of solving this problem will be futher discussed in a future 691 verison of this document. 693 7. IANA Considerations 695 TBA 697 8. Security Considerations 699 TBA 701 9. Acknowledgements 703 TBA 705 10. References 707 10.1. Normative References 709 [I-D.filsfils-spring-srv6-network-programming] 710 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 711 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 712 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 713 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 714 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 715 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 716 Camarillo, "SRv6 Network Programming", draft-filsfils- 717 spring-srv6-network-programming-03 (work in progress), 718 December 2017. 720 [I-D.ietf-6man-segment-routing-header] 721 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 722 Field, B., daniel.voyer@bell.ca, d., 723 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 724 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 725 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 726 Header (SRH)", draft-ietf-6man-segment-routing-header-08 727 (work in progress), January 2018. 729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, 731 DOI 10.17487/RFC2119, March 1997, 732 . 734 10.2. Informative References 736 [I-D.fioccola-spring-flow-label-alt-mark] 737 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, 738 "Using the IPv6 Flow Label for Performance Measurement 739 with Alternate Marking Method in Segment Routing", draft- 740 fioccola-spring-flow-label-alt-mark-01 (work in progress), 741 October 2017. 743 [I-D.ietf-ippm-alt-mark] 744 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 745 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 746 "Alternate Marking method for passive and hybrid 747 performance monitoring", draft-ietf-ippm-alt-mark-14 (work 748 in progress), December 2017. 750 [I-D.ietf-ippm-ioam-data] 751 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 752 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 753 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 754 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 755 data-02 (work in progress), March 2018. 757 [I-D.ietf-spring-segment-routing] 758 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 759 Litkowski, S., and R. Shakir, "Segment Routing 760 Architecture", draft-ietf-spring-segment-routing-15 (work 761 in progress), January 2018. 763 [I-D.ietf-spring-segment-routing-mpls] 764 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 765 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 766 data plane", draft-ietf-spring-segment-routing-mpls-12 767 (work in progress), February 2018. 769 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 770 Measurement for MPLS Networks", RFC 6374, 771 DOI 10.17487/RFC6374, September 2011, 772 . 774 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 775 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 776 "Alternate-Marking Method for Passive and Hybrid 777 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 778 January 2018, . 780 Authors' Addresses 782 Cheng Li 783 Huawei 785 Email: chengli13@huawei.com 787 Mach(Guoyi) Chen 788 Huawei 790 Email: mach.chen@huawei.com