One document matched: draft-kumaki-murai-pce-pcep-extension-l3vpn-00.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Category: standard track KDDI R&D Labs
Created: April 18, 2008 T. Murai, Ed.
Expires: October 18, 2008 FURUKAWA NETWORK
SOLUTION CORP.
PCEP extensions for a BGP/MPLS IP-VPN
draft-kumaki-murai-pce-pcep-extension-l3vpn-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
It is highly desirable for VPN customers to be able to dynamically
establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In
such a scenario, it is advantageous to use PCE to calculate customer
MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP-
VPNs.
K.Kumaki and T.Murai [Page 1]
draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008
Table of Contents
1. Introduction..................................................2
2. Problem Statement.............................................3
3. Terminology...................................................4
4. Protocol Extensions and Procedures............................4
4.1 Type Definition............................................4
4.2 Handling...................................................5
4.2.1 PCReq message Processing at Ingress PE(PCE)..............5
4.2.2 PCReq message Processing at Egress PE(PCE)...............6
5. Security Considerations.......................................6
6. IANA Considerations...........................................6
7. References....................................................6
7.1 Normative References.......................................6
7.2 Informative References.....................................6
8. Acknowledgments................................................7
9. Author's Addresses.............................................7
1. Introduction
[RFC4655] describes the motivations and architecture for a Path
Computation Element (PCE)-based path computation model for Multi
Protocol Label Switching (MPLS) / Generalized MPLS (GMPLS) Traffic
Engineering (TE) Label Switched Paths (LSPs). In this model, path
computation requests are issued by a PCC to PCE that may be composite
or external. In case the PCC and PCE are not composite, a
request/response communication protocol is required to carry the
request and return the response. The requirements for such a
communication protocol are described in [RFC4657]. The communication
protocol between PCC and PCE, and between PCEs, is defined in [PCEP].
Service Providers have requirements to support PCE architecture for a
customer MPLS TE LSP establishment in the context of a BGP/MPLS IP-
VPNs. [E2E-RSVP-TE] In order to establish a customer MPLS TE LSP over
BGP/MPLS IP-VPNs, PCEs need to know the VPNv4/VPNv6 tail-end address
or PCE addresses for this tail-end address to forward to them, and
finally need to calculate the end-to-end customer MPLS TE LSP. [BRPC]
can be used as an example of calculate methods for a customer MPLS TE
LSP. Also, in order to discover these PCEs in BGP/MPLS IP-VPNs, [PCE-
BGP-VPN] is proposed. Note that it is assumed that a PE will be a PCE.
In this way, it is advantageous to use PCE to calculate customer MPLS
TE LSPs in the context of BGP/MPLS IP-VPNs.
This document defines new object types in END-POINTS object to
calculate the end-to-end customer MPLS TE LSP in the context of
BGP/IP-VPNs and describes a procedure of PCEP message including new
object types. The new object types are defined in section 5.1 and the
specific procedure is described in section 5.2.
K.Kumaki and T.Murai [Page 2]
draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008
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. CE0 and CE4 are head-end routers.
3. CE3 and CE7 are tail-end routers.
4. A same address (e.g., 192.0.2.1) is assigned at CE3 and CE7.
<----------------a customer MPLS TE LSP for VPN1------------>
(PCE1) (PCE2)
............. .............
. --- --- . --- --- --- --- . --- --- .
.|CE0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2| |CE3|.
. --- --- . --- --- --- --- . --- --- .
............. | | .............
(VPN1) | | (VPN1)
| |
............. | | .............
. --- --- . | | . --- --- .
.|CE4| |CE5|-------+ +-------|CE6| |CE7|.
. --- --- . . --- --- .
............. .............
(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 establish a customer MPLS TE
LSP between their sites (i.e., between CE0 and CE3, between CE4 and
CE7) In this case, CE0 and CE4 send a PCReq message to PCE1 to
establish customer MPLS TE LSPs between CE0 and CE3, CE4 and CE7,
respectively. After receiving these messages, PE1 can identify each
PCReq message (i.e., a message for VPN1 and a message for VPN2) from
each incoming interface. Afterwards, PCE1 forwards the messages to
PCE2 by BGP discovery [PCE-BGP-VPN]. PE2, however, can not identify
each PCReq message from current specification of [PCEP] (i.e., the
K.Kumaki and T.Murai [Page 3]
draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008
message for VPN1 and the message for VPN2). Therefore, PCE2 can not
calculate an appropriate TE LSP between CEs per VPN.
In order to distinguish between the VPN1 PCReq message and the VPN2
PCReq message, an identifier in PCReq messages is required.
In this document, new object types in END-POINTS object as an
identifier are defined to distinguish PCReq messages per VPN in the
context of BGP/MPLS IP-VPNs.
3. Terminology
LSP: Label Switched Path
TE LSP: Traffic Engineering Label Switched Path
MPLS TE LSP: Multi Protocol Label Switching TE LSP
Customer MPLS TE LSP: an end-to-end MPLS TE LSP for customers
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
PE: Provider Edge: Provider Edge Equipment that has direct
connections to CEs from the Layer3 point of view.
4. Protocol Extensions and Procedures
4.1 Type Definition
Two new Object-Types for VPN-IPv4 address and VPN-IPv6 address in
END-POINTS object described in [PCEP] are defined.
END-POINTS Object-Type is to be assigned by IANA (recommended
value=3 for VPN-IPv4 and 4 for VPN-IPv6)
The format of the END-POINTS object body for VPN-IPv4 (Object-
Type=3) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K.Kumaki and T.Murai [Page 4]
draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008
| |
| 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) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Handling
It assumes that ingress PEs and egress PEs in the context of BGP/MPLS
IP-VPNs have PCE capabilities. It is considered that ingress PEs and
egress PEs are not PCEs (e.g., external PCE models). However, this
topic is for further study.
4.2.1 PCReq message Processing at Ingress PE(PCE)
When an ingress PE(PCE) received a PCReq message from a PCC/PCE, it
can distinguish a VRF instance that is associated with an incoming
interface. The ingress PE deals with a destination IPv4/IPv6 address
in END-POINTS object as a destination VPN-IPv4/VPN-IPv6 address in
the VRF instance. Afterwards, the destination VPN-IPv4/VPN-IPv6
address is looked up in the context of VRF instance, and the BGP
K.Kumaki and T.Murai [Page 5]
draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008
next-hop for this destination is identified. The destination VPN-
IPv4/VPN-IPv6 address in a new END-POINTS object consists of the
original destination IPv4/IPv6 address in END-POINTS object and the
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. Note
that 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.
The ingress PE will send the PCReq message to next PCE (maybe an
egress PE for BGP/MPLS IP-VPNs) if it needs to send it. Finally, the
ingress PE should replace the incoming END-POINTS object from PCC/PCE
into the new END-POINTS object.
4.2.2 PCReq message Processing at Egress PE(PCE)
When an egress PE(PCE) received a PCReq message from an ingress
PE(PCE), it can distinguish a 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 if it needs to send it.
Afterwards, the egress PE should 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 source and the
destination addresses in the original END-POINTS object are IPv4/IPv6
ones.
5. Security Considerations
We will write security considerations in next version.
6. IANA Considerations
IANA will assign END-POINTS Object-Types for VPN-IPv4 address and
VPN-IPv6 address.
7. References
7.1 Normative References
[PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", draft-ietf-
pce-pcep (Work in Progress), March 2008.
7.2 Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "Path
Computation Element (PCE) Architecture", RFC 4655,
August 2006.
K.Kumaki and T.Murai [Page 6]
draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008
[RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol
Generic Requirements", RFC4657, September 2006.
[E2E-RSVP-TE] Kumaki, K., Zhang, R. and Kamite, Y., "Requirements for
supporting Customer RSVP and RSVP-TE over a BGP/MPLS
IP-VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts (Work in
Progress), April 2008.
[BRPC] Vasseur, J.-P., et al., "A Backward Recursive PCE-
based Computation (BRPC) Procedure To Compute Shortest
Constrained Inter-domain Traffic Engineering Label
Switched Paths", draft-ietf-pce-brpc (Work in
Progress), April 2008.
[PCE-BGP-VPN] Kumaki, K. and Murai, "BGP protocol extensions for Path
Computation Element (PCE) Discovery in a BGP/MPLS IP-
VPN ", draft-kumaki-pce-bgp-disco-attribute (Work in
Progress), April 2008.
8. Acknowledgments
The author would like to express thanks to Makoto Nakamura for his
helpful and useful comments and feedback.
9. Author's Addresses
Kenji Kumaki (Editor)
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama 356-8502, JAPAN
Email: ke-kumaki@kddi.com
Tomoki Murai (Editor)
FURUKAWA NETWORK SOLUTION CORP.
5-1-9, HIGASHI-YAWATA, HIRATSUKA
Kanagawa 254-0016, JAPAN
Email: murai@fnsc.co.jp
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
K.Kumaki and T.Murai [Page 7]
draft-kumaki-murai-pce-pcep-extension-l3vpn-00 April 2008
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
K.Kumaki and T.Murai [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 05:01:33 |