Internet Engineering Task Force (IETF) S. Bryant Request for Comments: 8372 Huawei Category: Informational C. Pignataro ISSN: 2070-1721 Cisco M. Chen Z. Li Huawei G. Mirsky ZTE Corp. May 2018 MPLS Flow Identification Considerations
AbstractThis document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8372.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 3. Delay Measurement Considerations . . . . . . . . . . . . . . 4 4. Units of Identification . . . . . . . . . . . . . . . . . . . 4 5. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 8. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. Informative References . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 RFC6374]. When used to measure packet loss, [RFC6374] depends on the use of injected Operations, Administration, and Maintenance (OAM) packets to designate the beginning and the end of the packet group over which packet loss is being measured. If the misordering of packets from one group relative to the following group
or the misordering of any of the packets being counted relative to the Loss Measurement packet [RFC6374] occurs, then an error will occur in the packet loss measurement. In addition, [RFC6374] did not support different granularities of flow or address a number of multipoint cases in which two or more ingress Label Switching Routers (LSRs) could send packets to one or more destinations. Due to the very low loss rate in normal operation, improvements in link and transmission technologies have made it more difficult to assess packet loss using active performance measurement methods with synthetic traffic. That, together with more demanding service-level requirements, means that network operators now need to be able to measure the loss of the actual user data traffic using passive performance measurement methods. Any technique deployed needs to be transparent to the end user, and it needs to be assumed that they will not take any active part in the measurement process. Indeed, it is important that any flow identification technique be invisible to them and that no remnant of the measurement process leaks into their network. Additionally, when there are multiple traffic sources, such as in multipoint-to-point and multipoint-to-multipoint network environments, there needs to be a method whereby the sink can distinguish between packets from the various sources; that is to say, a multipoint measurement model needs to be developed. RFC8321], it may not be possible to achieve the required accuracy in the loss measurement of customer data traffic. Thus, when accurate measurement of packet loss is required, it may be economically advantageous, or even be a technical requirement, to include some form of marking in the packets to assign each packet to a particular counter for loss measurement purposes. When this level of accuracy is required and the traffic between a source-destination pair is subject to Equal-Cost Multipath (ECMP), a demarcation mechanism is needed to group the packets into batches. Once a batch is correlated at both ingress and egress, the packet accounting mechanism is then able to operate on the batch of packets that can be accounted for at both the packet ingress and the packet
egress. Errors in the accounting are particularly acute in Label Switched Paths (LSPs) subjected to ECMP because the network transit time will be different for the various ECMP paths since: 1. the packets may traverse different sets of LSRs; 2. the packets may depart from different interfaces on different line cards on LSRs; and 3. the packets may arrive at different interfaces on different line cards on LSRs. A consideration with this solution on modifying the identity label (the MPLS label ordinarily used to identify the LSP, Virtual Private Network, Pseudowire, etc.) to indicate the batch is the impact that this has on the path chosen by the ECMP mechanism. When the member of the ECMP path set is chosen by deep packet inspection, a change of batch represented by a change of identity label will have no impact on the ECMP path. If the path member is chosen by reference to an entropy label [RFC6790], then changing the batch identifier will not result in a change to the chosen ECMP path. ECMP is so pervasive in multipoint-to-(multi)point networks that some method of avoiding accounting errors introduced by ECMP needs to be supported.
This document considers the identification of the following traffic components: o Per source LSR: everything from one source is aggregated o Per group of LSPs chosen by an ingress LSR: an ingress LSP aggregates a group of LSPs (e.g., all the LSPs of a tunnel) o Per LSP: the basic form o Per flow [RFC6790] within an LSP: a fine-grained method Note that a fine-grained identity resolution is needed when there is a need to perform these operations on a flow not readily identified by some other element in the label stack. Such a fine-grained resolution may be possible by deep packet inspection. However, this may not always be possible, or it may be desired to minimize processing costs by doing this only on entry to the network. Adding a suitable identifier to the packet for reference by other network elements minimizes the processing needed by other network elements. An example of such a fine-grained case might be traffic belonging to a certain service or from a specific source, particularly if matters related to service level agreement or application performance were being investigated. We can thus characterize the identification requirement in the following broad terms: o There needs to be some way for an egress LSR to identify the ingress LSR with an appropriate degree of scope. This concept is discussed further in Section 6. o There needs to be a way to identify a specific LSP at the egress node. This allows for the case of instrumenting multiple LSPs operating between the same pair of nodes. In such cases, the identity of the ingress LSR is insufficient. o In order to conserve resources such as labels, counters, and/or compute cycles, it may be desirable to identify an LSP group so that an operation can be performed on the group as an aggregate. o There needs to be a way to identify a flow within an LSP. This is necessary when investigating a specific flow that has been aggregated into an LSP. The unit of identification and the method of determining which packets constitute a flow will be specific to the application or use case and are out of scope of this document.
RFC5420] signaling protocol or those that conform to the MPLS Transport Profile (MPLS-TP) [RFC5654], may be identified by inspection of the top label in the stack because, at any provider- edge (PE) or provider (P) router on the path, the top label is unique to the ingress-egress pair at every hop at a given layer in the LSP hierarchy. Provided that Penultimate Hop Popping (PHP) is disabled, the identity of the ingress LSR of a point-to-point LSP is available at the egress LSR; thus, determining the identity of the ingress LSR must be regarded as a solved problem. Note, however, that the identity of a flow cannot to be determined without further information being carried in the packet or gleaned from some aspect of the packet payload. In the case of a point-to-multipoint LSP, and in the absence of PHP, the identity of the ingress LSR may also be inferred from the top label. However, it may not possible to adequately identify the flow from the top label alone; thus, further information may need to be carried in the packet or gleaned from some aspect of the packet payload. In designing any solution, it is desirable that a common flow identification solution be used for both point-to-point and point-to-multipoint LSP types. Similarly, it is desirable that a common method of LSP group identification be used. In the above cases, a context label [RFC5331] needs to be used to provide the required identity information. This is a widely supported MPLS feature. A more interesting case is the case of a multipoint-to-point LSP. In this case, the same label is normally used by multiple ingress or upstream LSRs; hence, source identification is not possible by inspection of the top label by the egress LSRs. It is therefore necessary for a packet to be able to explicitly convey any of the identity types described in Section 4. Similarly, in the case of a multipoint-to-multipoint LSP, the same label is normally used by multiple ingress or upstream LSRs; hence, source identification is not possible by inspection of the top label by egress LSRs. The various identity types described in Section 4 are again needed. Note, however, that the scope of the identity may be constrained to be unique within the set of multipoint-to- multipoint LSPs terminating on any common node.
Section 4 and those that cannot. In addition, the identification of the traffic components described in Section 4 must be an optional feature that is disabled by default. As a design simplification, a solution may require that all egress LSRs of a point-to-multipoint or a multipoint-to- multipoint LSP support the identification type in use so that a single packet can be correctly processed by all egress devices. The corollary of this last point is that either all egress LSRs are enabled to support the required identity type or none of them are.
plane. Ideally, method(s) of identification that require no changes to the MPLS data plane should be given preferential consideration. If a method of identification that makes a change to the data plane is chosen, it will need to have a significant advantage over any method that makes no change, and the advantage of the approach will need to be carefully evaluated and documented. If a change to the MPLS data plane proves necessary, it should be (a) as small a change as possible and (b) a general-purpose method, so as to maximize its use for future applications. It is imperative that, as far as can be foreseen, any necessary change made to the MPLS data plane does not impose any foreseeable future limitation on the MPLS data plane. Stack size is an issue with many MPLS implementations both as a result of hardware limitations and due to the impact on networks and applications in which a large number of small payloads need to be transported. In particular, one MPLS payload may be carried inside another. For example, one LSP may be carried over another LSP, or a Pseudowire (PW) or similar multiplexing construct may be carried over an LSP, and identification may be required at both layers. Of particular concern is the implementation of low-cost edge LSRs that, for cost reasons, have a significant limit on the number of Label Stack Entries (LSEs) that they can impose or dispose. Therefore, any method of identity must not consume an excessive number of unique labels and must not result in an excessive increase in the size of the label stack. The design of the MPLS data plane provides two types of special- purpose labels: the original 16 reserved labels and the much larger set of special-purpose labels defined in [RFC7274]. The original reserved labels need one LSE, and the newer special-purpose labels [RFC7274] need two LSEs. Given the tiny number of original reserved labels, it is core to the MPLS design philosophy that this scarce resource is only used when it is absolutely necessary. Using a special-purpose label to encode flow identity requires two label stack entries, one for the reserved label and one for the flow identity. Use of extended special-purpose labels [RFC7274] requires a total of three label stack entries to encode the flow identity. The larger set of [RFC7274] labels requires two label stack entries for the special-purpose label itself; hence, a total of three label stack entries is needed to encode the flow identity. The use of special-purpose labels [RFC7274] as part of a method to encode the identity information therefore has a number of undesirable implications for the data plane. Thus, while a solution may use special-purpose labels, methods that do not require special-purpose labels need to be carefully considered.
RFC7258] have resulted in a preference for a solution that does not degrade the privacy of user traffic below that of an MPLS network not implementing the flow identification feature. The choice of using MPLS technology for this OAM solution has a privacy advantage, as the choice of the label identifying a flow is limited to the scope of the MPLS domain and does not have any dependency on the identification of the user data. This minimizes the observability of the flow characteristics. RFC5920].
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <https://www.rfc-editor.org/info/rfc5420>. [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>. [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>. [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>. [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.