idnits 2.17.1 draft-cheng-mpls-inband-pm-encapsulation-03.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 (March 7, 2020) is 1509 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 (-09) exists of draft-bryant-mpls-sfl-control-06 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-08 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-00 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-sfl-framework-06 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-spl-terminology-01 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 6 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: September 8, 2020 ZTE 6 T. Zhou 7 Huawei 8 X. Dong 9 FiberHome 10 Y. Peleg 11 Broadcom 12 March 7, 2020 14 Encapsulation For MPLS Performance Measurement with Alternate Marking 15 Method 16 draft-cheng-mpls-inband-pm-encapsulation-03 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 September 8, 2020. 41 Copyright Notice 43 Copyright (c) 2020 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. Terminology . . . . . . . . . . . . . . . . . . . . . 3 61 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 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 . . . 7 65 4. Procedures of Flow-ID allocation . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 [RFC8321] describes a passive performance measurement method, which 77 can be used to measure packet loss, delay, and jitter on live 78 traffic. Since this method is based on marking consecutive batches 79 of packets, the method is often referred to as Alternate Marking 80 Method. 82 [RFC8372] discusses the desired capabilities for MPLS flow 83 identification, in order to perform a better in-band performance 84 monitoring of user data packets. Synonymous Flow Label (SFL), which 85 is introduced in [I-D.ietf-mpls-sfl-framework], is identified as a 86 method of accomplishing MPLS flow identification. This document 87 employs a method, other than SFL, to accomplish MPLS flow 88 identification. The method described in this document is simple and 89 flexible, furthermore, it complies with the current MPLS forwarding 90 paradigm. 92 On one hand, the method described in this document is complementary 93 to the SFL method [I-D.ietf-mpls-sfl-framework] 94 [I-D.bryant-mpls-sfl-control], the former targets at hop-by-hop 95 performance measurement, and the latter targets at end-to-end 96 performance measurement, furthermore, the former supports the 97 application scenario where Flow-ID is applied to MPLS LSP and MPLS 98 VPN synchronously, and the latter doesn't support this kind of 99 application scenario. On the other hand, the method described in 100 this document is complementary to the In-situ OAM method 101 [I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-direct-export], the 102 former doesn't introduce any new header but the latter introduces a 103 new In-situ OAM header, furthermore, the former allows the network 104 nodes to report the refined data (e.g. calculated performance 105 metrics) associated with a specified flow, nevertheless the latter 106 requests the network nodes to report the data (e.g. ingress interface 107 and egress interface) associated with a specified packet. 109 This document defines the encapsulation for MPLS performance 110 measurement with alternate marking method, which performs flow-based 111 packet loss, delay, and jitter measurements on live traffic. 113 1.1. Conventions Used in This Document 115 1.1.1. Terminology 117 LSP: Label Switched Path 119 MPLS: Multi-Protocol Label Switching 121 NMS: Network Management System 123 PM: Performance Measurement 125 PW: PseudoWire 127 SFL: Synonymous Flow Label 129 TC: Traffic Class 131 TTL: Time to Live 133 VC: Virtual Channel 135 VPN: Virtual Private Network 137 1.1.2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 2. Flow-based PM Encapsulation in MPLS 147 Flow-based MPLS performance measurement encapsulation with alternate 148 marking method has the following format: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Extension Label (15) | TC |S| TTL | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Flow-ID Label Indicator (TBA1) | TC |S| TTL | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Flow-ID Label | TC |S| TTL | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: Flow-based PM Encapsulation in MPLS 162 Flow-ID Label Indicator is an Extended Special Purpose Label (eSPL), 163 which is combined with the Extension Label (XL, value 15) to form a 164 Composite Special Purpose Label (cSPL), as defined in 165 [I-D.ietf-mpls-spl-terminology]. Flow-ID Label Indicator is defined 166 in this document as value TBA1. 168 Analogous to Entropy Label Indicator [RFC6790], the TC and TTL for 169 the Extension Label and the Flow-ID Label Indicator SHOULD follow the 170 same field values of that label immediately preceding the Extension 171 Label, otherwise, the TC and TTL for the Extension Label and the 172 Flow-ID Label Indicator MAY be different values if it is known that 173 the Extension Label will not be exposed as the top label at any point 174 along the LSP. The S bit for the Extension Label and the Flow-ID 175 Label Indicator MUST be zero. 177 Flow-ID Label is used as MPLS flow identification [RFC8372], its 178 value should be unique within the administrative domain. Flow-ID 179 values can be allocated by an external NMS or a controller, based on 180 measurement object instance such as LSP or PW. There is a one-to-one 181 mapping between Flow-ID and flow. The specific method on how to 182 allocate the Flow-ID values is described in Section 4. 184 Analogous to Entropy Label [RFC6790], the Flow-ID Label can be placed 185 at either the bottom or the middle of the MPLS label stack, and the 186 Flow-ID Label MAY appear multiple times in a label stack. 187 Section 2.1 of this document provides several examples to illustrate 188 how to apply Flow-ID Label in a label stack. Again analogous to 189 Entropy Label, the TTL for the Flow-ID Label MUST be zero to ensure 190 that it is not used inadvertently for forwarding, the TC for the 191 Flow-ID Label may be any value, the S bit for the Flow-ID Label 192 depends on whether or not there are more labels in the label stack. 194 Besides flow identification, a color-marking field is also necessary 195 for alternate marking method. To achieve the purpose of coloring the 196 MPLS traffic, it's RECOMMENDED to reuse the Flow-ID Label's TC, i.e., 197 using TC's highest order two bits (called double-marking methodology 198 [RFC8321]) as color-marking bits. Alternatively, one more specific 199 MPLS color-marking label may be placed immediately following the 200 Flow-ID label. 202 2.1. Examples for Applying Flow-ID Label in a label stack 204 Three examples on different layout of Flow-ID Label (4 octets) are 205 illustrated as follows: 207 (1) Layout of Flow-ID Label when applied to MPLS LSP. 209 +----------------------+ 210 | LSP | 211 | Label | 212 +----------------------+ 213 | Extension | <--+ 214 | Label | | 215 +----------------------+ |--- cSPL 216 | Flow-ID Label | | 217 | Indicator | <--+ 218 +----------------------+ 219 | Flow-ID | 220 | Label | 221 +----------------------+ 222 | VPN | 223 | Label | 224 +----------------------+ <= Bottom of stack 225 | | 226 | Payload | 227 | | 228 +----------------------+ 230 Figure 2: Applying Flow-ID to MPLS LSP 232 (2) Layout of Flow-ID Label when applied to MPLS VPN traffic. 234 +----------------------+ 235 | LSP | 236 | Label | 237 +----------------------+ 238 | VPN | 239 | Label | 240 +----------------------+ 241 | Extension | <--+ 242 | Label | | 243 +----------------------+ |--- cSPL 244 | Flow-ID Label | | 245 | Indicator | <--+ 246 +----------------------+ 247 | Flow-ID | 248 | Label | 249 +----------------------+ <= Bottom of stack 250 | | 251 | Payload | 252 | | 253 +----------------------+ 255 Figure 3: Applying Flow-ID to MPLS VPN 257 (3) Layout of Flow-ID Label when applied to both MPLS LSP and MPLS 258 VPN traffic. 260 +----------------------+ 261 | LSP | 262 | Label | 263 +----------------------+ 264 | Extension | <--+ 265 | Label | | 266 +----------------------+ |--- cSPL 267 | Flow-ID Label | | 268 | Indicator | <--+ 269 +----------------------+ 270 | Flow-ID | 271 | Label | 272 +----------------------+ 273 | VPN | 274 | Label | 275 +----------------------+ 276 | Extension | <--+ 277 | Label | | 278 +----------------------+ |--- cSPL 279 | Flow-ID Label | | 280 | Indicator | <--+ 281 +----------------------+ 282 | Flow-ID | 283 | Label | 284 +----------------------+ <= Bottom of stack 285 | | 286 | Payload | 287 | | 288 +----------------------+ 290 Figure 4: Applying Flow-ID to both MPLS LSP and MPLS VPN 292 Note that here VPN label can be MPLS PW label, MPLS Ethernet VPN 293 label or MPLS IP VPN label, and it's also called VC label as defined 294 in [RFC4026]. 296 Also note that for this example the two Flow-ID values appearing in a 297 label stack MUST be different, that is to say, Flow-ID Label applied 298 to MPLS LSP and Flow-ID Label applied to MPLS VPN share the same 299 value space. 301 3. Procedures of Encapsulation, Look-up and Decapsulation 303 The procedures for Flow-ID label encapsulation, look-up and 304 decapsulation are summarized as follows: 306 o The ingress node inserts the Extension Label, the Flow-ID Label 307 Indicator, alongside with the Flow-ID label, into the MPLS label 308 stack. At the same time, the ingress node sets the color-marking 309 field, as needed by alternate-marking technique, and sets the 310 Flow-ID value, as defined in this document. 312 o The transit nodes look up the Flow-ID label with the help of the 313 Extension Label and the Flow-ID Label Indicator, and transmit the 314 collected information to an external NMS or a controller, which 315 includes the values of the block counters and the timestamps of 316 the marked packets, along with the value of the Flow-ID, referring 317 to the procedures of alternate marking method. 319 o The egress node pops the Extension Label and the Flow-ID Label 320 Indicator, alongside with the Flow-ID label, from the MPLS label 321 stack. This document doesn't introduce any new procedure 322 regarding to the process of the decapsulated packet. 324 4. Procedures of Flow-ID allocation 326 There are two ways of allocating Flow-ID, one way is to allocate 327 Flow-ID by manual trigger from the network operator, and the other 328 way is to allocate Flow-ID by automatic trigger from the ingress 329 node, details are as follows: 331 o In the case of manual trigger, the network operator would manually 332 input the characteristics (e.g. IP five tuples and IP DSCP) of 333 the measured IP traffic flow, then the NMS or the controller would 334 generate one or two Flow-IDs based on the input from the network 335 operator, and provision the ingress node with the characteristics 336 of the measured IP traffic flow and the corresponding allocated 337 Flow-ID(s). 339 o In the case of automatic trigger, the ingress node would identify 340 the IP traffic flow entering the measured path, export the 341 characteristics of the identified IP traffic flow to the NMS or 342 the controller by IPFIX [RFC7011], then the NMS or the controller 343 would generate one or two Flow-IDs based on the export from the 344 ingress node, and provision the ingress node with the 345 characteristics of the identified IP traffic flow and the 346 corresponding allocated Flow-ID(s). 348 The policy pre-configured at the NMS or the controller decides 349 whether one Flow-ID or two Flow-IDs would be generated. If the 350 performance measurement on VPN traffic is enabled, then one Flow-ID 351 applied to MPLS VPN would be generated; if the performance 352 measurement on LSP tunnel is enabled, then one Flow-ID applied to 353 MPLS LSP would be generated; if both of them are enabled, then two 354 Flow-IDs respectively applied to MPLS VPN and MPLS LSP would be 355 generated. 357 Whether using manual trigger or using automatic trigger, the NMS or 358 the controller MUST guarantee every generated Flow-ID is unique 359 within the administrative domain. 361 5. Security Considerations 363 This document introduces the performance measurement domain that is 364 the scope of a Flow-ID Label. The Flow-ID Label Indicator and Flow- 365 ID Label MUST NOT be signaled and distributed outside one performance 366 measurement domain. Improper configuration so that the Flow-ID Label 367 being passed from one domain to another would likely result in 368 potential Flow-ID conflicts. 370 To prevent packets carrying Flow-ID Label from leaking from one 371 domain to another, the domain boundary nodes SHOULD deploy some 372 policies (e.g., ACL) to filter out the packets. Specifically, in the 373 sending end, the domain boundary node SHOULD filter out the packets 374 that carry the Flow-ID Label Indicator and are sent to other domain; 375 in the receiving end, the domain boundary node SHOULD drop the 376 packets that carry the Flow-ID Label Indicator and are from other 377 domains. 379 6. IANA Considerations 381 In the Special-Purpose MPLS Label Values registry defined in 382 [SP-MPLS-Label], a new Extended Special-Purpose MPLS Label Value for 383 Flow-ID Label Indicator is requested from IANA as follows: 385 +-----------------------+----------------+--------------+-----------+ 386 | Extended Special- | Description | Semantics | Reference | 387 | Purpose MPLS Label | | Definition | | 388 | Value | | | | 389 +-----------------------+----------------+--------------+-----------+ 390 | TBA1 | Flow-ID Label | Section 2 | This | 391 | | Indicator | | Document | 392 +-----------------------+----------------+--------------+-----------+ 394 Table 1: New Extended Special-Purpose MPLS Label Value for Flow-ID 395 Label Indicator 397 7. Acknowledgements 399 The authors would like to acknowledge Loa Andersson, Tarek Saad, 400 Stewart Bryant, Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping 401 Zhan and Ming Ke for their careful review and very helpful comments. 403 8. References 405 8.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 413 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 414 May 2017, . 416 [SP-MPLS-Label] 417 "Special-Purpose MPLS Label Values", 2019, 418 . 421 8.2. Informative References 423 [I-D.bryant-mpls-sfl-control] 424 Bryant, S., Swallow, G., and S. Sivabalan, "A Simple 425 Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl- 426 control-06 (work in progress), January 2020. 428 [I-D.ietf-ippm-ioam-data] 429 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 430 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 431 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 432 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 433 ietf-ippm-ioam-data-08 (work in progress), October 2019. 435 [I-D.ietf-ippm-ioam-direct-export] 436 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 437 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 438 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 439 export-00 (work in progress), February 2020. 441 [I-D.ietf-mpls-sfl-framework] 442 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 443 and G. Mirsky, "Synonymous Flow Label Framework", draft- 444 ietf-mpls-sfl-framework-06 (work in progress), October 445 2019. 447 [I-D.ietf-mpls-spl-terminology] 448 Andersson, L., Kompella, K., and A. Farrel, "Special 449 Purpose Label terminology", draft-ietf-mpls-spl- 450 terminology-01 (work in progress), November 2019. 452 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 453 Private Network (VPN) Terminology", RFC 4026, 454 DOI 10.17487/RFC4026, March 2005, 455 . 457 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 458 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 459 RFC 6790, DOI 10.17487/RFC6790, November 2012, 460 . 462 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 463 "Specification of the IP Flow Information Export (IPFIX) 464 Protocol for the Exchange of Flow Information", STD 77, 465 RFC 7011, DOI 10.17487/RFC7011, September 2013, 466 . 468 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 469 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 470 "Alternate-Marking Method for Passive and Hybrid 471 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 472 January 2018, . 474 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 475 Mirsky, "MPLS Flow Identification Considerations", 476 RFC 8372, DOI 10.17487/RFC8372, May 2018, 477 . 479 Authors' Addresses 481 Weiqiang Cheng 482 China Mobile 483 Beijing 484 China 486 Email: chengweiqiang@chinamobile.com 488 Xiao Min 489 ZTE 490 Nanjing 491 China 493 Email: xiao.min2@zte.com.cn 494 Tianran Zhou 495 Huawei 496 Beijing 497 China 499 Email: zhoutianran@huawei.com 501 Ximing Dong 502 FiberHome 503 Wuhan 504 China 506 Email: dxm@fiberhome.com 508 Yoav Peleg 509 Broadcom 510 USA 512 Email: yoav.peleg@broadcom.com