idnits 2.17.1 draft-bryant-mpls-flow-ident-00.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 (October 24, 2014) is 3444 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 371, but no explicit reference was found in the text 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: April 27, 2015 October 24, 2014 7 MPLS Flow Identification 8 draft-bryant-mpls-flow-ident-00 10 Abstract 12 This memo discusses the desired capabilities for MPLS flow 13 identification. The key application that needs this is in-band 14 performance monitoring of user data packets. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 27, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 52 3. Units of identification . . . . . . . . . . . . . . . . . . . 3 53 4. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 55 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6 56 7. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 58 9. Manageability Considerations . . . . . . . . . . . . . . . . 8 59 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 60 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 63 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 14.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 14.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 This memo discusses the desired capabilities for MPLS flow 71 identification. The key application that needs this is in-band 72 performance monitoring of user data packets. 74 There is a need to identify flows in MPLS networks for applications 75 such as packet loss and packet delay measurement. A method of loss 76 and delay measurement in MPLS networks was defined in [RFC6374]. 77 However this work needs to be extended to deal with different 78 granularities of flow and to address a number of the multi-point 79 cases in which a number of ingress LSRs could send to one or more 80 destinations. 82 Improvements in link and transmission technologies mean that it is 83 difficult to assess a loss using synthetic traffic due to the very 84 low loss rate in normal operation. That together with more demanding 85 service level requirements mean that network operators need to be 86 able to measure the loss of the actual user data traffic. Any 87 technique deployed needs to be transparent to the end user, and it 88 needs to be assumed that they will not take any active part in the 89 measurement process. Indeed it is important that any flow 90 identification technique be invisible to them and that no remnant of 91 the identification of measurement process leak into their network. 93 2. Loss Measurement Considerations 95 Modern networks normally drop very few packets, thus packet loss 96 measurement are highly sensitive to counter errors. Without some 97 form of coloring or batch marking such as that proposed in 98 [I-D.tempia-opsawg-p3m] it may not be possible to achieve the 99 required accuracy in the loss measurement of customer data traffic. 100 Where accuracy better than the data link loss performance of a modern 101 optical network is required it may be economically advantage to 102 include temporal marking. 104 Where this level of accuracy is required and the traffic between a 105 source-destination pair is subject to ECMP a demarcation mechanism is 106 needed to group the packets into batches. The packet accounting 107 mechanism is then able to operate on a batch of packets which can be 108 accounted for at both the packet ingress and the packet egress. 109 Errors in the accounting are particularly acute in LSPs subjected to 110 ECMP because the network transit time will be different for the 111 various ECMP paths since: 113 a. The packets may traverse different sets of LSRs. 115 b. The packets may depart from different interfaces on different 116 line cards on LSRs 118 c. The packets may arrive at different interfaces on different line 119 cards on LSRs. 121 A consideration in modifying the identity label to indicate the batch 122 is the impact that this has on the path chosen by the ECMP mechanism. 123 When the member of the ECMP path set is chosen by deep packet 124 inspection a change of colour represented by a change of identity 125 label will have no impact on the ECMP path. Where the path member is 126 chosen by reference to an entropy label [RFC6790] then provided that 127 the entropy label is higher in the stack than the label that is 128 changing colour again there will be no change to the chosen ECMP 129 path. ECMP is so pervasive in multi-point to (multi-) point networks 130 that some method of avoiding accounting errors introduced by ECMP 131 needs to be supported. 133 3. Units of identification 135 The most basic unit of identification is the identity of the node 136 processed the packet on its entry to the MPLS network. However, the 137 required unit of identification may vary depending on the use case 138 for accounting, performance measurement or other types of packet 139 observations. In particular note that there mat be a need to impose 140 identify at several different layers of the MPLS label stack. 142 This document considers follow unit of identifications: 144 o Per source LSR - everything from one source is aggregated. 146 o Per group of LSPs chosen by an ingress LSR - an ingress LSP 147 aggregates group of LSPs (ex: all LSPs of a tunnel). 149 o Per LSP - the basic form. 151 o Per flow [RFC6790] within an LSP - fine graining method. 153 Note that a finer grained identity resolution is needed when there is 154 a need to perform these operations on a flow not readily identified 155 by some other element in the label stack. Such fine grained 156 resolution may be possible by deep packet inspection, but this may 157 not always be possible, or it may be desired to minimise processing 158 costs by doing only in entry to the network, and adding a suitable 159 identifier to the packet for reference by other network elements. An 160 example of such a fine grained case might be traffic from a specific 161 application, or from a specific application from a specific source, 162 particularly if matters related to service level agreement or 163 application performance were being investigated. 165 We can thus characterize the identification requirement in the 166 following broad terms: 168 o There needs to be some way for an egress LSR to identify the 169 ingress LSR with an appropriate degree of scope. This concept is 170 discussed further in Section 5. 172 o There needs to be a way to identify a specific LSP at the egress 173 node. This allows for the case of instrumenting multiple LSPs 174 operate between the same pair of nodes. In such cases the 175 identity of the ingress LSR is insufficient. 177 o In order to conserve resources such as labels, counters and/or 178 compute cycles it may be desirable to identify an LSP group so 179 that a operation can be performed on the group as an aggregate. 181 o There needs to be a way to identify a flow within an LSP. This is 182 necessary when investigating a specific flow that has been 183 aggregated into an LSP. 185 The method of determining which packets constitute a flow is outside 186 the scope of this memo. 188 4. Types of LSP 190 We need to consider a number of types of LSP. The two simplest types 191 to monitor are point to point LSPs and point to multi-point LSPs. 192 The ingress LSR for a point to point LSP, such as those created using 193 the RSVP-TE signalling protocol, or those that conform to the MPLS-TP 194 may be identified by inspection of the top label in the stack, since 195 at any PE or P router on the path this is unique to the ingress- 196 egress pair at every hop at a given layer in the LSP hierarchy. 197 Provided that penultimate hop popping is disabled, the identity of 198 the ingress LSR of a point to point LSP is available at the egress 199 LSR and thus determining the identity of the ingress LSR must be 200 regarded as a solved problem. Note however that the identity of a 201 flow cannot to be determined without further information. 203 In the case of a point to multi-point LSP the identity of the ingress 204 LSR may also be inferred from the top label. However it is not 205 possible to identify a flow from the top label, nor is it possible to 206 directly identify the ingress LSR since there may be many point to 207 multi-point LSP originating at that LSR. In designing any solution 208 it is desirable that a common flow identity solution be used for both 209 point to point and point to multi-point LSP types. Similarly it is 210 desirable that a common method of LSP group identification be used. 212 In the above cases, an explicit non-null label is needed to provide 213 context at the egress LSR. This is widely supported MPLS feature. 215 A more interesting case, and the core purpose of this memo, is the 216 case of a multi-point to point LSP. In this case the same label is 217 normally used by multiple ingress or upstream LSRs and hence source 218 identification is not possible by inspection of the top label by 219 egress LSRs. It is therefore necessary for a packet to be able to 220 explicitly convey any of the identity types described in Section 3. 222 Similarly, in the case of a multi-point to multi-point LSP the same 223 label is normally used by multiple ingress or upstream LSRs and hence 224 source identification is not possible by inspection of the top label 225 by egress LSRs. The various types of identity described in Section 3 226 are again needed. Note however, that the scope of the identity may 227 be constrained to be unique within the set of multi-point to multi- 228 point LSPs terminating on any common node. 230 Any method of identity must not consume an excessive number of unique 231 labels, nor result in an excessive increase in the size of the label 232 stack (Section 7). 234 5. Network Scope 236 The scope of identification can be constrained to the set of flows 237 that are uniquely identifiable at an ingress LSR, or some aggregation 238 thereof. There is no question of an ingress LSR seeking assistance 239 from outside the MPLS domain. 241 In any solution that constrains itself to carrying the required 242 identity in the MPLS label stack rather than in some different 243 associated data structure, constraints on the label stack size imply 244 that the scope of identity reside within that MPLS domain. For 245 similar reasons the identity scope of a component of an LSP should be 246 constrained to the scope of that LSP. 248 6. Backwards Compatibility 250 In any network it is unlikely that all LSRs will have the same 251 capability to support the methods of identification discussed in this 252 memo. It is therefore an important constraint on any identity 253 solution that it is backwards compatible with deployed MPLS equipment 254 to the extent that deploying the new feature will not disable 255 anything that currently works on a legacy equipment. 257 This is particularly the case when the deployment is incremental or 258 when the feature is not required for all LSRs or all LSPs. Thus in 259 broad the flow identification design must support the co-existence of 260 LSRs that can and cannot identify the traffic components described in 261 . (Section 3). In addition the identification of the traffic 262 components described in Section 3 needs to be an optional feature 263 that is disabled by default. As a design simplification, a solution 264 may require that all egress LSRs of a point to multipoint or a multi- 265 point to multipoint LSP to support the identification type in use so 266 that a single packet can be correctly processed by all egress 267 devices. The corollary of this last point is that either all egress 268 LSRs are enabled to support the required identity type, or none of 269 them are. 271 7. Dataplane 273 There is a huge installed base of MPLS equipment, typically this type 274 of equipment remains in service for an extended period of time, and 275 in many cases hardware constraints mean that it is not possible to 276 upgrade its dataplane functionality. Changes to the MPLS data plane 277 are therefore expensive to implement, add complexity to the network, 278 and may significantly impact the deployability of a solution that 279 requires such changes. For these reasons, the MPLS designers have 280 set a very high bar to changes to the MPLS data plane, and only a 281 very small number have been adopted. Hence, it is important that the 282 method of identification must minimize changes to the MPLS data 283 plane. Ideally method(s) of identification that require no changes 284 to the MPLS data plane should be given preferential consideration. 285 If a method of identification makes a change to the data plane is 286 chosen it will need to have a significant advantage over any method 287 that makes no change, and the advantage of the approach will need to 288 be carefully evaluated and documented. If a change is necessary to 289 the MPLS data plane proves necessary, it should be (a) be as small a 290 change as possible and (b) be a general purpose method so as to 291 maximise its use for future applications. It is imperative that, as 292 far as can be foreseen, any necessary change made to the MPLS data 293 plane does not impose any foreseeable future limitation on the MPLS 294 data plane. 296 Stack size is an issue with many MPLS implementations both as a 297 result of hardware limitations, and due to the impact on networks and 298 applications where a large number of small payloads need to be 299 transported In particular one MPLS payload may be carried inside 300 another. For example one LSP may be carried over another LSP, or a 301 PW or similar multiplexing construct may be carried over an LSP and 302 identification may be required at both layers. Of particular concern 303 is the implementation of low cost edge LSRs that for cost reasons 304 have a significant limit on the number of LSEs that they can impose 305 or dispose. 307 The MPLS data plane design provides only a tiny number of reserved 308 labels, it is therefore core to the MPLS design philosophy that this 309 scarce resource is only used when it is absolutely necessary. Using 310 a single LSE reserved or special purpose label to encode flow 311 identity thus requires two stack entries. A larger special purpose 312 labels space is available [RFC7274] but this requires two labels 313 stack entries for the reserved label itself and hence a total of 314 three label stack entries to encode the flow identity. 316 The use of special purpose labels (SPL) [RFC7274]as part of a method 317 to encode the identity information therefore has a number of 318 undesirable implications for the data plane and hence whilst a 319 solution may use SPL(s), methods that do not require SPLs need to be 320 carefully considered. 322 8. Control Plane 324 Any flow identity design should both seek to minimise the complexity 325 of the control plane and should minimise the amount of label co- 326 ordination needed amongst LSRs. 328 9. Manageability Considerations 330 This will be provided in a future version of this document. 332 10. Privacy Considerations 334 The inclusion of originating and/or flow information in a packet 335 provides more identity information and hence potentially degrades the 336 privacy of the communication. Recent IETF concerns on pervasive 337 monitoring would lead it to prefer a solution that does not degrade 338 the privacy of user traffic below that of an MPLS network not 339 implementing the flow identification feature. The minimizing the 340 scope of the identity indication can be useful in minimizing the 341 observability of the flow characteristics. 343 11. Security Considerations 345 Any solution to the flow identification needs must not degrade the 346 security of the MPLS network below that of an equivalent network not 347 deploying the specified identity solution. Propagation of 348 identification information outside the MPLS network imposing it must 349 be disabled by default. Any solution should provide for the 350 restriction of the identity information to those components of the 351 network that need to know it. It is thus desirable to limit the 352 knowledge of the identify of an endpoint to only those LSRs that need 353 to participate in traffic flow. 355 12. IANA Considerations 357 EDITOR'S NOTE: This section may be removed on publication 359 This memo has no IANA considerations. 361 13. Acknowledgements 363 The authors thank Nobo Akiya (nobo@cisco.com), Nagendra Kumar Nainar 364 (naikumar@cisco.com) and George Swallow (swallow@cisco.com) for their 365 comments. 367 14. References 369 14.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 14.2. Informative References 376 [I-D.tempia-opsawg-p3m] 377 Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, 378 "A packet based method for passive performance 379 monitoring", draft-tempia-opsawg-p3m-04 (work in 380 progress), February 2014. 382 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 383 Measurement for MPLS Networks", RFC 6374, September 2011. 385 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 386 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 387 RFC 6790, November 2012. 389 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 390 and Retiring Special-Purpose MPLS Labels", RFC 7274, June 391 2014. 393 Authors' Addresses 395 Stewart Bryant 396 Cisco Systems 398 Email: stbryant@cisco.com 400 Carlos Pignataro 401 Cisco Systems 403 Email: cpignata@cisco.com