idnits 2.17.1 draft-bryant-mpls-flow-ident-01.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 26, 2015) is 3317 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-00 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 C. Pignataro 4 Intended status: Informational Cisco Systems 5 Expires: September 27, 2015 M. Chen 6 Z. Li 7 Huawei 8 G. Mirsky 9 Ericsson 10 March 26, 2015 12 MPLS Flow Identification 13 draft-bryant-mpls-flow-ident-01 15 Abstract 17 This memo discusses the desired capabilities for MPLS flow 18 identification. The key application that needs this is in-band 19 performance monitoring of user data packets. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 27, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 58 4. Delay Measurement Considerations . . . . . . . . . . . . . . 4 59 5. Units of identification . . . . . . . . . . . . . . . . . . . 4 60 6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 63 9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 65 11. Manageability Considerations . . . . . . . . . . . . . . . . 8 66 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 67 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 16.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 16.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 OAM packets are used to designate the beginning and the end 86 of the packet group over which packet loss is being measured. Where 87 the 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. In addition, this packet performance system needs 91 to be extended to deal with different granularities of flow and to 92 address a number of the multi-point cases in which a number of 93 ingress LSRs could send to one or more destinations. 95 Improvements in link and transmission technologies mean that it may 96 be difficult to assess packet loss using active performance 97 measurement methods with synthetic traffic, due to the very low loss 98 rate in normal operation. That together with more demanding service 99 level requirements mean that network operators need to be able to 100 measure the loss of the actual user data traffic by using passive 101 performance measurement methods. Any technique deployed needs to be 102 transparent to the end user, and it needs to be assumed that they 103 will not take any active part in the measurement process. Indeed it 104 is important that any flow identification technique be invisible to 105 them and that no remnant of the identification of measurement process 106 leak into their network. 108 Additionally where there are multiple traffic sources, such as in 109 multi-point to point and multi-point to multi-point network 110 environments there needs to be a method whereby the sink can 111 distinguish between packets from the various sources, that is to say, 112 that a multi-point to multi-point measurement model needs to be 113 developed. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Loss Measurement Considerations 123 Modern networks, if not oversubscribed, normally drop very few 124 packets, thus packet loss measurement is highly sensitive to counter 125 errors. Without some form of coloring or batch marking such as that 126 proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve 127 the required accuracy in the loss measurement of customer data 128 traffic. Where accuracy better than the data link loss performance 129 of a modern optical network is required, it may be economically 130 advantageous, or even a technical requirement, to include temporal 131 marking. 133 Where this level of accuracy is required and the traffic between a 134 source-destination pair is subject to ECMP a demarcation mechanism is 135 needed to group the packets into batches. Once a batch is correlated 136 at both ingress and egress, the packet accounting mechanism is then 137 able to operate on the batch of packets which can be accounted for at 138 both the packet ingress and the packet egress. Errors in the 139 accounting are particularly acute in LSPs subjected to ECMP because 140 the network transit time will be different for the various ECMP paths 141 since: 143 a. The packets may traverse different sets of LSRs. 145 b. The packets may depart from different interfaces on different 146 line cards on LSRs 148 c. The packets may arrive at different interfaces on different line 149 cards on LSRs. 151 A consideration in modifying the identity label (the MPLS label 152 ordinarily used to identify the LSP, Virtual Private Network, 153 Pseudowire etc) to indicate the batch is the impact that this has on 154 the path chosen by the ECMP mechanism. When the member of the ECMP 155 path set is chosen by deep packet inspection a change of batch 156 represented by a change of identity label will have no impact on the 157 ECMP path. Where the path member is chosen by reference to an 158 entropy label [RFC6790] then provided that the entropy label is 159 higher in the stack than the label that is changing the batch 160 identifier again there will be no change to the chosen ECMP path. 161 ECMP is so pervasive in multi-point to (multi-) point networks that 162 some method of avoiding accounting errors introduced by ECMP needs to 163 be supported. 165 4. Delay Measurement Considerations 167 Most of the existing delay measurement methods are active measurement 168 that depend on the extra injected test packet to evaluate the delay 169 of a path. With the active measurement method, the rate, numbers and 170 interval between the injected packets may affect the accuracy of the 171 results. Also, for injected test packets, these may not be co-routed 172 with the data traffic due to ECMP. Thus there exists a requirements 173 to measure the delay of the real traffic. For loss delay, the 174 identity considerations described in Section 3 also apply. 176 5. Units of identification 178 The most basic unit of identification is the identity of the node 179 processed the packet on its entry to the MPLS network. However, the 180 required unit of identification may vary depending on the use case 181 for accounting, performance measurement or other types of packet 182 observations. In particular note that there mat be a need to impose 183 identify at several different layers of the MPLS label stack. 185 This document considers following units of identifications: 187 o Per source LSR - everything from one source is aggregated. 189 o Per group of LSPs chosen by an ingress LSR - an ingress LSP 190 aggregates group of LSPs (ex: all LSPs of a tunnel). 192 o Per LSP - the basic form. 194 o Per flow [RFC6790] within an LSP - fine graining method. 196 Note that a finer grained identity resolution is needed when there is 197 a need to perform these operations on a flow not readily identified 198 by some other element in the label stack. Such fine grained 199 resolution may be possible by deep packet inspection, but this may 200 not always be possible, or it may be desired to minimise processing 201 costs by doing only in entry to the network, and adding a suitable 202 identifier to the packet for reference by other network elements. An 203 example of such a fine grained case might be traffic from a specific 204 application, or from a specific application from a specific source, 205 particularly if matters related to service level agreement or 206 application performance were being investigated. 208 We can thus characterize the identification requirement in the 209 following broad terms: 211 o There needs to be some way for an egress LSR to identify the 212 ingress LSR with an appropriate degree of scope. This concept is 213 discussed further in Section 7. 215 o There needs to be a way to identify a specific LSP at the egress 216 node. This allows for the case of instrumenting multiple LSPs 217 operate between the same pair of nodes. In such cases the 218 identity of the ingress LSR is insufficient. 220 o In order to conserve resources such as labels, counters and/or 221 compute cycles it may be desirable to identify an LSP group so 222 that a operation can be performed on the group as an aggregate. 224 o There needs to be a way to identify a flow within an LSP. This is 225 necessary when investigating a specific flow that has been 226 aggregated into an LSP. 228 The unit of identification and the method of determining which 229 packets constitute a flow will be application or use-case specific 230 and is out of scope of this memo. 232 6. Types of LSP 234 We need to consider a number of types of LSP. The two simplest types 235 to monitor are point to point LSPs and point to multi-point LSPs. 236 The ingress LSR for a point to point LSP, such as those created using 237 the RSVP-TE signalling protocol, or those that conform to the MPLS-TP 238 may be identified by inspection of the top label in the stack, since 239 at any PE or P router on the path this is unique to the ingress- 240 egress pair at every hop at a given layer in the LSP hierarchy. 241 Provided that penultimate hop popping is disabled, the identity of 242 the ingress LSR of a point to point LSP is available at the egress 243 LSR and thus determining the identity of the ingress LSR must be 244 regarded as a solved problem. Note however that the identity of a 245 flow cannot to be determined without further information. 247 In the case of a point to multi-point LSP the identity of the ingress 248 LSR may also be inferred from the top label. [Editor's note - there 249 was discussion of the following sentence amongst the authors and this 250 needs to be looked at in the next version]. However, it may not 251 possible to adequately from the top label alone. In designing any 252 solution it is desirable that a common flow identity solution be used 253 for both point to point and point to multi-point LSP types. 254 Similarly it is desirable that a common method of LSP group 255 identification be used. 257 [Editor's note: The following text was in -00, and a review comment 258 asks why. At the time of editing I cannot remember the context. If 259 the original authors cannot remember why by the next version, it will 260 be deleted] In the above cases, an explicit non-null label is needed 261 to provide context at the egress LSR. This is widely supported MPLS 262 feature. 264 A more interesting case, and the core purpose of this memo, is the 265 case of a multi-point to point LSP. In this case the same label is 266 normally used by multiple ingress or upstream LSRs and hence source 267 identification is not possible by inspection of the top label by 268 egress LSRs. It is therefore necessary for a packet to be able to 269 explicitly convey any of the identity types described in Section 5. 271 Similarly, in the case of a multi-point to multi-point LSP the same 272 label is normally used by multiple ingress or upstream LSRs and hence 273 source identification is not possible by inspection of the top label 274 by egress LSRs. The various types of identity described in Section 5 275 are again needed. Note however, that the scope of the identity may 276 be constrained to be unique within the set of multi-point to multi- 277 point LSPs terminating on any common node. 279 7. Network Scope 281 The scope of identification can be constrained to the set of flows 282 that are uniquely identifiable at an ingress LSR, or some aggregation 283 thereof. There is no question of an ingress LSR seeking assistance 284 from outside the MPLS protocol domain. 286 In any solution that constrains itself to carrying the required 287 identity in the MPLS label stack rather than in some different 288 associated data structure, constraints on the label stack size imply 289 that the scope of identity reside within that MPLS domain. For 290 similar reasons the identity scope of a component of an LSP should be 291 constrained to the scope of that LSP. 293 8. Backwards Compatibility 295 In any network it is unlikely that all LSRs will have the same 296 capability to support the methods of identification discussed in this 297 memo. It is therefore an important constraint on any identity 298 solution that it is backwards compatible with deployed MPLS equipment 299 to the extent that deploying the new feature will not disable 300 anything that currently works on a legacy equipment. 302 This is particularly the case when the deployment is incremental or 303 when the feature is not required for all LSRs or all LSPs. Thus in 304 broad the flow identification design MUST support the co-existence of 305 LSRs that can and cannot identify the traffic components described in 306 Section 5. In addition the identification of the traffic components 307 described in Section 5 MUST be an optional feature that is disabled 308 by default. As a design simplification, a solution MAY require that 309 all egress LSRs of a point to multipoint or a multi-point to 310 multipoint LSP support the identification type in use so that a 311 single packet can be correctly processed by all egress devices. The 312 corollary of this last point is that either all egress LSRs are 313 enabled to support the required identity type, or none of them are. 315 9. Dataplane 317 There is a huge installed base of MPLS equipment, typically this type 318 of equipment remains in service for an extended period of time, and 319 in many cases hardware constraints mean that it is not possible to 320 upgrade its dataplane functionality. Changes to the MPLS data plane 321 are therefore expensive to implement, add complexity to the network, 322 and may significantly impact the deployability of a solution that 323 requires such changes. For these reasons, the MPLS designers have 324 set a very high bar to changes to the MPLS data plane, and only a 325 very small number have been adopted. Hence, it is important that the 326 method of identification must minimize changes to the MPLS data 327 plane. Ideally method(s) of identification that require no changes 328 to the MPLS data plane should be given preferential consideration. 329 If a method of identification makes a change to the data plane is 330 chosen it will need to have a significant advantage over any method 331 that makes no change, and the advantage of the approach will need to 332 be carefully evaluated and documented. If a change is necessary to 333 the MPLS data plane proves necessary, it should be (a) be as small a 334 change as possible and (b) be a general purpose method so as to 335 maximise its use for future applications. It is imperative that, as 336 far as can be foreseen, any necessary change made to the MPLS data 337 plane does not impose any foreseeable future limitation on the MPLS 338 data plane. 340 Stack size is an issue with many MPLS implementations both as a 341 result of hardware limitations, and due to the impact on networks and 342 applications where a large number of small payloads need to be 343 transported In particular one MPLS payload may be carried inside 344 another. For example one LSP may be carried over another LSP, or a 345 PW or similar multiplexing construct may be carried over an LSP and 346 identification may be required at both layers. Of particular concern 347 is the implementation of low cost edge LSRs that for cost reasons 348 have a significant limit on the number of Label Stack Elements (LSEs) 349 that they can impose or dispose. Therefore, any method of identity 350 MUST NOT consume an excessive number of unique labels, and MUST NOT 351 result in an excessive increase in the size of the label stack. 353 The MPLS data plane design provides two types of special purpose 354 labels: the original 16 reserved labels and the much larger set of 355 special purpose labels defined in [RFC7274]. The original reserved 356 labels need one LSE, and the newer [RFC7274] special purpose labels 357 need two LSEs. Given the tiny number of original reserved labels, it 358 is core to the MPLS design philosophy that this scarce resource is 359 only used when it is absolutely necessary. Using a single LSE 360 reserved or special purpose label to encode flow identity thus 361 requires two stack entries, one for the reserved label and one for 362 the flow identity. The larger set of [RFC7274] labels requires two 363 labels stack entries for the special purpose label itself and hence a 364 total of three label stack entries to encode the flow identity. 366 The use of special purpose labels (SPL) [RFC7274]as part of a method 367 to encode the identity information therefore has a number of 368 undesirable implications for the data plane and hence whilst a 369 solution may use SPL(s), methods that do not require SPLs need to be 370 carefully considered. 372 10. Control Plane 374 Any flow identity design should both seek to minimise the complexity 375 of the control plane and should minimise the amount of label co- 376 ordination needed amongst LSRs. 378 11. Manageability Considerations 380 This will be provided in a future version of this document. 382 12. Privacy Considerations 384 The inclusion of originating and/or flow information in a packet 385 provides more identity information and hence potentially degrades the 386 privacy of the communication. Recent IETF concerns on pervasive 387 monitoring would lead it to prefer a solution that does not degrade 388 the privacy of user traffic below that of an MPLS network not 389 implementing the flow identification feature. The minimizing the 390 scope of the identity indication can be useful in minimizing the 391 observability of the flow characteristics. 393 13. Security Considerations 395 Any solution to the flow identification needs must not degrade the 396 security of the MPLS network below that of an equivalent network not 397 deploying the specified identity solution. Propagation of 398 identification information outside the MPLS network imposing it must 399 be disabled by default. Any solution should provide for the 400 restriction of the identity information to those components of the 401 network that need to know it. It is thus desirable to limit the 402 knowledge of the identify of an endpoint to only those LSRs that need 403 to participate in traffic flow. 405 14. IANA Considerations 407 EDITOR'S NOTE: This section may be removed on publication 409 This memo has no IANA considerations. 411 15. Acknowledgements 413 The authors thank Nobo Akiya (nobo@cisco.com), Nagendra Kumar Nainar 414 (naikumar@cisco.com) and George Swallow (swallow@cisco.com) for their 415 comments. 417 16. References 419 16.1. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 16.2. Informative References 426 [I-D.tempia-ippm-p3m] 427 Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., 428 and A. Bonda, "A packet based method for passive 429 performance monitoring", draft-tempia-ippm-p3m-00 (work in 430 progress), March 2015. 432 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 433 Measurement for MPLS Networks", RFC 6374, September 2011. 435 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 436 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 437 RFC 6790, November 2012. 439 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 440 and Retiring Special-Purpose MPLS Labels", RFC 7274, June 441 2014. 443 Authors' Addresses 445 Stewart Bryant 446 Cisco Systems 448 Email: stbryant@cisco.com 450 Carlos Pignataro 451 Cisco Systems 453 Email: cpignata@cisco.com 455 Mach Chen 456 Huawei 458 Email: mach.chen@huawei.com 460 Zhenbin Li 461 Huawei 463 Email: lizhenbin@huawei.com 465 Gregory Mirsky 466 Ericsson 468 Email: gregory.mirsky@ericsson.com