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