Internet DRAFT - draft-dong-bess-l3vpn-pm-framework
draft-dong-bess-l3vpn-pm-framework
Network Working Group J. Dong
Internet-Draft Z. Li
Intended status: Informational Huawei Technologies
Expires: April 21, 2016 B. Parise
Cisco Systems
October 19, 2015
A Framework for L3VPN Performance Monitoring
draft-dong-bess-l3vpn-pm-framework-00
Abstract
The performance monitoring (PM) of BGP/MPLS IP Virtual Private
Networks (L3VPN) is important for satisfying the Service Level
Agreement(SLA) for critical network services. Since L3VPN is
essentially using a multipoint-to-point service model, flow
identification becomes a big challenge for L3VPN PM. This document
specifies the framework and mechanisms for the application of PM in
L3VPN.
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 21, 2016.
Dong, et al. Expires April 21, 2016 [Page 1]
Internet-Draft L3VPN PM Framework October 2015
Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Flow Identification in L3VPN PM . . . . . . . . . . . . . . . 3
3. Local-Allocated SFL for L3VPN PM . . . . . . . . . . . . . . 3
3.1. Additional SFL for Source Identification . . . . . . . . 4
3.2. Replacing the VPN Label with SFL . . . . . . . . . . . . 4
4. Global SFL for L3VPN PM . . . . . . . . . . . . . . . . . . . 5
4.1. Global SFL for VPN Identification . . . . . . . . . . . . 5
4.2. Global SFL for Ingress VRF Identification . . . . . . . . 6
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. VPN Membership Auto-Discovery . . . . . . . . . . . . . . 7
5.2. Allocation of Synonymous Flow Label for L3VPN PM . . . . 7
5.2.1. Local SFL Allocation . . . . . . . . . . . . . . . . 8
5.2.2. Global SFL Allocation . . . . . . . . . . . . . . . . 8
6. L3VPN Performance Monitoring . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
BGP/MPLS IP Virtual Private Networks (L3VPN) [RFC4364] is widely
deployed to provide various services such as enterprise VPN, Voice
over IP (VoIP), video, mobile backhaul, etc. Most of these services
are sensitive to packet loss and delay. The capability to measure
and monitor the performance metrics such as packet loss, delay, as
well as related metrics is important for meeting the Service Level
Agreements (SLA). This performance measurement capability also
provides operators with greater visibility into the performance
Dong, et al. Expires April 21, 2016 [Page 2]
Internet-Draft L3VPN PM Framework October 2015
characteristics of the services in their networks, and provides
diagnostic information in case of performance degradation or failure
and helps fault localization.
In order to perform the measurement of packet loss, delay and other
metrics on a particular L3VPN 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 L3VPN.
This document specifies the framework and mechanisms for the
application of performance monitoring in L3VPN.
2. Flow Identification in L3VPN PM
Based on the mechanisms defined in [RFC4364], for a specific VPN
prefix, the directly connected PE would allocate and advertise the
same VPN label to all the remote PEs which have the VPN Routing and
Forwarding Tables (VRFs) of the same VPN. Essentially this is a
multipoint-to-point service model. On the egress PE, performance
monitoring can not be performed based on the VPN label, because it
cannot identify the ingress VRF which generates the VPN packets.
As analyzed in [I-D.zheng-l3vpn-pm-analysis], in order to perform the
packet loss or delay measurement on a specific L3VPN traffic flow, it
is critical that the egress PE can uniquely identify the ingress VRF
of the received VPN packets.
[I-D.bryant-mpls-synonymous-flow-labels] defines the concept of
Synonymous Flow Labels (SFL), for which the typical use case is the
performance monitoring of MPLS applications. The Synonymous Flow
Labels are used here for the performance monitoring of L3VPN, in
which the SFLs are used by the egress PE to uniquely identify the
ingress VRF of the received VPN packets. Depends on specific
provisioning models, the SFLs can be either local-allocated or
globally allocated labels. Subsequent sections specifies the data
plane encapsulation and control plane considerations for different
modes.
3. Local-Allocated SFL for L3VPN PM
This section specifies the L3VPN PM mechanism with local-allocated
Synonymous Flow Labels, in which the SFLs are allocated by the egress
PEs. The SFL can be allocated to identify a specific ingress VRF, or
a specific ingress-egress VRF pair. Depends on the semantics of the
SFL, two MPLS label stack encapsulations are used.
Dong, et al. Expires April 21, 2016 [Page 3]
Internet-Draft L3VPN PM Framework October 2015
3.1. Additional SFL for Source Identification
This section specifies the label stack encapsulation in which the SFL
is allocated by the egress PE to identify the ingress VRF and the
ingress PE. While the VPN label is still used for packet forwarding
decision on the egress PE.
When a VPN data packet is to be sent by an ingress PE, firstly the
VPN label obtained from the BGP VPN route of the destination address
prefix is pushed onto the label stack. Then according to the next-
hop of the BGP VPN route, the Synonymous Flow Label allocated by the
next-hop PE for the ingress VRF SHOULD be pushed onto the label
stack. Finally, the MPLS tunnel label is pushed onto the label
stack. The TTL and TC fields of the VPN label and the tunnel label
entries SHOULD be set according to the Pipe or Uniform Model as
defined in [RFC3270] and [RFC3443]. The value of the TTL and TC
fields of the VPN label entry SHOULD be copied to the TTL and TC
fields of the Synonymous Flow Label entry respectively. With this
encapsulation, one additional label is carried in the label stack
compared with traditional L3VPN encapsulation defined in [RFC4364].
When the VPN packet arrives at the egress PE, the outermost tunnel
label is popped (if present), then the egress PE uses the Synonymous
Flow Label to identify the ingress VRF of the packet. The TTL and
COS fields SHOULD be processed according to the Pipe or Uniform
Models defined in [RFC3270] and [RFC3443]. Since the value of the
TTL and TC fields of the VPN label and the SFL are the same, the TTL
and TC fields of the SFL can be ignored by the egress PE.
+--------------+ +---------------+
| Tunnel Label | | Tunnel Label |
+--------------+ \ +---------------+
| VPN | -------\ |Synonymous Flow|
| Label | \ | Label |
+--------------+ -------/ +---------------+
| Payload | / | VPN Label |
+--------------+ +---------------+
| Payload |
+---------------+
Figure 1. Additional SFL for Source Identification
3.2. Replacing the VPN Label with SFL
This section specifies the label stack encapsulation in which the SFL
is allocated by the egress PE to identify a specific ingress-egress
VRF pair. In this case, since the SFL could also be used by the
egress PE to identify the egress VRF, if the VPN label is a per-
Dong, et al. Expires April 21, 2016 [Page 4]
Internet-Draft L3VPN PM Framework October 2015
instance label, on the ingress PE the VPN label can be replaced with
the SFL, then the tunnel label is pushed onto the label stack. The
TTL and TC fields of the Synonymous Flow Label and the tunnel label
SHOULD be set according to the Pipe or Uniform Model as defined in
[RFC3270] and [RFC3443]. The value of the TTL and TC fields of the
VPN label entry should be copied to the TTL and TC fields of the
Synonymous Flow Label entry respectively. With this mechanism, the
depth of the MPLS label stack is not increased, while the number of
Synonymous Flow Labels needed would be more than that in the
mechanism of Section 3.1.
+--------------+ +---------------+
| Tunnel Label | | Tunnel Label |
+--------------+ \ +---------------+
| VPN | -------\ |Synonymous Flow|
| Label | \ | Label |
+--------------+ -------/ +---------------+
| Payload | / | Payload |
+--------------+ +---------------+
Figure 2. VPN label replaced with SFL
Note that this label stack encapsulation would require the egress PE
to lookup the destination VPN prefix in the egress VRF before the
packet can be forwarded to a specific CE. This is similar to the
per-instance VPN label allocation mechanism in [RFC4364]. The TTL
and TC fields SHOULD be processed according to the Pipe or Uniform
Model as defined in [RFC3270] and [RFC3443]. Since the VPN label
entry is replaced with the Synonymous Flow Label, the TTL and TC
fields of the SFL should be used as those of the VPN label entry in
traditional L3VPN encapsulation.
4. Global SFL for L3VPN PM
In some scenarios global MPLS label can be beneficial for L3VPN
services. This section specifies the L3VPN PM mechanism with global
Synonymous Flow Labels.
4.1. Global SFL for VPN Identification
In this mode, a global unique SFL is allocated for each VPN.
Besides, a global unique label is allocated to identify each PE node
in the network. An ingress VRF can be identified by the combination
of the PE label and the VPN SFL label.
When a VPN data packet is to be sent by an ingress PE, firstly the
VPN label obtained from the BGP VPN route of the destination address
prefix is pushed onto the label stack. Then the Synonymous VPN Label
Dong, et al. Expires April 21, 2016 [Page 5]
Internet-Draft L3VPN PM Framework October 2015
and the PE label are pushed onto the label stack. Finally, the MPLS
tunnel label is pushed onto the label stack.
With this approach, two additional labels are carried in the label
stack compared with traditional L3VPN encapsulation defined in
[RFC4364].
+---------------+
| Tunnel Label |
+--------------+ +---------------+
| Tunnel Label | |Source PE Label|
+--------------+ \ +---------------+
| VPN | -------\ | VPN Synonymous|
| Label | \ | Flow Label |
+--------------+ -------/ +---------------+
| Payload | / | VPN Label |
+--------------+ +---------------+
| Payload |
+---------------+
Figure 3. Label stack with global PE label and VPN SFL
In scenarios where the VPN label is per-instance label, the VPN
Synonymous Flow Label can replace the VPN label, then the MPLS label
stack would contain one additional label compared with traditional
L3VPN encapsulation.
+--------------+ +---------------+
| Tunnel Label | | Tunnel Label |
+--------------+ \ +---------------+
| VPN | -------\ |Source PE Label|
| Label | \ +---------------+
+--------------+ -------/ | VPN Synonymous|
| Payload | / | Flow Label |
+--------------+ +---------------+
| Payload |
+---------------+
Figure 4. VPN label replaced with global VPN SFL
4.2. Global SFL for Ingress VRF Identification
In this mode, a global unique SFL is allocated for each VRF on each
PE, which can be used by the egress PE to identify both the ingress
VRF and the ingress PE.
When a VPN data packet is to be sent by an ingress PE, firstly the
VPN label obtained from the BGP VPN route of the destination address
Dong, et al. Expires April 21, 2016 [Page 6]
Internet-Draft L3VPN PM Framework October 2015
prefix is pushed onto the label stack. Then the VRF SFL is pushed
onto the label stack. Finally, the MPLS tunnel label is pushed.
With this approach, one additional label is carried in the label
stack compared with the traditional L3VPN encapsulation.
+--------------+ +---------------+
| Tunnel Label | | Tunnel Label |
+--------------+ \ +---------------+
| VPN | -------\ | VRF Synonymous|
| Label | \ | Flow Label |
+--------------+ -------/ +---------------+
| Payload | / | VPN Label |
+--------------+ +---------------+
| Payload |
+---------------+
Figure 5. Label stack with global VRF SFL
When the VPN packet arrives at the egress PE, the outermost tunnel
label is popped (if present), then the egress PE uses the VRF
Synonymous Flow Label to identify the ingress VRF of the packet. The
VPN label is used for packet forwarding decision on the egress PE.
5. Control Plane
This section describes the corresponding control plane mechanisms for
L3VPN performance monitoring with the help of Synonymous Flow Label.
5.1. VPN Membership Auto-Discovery
Before the Synonymous Flow Labels are allocated, a PE which attaches
to a particular VPN needs to know all the remote VRFs on other PEs
that attach to the same VPN. This is achieved via the BGP membership
auto-discovery procedure. Mechanisms similar to the membership auto-
discovery of MVPN [RFC6513] can be used. Detailed BGP protocol
extensions will be specified in a companion document.
5.2. Allocation of Synonymous Flow Label for L3VPN PM
After the VPN membership information is obtained, Synonymous Flow
Labels needs to be allocated for L3VPN PM. The SFL can be either
local-allocated by each PE, or it can be global unique label which is
allocated for L3VPN PM.
Dong, et al. Expires April 21, 2016 [Page 7]
Internet-Draft L3VPN PM Framework October 2015
5.2.1. Local SFL Allocation
With local label allocation, for each attached VPN, a PE SHOULD
allocate unique Synonymous Flow Label for each remote VRF on its
remote PEs. Two label allocation methods can be used:
1. A Synonymous Flow Label is allocated for each remote VRF. This
SFL would be used by the egress PE to identify the ingress VRF of the
received packet.
2. A Synonymous Flow Label is allocated for each remote-local VRF
pair. With this approach, the SFL can replace the VPN label in the
MPLS label stack of L3VPN packet as specified in Section 3.2.
With both methods, the allocated Synonymous Flow Label SHOULD be
advertised to remote PEs via the L3VPN control plane, where some
extensions to BGP is needed. Detailed BGP protocol extensions will
be specified in a future version.
5.2.2. Global SFL Allocation
With global label allocation, the SFLs are allocated by a network
controller, which obtains the VPN membership information via the VPN
membership auto-discovery. Two global label allocation methods can
be used:
1. A global SFL is allocated for each VPN. The combination of this
SFL and the global PE label can identify the ingress VRF of the
received packets.
2. A global SFL is allocated for each VRF on each PE. This SFL
itself can identify the ingress VRF of the received packets.
Detailed mechanisms about the global SFL allocation will be specified
in a companion document.
6. L3VPN Performance Monitoring
Since the challenge of source identification in L3VPN is resolved,
the procedures for the packet loss and delay measurement as defined
in [RFC6374] can be applied to L3VPN performance monitoring. Note
that in L3VPN performance monitoring, the source and destination
address TLV of the LM and DM messages SHOULD be set to the VPN-IPv4
or VPN-IPv6 address, which begins with the 8-byte Route Distinguisher
(RD) of the VRF and ends with a 4-byte IPv4 address or 16-byte IPv6
address of the ingress or egress PE node.
Dong, et al. Expires April 21, 2016 [Page 8]
Internet-Draft L3VPN PM Framework October 2015
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
TBD
9. References
9.1. Normative References
[I-D.bryant-mpls-synonymous-flow-labels]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft-
bryant-mpls-synonymous-flow-labels-01 (work in progress),
July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003,
<http://www.rfc-editor.org/info/rfc3443>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>.
Dong, et al. Expires April 21, 2016 [Page 9]
Internet-Draft L3VPN PM Framework October 2015
9.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., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
Authors' Addresses
Jie Dong
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Bhavani Parise
Cisco Systems
Email: bhavani@cisco.com
Dong, et al. Expires April 21, 2016 [Page 10]
