idnits 2.17.1 draft-ietf-mpls-flow-ident-07.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 01, 2018) is 2220 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Bryant 3 Internet-Draft Huawei 4 Intended status: Informational C. Pignataro 5 Expires: September 2, 2018 Cisco Systems 6 M. Chen 7 Z. Li 8 Huawei 9 G. Mirsky 10 ZTE Corp. 11 March 01, 2018 13 MPLS Flow Identification Considerations 14 draft-ietf-mpls-flow-ident-07 16 Abstract 18 This document discusses the aspects that need to be be considered 19 when developing a solution for MPLS flow identification. The key 20 application that needs this is in-band performance monitoring of MPLS 21 flows when MPLS is used to encapsulate user data packets. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 2, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 59 3. Delay Measurement Considerations . . . . . . . . . . . . . . 4 60 4. Units of identification . . . . . . . . . . . . . . . . . . . 4 61 5. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 64 8. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 14. Informative References . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 This document discusses the aspects that need to be considered when 76 developing a solution for MPLS flow identification. The key 77 application that needs this is in-band performance monitoring of MPLS 78 flows when MPLS is used for the encapsulation of user data packets. 80 There is a need to identify flows in MPLS networks for various 81 applications such as determining packet loss and packet delay 82 measurement. A method of loss and delay measurement in MPLS networks 83 was defined in [RFC6374]. When used to measure packet loss [RFC6374] 84 depends on the use of injected Operations, Administration, and 85 Maintenance (OAM) packets to designate the beginning and the end of 86 the packet group over which packet loss is being measured. Where the 87 misordering of packets from one group relative to the following 88 group, or misordering of one of the packets being counted relative to 89 the [RFC6374] packet occurs, then an error will occur in the packet 90 loss measurement. 92 In addition, [RFC6374] did not support different granularities of 93 flow or address a number of multi-point cases in which two or more 94 ingress Label Switching Routers (LSRs) could send packets to one or 95 more destinations. 97 Improvements in link and transmission technologies have made it more 98 difficult to assess packet loss using active performance measurement 99 methods with synthetic traffic, due to the very low loss rate in 100 normal operation. That, together with more demanding service level 101 requirements, means that network operators now need to be able to 102 measure the loss of the actual user data traffic by using passive 103 performance measurement methods. Any technique deployed needs to be 104 transparent to the end user, and it needs to be assumed that they 105 will not take any active part in the measurement process. 106 Indeed it is important that any flow identification technique be 107 invisible to them, and that no remnant of the measurement process 108 leaks into their network. 110 Additionally where there are multiple traffic sources, such as in 111 multi-point to point and multi-point to multi-point network 112 environments there needs to be a method whereby the sink can 113 distinguish between packets from the various sources, that is to say, 114 that a multi-point to multi-point measurement model needs to be 115 developed. 117 2. Loss Measurement Considerations 119 Modern networks, if not oversubscribed, generally drop relatively few 120 packets, thus packet loss measurement is highly sensitive to the 121 common demarcation of the exact set of packets to be measured for 122 loss. Without some form of coloring or batch marking such as that 123 proposed in [RFC8321] it may not be possible to achieve the required 124 accuracy in the loss measurement of customer data traffic. Thus 125 where accurate measurement of packet loss is required, it may be 126 economically advantageous, or even a technical requirement, to 127 include some form of marking in the packets to assign each packet to 128 a particular counter for loss measurement purposes. 130 Where this level of accuracy is required and the traffic between a 131 source-destination pair is subject to Equal-Cost Multipath (ECMP) a 132 demarcation mechanism is needed to group the packets into batches. 133 Once a batch is correlated at both ingress and egress, the packet 134 accounting mechanism is then able to operate on the batch of packets 135 which can be accounted for at both the packet ingress and the packet 136 egress. Errors in the accounting are particularly acute in Label 137 Switched Paths (LSPs) subjected to ECMP because the network transit 138 time will be different for the various ECMP paths since: 140 1. The packets may traverse different sets of LSRs. 142 2. The packets may depart from different interfaces on different 143 line cards on LSRs. 145 3. The packets may arrive at different interfaces on different line 146 cards on LSRs. 148 A consideration with this solution on modifying the identity label 149 (the MPLS label ordinarily used to identify the LSP, Virtual Private 150 Network, Pseudowire etc) to indicate the batch is the impact that 151 this has on the path chosen by the ECMP mechanism. When the member 152 of the ECMP path set is chosen by deep packet inspection a change of 153 batch represented by a change of identity label will have no impact 154 on the ECMP path. Where the path member is chosen by reference to an 155 entropy label [RFC6790] then changing the batch identifier will not 156 result in a change to the chosen ECMP path. ECMP is so pervasive in 157 multi-point to (multi-) point networks that some method of avoiding 158 accounting errors introduced by ECMP needs to be supported. 160 3. Delay Measurement Considerations 162 Most of the existing delay measurement methods are active methods 163 that depend on the extra injected test packet to evaluate the delay 164 of a path. With the active measurement method, the rate, numbers and 165 interval between the injected packets may affect the accuracy of the 166 results. Due to ECMP (or link aggregation techniques) injected test 167 packets may traverse different links from the ones used by the data 168 traffic. Thus there exists a requirement to measure the delay of the 169 real traffic. 171 For combined loss-delay measurements, both the loss and the delay 172 considerations apply. 174 4. Units of identification 176 The most basic unit of identification is the identity of the node 177 that processed the packet on its entry to the MPLS network. However, 178 the required unit of identification may vary depending on the use 179 case for accounting, performance measurement or other types of packet 180 observations. In particular note that there may be a need to impose 181 identity at several different layers of the MPLS label stack. 183 This document considers following units of identifications: 185 o Per source LSR - everything from one source is aggregated. 187 o Per group of LSPs chosen by an ingress LSR - an ingress LSP 188 aggregates group of LSPs (ex: all LSPs of a tunnel). 190 o Per LSP - the basic form. 192 o Per flow [RFC6790] within an LSP - fine grained method. 194 Note that a fine grained identity resolution is needed when there is 195 a need to perform these operations on a flow not readily identified 196 by some other element in the label stack. 197 Such fine-grained resolution may be possible by deep packet 198 inspection. However, this may not always be possible, or it may be 199 desired to minimize processing costs by doing this only on entry to 200 the network. Adding a suitable identifier to the packet for 201 reference by other network elements minumises the processing needed 202 by other network elements. An example of such a fine grained case 203 might be traffic belonging to a certain service or from a specific 204 source, particularly if matters related to service level agreement or 205 application performance were being investigated 207 We can thus characterize the identification requirement in the 208 following broad terms: 210 o There needs to be some way for an egress LSR to identify the 211 ingress LSR with an appropriate degree of scope. This concept is 212 discussed further in Section 6. 214 o There needs to be a way to identify a specific LSP at the egress 215 node. This allows for the case of instrumenting multiple LSPs 216 operating between the same pair of nodes. In such cases the 217 identity of the ingress LSR is insufficient. 219 o In order to conserve resources such as labels, counters and/or 220 compute cycles it may be desirable to identify an LSP group so 221 that a operation can be performed on the group as an aggregate. 223 o There needs to be a way to identify a flow within an LSP. This is 224 necessary when investigating a specific flow that has been 225 aggregated into an LSP. 227 The unit of identification and the method of determining which 228 packets constitute a flow will be application or use-case specific 229 and is out of scope of this document. 231 5. Types of LSP 233 We need to consider a number of types of LSP. The two simplest types 234 to monitor are point to point LSPs and point to multi-point LSPs. 235 The ingress LSR for a point to point LSP, such as those created using 236 the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 237 [RFC5420] Signaling protocol, or those that conform to the MPLS 238 Transport Profile (MPLS-TP) [RFC5654] may be identified by inspection 239 of the top label in the stack, since at any provider-edge (PE) or 240 provider (P) router on the path this is unique to the ingress-egress 241 pair at every hop at a given layer in the LSP hierarchy. Provided 242 that penultimate hop popping is disabled, the identity of the ingress 243 LSR of a point to point LSP is available at the egress LSR and thus 244 determining the identity of the ingress LSR must be regarded as a 245 solved problem. Note however that the identity of a flow cannot to 246 be determined without further information being carried in the 247 packet, or gleaned from some aspect of the packet payload. 249 In the case of a point to multi-point LSP, and in the absence of 250 Penultimate Hop Popping (PHP) the identity of the ingress LSR may 251 also be inferred from the top label. However, it may not possible to 252 adequately identify the flow from the top label alone, and thus 253 further information may need to be carried in the packet, or gleaned 254 from some aspect of the packet payload. In designing any solution it 255 is desirable that a common flow identity solution be used for both 256 point to point and point to multi-point LSP types. Similarly it is 257 desirable that a common method of LSP group identification be used. 258 In the above cases, a context label [RFC5331] needs to be used to 259 provide the required identity information. This is widely supported 260 MPLS feature. 262 A more interesting case is the case of a multi-point to point LSP. 263 In this case the same label is normally used by multiple ingress or 264 upstream LSRs and hence source identification is not possible by 265 inspection of the top label by the egress LSRs. It is therefore 266 necessary for a packet to be able to explicitly convey any of the 267 identity types described in Section 4. 269 Similarly, in the case of a multi-point to multi-point LSP the same 270 label is normally used by multiple ingress or upstream LSRs and hence 271 source identification is not possible by inspection of the top label 272 by egress LSRs. The various types of identity described in Section 4 273 are again needed. Note however, that the scope of the identity may 274 be constrained to be unique within the set of multi-point to multi- 275 point LSPs terminating on any common node. 277 6. Network Scope 279 The scope of identification can be constrained to the set of flows 280 that are uniquely identifiable at an ingress LSR, or some aggregation 281 thereof. There is no need of an ingress LSR seeking assistance from 282 outside the MPLS protocol domain. 284 In any solution that constrains itself to carrying the required 285 identity in the MPLS label stack rather than in some different 286 associated data structure, constraints on the choice of label and 287 label stack size imply that the scope of identity resides within that 288 MPLS domain. For similar reasons the identity scope of a component 289 of an LSP is constrained to the scope of that LSP. 291 7. Backwards Compatibility 293 In any network it is unlikely that all LSRs will have the same 294 capability to support the methods of identification discussed in this 295 document. It is therefore an important constraint on any flow 296 identity solution that it is backwards compatible with deployed MPLS 297 equipment to the extent that deploying the new feature will not 298 disable anything that currently works on a legacy equipment. 300 This is particularly the case when the deployment is incremental or 301 the feature is not required for all LSRs or all LSPs. Thus, the flow 302 identification design must support the co-existence of both LSRs that 303 can, and cannot, identify the traffic components described in 304 Section 4. In addition the identification of the traffic components 305 described in Section 4 must be an optional feature that is disabled 306 by default. As a design simplification, a solution may require that 307 all egress LSRs of a point to multi-point or a multi- point to multi- 308 point LSP support the identification type in use so that a single 309 packet can be correctly processed by all egress devices. The 310 corollary of this last point is that either all egress LSRs are 311 enabled to support the required identity type, or none of them are. 313 8. Dataplane 315 There is a huge installed base of MPLS equipment, typically this type 316 of equipment remains in service for an extended period of time, and 317 in many cases hardware constraints mean that it is not possible to 318 upgrade its dataplane functionality. Changes to the MPLS data plane 319 are therefore expensive to implement, add complexity to the network, 320 and may significantly impact the deployability of a solution that 321 requires such changes. For these reasons, MPLS users have set a very 322 high bar to changes to the MPLS data plane, and only a very small 323 number have been adopted. Hence, it is important that the method of 324 identification must minimize changes to the MPLS data plane. Ideally 325 method(s) of identification that require no changes to the MPLS data 326 plane should be given preferential consideration. If a method of 327 identification makes a change to the data plane is chosen it will 328 need to have a significant advantage over any method that makes no 329 change, and the advantage of the approach will need to be carefully 330 evaluated and documented. If a change is necessary to the MPLS data 331 plane proves necessary, it should be (a) be as small a change as 332 possible and (b) be a general purpose method so as to maximize its 333 use for future applications. It is imperative that, as far as can be 334 foreseen, any necessary change made to the MPLS data plane does not 335 impose any foreseeable future limitation on the MPLS data plane. 337 Stack size is an issue with many MPLS implementations both as a 338 result of hardware limitations, and due to the impact on networks and 339 applications where a large number of small payloads need to be 340 transported In particular one MPLS payload may be carried inside 341 another. For example, one LSP may be carried over another LSP, or a 342 PW or similar multiplexing construct may be carried over an LSP and 343 identification may be required at both layers. Of particular concern 344 is the implementation of low cost edge LSRs that for cost reasons 345 have a significant limit on the number of Label Stack Elements (LSEs) 346 that they can impose or dispose. Therefore, any method of identity 347 must not consume an excessive number of unique labels, and must not 348 result in an excessive increase in the size of the label stack. 350 The MPLS data plane design provides two types of special purpose 351 labels: the original 16 reserved labels and the much larger set of 352 special purpose labels defined in [RFC7274]. The original reserved 353 labels need one LSE, and the newer [RFC7274] special purpose labels 354 need two LSEs. Given the tiny number of original reserved labels, it 355 is core to the MPLS design philosophy that this scarce resource is 356 only used when it is absolutely necessary. Using a single LSE 357 reserved or special purpose label to encode flow identity thus 358 requires two stack entries, one for the reserved label and one for 359 the flow identity. The larger set of [RFC7274] labels requires two 360 labels stack entries for the special purpose label itself and hence a 361 total of three label stack entries to encode the flow identity. 363 The use of special purpose labels (SPL) [RFC7274] as part of a method 364 to encode the identity information therefore has a number of 365 undesirable implications for the data plane and hence whilst a 366 solution may use SPL(s), methods that do not require SPLs need to be 367 carefully considered. 369 9. Control Plane 371 Any flow identity design should both seek to minimise the complexity 372 of the control plane and should minimise the amount of label co- 373 ordination needed amongst LSRs. 375 10. Privacy Considerations 377 The inclusion of originating and/or flow information in a packet 378 provides more identity information and hence potentially degrades the 379 privacy of the communication. Recent IETF concerns on pervasive 380 monitoring [RFC7258] would lead it to prefer a solution that does not 381 degrade the privacy of user traffic below that of an MPLS network not 382 implementing the flow identification feature. The choice of using 383 MPLS technology for this OAM solution has a privacy advantage as the 384 choice of the label identifying a flow is limited to the scope of the 385 MPLS domain and does not have any dependency on the user data's 386 identification. This minimizes the observability of the flow 387 characteristics. 389 11. Security Considerations 391 Any solution to the flow identification needs must not degrade the 392 security of the MPLS network below that of an equivalent network not 393 deploying the specified identity solution. 394 In order to preserve present assumptions about MPLS privacy 395 properties, propagation of identification information outside the 396 MPLS network imposing it must be disabled by default. Any solution 397 should provide for the restriction of the identity information to 398 those components of the network that need to know it. It is thus 399 desirable to limit the knowledge of the identify of an endpoint to 400 only those LSRs that need to participate in traffic flow. The choice 401 of using MPLS technology for this OAM solution, with MPLS 402 encapsulation of user traffic, provides for a key advantage over 403 other data plane solutions, as it provides for a controlled access 404 and trusted domain within a Service Provider's network. 406 For a more comprehensive discussion of MPLS security and attack 407 mitigation techniques, please see the Security Framework for MPLS and 408 GMPLS Networks [RFC5920]. 410 12. IANA Considerations 412 This document has no IANA considerations. (At the discretion of the 413 RFC Editor this section may be removed before publication). 415 13. Acknowledgments 417 The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow 418 and Deborah Brungard for their comments. 420 14. Informative References 422 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 423 Label Assignment and Context-Specific Label Space", 424 RFC 5331, DOI 10.17487/RFC5331, August 2008, 425 . 427 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 428 Ayyangarps, "Encoding of Attributes for MPLS LSP 429 Establishment Using Resource Reservation Protocol Traffic 430 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 431 February 2009, . 433 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 434 Sprecher, N., and S. Ueno, "Requirements of an MPLS 435 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 436 September 2009, . 438 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 439 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 440 . 442 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 443 Measurement for MPLS Networks", RFC 6374, 444 DOI 10.17487/RFC6374, September 2011, 445 . 447 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 448 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 449 RFC 6790, DOI 10.17487/RFC6790, November 2012, 450 . 452 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 453 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 454 2014, . 456 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 457 and Retiring Special-Purpose MPLS Labels", RFC 7274, 458 DOI 10.17487/RFC7274, June 2014, 459 . 461 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 462 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 463 "Alternate-Marking Method for Passive and Hybrid 464 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 465 January 2018, . 467 Authors' Addresses 469 Stewart Bryant 470 Huawei 472 Email: stewart.bryant@gmail.com 474 Carlos Pignataro 475 Cisco Systems 477 Email: cpignata@cisco.com 478 Mach Chen 479 Huawei 481 Email: mach.chen@huawei.com 483 Zhenbin Li 484 Huawei 486 Email: lizhenbin@huawei.com 488 Gregory Mirsky 489 ZTE Corp. 491 Email: gregimirsky@gmail.com