One document matched: draft-kumaki-murai-pce-pcep-extension-l3vpn-03.txt
Differences from draft-kumaki-murai-pce-pcep-extension-l3vpn-02.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Category: standards track KDDI R&D Labs
Created: July 8, 2009 T. Murai, Ed.
Expires: January 8, 2010 FURUKAWA NETWORK
SOLUTION CORP.
PCEP extensions for a BGP/MPLS IP-VPN
draft-kumaki-murai-pce-pcep-extension-l3vpn-03.txt
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.
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.
Table of Contents
1. Introduction ..................................................2
2. Problem Statement .............................................3
3. Terminology ...................................................4
K.Kumaki, et al. [Page 1]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
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
4.2.3 PCRep message Processing at Egress PE (PCE)..............6
4.2.4 PCRep message Processing at Ingress PE (PCE).............6
5. Security Considerations .......................................7
6. IANA Considerations ...........................................7
7. References ....................................................7
7.1 Normative References.......................................7
7.2 Informative References.....................................7
8. Acknowledgments................................................8
9. Author's Addresses.............................................8
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
[RFC5440].
Service Providers have requirements to support PCE architecture for a
CE-CE MPLS TE LSP / a PE-PE MPLS TE LSP establishments in the context
of a BGP/MPLS IP-VPNs. [E2E-RSVP-TE][PCE-VPN-REQ] In order to
establish a customer MPLS TE LSP over BGP/MPLS IP-VPNs, PCEs need to
know the VPNv4/VPNv6 tail-end addresses 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. [RFC5441] 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 PCE functions are included in
PE. In this way, it is advantageous to use PCEs 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 4.1 and the
specific procedure is described in section 4.2.
K.Kumaki, et al. [Page 2]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
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 [RFC5440] (i.e., the
K.Kumaki, et al. [Page 3]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
message for VPN1 and the message for VPN2). Therefore, PCE2 can not
calculate an appropriate TE LSP between CEs per VPN.
Also, PCRep messages per VPN can not be identified at PCE1 due to the
above reason.
In order to distinguish between the VPN1 PCReq/PCRep messages and the
VPN2 PCReq/PCRep messages, an identifier in PCReq/PCRep 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 [RFC5440] 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:
K.Kumaki, et al. [Page 4]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
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) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
K.Kumaki, et al. [Page 5]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
When an ingress PE (PCE) receives 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
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) receives 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. The egress PE should store the new END-POINTS object for a
PCReq message in a VRF instance.
4.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 can 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 send it to an ingress PE.
4.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 6]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
Therefore, it is now possible to generate a PCRep message to send to
an appropriate PCC/PCE.
5. Security Considerations
This document defines PCEP extensions for BGP/MPLS IP-VPNs. Hence the
security of the PCE extensions relies on the security of PCEP.
The security issues are described in the existing PCEP. [RFC5440]
6. IANA Considerations
IANA will assign END-POINTS Object-Types for VPN-IPv4 address and
VPN-IPv6 address.
7. References
7.1 Normative References
[RFC5440] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", RFC5440,
March 2009.
7.2 Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "Path
Computation Element (PCE) Architecture", RFC 4655,
August 2006.
[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), October 2008.
[PCE-VPN-REQ] Yasukawa, S. and Farrel, A., "PCC-PCE Communication
Requirements for VPNs", draft-ietf-pce-vpn-req (Work
in Progress), March 2009.
[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.
[PCE-BGP-VPN] Kumaki, K. and Murai, "BGP protocol extensions for Path
Computation Element (PCE) Discovery in a BGP/MPLS IP-
K.Kumaki, et al. [Page 7]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
VPN ", draft-kumaki-pce-bgp-disco-attribute (Work in
Progress), July 2009.
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
Intellectual Property Statement
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
K.Kumaki, et al. [Page 8]
draft-kumaki-murai-pce-pcep-extension-l3vpn-03 July 2009
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
K.Kumaki, et al. [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 05:02:20 |