--- 1/draft-ietf-mpls-flow-ident-03.txt 2017-02-24 12:13:10.419540292 -0800 +++ 2/draft-ietf-mpls-flow-ident-04.txt 2017-02-24 12:13:10.443540854 -0800 @@ -1,47 +1,48 @@ MPLS Working Group S. Bryant Internet-Draft Huawei Intended status: Informational C. Pignataro -Expires: July 27, 2017 Cisco Systems +Expires: August 28, 2017 Cisco Systems M. Chen Z. Li Huawei G. Mirsky ZTE Corp. - January 23, 2017 + February 24, 2017 MPLS Flow Identification Considerations - draft-ietf-mpls-flow-ident-03 + draft-ietf-mpls-flow-ident-04 Abstract - This memo discusses the desired capabilities for MPLS flow - identification. The key application that needs this is in-band - performance monitoring of user data packets. + This memo discusses the aspects that must be considered when + developing a solution for MPLS flow identification. The key + application that needs this is in-band performance monitoring of user + data packets. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 27, 2017. + This Internet-Draft will expire on August 28, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -51,51 +52,53 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 4. Delay Measurement Considerations . . . . . . . . . . . . . . 4 5. Units of identification . . . . . . . . . . . . . . . . . . . 4 - 6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5 - 7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 - 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 + 10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 + 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 15.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 15.2. Informative References . . . . . . . . . . . . . . . . . 9 + 15.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction - This memo discusses the desired capabilities for MPLS flow - identification. The key application that needs this is in-band - performance monitoring of user data packets. + This memo discusses the aspects that must be considered when + developing a solution for MPLS flow identification. The key + application that needs this is in-band performance monitoring of user + data packets. There is a need to identify flows in MPLS networks for applications such as packet loss and packet delay measurement. A method of loss and delay measurement in MPLS networks was defined in [RFC6374]. When used to measure packet loss [RFC6374] depends on the use of the 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. Where the misordering of packets from one group relative to the following group, or misordering of one of the packets being counted relative to the [RFC6374] packet occurs, - then an error will occur in the packet loss measurement. In - addition, this packet performance measurement system needs to be + then an error will occur in the packet loss measurement. + + In addition, this packet performance measurement system needs to be extended to deal with different granularities of flow and to address a number of the multi-point cases in which two or more ingress Label Switching Routers (LSRs) could send packets to one or more destinations. Improvements in link and transmission technologies mean that it may be difficult to assess packet loss using active performance measurement methods with synthetic traffic, due to the very low loss rate in normal operation. That, together with more demanding service level requirements, mean that network operators need to be able to @@ -115,45 +118,45 @@ developed. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 3. Loss Measurement Considerations - Modern networks, if not oversubscribed, normally drop very few - packets, thus packet loss measurement is highly sensitive to counter - errors. Without some form of coloring or batch marking such as that + Modern networks, if not oversubscribed, potentially drop relatively + few packets, thus packet loss measurement is highly sensitive to the + common demarcation of the exact set of packets to be measured for + loss. Without some form of coloring or batch marking such as that proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve the required accuracy in the loss measurement of customer data - traffic. Thus where accuracy better than the data link loss - performance of a modern optical network is required, it may be - economically advantageous, or even a technical requirement, to - include some form of marking in the packets to assign each packet to - a particular counter. + traffic. Thus where accurate measurement of packet loss is required, + it may be economically advantageous, or even a technical requirement, + to include some form of marking in the packets to assign each packet + to a particular counter for loss measurement purposes. Where 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 which 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 + line cards on LSRs. 3. The packets may arrive at different interfaces on different line cards on LSRs. A consideration in 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 @@ -163,22 +166,25 @@ multi-point to (multi-) point networks that some method of avoiding accounting errors introduced by ECMP needs to be supported. 4. Delay Measurement Considerations Most of the existing delay measurement methods are active measurement that depend on the extra injected test packet to evaluate the delay of a path. With the active measurement method, the rate, numbers and interval between the injected packets may affect the accuracy of the results. Also, for injected test packets, these may not be co-routed - with the data traffic due to ECMP. Thus there exists a requirement - to measure the delay of the real traffic. + with the data traffic due to ECMP, or various link aggregation + technologies all of which distribute flows across a number of paths + at the network, or data-link and hence at the physical layer. + Thus there exists a requirement to measure the delay of the real + traffic. For combined loss-delay measurements, both the loss and the delay considerations apply. 5. Units of identification The most basic unit of identification is the identity of the node that processed the packet on its entry to the MPLS network. However, the required unit of identification may vary depending on the use case for accounting, performance measurement or other types of packet @@ -187,27 +193,27 @@ This document considers following units of identifications: o Per source LSR - everything from one source is aggregated. o Per group of LSPs chosen by an ingress LSR - an ingress LSP aggregates group of LSPs (ex: all LSPs of a tunnel). o Per LSP - the basic form. - o Per flow [RFC6790] within an LSP - fine graining method. + o Per flow [RFC6790] within an LSP - 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 fine grained resolution may be possible by deep packet inspection, but this may - not always be possible, or it may be desired to minimise processing + not always be possible, or it may be desired to minimize processing costs by doing this only in entry to the network, and adding a suitable identifier to the packet for reference by other network elements. An example of such a fine grained case might be traffic from a specific application, or from a specific application 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: @@ -231,21 +237,21 @@ The unit of identification and the method of determining which packets constitute a flow will be application or use-case specific and is out of scope of this memo. 6. Types of LSP We need to consider a number of types of LSP. The two simplest types to monitor are point to point LSPs and point to multi-point LSPs. The ingress LSR for a point to point LSP, such as those created using the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) - [RFC5420] signalling protocol, or those that conform to the MPLS + [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, since at any provider-edge (PE) or provider (P) router on the path this is unique to the ingress-egress pair at every hop at a given layer in the LSP hierarchy. Provided that penultimate hop popping is disabled, the identity of the ingress LSR of a point to point LSP is available at the egress LSR and 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. @@ -301,23 +307,23 @@ to the extent that deploying the new feature will not disable anything that currently works on a legacy equipment. This is particularly the case when the deployment is incremental or when the feature is not required for all LSRs or all LSPs. Thus in broad the flow identification design MUST support the co-existence of both LSRs that can, and cannot, identify the traffic components described in Section 5. In addition the identification of the traffic components described in Section 5 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 multi- - point to multipoint LSP support the identification type in use so - that a single packet can be correctly processed by all egress + MAY require that all egress LSRs of a point to multi-point or a + multi- point to multi-point 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. 9. Dataplane There is a huge installed base of MPLS equipment, typically this type of equipment remains in service for an extended period of time, and in many cases hardware constraints mean that it is not possible to upgrade its dataplane functionality. Changes to the MPLS data plane @@ -328,30 +334,30 @@ very small number have been adopted. Hence, it is important that the method of identification must minimize changes to the MPLS data 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 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 is necessary to the MPLS data plane proves necessary, it should be (a) be as small a change as possible and (b) be a general purpose method so as to - maximise its use for future applications. It is imperative that, as + 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 where 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 + another. For example, one LSP may be carried over another LSP, or a 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 Elements (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 MPLS data plane design provides two types of special purpose labels: the original 16 reserved labels and the much larger set of