Internet DRAFT - draft-dong-l3vpn-pm-framework
draft-dong-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]
