Network Working Group L. Zheng Internet-Draft Z. Li Intended status: Informational S. Aldrin Expires: April 21, 2014 Huawei Technologies B. Parise Cisco Systems October 18, 2013 Performance Monitoring Analysis for L3VPN draft-zheng-l3vpn-pm-analysis-02 Abstract To perform the measurement of packet loss, delay and other metrics on a particular VPN flow, the egress PE need to tell to which specific ingress VRF a packet belongs to. But for L3VPN, multipoint-to-point or multipoint-to-multipoint (MP2MP) network model applies, flow identifying is a big challenge. This document summarizes the current performance monitoring mechanisms for L3VPN in MPLS networks, and analyzes various solutions and challenges for measuring performance metrics within these networks. This document also identifies various key points which needs to be taken in consideration when designing L3VPN performance monitoring mechanisms. Performance measurements within non-MPLS L3VPN networks is not within the scope of the document. 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 RFC 2119 [RFC2119]. 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." Zheng, et al. Expires April 21, 2014 [Page 1] Internet-Draft PM Analysis for L3VPN October 2013 This Internet-Draft will expire on April 21, 2014. Copyright Notice Copyright (c) 2013 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of current mechanisms for MPLS networks . . . . . . 3 2.1. Packet Loss and Delay Measurement for MPLS Networks . . . 3 2.2. Synthetic measurements . . . . . . . . . . . . . . . . . 4 2.3. Real packet measurements . . . . . . . . . . . . . . . . 4 2.4. Profile for MPLS-based Transport Networks . . . . . . . . 4 3. Challenge for L3VPN Performance Monitoring . . . . . . . . . 4 4. Design Consideration . . . . . . . . . . . . . . . . . . . . 6 4.1. P2P Connection . . . . . . . . . . . . . . . . . . . . . 6 4.2. Hierarchy L3VPN . . . . . . . . . . . . . . . . . . . . . 6 4.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . 7 4.6. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.7. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Manageability Consideration . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Zheng, et al. Expires April 21, 2014 [Page 2] Internet-Draft PM Analysis for L3VPN October 2013 1. Introduction Level 3 Virtual Private Network (L3VPN) [RFC4364]service is widely deployed in the production network. It is deployed to provide enterprise interconnection, Voice over IP (VoIP), video, mobile, etc. services. Most of these services are sensitive to the packet loss and delay. The capability to measure and monitor performance metrics for packet loss, delay, as well as related metrics is essential for SLA. The requirement for SLA measurement for MPLS networks has been documented in [RFC4377]. One popular deployment of L3VPN nowadays is in mobile backhaul networks. When deploying MPLS-TP in mobile backhaul networks, due to the scalability issue with PW, L3VPN is used either for end-to-end service delivery, or L2VPN and L3VPN hybrid networking. The measurement capability of L3VPN provides operators with greater visibility into the performance characteristics of their networks, and provides diagnostic information in case of performance degradation or failure and helps for fault localization. To perform the measurement of packet loss, delay and other metrics on a particular VPN flow, the egress PE need to tell to which specific ingress VRF a packet belongs. But for L3VPN, multipoint-to-point or multipoint-to-multipoint (MP2MP) network model applies, flow identifying is a big challenge. This document summarizes the current performance monitoring mechanisms for MPLS networks, and analyzes the challenge for L3VPN performance monitoring. This document also discuss the key points need to be taken in consideration when designing L3VPN performance monitoring mechanisms. All references to L3VPN further in the document refers to MPLS L3VPN networks. 2. Overview of current mechanisms for MPLS networks 2.1. Packet Loss and Delay Measurement for MPLS Networks [RFC6374]defines procedure and protocol mechanisms to enable the efficient and accurate measurement of packet loss, delay, as well as related metrics in MPLS networks. The LM protocol can perform two distinct kinds of loss measurement. In inferred mode, it can measure the loss of specially generated test packets (in order to infer the approximate data-plane loss level). In direct mode, it can directly measure data-plane packet loss. Direct measurement provides perfect loss accounting, but may require specialized hardware support and is only applicable to some LSP types. Inferred measurement provides only approximate loss accounting but is generally applicable. There should also be inferred mode and direct mode for LM in the L3VPN environment. This Zheng, et al. Expires April 21, 2014 [Page 3] Internet-Draft PM Analysis for L3VPN October 2013 document focuses on the direct mode. The inferred mode is out of scope of the document. The LM and DM protocols are initiated from a single node. A query message may be received either by a single node or by multiple nodes; i.e. these protocols provide point-to-point or point-to-multipoint measurement capabilities. 2.2. Synthetic measurements Performance measurements are done using synthetic packets sent over the network. Metrics like response time, jitter, packet loss could be inferred using these synthetic packet measurements. In order to perform inferred measurements, the crafted packets have to behave like data packets and take the same path as data packets. 2.3. Real packet measurements Measurements of actual data packets is resource intensive and requires special way of accounting for the measurements. Counters within the network devices are primarily used to measure various metrics. Various technologies like Netflow, IPFIX, etc are used to collect the data and process it offline to derive performance measurements. When the data is aggregated, collecting per flow or per VPN customer traffic data becomes complex. More details are found in the subsequent sections. 2.4. Profile for MPLS-based Transport Networks Procedures for the measurement of packet loss, delay, and throughput in MPLS networks are defined in [RFC6374]. [RFC6375]describes a profile, i.e. a simplified subset, of procedures that suffices to meet the specific requirements of MPLS-based transport networks [RFC5921] as defined in [RFC5860]. This profile is presented for the convenience of implementers who are concerned exclusively with the transport network context. LM session is externally configured and the values of several protocol parameters can be fixed in advance at the endpoints involved in the session, so that inspection or negotiation of these parameters is not required. 3. Challenge for L3VPN Performance Monitoring Zheng, et al. Expires April 21, 2014 [Page 4] Internet-Draft PM Analysis for L3VPN October 2013 To perform the measurement of packet loss, delay and other metrics on a particular VPN flow, the egress PE need to tell to which specific ingress VRF a packet belongs. The above mentioned existing mechanisms for MPLS networks provide either point-to-point or point-to-multipoint measurement capabilities. For a specific receiver, it could easily identify a specific flow by the label stack information, when LDP is not used and Penultimate Hop Pop (PHP) function is disabled. But in the case of L3VPN, multipoint-to-point or multipoint-to- multipoint (MP2MP) network model applies , it makes the identification of a flow, a big challenge, for packet loss and delay measurement. According to the label allocation mechanisms of L3VPN, a private label itself cannot uniquely identify a specific VPN flow. That is, when the egress PE allocates VPN label for a specific prefix of a VPN, the same label will be advertised to all its peers. Given a VPN flow, the egress PE cannot tell which ingress VRF is from based on the private label it carries. As a result, it's not feasible to perform the loss or delay measurement on this flow. In L3VPN the LSPs may be merged at any intermediate nodes along the LSP (e.g., Label Distribution Protocol (LDP) [RFC5036] based LSP). The egress PE cannot derive a unique identifier of the source PE from label stack. The tunnel label cannot help for flow identification due to the LSP merge. In L3VPN, the ingress PE could be identified by the tunnel label when TE LSP applies [RFC3209], but the egress PE cannot tell to which specific VRF a packet belongs to, when extranet (If the various sites in a VPN are owned by different enterprises) exist on ingress PE. Figure 1 shows an example of extranet. In Figure1, Site A,B,C,D all belong to the same VPN-A, but Site C and Site D does not belong to the same enterprise (Site D also belongs to a VPN-B), so different VRFs are maintained for each site on PE3. PE1 assign the same label L for prefix 10.0.0.1 to PE3 of VPN-A, when it receives the VPN-A flow from PE3, it can not tell the flow is from either VRFC or VRFD by the label stack. +------+ +------------+ +-------------+ +------+ | SITE |----+----| PE +---------+ PE +----+-----+ SITE | | A | |VRFA| 1 | | 2 |VRFB| | B | +------+ +----+------------+ +------+------+----+ +------+ | | | VPN-A | | | | +------+-----+ +---------------+ PE | Zheng, et al. Expires April 21, 2014 [Page 5] Internet-Draft PM Analysis for L3VPN October 2013 | 3 | +----+--+----+ |VRFC| |VRFD| +----+ +----+ | | | | Extranet VPN-B +------+ +------+ | SITE | | SITE | | C | | D +---- +------+ +------+ Figure1: Extranet on Ingress PE The current label allocation mechanism of L3VPN makes the flow identification a big challenge for L3VPN performance monitoring, as a result the current performance monitoring mechanisms for MPLS networks cannot be applied to L3VPN networks. Without any extensions or alteration to current label allocation mechanisms, performance measurements cannot be performed in L3VPN networks. 4. Design Consideration This section discuss the key points need to be taken in consideration when designing L3VPN performance monitoring mechanism. 4.1. P2P Connection As analyzed above, to perform the packet loss or delay measurement on a specific VPN flow, it is critical for the egress PE to identify the unique ingress VRF, i.e. to establish the Point-to-Point connection between the two VRFs. Current allocation mechanism may need extension or alteration to help build up the Point-to-Point connection. Once the Point-to-Point connection is built up, current measurement mechanisms may be applied to L3VPN . Conditions like Penultimate Hop Popping (PHP), Equal-Cost Multi-Path (ECMP) load-balancing and BGP multi-path may make it infeasible for receiving PE to identify the ingress PE. These conditions are to be considered when designing solutions. 4.2. Hierarchy L3VPN There are flexible hierarchy L3VPN deployment scenarios such as inter-AS, carrier's carrier, etc[RFC4364]. The mechanism design should take into account these scenarios. Since the document focuses on MPLS transport network which seldom introduces the complex L3VPN scenarios, it is for further research if more complex mechanisms for Zheng, et al. Expires April 21, 2014 [Page 6] Internet-Draft PM Analysis for L3VPN October 2013 these hierarchy L3VPN scenarios besides reusing the mechanism for the simple L3VPN scenarios has to be introduced. 4.3. Control Plane In L3VPN, BGP is used to distribute a particular route, as well as an MPLS label that is mapped to that route [RFC4364]. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. In order to setup the Point-to-Point connection between ingress and egress VRFs the current label distribution mechanism may be altered. For compatibility, this alteration SHOULD NOT change the current label distribution mechanism dramatically. 4.4. Data Plane Same as for control plane, for compatibility reason, the data plane should as far as be compatible with the current L3VPN forwarding procedure. 4.5. MPLS OAM [RFC6374], [RFC6375]defines procedure and protocol mechanisms to enable the measurement of packet loss, delay, as well as related metrics in MPLS networks. These mechanisms SHOULD be reasonably reused in L3VPN networks. The addressing of source an destination of Loss Measurement (LM) and Delay Measurement (DM) messages may needed to be changed to identify the measured VRF. LSP ping and trace based on [RFC4379] are used to perform various metric measurement which includes jitter etc. Most of the measurements like response time, jitter, etc., are inferred measurements with synthetic measurements and not necessarily the true representation of the data packets traversing the network, especially with respect to packet loss measurements. 4.6. QoS To perform the packet loss or delay measurement in L3VPN network, either proactive or on-demand, SHOULD NOT impact the customer QoS experience. 4.7. ECMP Performance measurements within ECMP networks poses a bigger challenge. When the data packet traverse the network, the logic of hashing on to a ECMP path is a local decision based on the header information it is carrying. Number of labels, IP header, UDP header Zheng, et al. Expires April 21, 2014 [Page 7] Internet-Draft PM Analysis for L3VPN October 2013 could play a role in considering which path the packet traverses. When PM is measured with synthetic packets, the crafted packets have to be constructed to ensure various ECMP paths are measured. This poses a big challenge for the source, which generates these packets, to reflect the behavior of the actual data traffic and measure the metrics. [RFC4379] provides various mechanisms to perform LM and DM measurements over ECMP networks. 5. Manageability Consideration [RFC6374] describes manageability consideration of packet loss and delay measurement for MPLS network. The defined mechanisms should be reused for L3VPN PM. 6. Security Considerations This document does not change the security properties of L3VPN. 7. IANA Considerations This document makes no request to IANA. 8. Acknowledgements The authors would like to thank XXX for their valuable comments. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. Zheng, et al. Expires April 21, 2014 [Page 8] Internet-Draft PM Analysis for L3VPN October 2013 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. Authors' Addresses Lianshu Zheng Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing 100095 China Email: vero.zheng@huawei.com Zhenbin Li Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Sam K. Aldrin Huawei Technologies Email: aldrin.ietf@gmail.com Zheng, et al. Expires April 21, 2014 [Page 9] Internet-Draft PM Analysis for L3VPN October 2013 Bhavani Parise Cisco Systems Email: bhavani@cisco.com Zheng, et al. Expires April 21, 2014 [Page 10]