Internet DRAFT - draft-kumaki-murai-pce-pcep-extension-l3vpn
draft-kumaki-murai-pce-pcep-extension-l3vpn
Network Working Group
Internet Draft K. Kumaki, Ed.
Intended Status: Experimental KDDI Corporation
Expires: March 28, 2016 T. Murai
Furukawa Network Solutions Corp.
T. Miyasaka
KDDI Corporation
September 25, 2015
PCEP extensions for a BGP/MPLS IP-VPN
draft-kumaki-murai-pce-pcep-extension-l3vpn-17.txt
Abstract
IP Virtual Private Networks (IP-VPNs) allow Service Providers to
offer customers connectivity between sites across an IP Backbone.
These VPNs can be supported using BGP/MPLS and the connections can be
created by using MPLS Traffic Engineered (TE) Label Switched Paths
(LSPs). The paths of these LSPs must be computed to provide the
connectivity between customer sites. Path selection may be dependent
on a variety of factors including traffic engineering constraints
and bandwidth requirements.
It is highly desirable for VPN customers to be able to dynamically
establish their MPLS TE LSPs for interconnectivity between BGP/MPLS
IP-VPN sites. The Path Computation Element (PCE) can determine the
optimal paths of TE LSPs within an MPLS network. This document
defines how to extend the PCEP to support the dynamic creation of
MPLS TE LSPs between BGP/MPLS IP-VPN sites.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 28, 2015.
K.Kumaki, et al. [Page 1]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
Copyright Notice
Copyright (c) 2014 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative works
of it may not be created outside the IETF Standards Process, except
to format it for publication as an RFC or to translate it into
languages other than English.
Table of Contents
1. Introduction.................................................3
2. Problem Statement............................................4
3. Protocol Extensions and Procedures...........................5
3.1 Type Definition..........................................5
3.2 PCE Capabilities.........................................6
3.2.1 PCReq message Processing at Ingress PE (PCE)...........6
3.2.2 PCReq message Processing at Egress PE (PCE)............7
3.2.3 PCRep message Processing at Egress PE (PCE)............7
3.2.4 PCRep message Processing at Ingress PE (PCE)...........7
4. Security Considerations......................................8
5. IANA Considerations..........................................8
6. References...................................................8
6.1 Normative References.....................................8
6.2 Informative References...................................8
7. Acknowledgments..............................................9
8. Authors' Addresses...........................................9
K.Kumaki, et al. [Page 2]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
1. Introduction
[RFC4364] describes how a Service Provider could use an IP backbone
to provide IP Virtual Private Networks (VPNs) to its customers. Each
VPN contains at least one Customer Edge (CE) router which is attached
to a Provider (PE) router. It is possible for CE routers to be
attached to multiple PE routers. The Border Gateway Protocol (BGP)
[RFC4271] can be used to exchange VPN route information between the
PE routers.
[RFC4655] describes the motivation and architecture for the Path
Computation Element (PCE). The PCE can be used to compute the routes
for MPLS and GMPLS Traffic Engineering (TE) Label Switched Paths
(LSPs). A path computation request is issued by a Path Computation
Client (PCC) to the PCE. The communication protocol between PCCs and
PCEs is called the Path Computation Element Communication Protocol
(PCEP) and is defined in [RFC5440].
This document describes experimental mechanisms that use the PCE
architecture to establish connectivity between IP/MPLS VPNs. And
defines extensions to PCEP to support this experimental mechanisms.
The requirements for establishing connectivity between CE and PE
sites are defined in [RFC5824]. The extensions to support RSVP-TE
between customer sites when a single PE supports multiple VPNs are
experimented in [RFC6882].
In order to establish a customer MPLS TE LSP over a BGP/MPLS IP-VPN,
a PCE needs to know the VPNv4/VPNv6 tail-end addresses (source and
destination) and the addresses for the PEs that provide access to
them. Additionally the PCE needs to calculate the route of an
end-to-end customer MPLS TE LSP. [RFC5441] describes the Backward
Recursive Path Computation (BRPC) technique that could be used to
compute the route of a customer MPLS TE LSP.
It is assumed in this experiment that PCE functions are included in
PE routers that are fully accessible to all PCCs in the VPN.
This experiment defines new object types in the PCEP END-POINTS
object to calculate the end-to-end customer MPLS TE LSP used for
BGP/IP-VPNs, and verifies a procedure for the PCEP message
processing. The new object types are defined in Section 3.1 and the
specific procedure is described in Section 3.2.
K.Kumaki, et al. [Page 3]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
2. Problem Statement
PCEs in the context of BGP/MPLS IP-VPNs are shown in figure 1. Here,
we make the following set of assumptions.
1. VPN1 and VPN2 are completely different customers.
2. C0 and C4 are head-end routers.
3. C3 and C7 are tail-end routers.
4. The same address (e.g., 192.0.2.1) is assigned to both C3 and C7.
<---------------A customer MPLS TE LSP for VPN1----------->
(PCE1) (PCE2)
............ ............
. -- --- . --- --- --- --- . --- -- .
.|C0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |C3|.
. -- --- . --- --- --- --- . --- -- .
............ | | ............
(VPN1) | | (VPN1)
| |
............ | | ............
. -- --- . | | . --- -- .
.|C4| |CE5|-------+ +-------|CE6| |C7|.
. -- --- . . --- -- .
............ ............
(VPN2) (VPN2)
<--------------A customer MPLS TE LSP for VPN2------------>
^ ^
| |
VRF instance VRF instance
<--Customer--> <------BGP/MPLS IP-VPN------> <-Customer->
network network
Figure 1 PCEs in the context of BGP/MPLS IP-VPNs
Consider that customers in VPN1 and VPN2 would like to establish
customer MPLS TE LSPs between their sites (i.e., between CE0 and
CE3, and between CE4 and CE7). The following PCEP requests will
occur:
1. C0 send a PCReq message to PCE1 to compute a path for a
customer MPLS TE LSPs between C0 and C3.
2. C4 send a PCReq message to PCE1 to compute a path for a
customer MPLS TE LSPs between C4 and C7.
K.Kumaki, et al. [Page 4]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
PCE1 (PE1) is able to distinguish to which VPN the received requests
apply from the interface over which the requests were received. PCE1
can forward the request to PCE2 having been configured with or
discovered the existence and address of PCE2. However, based on the
PCEP specification defined in [RFC5440] and the fact that the two
messages come from the same cooperating PCE (PCE1), PCE2 cannot
determine to which VPN the computation requests apply. Therefore,
PCE2 cannot calculate the requested paths.
In order to distinguish between the VPN1 PCReq messages and the VPN2
PCReq messages, a VPN identifier is required in PCReq messages. This
identifier can be duplicated into the PCRep messages to achieve
symmetry and allow cross-checking.
This experiment defines a new object type for the END-POINTS object
to be used to facilitate VPN identification.
3. Protocol Extensions and Procedures
The new END-POINTS Object-Types for the PCEP request allow the
PCE to distinguish the VRF instance that is associated with the
incoming PCEP message.
3.1 Type Definition
The END-POINTS Object is defined in [RFC5440].
Two new Object-Types are defined to carry VPN-IPv4 addresses and
VPN-IPv6 addresses.
END-POINTS Object-Type is to be assigned by IANA (recommended
values: 3 for VPN-IPv4 and 4 for VPN-IPv6)
The format of the END-POINTS object body for VPN-IPv4 is as follows:
K.Kumaki, et al. [Page 5]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source VPN-IPv4 address (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination VPN-IPv4 address (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the END-POINTS object body for VPN-IPv6 (Object-
Type=4) is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Source VPN-IPv6 address (24 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Destination VPN-IPv6 address (24 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2 PCE Capabilities
It is assumed that the BGP/MPLS IP-VPN ingress and egress PE routers
have PCE capabilities. External PCE architectures will require
further study and will be discussed in future revisions of this
document.
3.2.1 PCReq Message Processing at Ingress PE (PCE)
When an ingress PE (PCE) receives a PCReq message from a PCC/PCE, it
can distinguish the VRF instance that is associated with an incoming
interface:
1. The ingress PE processes the destination IPv4/IPv6 address
in the END-POINTS object as the destination VPN-IPv4/VPN-IPv6
address for the VRF instance.
K.Kumaki, et al. [Page 6]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
2. The destination VPN-IPv4/VPN-IPv6 address is looked up in the
context of VRF instance, and the BGP next-hop for this
destination is identified.
3. The destination VPN-IPv4/VPN-IPv6 address is then added to
END-POINTS object consisting of the original destination
IPv4/IPv6 address in END-POINTS object followed by the 8
octet Route Distinguisher (RD).
Note that the RD is specified by the BGP next-hop for the destination
VPN-IPv4/VPN-IPv6 address. The source VPN-IPv4/VPN-IPv6 address in
the new END-POINTS object consists of the original IPv4/IPv6 address
in END-POINTS object and the RD. Also the RD is used by this ingress
PE to advertise customer's prefix including the source
VPN-IPv4/VPN-IPv6 address into the VRF instance.
4. If necessary, the ingress PE will then send the PCReq message
to next PCE (the egress PE for BGP/MPLS IP-VPNs).
5. Finally, the ingress PE should replace the incoming END-POINTS
object from the PCC/PCE into the new END-POINTS object.
3.2.2 PCReq Message Processing at Egress PE (PCE)
When an egress PE (PCE) receives a PCReq message from an ingress
PE(PCE), it is able to distinguish the VRF instance from the
destination VPN-IPv4/VPN-IPv6 address in the new END-POINTS object.
The egress PE will send a PCReq message to next PCE (PE) if needed.
The egress PE will then remove the RD from the source and the
destination VPN-IPv4/VPN-IPv6 addresses in the new END-POINTS object
received from the ingress PE. Finally, the egress PE should store the
new END-POINTS object for a PCReq message in a VRF instance.
3.2.3 PCRep message Processing at Egress PE (PCE)
When an egress PE (PCE) receives a PCRep message for a PCReq message
from a previous PCE (i.e. CE), it will look up the new END-POINTS
object associated with the PCReq message for the PCRep message.
The egress PE performs a path computation. Note that the path
computation procedure itself is out of scope in this document.
Afterwards, the egress PE adds the new END-POINTS object in a PCRep
message and sends it to an ingress PE.
3.2.4 PCRep Message Processing at Ingress PE (PCE)
When an ingress PE (PCE) receives a PCRep message for a PCReq message
from an egress PE (PCE), it can distinguish a VRF instance from the
source VPN-IPv4/VPN-IPv6 address in the new END-POINTS object.
K.Kumaki, et al. [Page 7]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
Therefore, it is now possible to generate a PCRep message to send to
an appropriate PCC/PCE.
4. Security Considerations
This document defines PCEP extensions for BGP/MPLS IP-VPNs. The
security of the PCE extensions relies on the security of PCEP
[RFC5440]. It is important that implementations conform to security
features defined in [RFC5440].
5. IANA Considerations
IANA maintains a registry of PCEP parameters. As described in
Section 3.1 (Type Definition), two Object-Types have been defined.
IANA is requested to make the following allocations from the
"PCEP Objects" sub-registry.
Object-Class Name Object-Type Reference
Value
4 END-POINTS 1: IPv4 addresses [RFC5440]
2: IPv6 addresses [RFC5440]
3: VPN-IPv4 addresses [This.I-D]
4: VPN-IPv6 addresses [This.I-D]
5-15: Unassigned
The values 3 and 4 are suggested.
6. References
6.1 Normative References
[RFC4271] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[RFC5440] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", RFC5440,
March 2009.
K.Kumaki, et al. [Page 8]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
6.2 Informative References
[RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "Path
Computation Element (PCE) Architecture", RFC 4655,
August 2006.
[RFC5824] Kumaki, K., Zhang, R., and Kamite, Y., "Requirements
for supporting Customer RSVP and RSVP-TE over a
BGP/MPLS IP-VPN", RFC 5824, April 2010.
[RFC6882] Kumaki, K., Murai, T., Matsushima, S., and Jiang, P.,
"Support for Resource Reservation Protocol Traffic
Engineering (RSVP-TE) in Layer 3 Virtual Private
Networks (L3VPNs)", RFC 6882, March 2013.
[RFC5441] Vasseur, J.-P., et al., "A Backward Recursive PCE-
based Computation (BRPC) Procedure To Compute Shortest
Constrained Inter-domain Traffic Engineering Label
Switched Paths", RFC5441, April 2009.
7. Acknowledgments
The author would like to express thanks to Makoto Nakamura for his
helpful and useful comments and feedback.
8. Authors' Addresses
Kenji Kumaki
KDDI Corporation
1-20-1 Nishishinjuku
Shinjuku-ku, Tokyo 160-0023
Japan
Email: ke-kumaki@kddi.com
Tomoki Murai
FURUKAWA NETWORK SOLUTION CORP.
5-1-9, HIGASHI-YAWATA, HIRATSUKA
Kanagawa 254-0016, JAPAN
Email: murai@fnsc.co.jp
K.Kumaki, et al. [Page 9]
draft-kumaki-murai-pce-pcep-extension-l3vpn-17 March 2016
Takuya Miyasaka
KDDI Corporation
1-20-1 Nishishinjuku
Shinjuku-ku, Tokyo 160-0023
Japan
Email: ta-miyasaka@kddi.com
Chikara Sasaki
KDDI Corporation
1-20-1 Nishishinjuku
Shinjuku-ku, Tokyo 160-0023
Japan
Email: ch-sasaki@kddi.com
Peng Jiang
KDDI Corporation
1-20-1 Nishishinjuku
Shinjuku-ku, Tokyo 160-0023
Japan
Email: pe-jiang@kddi.com
