idnits 2.17.1 draft-ietf-mpls-inband-pm-encapsulation-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 : ---------------------------------------------------------------------------- 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 (January 25, 2021) is 1185 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. 'SP-MPLS-Label' == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group W. Cheng 3 Internet-Draft China Mobile 4 Intended status: Standards Track X. Min 5 Expires: July 29, 2021 ZTE 6 T. Zhou 7 Huawei 8 X. Dong 9 FiberHome 10 Y. Peleg 11 Broadcom 12 January 25, 2021 14 Encapsulation For MPLS Performance Measurement with Alternate Marking 15 Method 16 draft-ietf-mpls-inband-pm-encapsulation-00 18 Abstract 20 This document defines the encapsulation for MPLS performance 21 measurement with alternate marking method, which performs flow-based 22 packet loss, delay, and jitter measurements on live traffic. 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 July 29, 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 60 1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 3 61 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 62 2. Flow-based PM Encapsulation in MPLS . . . . . . . . . . . . . 4 63 2.1. Examples for Applying Flow-ID Label in a label stack . . 5 64 3. Procedures of Encapsulation, Look-up and Decapsulation . . . 8 65 4. Procedures of Flow-ID allocation . . . . . . . . . . . . . . 9 66 5. FLC and FRLD Considerations . . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 9.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 [RFC8321] describes a passive performance measurement method, which 78 can be used to measure packet loss, delay, and jitter on live 79 traffic. Since this method is based on marking consecutive batches 80 of packets, the method is often referred to as Alternate Marking 81 Method. 83 [RFC8372] discusses the desired capabilities for MPLS flow 84 identification, in order to perform a better in-band performance 85 monitoring of user data packets. Synonymous Flow Label (SFL), which 86 is introduced in [I-D.ietf-mpls-sfl-framework], is identified as a 87 method of accomplishing MPLS flow identification. This document 88 employs a method, other than SFL, to accomplish MPLS flow 89 identification. The method described in this document is simple and 90 flexible, furthermore, it complies with the current MPLS forwarding 91 paradigm. 93 On one hand, the method described in this document is complementary 94 to the SFL method [I-D.ietf-mpls-sfl-framework] 95 [I-D.bryant-mpls-sfl-control], the former targets at hop-by-hop 96 performance measurement, and the latter targets at end-to-end 97 performance measurement, furthermore, the former supports the 98 application scenario where Flow-ID is applied to MPLS LSP and MPLS 99 VPN synchronously, and the latter doesn't support this kind of 100 application scenario. On the other hand, the method described in 101 this document is complementary to the In-situ OAM method 102 [I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-direct-export], the 103 former doesn't introduce any new header but the latter introduces a 104 new In-situ OAM header, furthermore, the former allows the network 105 nodes to report the refined data (e.g. calculated performance 106 metrics) associated with a specified flow, nevertheless the latter 107 requests the network nodes to report the data (e.g. ingress interface 108 and egress interface) associated with a specified packet. 110 This document defines the encapsulation for MPLS performance 111 measurement with alternate marking method, which performs flow-based 112 packet loss, delay, and jitter measurements on live traffic. 114 1.1. Conventions Used in This Document 116 1.1.1. Abbreviations 118 ELC: Entropy Label Capability 120 ERLD: Entropy Readable Label Depth 122 FLC: Flow-ID Label Capability 124 FRLD: Flow-ID Readable Label Depth 126 LSP: Label Switched Path 128 MPLS: Multi-Protocol Label Switching 130 NMS: Network Management System 132 PM: Performance Measurement 134 PW: PseudoWire 136 SFL: Synonymous Flow Label 138 SID: Segment ID 140 SR: Segment Routing 142 TC: Traffic Class 144 TTL: Time to Live 145 VC: Virtual Channel 147 VPN: Virtual Private Network 149 1.1.2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 2. Flow-based PM Encapsulation in MPLS 159 Flow-based MPLS performance measurement encapsulation with alternate 160 marking method has the following format: 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Extension Label (15) | TC |S| TTL | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Flow-ID Label Indicator (TBA1) | TC |S| TTL | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Flow-ID Label | TC |S| TTL | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: Flow-based PM Encapsulation in MPLS 174 Flow-ID Label Indicator is an Extended Special Purpose Label (eSPL), 175 which is combined with the Extension Label (XL, value 15) to form a 176 Composite Special Purpose Label (cSPL), as defined in 177 [I-D.ietf-mpls-spl-terminology]. Flow-ID Label Indicator is defined 178 in this document as value TBA1. 180 Analogous to Entropy Label Indicator [RFC6790], the TC and TTL for 181 the Extension Label and the Flow-ID Label Indicator SHOULD follow the 182 same field values of that label immediately preceding the Extension 183 Label, otherwise, the TC and TTL for the Extension Label and the 184 Flow-ID Label Indicator MAY be different values if it is known that 185 the Extension Label will not be exposed as the top label at any point 186 along the LSP. The S bit for the Extension Label and the Flow-ID 187 Label Indicator MUST be zero. 189 Flow-ID Label is used as MPLS flow identification [RFC8372], its 190 value should be unique within the administrative domain. Flow-ID 191 values can be allocated by an external NMS or a controller, based on 192 measurement object instance such as LSP or PW. There is a one-to-one 193 mapping between Flow-ID and flow. The specific method on how to 194 allocate the Flow-ID values is described in Section 4. 196 Analogous to Entropy Label [RFC6790], the Flow-ID Label can be placed 197 at either the bottom or the middle of the MPLS label stack, and the 198 Flow-ID Label MAY appear multiple times in a label stack. 199 Section 2.1 of this document provides several examples to illustrate 200 how to apply Flow-ID Label in a label stack. Again analogous to 201 Entropy Label, the TTL for the Flow-ID Label MUST be zero to ensure 202 that it is not used inadvertently for forwarding, the TC for the 203 Flow-ID Label may be any value, the S bit for the Flow-ID Label 204 depends on whether or not there are more labels in the label stack. 206 Besides flow identification, a color-marking field is also necessary 207 for alternate marking method. To achieve the purpose of coloring the 208 MPLS traffic, the current practice when writing this document is to 209 reuse the Flow-ID Label's TC, i.e., using TC's highest order two bits 210 (called double-marking methodology [RFC8321]) as color-marking bits. 211 Alternatively, allocating multiple Flow-ID Labels to the same flow 212 may be used for the purpose of alternate marking. 214 2.1. Examples for Applying Flow-ID Label in a label stack 216 Three examples on different layout of Flow-ID Label (4 octets) are 217 illustrated as follows: 219 (1) Layout of Flow-ID Label when applied to MPLS LSP. 221 +----------------------+ 222 | LSP | 223 | Label | 224 +----------------------+ 225 | Extension | <--+ 226 | Label | | 227 +----------------------+ |--- cSPL 228 | Flow-ID Label | | 229 | Indicator | <--+ 230 +----------------------+ 231 | Flow-ID | 232 | Label | 233 +----------------------+ 234 | VPN | 235 | Label | 236 +----------------------+ <= Bottom of stack 237 | | 238 | Payload | 239 | | 240 +----------------------+ 242 Figure 2: Applying Flow-ID to MPLS LSP 244 (2) Layout of Flow-ID Label when applied to MPLS VPN traffic. 246 +----------------------+ 247 | LSP | 248 | Label | 249 +----------------------+ 250 | VPN | 251 | Label | 252 +----------------------+ 253 | Extension | <--+ 254 | Label | | 255 +----------------------+ |--- cSPL 256 | Flow-ID Label | | 257 | Indicator | <--+ 258 +----------------------+ 259 | Flow-ID | 260 | Label | 261 +----------------------+ <= Bottom of stack 262 | | 263 | Payload | 264 | | 265 +----------------------+ 267 Figure 3: Applying Flow-ID to MPLS VPN 269 (3) Layout of Flow-ID Label when applied to both MPLS LSP and MPLS 270 VPN traffic. 272 +----------------------+ 273 | LSP | 274 | Label | 275 +----------------------+ 276 | Extension | <--+ 277 | Label | | 278 +----------------------+ |--- cSPL 279 | Flow-ID Label | | 280 | Indicator | <--+ 281 +----------------------+ 282 | Flow-ID | 283 | Label | 284 +----------------------+ 285 | VPN | 286 | Label | 287 +----------------------+ 288 | Extension | <--+ 289 | Label | | 290 +----------------------+ |--- cSPL 291 | Flow-ID Label | | 292 | Indicator | <--+ 293 +----------------------+ 294 | Flow-ID | 295 | Label | 296 +----------------------+ <= Bottom of stack 297 | | 298 | Payload | 299 | | 300 +----------------------+ 302 Figure 4: Applying Flow-ID to both MPLS LSP and MPLS VPN 304 Note that here VPN label can be MPLS PW label, MPLS Ethernet VPN 305 label or MPLS IP VPN label, and it's also called VC label as defined 306 in [RFC4026]. 308 Also note that for this example the two Flow-ID values appearing in a 309 label stack MUST be different, that is to say, Flow-ID Label applied 310 to MPLS LSP and Flow-ID Label applied to MPLS VPN share the same 311 value space. 313 3. Procedures of Encapsulation, Look-up and Decapsulation 315 The procedures for Flow-ID label encapsulation, look-up and 316 decapsulation are summarized as follows: 318 o The ingress node inserts the Extension Label, the Flow-ID Label 319 Indicator, alongside with the Flow-ID label, into the MPLS label 320 stack. At the same time, the ingress node sets the color-marking 321 field, as needed by alternate-marking technique, and sets the 322 Flow-ID value, as defined in this document. 324 o The transit nodes look up the Flow-ID label with the help of the 325 Extension Label and the Flow-ID Label Indicator, and transmit the 326 collected information to an external NMS or a controller, which 327 includes the values of the block counters and the timestamps of 328 the marked packets, along with the value of the Flow-ID, referring 329 to the procedures of alternate marking method. 331 o The egress node pops the Extension Label and the Flow-ID Label 332 Indicator, alongside with the Flow-ID label, from the MPLS label 333 stack. This document doesn't introduce any new procedure 334 regarding to the process of the decapsulated packet. 336 4. Procedures of Flow-ID allocation 338 There are two ways of allocating Flow-ID, one way is to allocate 339 Flow-ID by manual trigger from the network operator, and the other 340 way is to allocate Flow-ID by automatic trigger from the ingress 341 node, details are as follows: 343 o In the case of manual trigger, the network operator would manually 344 input the characteristics (e.g. IP five tuples and IP DSCP) of 345 the measured IP traffic flow, then the NMS or the controller would 346 generate one or two Flow-IDs based on the input from the network 347 operator, and provision the ingress node with the characteristics 348 of the measured IP traffic flow and the corresponding allocated 349 Flow-ID(s). 351 o In the case of automatic trigger, the ingress node would identify 352 the IP traffic flow entering the measured path, export the 353 characteristics of the identified IP traffic flow to the NMS or 354 the controller by IPFIX [RFC7011], then the NMS or the controller 355 would generate one or two Flow-IDs based on the export from the 356 ingress node, and provision the ingress node with the 357 characteristics of the identified IP traffic flow and the 358 corresponding allocated Flow-ID(s). 360 The policy pre-configured at the NMS or the controller decides 361 whether one Flow-ID or two Flow-IDs would be generated. If the 362 performance measurement on VPN traffic is enabled, then one Flow-ID 363 applied to MPLS VPN would be generated; if the performance 364 measurement on LSP tunnel is enabled, then one Flow-ID applied to 365 MPLS LSP would be generated; if both of them are enabled, then two 366 Flow-IDs respectively applied to MPLS VPN and MPLS LSP would be 367 generated. 369 Whether using manual trigger or using automatic trigger, the NMS or 370 the controller MUST guarantee every generated Flow-ID is unique 371 within the administrative domain. 373 5. FLC and FRLD Considerations 375 Analogous to the Entropy Label Capability (ELC) defined in Section 5 376 of [RFC6790], and the Entropy Readable Label Depth (ERLD) defined in 377 Section 4 of [RFC8662], the Flow-ID Label Capability (FLC) and the 378 Flow-ID Readable Label Depth (FRLD) are defined in this document. 379 Both FLC and FRLD have the similar semantics with ELC and ERLD to a 380 router, except that the Flow-ID is used in its flow identification 381 function while the Entropy is used in its load-balancing function. 383 The ingress node MUST insert each Flow-ID Label at an appropriate 384 depth, which ensures the node that needs to process the Flow-ID Label 385 has the FLC. How the ingress node knows the Flow-ID Label processing 386 node has the FLC is outside the scope of this document. 388 The ingress node SHOULD insert each Flow-ID Label within an 389 appropriate FRLD, which is the minimum FRLD of all on-path nodes that 390 needs to read and use the Flow-ID Label in question. How the ingress 391 node knows the appropriate FRLD for each Flow-ID Label is outside the 392 scope of this document. 394 When SR paths are used as transport, the label stack grows as the 395 number of on-path segments increases, if the number of on-path 396 segments is high, that may become a challenge for the Flow-ID Label 397 to be placed within an appropriate FRLD. In order to overcome this 398 potential challenge, an implementation MAY provide flexibility to the 399 ingress node to place Flow-ID Label between SID labels, i.e., 400 multiple identical Flow-ID Labels at different depths MAY be 401 interleaved with SID labels, when that happens a sophisticated 402 network planning may be needed and it's beyond the scope of this 403 document. 405 6. Security Considerations 407 This document introduces the performance measurement domain that is 408 the scope of a Flow-ID Label. The Flow-ID Label Indicator and Flow- 409 ID Label MUST NOT be signaled and distributed outside one performance 410 measurement domain. Improper configuration so that the Flow-ID Label 411 being passed from one domain to another would likely result in 412 potential Flow-ID conflicts. 414 To prevent packets carrying Flow-ID Label from leaking from one 415 domain to another, the domain boundary nodes SHOULD deploy some 416 policies (e.g., ACL) to filter out the packets. Specifically, in the 417 sending end, the domain boundary node SHOULD filter out the packets 418 that carry the Flow-ID Label Indicator and are sent to other domain; 419 in the receiving end, the domain boundary node SHOULD drop the 420 packets that carry the Flow-ID Label Indicator and are from other 421 domains. 423 7. IANA Considerations 425 In the Special-Purpose MPLS Label Values registry defined in 426 [SP-MPLS-Label], a new Extended Special-Purpose MPLS Label Value for 427 Flow-ID Label Indicator is requested from IANA as follows: 429 +-----------------------+----------------+--------------+-----------+ 430 | Extended Special- | Description | Semantics | Reference | 431 | Purpose MPLS Label | | Definition | | 432 | Value | | | | 433 +-----------------------+----------------+--------------+-----------+ 434 | TBA1 | Flow-ID Label | Section 2 | This | 435 | | Indicator | | Document | 436 +-----------------------+----------------+--------------+-----------+ 438 Table 1: New Extended Special-Purpose MPLS Label Value for Flow-ID 439 Label Indicator 441 8. Acknowledgements 443 The authors would like to acknowledge Loa Andersson, Tarek Saad, 444 Stewart Bryant, Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping 445 Zhan and Ming Ke for their careful review and very helpful comments. 447 9. References 449 9.1. Normative References 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997, 454 . 456 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 457 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 458 May 2017, . 460 [SP-MPLS-Label] 461 "Special-Purpose MPLS Label Values", 2019, 462 . 465 9.2. Informative References 467 [I-D.bryant-mpls-sfl-control] 468 Bryant, S., Swallow, G., and S. Sivabalan, "A Simple 469 Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl- 470 control-09 (work in progress), December 2020. 472 [I-D.ietf-ippm-ioam-data] 473 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 474 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 475 progress), November 2020. 477 [I-D.ietf-ippm-ioam-direct-export] 478 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 479 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 480 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 481 export-02 (work in progress), November 2020. 483 [I-D.ietf-mpls-sfl-framework] 484 Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. 485 Mirsky, "Synonymous Flow Label Framework", draft-ietf- 486 mpls-sfl-framework-11 (work in progress), October 2020. 488 [I-D.ietf-mpls-spl-terminology] 489 Andersson, L., Kompella, K., and A. Farrel, "Special 490 Purpose Label terminology", draft-ietf-mpls-spl- 491 terminology-06 (work in progress), January 2021. 493 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 494 Private Network (VPN) Terminology", RFC 4026, 495 DOI 10.17487/RFC4026, March 2005, 496 . 498 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 499 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 500 RFC 6790, DOI 10.17487/RFC6790, November 2012, 501 . 503 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 504 "Specification of the IP Flow Information Export (IPFIX) 505 Protocol for the Exchange of Flow Information", STD 77, 506 RFC 7011, DOI 10.17487/RFC7011, September 2013, 507 . 509 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 510 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 511 "Alternate-Marking Method for Passive and Hybrid 512 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 513 January 2018, . 515 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 516 Mirsky, "MPLS Flow Identification Considerations", 517 RFC 8372, DOI 10.17487/RFC8372, May 2018, 518 . 520 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 521 Shakir, R., and J. Tantsura, "Entropy Label for Source 522 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 523 DOI 10.17487/RFC8662, December 2019, 524 . 526 Authors' Addresses 528 Weiqiang Cheng 529 China Mobile 530 Beijing 531 China 533 Email: chengweiqiang@chinamobile.com 535 Xiao Min 536 ZTE 537 Nanjing 538 China 540 Email: xiao.min2@zte.com.cn 542 Tianran Zhou 543 Huawei 544 Beijing 545 China 547 Email: zhoutianran@huawei.com 548 Ximing Dong 549 FiberHome 550 Wuhan 551 China 553 Email: dxm@fiberhome.com 555 Yoav Peleg 556 Broadcom 557 USA 559 Email: yoav.peleg@broadcom.com