idnits 2.17.1 draft-ietf-mpls-flow-ident-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 (January 23, 2017) is 2643 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: July 27, 2017 Cisco Systems 6 M. Chen 7 Z. Li 8 Huawei 9 G. Mirsky 10 ZTE Corp. 11 January 23, 2017 13 MPLS Flow Identification Considerations 14 draft-ietf-mpls-flow-ident-03 16 Abstract 18 This memo discusses the desired capabilities for MPLS flow 19 identification. The key application that needs this is in-band 20 performance monitoring of user data packets. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 27, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 59 4. Delay Measurement Considerations . . . . . . . . . . . . . . 4 60 5. Units of identification . . . . . . . . . . . . . . . . . . . 4 61 6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 64 9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 66 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 15.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 15.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 This memo discusses the desired capabilities for MPLS flow 78 identification. The key application that needs this is in-band 79 performance monitoring of user data packets. 81 There is a need to identify flows in MPLS networks for applications 82 such as packet loss and packet delay measurement. A method of loss 83 and delay measurement in MPLS networks was defined in [RFC6374]. 84 When used to measure packet loss [RFC6374] depends on the use of the 85 injected Operations, Administration, and Maintenance (OAM) packets to 86 designate the beginning and the end of the packet group over which 87 packet loss is being measured. Where the misordering of packets from 88 one group relative to the following group, or misordering of one of 89 the packets being counted relative to the [RFC6374] packet occurs, 90 then an error will occur in the packet loss measurement. In 91 addition, this packet performance measurement system needs to be 92 extended to deal with different granularities of flow and to address 93 a number of the multi-point cases in which two or more ingress Label 94 Switching Routers (LSRs) could send packets to one or more 95 destinations. 97 Improvements in link and transmission technologies mean that it may 98 be difficult to assess packet loss using active performance 99 measurement methods with synthetic traffic, due to the very low loss 100 rate in normal operation. That, together with more demanding service 101 level requirements, mean that network operators 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. Indeed it 106 is important that any flow identification technique be invisible to 107 them and that no remnant of the identification of measurement process 108 leak 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. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC2119 [RFC2119]. 123 3. Loss Measurement Considerations 125 Modern networks, if not oversubscribed, normally drop very few 126 packets, thus packet loss measurement is highly sensitive to counter 127 errors. Without some form of coloring or batch marking such as that 128 proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve 129 the required accuracy in the loss measurement of customer data 130 traffic. Thus where accuracy better than the data link loss 131 performance of a modern optical network is required, it may be 132 economically advantageous, or even a technical requirement, to 133 include some form of marking in the packets to assign each packet to 134 a particular counter. 136 Where this level of accuracy is required and the traffic between a 137 source-destination pair is subject to Equal-Cost Multipath (ECMP) a 138 demarcation mechanism is needed to group the packets into batches. 139 Once a batch is correlated at both ingress and egress, the packet 140 accounting mechanism is then able to operate on the batch of packets 141 which can be accounted for at both the packet ingress and the packet 142 egress. Errors in the accounting are particularly acute in Label 143 Switched Paths (LSPs) subjected to ECMP because the network transit 144 time will be different for the various ECMP paths since: 146 1. The packets may traverse different sets of LSRs. 148 2. The packets may depart from different interfaces on different 149 line cards on LSRs 151 3. The packets may arrive at different interfaces on different line 152 cards on LSRs. 154 A consideration in modifying the identity label (the MPLS label 155 ordinarily used to identify the LSP, Virtual Private Network, 156 Pseudowire etc) to indicate the batch is the impact that this has on 157 the path chosen by the ECMP mechanism. When the member of the ECMP 158 path set is chosen by deep packet inspection a change of batch 159 represented by a change of identity label will have no impact on the 160 ECMP path. Where the path member is chosen by reference to an 161 entropy label [RFC6790] then changing the batch identifier will not 162 result in a change to the chosen ECMP path. ECMP is so pervasive in 163 multi-point to (multi-) point networks that some method of avoiding 164 accounting errors introduced by ECMP needs to be supported. 166 4. Delay Measurement Considerations 168 Most of the existing delay measurement methods are active measurement 169 that depend on the extra injected test packet to evaluate the delay 170 of a path. With the active measurement method, the rate, numbers and 171 interval between the injected packets may affect the accuracy of the 172 results. Also, for injected test packets, these may not be co-routed 173 with the data traffic due to ECMP. Thus there exists a requirement 174 to measure the delay of the real traffic. 176 For combined loss-delay measurements, both the loss and the delay 177 considerations apply. 179 5. Units of identification 181 The most basic unit of identification is the identity of the node 182 that processed the packet on its entry to the MPLS network. However, 183 the required unit of identification may vary depending on the use 184 case for accounting, performance measurement or other types of packet 185 observations. In particular note that there may be a need to impose 186 identify at several different layers of the MPLS label stack. 188 This document considers following units of identifications: 190 o Per source LSR - everything from one source is aggregated. 192 o Per group of LSPs chosen by an ingress LSR - an ingress LSP 193 aggregates group of LSPs (ex: all LSPs of a tunnel). 195 o Per LSP - the basic form. 197 o Per flow [RFC6790] within an LSP - fine graining method. 199 Note that a fine grained identity resolution is needed when there is 200 a need to perform these operations on a flow not readily identified 201 by some other element in the label stack. Such fine grained 202 resolution may be possible by deep packet inspection, but this may 203 not always be possible, or it may be desired to minimise processing 204 costs by doing this only in entry to the network, and adding a 205 suitable identifier to the packet for reference by other network 206 elements. An example of such a fine grained case might be traffic 207 from a specific application, or from a specific application from a 208 specific source, particularly if matters related to service level 209 agreement or application performance were being investigated. 211 We can thus characterize the identification requirement in the 212 following broad terms: 214 o There needs to be some way for an egress LSR to identify the 215 ingress LSR with an appropriate degree of scope. This concept is 216 discussed further in Section 7. 218 o There needs to be a way to identify a specific LSP at the egress 219 node. This allows for the case of instrumenting multiple LSPs 220 operate between the same pair of nodes. In such cases the 221 identity of the ingress LSR is insufficient. 223 o In order to conserve resources such as labels, counters and/or 224 compute cycles it may be desirable to identify an LSP group so 225 that a operation can be performed on the group as an aggregate. 227 o There needs to be a way to identify a flow within an LSP. This is 228 necessary when investigating a specific flow that has been 229 aggregated into an LSP. 231 The unit of identification and the method of determining which 232 packets constitute a flow will be application or use-case specific 233 and is out of scope of this memo. 235 6. Types of LSP 237 We need to consider a number of types of LSP. The two simplest types 238 to monitor are point to point LSPs and point to multi-point LSPs. 239 The ingress LSR for a point to point LSP, such as those created using 240 the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 241 [RFC5420] signalling protocol, or those that conform to the MPLS 242 Transport Profile (MPLS-TP) [RFC5654] may be identified by inspection 243 of the top label in the stack, since at any provider-edge (PE) or 244 provider (P) router on the path this is unique to the ingress-egress 245 pair at every hop at a given layer in the LSP hierarchy. Provided 246 that penultimate hop popping is disabled, the identity of the ingress 247 LSR of a point to point LSP is available at the egress LSR and thus 248 determining the identity of the ingress LSR must be regarded as a 249 solved problem. Note however that the identity of a flow cannot to 250 be determined without further information being carried in the 251 packet, or gleaned from some aspect of the packet payload. 253 In the case of a point to multi-point LSP, and in the absence of 254 Penultimate Hop Popping (PHP) the identity of the ingress LSR may 255 also be inferred from the top label. However, it may not possible to 256 adequately identify the flow from the top label alone, and thus 257 further information may need to be carried in the packet, or gleaned 258 from some aspect of the packet payload. In designing any solution it 259 is desirable that a common flow identity solution be used for both 260 point to point and point to multi-point LSP types. Similarly it is 261 desirable that a common method of LSP group identification be used. 262 In the above cases, a context label [RFC5331] needs to be used to 263 provide the required identity information. This is widely supported 264 MPLS feature. 266 A more interesting case is the case of a multi-point to point LSP. 267 In this case the same label is normally used by multiple ingress or 268 upstream LSRs and hence source identification is not possible by 269 inspection of the top label by the egress LSRs. It is therefore 270 necessary for a packet to be able to explicitly convey any of the 271 identity types described in Section 5. 273 Similarly, in the case of a multi-point to multi-point LSP the same 274 label is normally used by multiple ingress or upstream LSRs and hence 275 source identification is not possible by inspection of the top label 276 by egress LSRs. The various types of identity described in Section 5 277 are again needed. Note however, that the scope of the identity may 278 be constrained to be unique within the set of multi-point to multi- 279 point LSPs terminating on any common node. 281 7. Network Scope 283 The scope of identification can be constrained to the set of flows 284 that are uniquely identifiable at an ingress LSR, or some aggregation 285 thereof. There is no question of an ingress LSR seeking assistance 286 from outside the MPLS protocol domain. 288 In any solution that constrains itself to carrying the required 289 identity in the MPLS label stack rather than in some different 290 associated data structure, constraints on the label stack size imply 291 that the scope of identity reside within that MPLS domain. For 292 similar reasons the identity scope of a component of an LSP should be 293 constrained to the scope of that LSP. 295 8. Backwards Compatibility 297 In any network it is unlikely that all LSRs will have the same 298 capability to support the methods of identification discussed in this 299 memo. It is therefore an important constraint on any flow identity 300 solution that it is backwards compatible with deployed MPLS equipment 301 to the extent that deploying the new feature will not disable 302 anything that currently works on a legacy equipment. 304 This is particularly the case when the deployment is incremental or 305 when the feature is not required for all LSRs or all LSPs. Thus in 306 broad the flow identification design MUST support the co-existence of 307 both LSRs that can, and cannot, identify the traffic components 308 described in Section 5. In addition the identification of the 309 traffic components described in Section 5 MUST be an optional feature 310 that is disabled by default. As a design simplification, a solution 311 MAY require that all egress LSRs of a point to multipoint or a multi- 312 point to multipoint LSP support the identification type in use so 313 that a single packet can be correctly processed by all egress 314 devices. The corollary of this last point is that either all egress 315 LSRs are enabled to support the required identity type, or none of 316 them are. 318 9. Dataplane 320 There is a huge installed base of MPLS equipment, typically this type 321 of equipment remains in service for an extended period of time, and 322 in many cases hardware constraints mean that it is not possible to 323 upgrade its dataplane functionality. Changes to the MPLS data plane 324 are therefore expensive to implement, add complexity to the network, 325 and may significantly impact the deployability of a solution that 326 requires such changes. For these reasons, the MPLS designers have 327 set a very high bar to changes to the MPLS data plane, and only a 328 very small number have been adopted. Hence, it is important that the 329 method of identification must minimize changes to the MPLS data 330 plane. Ideally method(s) of identification that require no changes 331 to the MPLS data plane should be given preferential consideration. 332 If a method of identification makes a change to the data plane is 333 chosen it will need to have a significant advantage over any method 334 that makes no change, and the advantage of the approach will need to 335 be carefully evaluated and documented. If a change is necessary to 336 the MPLS data plane proves necessary, it should be (a) be as small a 337 change as possible and (b) be a general purpose method so as to 338 maximise its use for future applications. It is imperative that, as 339 far as can be foreseen, any necessary change made to the MPLS data 340 plane does not impose any foreseeable future limitation on the MPLS 341 data plane. 343 Stack size is an issue with many MPLS implementations both as a 344 result of hardware limitations, and due to the impact on networks and 345 applications where a large number of small payloads need to be 346 transported In particular one MPLS payload may be carried inside 347 another. For example one LSP may be carried over another LSP, or a 348 PW or similar multiplexing construct may be carried over an LSP and 349 identification may be required at both layers. Of particular concern 350 is the implementation of low cost edge LSRs that for cost reasons 351 have a significant limit on the number of Label Stack Elements (LSEs) 352 that they can impose or dispose. Therefore, any method of identity 353 MUST NOT consume an excessive number of unique labels, and MUST NOT 354 result in an excessive increase in the size of the label stack. 356 The MPLS data plane design provides two types of special purpose 357 labels: the original 16 reserved labels and the much larger set of 358 special purpose labels defined in [RFC7274]. The original reserved 359 labels need one LSE, and the newer [RFC7274] special purpose labels 360 need two LSEs. Given the tiny number of original reserved labels, it 361 is core to the MPLS design philosophy that this scarce resource is 362 only used when it is absolutely necessary. Using a single LSE 363 reserved or special purpose label to encode flow identity thus 364 requires two stack entries, one for the reserved label and one for 365 the flow identity. The larger set of [RFC7274] labels requires two 366 labels stack entries for the special purpose label itself and hence a 367 total of three label stack entries to encode the flow identity. 369 The use of special purpose labels (SPL) [RFC7274] as part of a method 370 to encode the identity information therefore has a number of 371 undesirable implications for the data plane and hence whilst a 372 solution may use SPL(s), methods that do not require SPLs need to be 373 carefully considered. 375 10. Control Plane 377 Any flow identity design should both seek to minimise the complexity 378 of the control plane and should minimise the amount of label co- 379 ordination needed amongst LSRs. 381 11. Privacy Considerations 383 The inclusion of originating and/or flow information in a packet 384 provides more identity information and hence potentially degrades the 385 privacy of the communication. Recent IETF concerns on pervasive 386 monitoring [RFC7258] would lead it to prefer a solution that does not 387 degrade the privacy of user traffic below that of an MPLS network not 388 implementing the flow identification feature. The minimizing the 389 scope of the identity indication can be useful in minimizing the 390 observability of the flow characteristics. 392 12. Security Considerations 394 Any solution to the flow identification needs must not degrade the 395 security of the MPLS network below that of an equivalent network not 396 deploying the specified identity solution. Propagation of 397 identification information outside the MPLS network imposing it must 398 be disabled by default. Any solution should provide for the 399 restriction of the identity information to those components of the 400 network that need to know it. It is thus desirable to limit the 401 knowledge of the identify of an endpoint to only those LSRs that need 402 to participate in traffic flow. 404 13. IANA Considerations 406 This memo has no IANA considerations. 408 14. Acknowledgements 410 The authors thank Nobo Akiya (nobo@cisco.com), Nagendra Kumar Nainar 411 (naikumar@cisco.com) and George Swallow (swallow@cisco.com) for their 412 comments. 414 15. References 416 15.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 15.2. Informative References 425 [I-D.tempia-ippm-p3m] 426 Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., 427 and A. Bonda, "A packet based method for passive 428 performance monitoring", draft-tempia-ippm-p3m-03 (work in 429 progress), March 2016. 431 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 432 Label Assignment and Context-Specific Label Space", 433 RFC 5331, DOI 10.17487/RFC5331, August 2008, 434 . 436 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 437 Ayyangarps, "Encoding of Attributes for MPLS LSP 438 Establishment Using Resource Reservation Protocol Traffic 439 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 440 February 2009, . 442 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 443 Sprecher, N., and S. Ueno, "Requirements of an MPLS 444 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 445 September 2009, . 447 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 448 Measurement for MPLS Networks", RFC 6374, 449 DOI 10.17487/RFC6374, September 2011, 450 . 452 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 453 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 454 RFC 6790, DOI 10.17487/RFC6790, November 2012, 455 . 457 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 458 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 459 2014, . 461 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 462 and Retiring Special-Purpose MPLS Labels", RFC 7274, 463 DOI 10.17487/RFC7274, June 2014, 464 . 466 Authors' Addresses 468 Stewart Bryant 469 Huawei 471 Email: stewart.bryant@gmail.com 473 Carlos Pignataro 474 Cisco Systems 476 Email: cpignata@cisco.com 478 Mach Chen 479 Huawei 481 Email: mach.chen@huawei.com 482 Zhenbin Li 483 Huawei 485 Email: lizhenbin@huawei.com 487 Gregory Mirsky 488 ZTE Corp. 490 Email: gregimirsky@gmail.com