idnits 2.17.1 draft-cheng-mpls-inband-pm-encapsulation-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 (November 2, 2019) is 1635 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 (-11) exists of draft-ietf-mpls-sfl-framework-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: May 5, 2020 ZTE 6 T. Zhou 7 Huawei 8 X. Dong 9 FiberHome 10 Y. Peleg 11 Broadcom 12 November 2, 2019 14 Encapsulation For MPLS Performance Measurement with Alternate Marking 15 Method 16 draft-cheng-mpls-inband-pm-encapsulation-02 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 May 5, 2020. 41 Copyright Notice 43 Copyright (c) 2019 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 . . . . . . . . . . . . . 3 63 2.1. Examples for Applying Flow-ID in a label stack . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 [I-D.fioccola-spring-flow-label-alt-mark] describes how the alternate 77 marking method can be used as the passive performance measurement 78 method in an IPv6 domain, actually the alternate marking method can 79 also be applied to an MPLS domain, and what's missed is the 80 encapsulation for MPLS performance measurement with 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 The method described in this document is complementary to the SFL 94 method, the former targets at hop-by-hop performance measurement, and 95 the latter targets at end-to-end performance measurement, 96 furthermore, the former supports the application scenario where Flow- 97 ID is applied to MPLS LSP and MPLS VPN synchronously, and the latter 98 doesn't support this kind of application scenario. 100 This document defines the encapsulation for MPLS performance 101 measurement with alternate marking method, which performs flow-based 102 packet loss, delay, and jitter measurements on live traffic. 104 1.1. Conventions Used in This Document 106 1.1.1. Terminology 108 LSP: Label Switched Path 110 MPLS: Multi-Protocol Label Switching 112 NMS: Network Management System 114 PM: Performance Measurement 116 PW: PseudoWire 118 SFL: Synonymous Flow Label 120 TC: Traffic Class 122 TTL: Time to Live 124 VC: Virtual Channel 126 VPN: Virtual Private Network 128 1.1.2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Flow-based PM Encapsulation in MPLS 138 Flow-based MPLS performance measurement encapsulation with alternate 139 marking method has the following format: 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Flow-ID Indicator Label (TBA1) | TC |S| TTL | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Flow-ID |L|D|R|S| Reserved | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 ~ Payload ~ 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1: Flow-based PM Encapsulation in MPLS 155 Where Flow-ID Indicator Label is defined in this document as value 156 TBA1, and the other fields related to the Flow-based PM encapsulation 157 are defined as follows: 159 o Flow-ID - an MPLS label value used as MPLS flow identification 160 [RFC8372], it should be unique within the administrative domain. 161 Flow-ID values can be allocated by an external NMS or a 162 controller, based on measurement object instance such as LSP and 163 PW. There is a one-to-one mapping between Flow-ID and flow. The 164 specific method on how to allocate the Flow-ID values is described 165 in Section 4. Note that the Flow-ID Label can be placed either at 166 the bottom of the MPLS label stack or not, and the Flow-ID 167 Indicator Label MAY appear multiple times in a label stack, which 168 means more than one Flow-ID can be present within an MPLS label 169 stack. Section 2.1 of this document provides several examples to 170 illustrate how to apply Flow-ID in a label stack. 172 o L and D - L(oss) bit and D(elay) bit are used for coloring the 173 packets (called double-marking methodology), which is required by 174 the alternate marking method. 176 o R - R bit is reserved for future use and MUST be set to zero. 178 o Reserved - one octet long field reserved for future use and MUST 179 be set to zero. 181 2.1. Examples for Applying Flow-ID in a label stack 183 Three examples on different layout of Flow-ID label (4 octets) are 184 illustrated as follows: 186 (1) Layout of Flow-ID label when applied to MPLS LSP. 188 +----------------------+ 189 | | 190 | LSP | 191 | Label | 192 +----------------------+ 193 | | 194 | Flow-ID Indicator | 195 | Label | 196 +----------------------+ 197 | | 198 | Flow-ID | 199 | Label | 200 +----------------------+ 201 | | 202 | VPN | 203 | Label | 204 +----------------------+ <= Bottom of stack 205 | | 206 | Payload | 207 | | 208 +----------------------+ 210 Figure 2: Applying Flow-ID to MPLS LSP 212 (2) Layout of Flow-ID label when applied to MPLS VPN traffic. 214 +----------------------+ 215 | | 216 | LSP | 217 | Label | 218 +----------------------+ 219 | | 220 | VPN | 221 | Label | 222 +----------------------+ 223 | | 224 | Flow-ID Indicator | 225 | Label | 226 +----------------------+ 227 | | 228 | Flow-ID | 229 | Label | 230 +----------------------+ <= Bottom of stack 231 | | 232 | Payload | 233 | | 234 +----------------------+ 236 Figure 3: Applying Flow-ID to MPLS VPN 238 (3) Layout of Flow-ID label when applied to both MPLS LSP and MPLS 239 VPN traffic. 241 +----------------------+ 242 | | 243 | LSP | 244 | Label | 245 +----------------------+ 246 | | 247 | Flow-ID Indicator | 248 | Label | 249 +----------------------+ 250 | | 251 | Flow-ID | 252 | Label | 253 +----------------------+ 254 | | 255 | VPN | 256 | Label | 257 +----------------------+ 258 | | 259 | Flow-ID Indicator | 260 | Label | 261 +----------------------+ 262 | | 263 | Flow-ID | 264 | Label | 265 +----------------------+ <= Bottom of stack 266 | | 267 | Payload | 268 | | 269 +----------------------+ 271 Figure 4: Applying Flow-ID to both MPLS LSP and MPLS VPN 273 Note that here VPN label can be MPLS PW label, MPLS Ethernet VPN 274 label or MPLS IP VPN label, and it's also called VC label as defined 275 in [RFC4026]. 277 Also note that for this example the two Flow-ID values appearing in a 278 label stack MUST be different, that is to say, Flow-ID applied to 279 MPLS LSP and Flow-ID applied to MPLS VPN share the same value space. 281 3. Procedures of Encapsulation, Look-up and Decapsulation 283 The procedures for Flow-ID label encapsulation, look-up and 284 decapsulation are summarized as follows: 286 o The ingress node inserts the Flow-ID Indicator Label, alongside 287 with the Flow-ID label, into the MPLS label stack. At the same 288 time, the ingress node sets the L bit and D bit, as needed by 289 alternate-marking technique, and sets the Flow-ID value, as 290 defined in this document. 292 o The transit nodes look up the Flow-ID label with the help of the 293 Flow-ID Indicator Label, and transmit the collected information to 294 an external NMS or a controller, which includes the values of the 295 block counters and the timestamps of the marked packets, along 296 with the value of the Flow-ID, referring to the procedures of 297 alternate marking method. 299 o The egress node pops the Flow-ID Indicator Label, alongside with 300 the Flow-ID label, from the MPLS label stack. This document 301 doesn't introduce any new procedure regarding to the process of 302 the decapsulated packet. 304 4. Procedures of Flow-ID allocation 306 There are two ways of allocating Flow-ID, one way is to allocate 307 Flow-ID by manual trigger from the network operator, and the other 308 way is to allocate Flow-ID by automatic trigger from the ingress 309 node, details are as follows: 311 o In the case of manual trigger, the network operator would manually 312 input the characteristics (e.g. IP five tuples and IP DSCP) of 313 the measured IP traffic flow, then the NMS or the controller would 314 generate one or two Flow-IDs based on the input from the network 315 operator, and provision the ingress node with the characteristics 316 of the measured IP traffic flow and the corresponding allocated 317 Flow-ID(s). 319 o In the case of automatic trigger, the ingress node would identify 320 the IP traffic flow entering the measured path, export the 321 characteristics of the identified IP traffic flow to the NMS or 322 the controller by IPFIX [RFC7011], then the NMS or the controller 323 would generate one or two Flow-IDs based on the export from the 324 ingress node, and provision the ingress node with the 325 characteristics of the identified IP traffic flow and the 326 corresponding allocated Flow-ID(s). 328 The policy pre-configured at the NMS or the controller decides 329 whether one Flow-ID or two Flow-IDs would be generated. If the 330 performance measurement on VPN traffic is enabled, then one Flow-ID 331 applied to MPLS VPN would be generated; if the performance 332 measurement on LSP tunnel is enabled, then one Flow-ID applied to 333 MPLS LSP would be generated; if both of them are enabled, then two 334 Flow-IDs respectively applied to MPLS VPN and MPLS LSP would be 335 generated. 337 Whether using manual trigger or using automatic trigger, the NMS or 338 the controller MUST guarantee every generated Flow-ID is unique 339 within the administrative domain. 341 5. Security Considerations 343 This document does not introduce additional security requirements and 344 mechanisms. 346 6. IANA Considerations 348 In the Special-Purpose MPLS Label Values registry defined in 349 [SP-MPLS-Label], a new Special-Purpose MPLS Label Value for Flow-ID 350 Indicator is requested from IANA as follows: 352 +---------------------+-----------------+---------------+-----------+ 353 | Special-Purpose | Description | Semantics | Reference | 354 | MPLS Label Value | | Definition | | 355 +---------------------+-----------------+---------------+-----------+ 356 | TBA1 | Flow-ID | Section 2 | This | 357 | | Indicator Label | | Document | 358 +---------------------+-----------------+---------------+-----------+ 360 Table 1: New Special-Purpose MPLS Label Value for Flow-ID Indicator 362 7. Acknowledgements 364 The authors would like to acknowledge Greg Mirsky, Aihua Liu, 365 Shuangping Zhan and Ming Ke for their careful review and very helpful 366 comments. 368 8. References 370 8.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 379 May 2017, . 381 [SP-MPLS-Label] 382 "Special-Purpose MPLS Label Values", 2014, 383 . 386 8.2. Informative References 388 [I-D.fioccola-spring-flow-label-alt-mark] 389 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, 390 "Using the IPv6 Flow Label for Performance Measurement 391 with Alternate Marking Method in Segment Routing", draft- 392 fioccola-spring-flow-label-alt-mark-01 (work in progress), 393 October 2017. 395 [I-D.ietf-mpls-sfl-framework] 396 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 397 and G. Mirsky, "Synonymous Flow Label Framework", draft- 398 ietf-mpls-sfl-framework-06 (work in progress), October 399 2019. 401 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 402 Private Network (VPN) Terminology", RFC 4026, 403 DOI 10.17487/RFC4026, March 2005, 404 . 406 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 407 "Specification of the IP Flow Information Export (IPFIX) 408 Protocol for the Exchange of Flow Information", STD 77, 409 RFC 7011, DOI 10.17487/RFC7011, September 2013, 410 . 412 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 413 Mirsky, "MPLS Flow Identification Considerations", 414 RFC 8372, DOI 10.17487/RFC8372, May 2018, 415 . 417 Authors' Addresses 419 Weiqiang Cheng 420 China Mobile 421 Beijing 422 China 424 Email: chengweiqiang@chinamobile.com 426 Xiao Min 427 ZTE 428 Nanjing 429 China 431 Email: xiao.min2@zte.com.cn 432 Tianran Zhou 433 Huawei 434 Beijing 435 China 437 Email: zhoutianran@huawei.com 439 Ximing Dong 440 FiberHome 441 Wuhan 442 China 444 Email: dxm@fiberhome.com 446 Yoav Peleg 447 Broadcom 448 USA 450 Email: yoav.peleg@broadcom.com