[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-dong-bess-l3vpn-pm-framework

Network Working Group                                            J. Dong
Internet-Draft                                                     Z. Li
Intended status: Informational                       Huawei Technologies
Expires: April 30, 2015                                B. Bhavani Parise
                                                           Cisco Systems
                                                        October 27, 2014


              A Framework for L3VPN Performance Monitoring
                    draft-dong-l3vpn-pm-framework-03

Abstract

   The capability of BGP/MPLS IP Virtual Private Networks (L3VPN)
   performance monitoring (PM) is important to meet the Service Level
   Agreement(SLA) for the service beared.  Since multipoint-to-point or
   multipoint-to-multipoint (MP2MP) network model applies, flow
   identifying is a big challenge for L3VPN PM.  This document specifies
   the framework and mechanisms for the application of L3VPN PM.

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."

   This Internet-Draft will expire on April 30, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Dong, et al.             Expires April 30, 2015                 [Page 1]


Internet-Draft             L3VPN PM Framework               October 2014


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview and Concepts . . . . . . . . . . . . . . . . . . . .   3
     2.1.  VRF-to-VRF Tunnel . . . . . . . . . . . . . . . . . . . .   3
   3.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  VPN Membership Auto-Discovery . . . . . . . . . . . . . .   3
     3.2.  VRF-to-VRF Label Allocation . . . . . . . . . . . . . . .   3
   4.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Additional Label for Ingress VRF Identification . . . . .   4
     4.2.  Replace the VPN Label with VT Label . . . . . . . . . . .   5
   5.  L3VPN Performance Monitoring  . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Level 3 Virtual Private Network (L3VPN) [RFC4364] service is widely
   deployed to provide enterprise VPN, Voice over IP (VoIP), video,
   mobile backhaul, 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 meeting the Service Level Agreement (SLA).
   This measurement capability also provides operators with greater
   visibility into the performance characteristics of the services in
   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 traffic flow, the egress PE needs to identify the
   ingress VRF sending the VPN packets.  As specified in
   [I-D.zheng-l3vpn-pm-analysis], such flow identification is a big
   challenge for existing L3VPN.




Dong, et al.             Expires April 30, 2015                 [Page 2]


Internet-Draft             L3VPN PM Framework               October 2014


   This document specifies the framework and mechanisms for the
   application of performance monitoring in L3VPN.

2.  Overview and Concepts

   Based on the mechanisms in [RFC4364], for a particular VPN prefix,
   the directly connected PE allocates the same VPN label to all the
   remote PEs which maintain VPN Routing and Forwarding Tables (VRFs) of
   that VPN.  Thus performance monitoring can not be performed on the
   egress PE, since it is not able to identify the source VRF of the
   received VPN packets.

   As analyzed in [I-D.zheng-l3vpn-pm-analysis], to perform the packet
   loss or delay measurement on a specific VPN flow, it is critical for
   the egress PE to identify the unique VRF, i.e. to establish the
   Point-to-Point connection between the two VRFs . Once the Point-to-
   Point connection is built up, current measurement mechanisms may be
   applied to L3VPN.  A new concept "VRF-to-VRF Tunnel" is introduced in
   the following section to establish such Point-to-Point connection.

2.1.  VRF-to-VRF Tunnel

   In order to perform performance monitoring in L3VPN, a point-to-point
   connection between any two VRFs of a particular VPN needs to be
   established.  This guarantees that the egress PE could identify the
   ingress VRF of the received VPN traffic, thus it could measure the
   packet loss and delay between the ingress and egress VRFs.  Such
   point-to-point VPN connection between an ingress VRF and an egress
   VRF is called "VRF-to-VRF Tunnel (VT)".

3.  Control Plane

   This section describes the control plane mechanisms needed for L3VPN
   performance monitoring.

3.1.  VPN Membership Auto-Discovery

   Before establishing the Point-to-Point connections between VRFs, each
   PE attaching a given VPN needs to know all the remote PEs that attach
   to the same VPN.  This can be achieved by the membership auto-
   discovery procedure.  Some mechanisms similar to the membership auto-
   discovery in MVPN [RFC6513] can be used.

3.2.  VRF-to-VRF Label Allocation

   After obtaining the VPN membership information, each PE needs to
   allocate MPLS labels to identify the VRF-to-VRF tunnel between the
   local VRF and the remote VRFs, such labels are called VT labels.  For



Dong, et al.             Expires April 30, 2015                 [Page 3]


Internet-Draft             L3VPN PM Framework               October 2014


   each local VRF, the egress PE SHOULD allocate different VT labels for
   each remote VRF in PEs belonging to the same VPN.  This way, the
   egress PE could identify the VPN flow received from different ingress
   VRFs, and the packet loss and delay measurement could be performed
   between each ingress VRF and the local VRF.

4.  Data Plane

   This section introduces two new MPLS label stack encapsulations when
   VT label applies.

4.1.  Additional Label for Ingress VRF Identification

   When a VPN data packet needs to be sent, firstly the VPN label
   obtained from the BGP VPN route of the destination address prefix is
   pushed onto the label stack.  The VT label allocated by the egress
   VRF should then be pushed onto the label stack to identify the Point-
   to-Point connection between the sending and receiving VRF.  Finally,
   the MPLS tunnel label is pushed onto the label stack.  The process of
   TTL and COS fields between the VPN label encapsulation and the tunnel
   label encapsulation is done according to the Pipe and Uniform Models
   defined in [RFC3270] and [RFC3443].  The TTL and COS value in the VPN
   label entry should be copied to the TTL and COS fields of the VT
   label encapsulation respectively.  This way, one additional label is
   carried in the label stack compared with L3VPN data plane in
   [RFC4364].

   When the VPN data packet arrives at the egress PE, the outermost
   tunnel label is popped, then the egress PE could use the VT label to
   identify the ingress VRF of the packet.  The process of TTL and COS
   fields at the egress node should be done according to the Pipe and
   Uniform Models defined in [RFC3270] and [RFC3443].  Since the value
   of the TTL and COS fields of the VPN label encapsulation and the VT
   label encapsulation are the same, the TTL and COS fields of the VT
   label encapsulation can be ignored during the course of the TTL and
   COS process at the egress node.

    +--------------+              +--------------+
    | Tunnel Label |              | Tunnel Label |
    +--------------+        \     +--------------+
    |   VPN Label  |  -------\    |   VT Label   |
    +--------------+  -------/    +--------------+
    |    Payload   |        /     |  VPN Label   |
    +--------------+              +--------------+
                                  |   Payload    |
                                  +--------------+

           Fig.1 Additional Label for Ingress VRF Identification



Dong, et al.             Expires April 30, 2015                 [Page 4]


Internet-Draft             L3VPN PM Framework               October 2014


4.2.  Replace the VPN Label with VT Label

   Since the VT label identifies the connection between the ingress VRF
   and egress VRF, it could also be used to identify the egress VRF
   table in which the VPN prefix lookup should be performed.  Thus when
   encapsulating the VPN data packets, the ingress PE could simply
   replace the VPN label with the VT label, then push the tunnel label.
   The process of TTL and COS fields between the VPN label encapsulation
   and the tunnel label encapsulation is done according to the Pipe and
   Uniform Models defined in [RFC3270] and [RFC3443].  The TTL and COS
   value of the VPN label entry should be copied to the TTL and COS
   field of the VT label respectively.  In this way the depth of the
   MPLS label stack is unchanged.

   The encapsulation method would require the egress PE to perform VPN
   prefix lookup in the egress VRF table before the packet can be
   forwarded to a specific CE.  The similar procedure is also required
   when per-instance VPN label allocation mechanism is used.  The
   process of TTL and COS fields at the egress node should be done
   according to the Pipe and Uniform Models defined in [RFC3270] and
   [RFC3443].  Since the VPN label encapsulation is replaced with the VT
   label encapsulation, the TTL and COS fields of the VT label
   encapsulation should be used as those of the VPN label encapsulation
   during the course of the TTL and COS process at the egress node.

    +--------------+              +--------------+
    | Tunnel Label |              | Tunnel Label |
    +--------------+        \     +--------------+
    |   VPN Label  |  -------\    |   VT Label   |
    +--------------+  -------/    +--------------+
    |    Payload   |        /     |    Payload   |
    +--------------+              +--------------+

                 Fig.2 Replace the VPN Label with VT Label

5.  L3VPN Performance Monitoring

   Since the challenge of identifying the ingress VRF is resolved in
   section 4, the procedures for the packet loss and delay measurement
   as defined in [RFC6374] can be utilized for L3VPN performance
   monitoring.  The main difference between performance monitoring of
   L3VPN and MPLS is the format of identifiers in the Loss Measurement
   (LM) and Delay Measurement (DM) messages.  Specifically, for L3VPN,
   the source and destination addresses of the LM and DM messages should
   be set to the concatenation of the Route Distinguisher (RD) of the
   particular VRF and the IP address of the ingress and egress PE
   respectively.




Dong, et al.             Expires April 30, 2015                 [Page 5]


Internet-Draft             L3VPN PM Framework               October 2014


6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.  Security Considerations

   TBD

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
              Protocol Label Switching (MPLS) Support of Differentiated
              Services", RFC 3270, May 2002.

   [RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
              in Multi-Protocol Label Switching (MPLS) Networks", RFC
              3443, January 2003.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.

8.2.  Informative References

   [I-D.zheng-l3vpn-pm-analysis]
              Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance
              Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm-
              analysis-03 (work in progress), July 2014.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

Authors' Addresses







Dong, et al.             Expires April 30, 2015                 [Page 6]


Internet-Draft             L3VPN PM Framework               October 2014


   Jie Dong
   Huawei Technologies
   Huawei Building, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com


   Zhenbin Li
   Huawei Technologies
   Huawei Building, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Bhavani Parise
   Cisco Systems

   Email: bhavani@cisco.com





























Dong, et al.             Expires April 30, 2015                 [Page 7]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/