One document matched: draft-kumaki-pce-bgp-disco-attribute-06.txt
Differences from draft-kumaki-pce-bgp-disco-attribute-05.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Intended Status: Standards Track KDDI Corporation
Created: March 8, 2010 T. Murai
Expires: September 8, 2010 Furukawa Network Solutions Corp.
T. Yamagata
KDDI Corporation
C. Sasaki
KDDI R&D Labs
BGP Protocol Extensions for Path Computation Element (PCE) Discovery
in a BGP/MPLS IP-VPN
draft-kumaki-pce-bgp-disco-attribute-06.txt
Abstract
Connectivity between customer sites in an IP Virtual Private Network
(VPN) supported by BGP/MPLS may be achieved using MPLS Traffic
Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs
must be computed to provide the end-to-end connectivity desired, and
the paths selected may depend upon the VPN being served, and the
location and reachability of target addresses within customer sites.
The Path Computation Element (PCE) is a server that can compute the
paths of TE LSPs in an MPLS network. Where one or more VPNs is
supported over a core network, different PCEs may serve computations
for different VPNs.
PCE discovery allows a Path Computation Client (PCC) to determine
which PCEs are available to service its computation requests.
Using an IGP to distribute PCE discovery information for VPN use
would result in the information being needlessly flooded to all core
nodes regardless of whether they are aware of the VPN. These nodes do
not need to be aware of per-VPN PCE function. This document describes
how BGP can be used to distribute PCE discovery information
specifically for use in VPN path computation.
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."
K. Kumaki, et al. [Page 1]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
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 September 8, 2010.
Copyright Notice
Copyright (c) 2010 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.
Conventions used in this document
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 [RFC2119].
1. Introduction
[RFC4364] documents 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 Edge (PE) router. It is possible for CE routers to be
attached to multiple PE routers. BGP [RFC4271] can be used to
exchange VPN route information between the PE routers.
K. Kumaki, et al. [Page 2]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
[RFC4655] describes the motivations and architecture for a PCE-based
path computation model for MPLS and GMPLS Traffic Engineering (TE)
Label Switched Paths (LSPs). In this model, path computation requests
are issued by a Path Computation Client (PCC) to a PCE. If the PCC
and PCE are not colocated, a request/response communication protocol
is needed to carry the request and to return the response. The
requirements for such a communication protocol are described in
[RFC4657]. The Path Computation Element Communication Protocol
(called PCEP) is defined in [RFC5440].
When a PCC is not colocated with the PCE, the PCC must determine the
location of the PCE that will service its requests. As described in
[RFC4655], the knowledge of the location of a PCE may be achieved
through local configuration at the PCC or may rely on a protocol-
based discovery mechanism.
[E2E-RSVP-TE] lists requirements for supporting customer Resource
Reservation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP VPN.
Section 5.8 of that document states that a solution should support
the use of per-VPN PCEs for determining the paths of end-to-end MPLS
TE LSPs between customer sites.
Requirements for the use of PCE to support VPNs are discussed in
[PCE-VPN]. That document notes that there is likely to be a
correlation between the VPN auto-discovery / membership distribution
mechanism and the PCE discovery mechanism used for per-VPN PCEs. But
the document sets PCE discovery as out of scope.
In a VPN model as described in [E2E-RSVP-TE], CEs or PEs may be PCCs,
and PEs or Provider (P) core nodes may be PCEs. There may be very
many VPNs supported by a network and many customer sites within each
VPN. Furthermore, manual configuration of VPN site information is
burdensome and error-prone. Therefore, an automated, protocol-based
solution is desirable for per-VPN PCE discovery.
[RFC5088] and [RFC5089] describe IGP-based PCE discovery mechanisms.
These mechanisms are ideal where all or a large percentage of the
nodes in a network need to know the location of the PCE. However, in
the case of per-VPN PCEs, it is only the CE and PE nodes that
participate in support for the specific VPN that need to know the
location of the PCE that serves that VPN. Furthermore, in a VPN
environment, the IGP used in the core does not distribute information
to CE nodes. Therefore, the IGP solutions are not optimal.
This document leverages the use of BGP in VPNs to additionally
distribute per-VPN PCE location and capabilities information. A new
BGP PCE Discovery Attribute is defined and this is carried in the
Path Attributes of the BGP UPDATE message.
K. Kumaki, et al. [Page 3]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
2. PCE Discovery Information
As defined in [RFC4674], the mandatory PCE discovery information
consists of:
- Discovery of PCE Location
This is an IPv4 and/or an IPv6 address used to reach the PCE.
- Domain Visibility Information
The computation domains that the PCE serves must be advertised so
that PCCs know whether the PCE can satisfy their requests. In the
context of per-VPN PCEs, the computation domains are the VPNs.
2.1. BGP PCE Discovery Attribute
The PCE information is carried in the Path Attributes of the UPDATE
message described in [RFC4271]. The Transitive bit is defined to be
set as transitive.
The Attribute Flags are set as follows:
The Optional bit set to 1 (optional).
The Transitive bit set to 1 (transitive).
The Partial bit set to 0 (complete).
The Extended Length bit set to 1 (2 octets).
The Attribute Type is to be assigned by IANA. <recommended value=20>
The Path Attributes will be encoded as < Length, List of TLVs >.
+---------------------------+
| Length (2 octets) |
+---------------------------+
| List of TLVs (variable) |
+---------------------------+
The meaning of the fields is as follows.
Length :
The length in bytes of the list of TLVs carried in the Path
Attribute.
List of TLVs :
This contains a list of TLVs each of which can be a BGP PCE
Discovery TLV.
2.1.1. The BGP PCE Discovery TLV
K. Kumaki, et al. [Page 4]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
The BGP PCE Discovery TLV (PCED TLV) contains a non-ordered set of
sub-TLVs.
The BGP PCED TLV is composed of 2 octets for the type, 2 octets
specifying the length of the value portion in octets, and a value
field.
The BGP PCED TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
Type: 1
Length: Variable
Value: This comprises one or more sub-TLVs
One sub-TLV is defined:
Sub-TLV type Length Name
------------ -------- --------------------
1 variable PCE-ADDRESS sub-TLV
The following sub-section describes the sub-TLVs that may be carried
within the PCED TLV.
2.1.1.1. PCE-ADDRESS Sub-TLV
The PCE-ADDRESS sub-TLV specifies an IP address that can be used to
reach the PCE. It is RECOMMENDED to use an address that is always
reachable, provided that the PCE is alive and reachable.
The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
PCED TLV. It MAY appear more than once, when the PCE has an address
from more than one address type (i.e., both IPv4 and IPv6). It MUST
NOT appear more than once for the same address type. If it appears
more than once for the same address type, only the first occurrence
is processed and any others MUST be ignored.
K. Kumaki, et al. [Page 5]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
The format of the PCE-ADDRESS sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCE IP Address //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
Type: 1
Length: 8 (IPv4) or 20 (IPv6)
Address-type: 1 IPv4
2 IPv6
Reserved: SHOULD be set to zero on transmission and MUST be
ignored on receipt.
PCE IP Address: The IP address to be used to reach the PCE.
3. Procedures
The PCE Discovery Attribute can be carried in the Path Attribute of
BGP UPDATE messages. It can be handled regardless of whether
IPv4/IPv6 and VPNv4/VPNv6 routes are present in the BGP UPDATE
messages.
3.1. Transmission Processing
BGP speakers can advertise the address of a per-VPN PCE at the same
time as it advertises routes for the VPN. The PCE address is included
in the Path Attribute of BGP UPDATE message as a BGP PCE Discovery
Attribute.
The PCE advertised is associated with the VPN instance to which the
BGP UPDATE applies. Thus, the mandatory Domain Visibility Information
noted in Section 2 is distributed implicitly.
It can be made a configuration choice whether to advertise the PCE
address or not.
K. Kumaki, et al. [Page 6]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
3.1.1. Choice of PCE Address
If a BGP speaker is PCE capable, the PCE address is an assigned
address for the BGP speaker itself. It may be a VPN Routing and
Forwarding (VRF) interface address or a loopback address. If a BGP
speaker is not PCE capable, the address of the PCE may be decided by
configuration or any other method; this method is out of scope of
this document.
3.2. Receiver Processing
BGP speakers that receive PCE Discovery Attributes store the
information for use when a PCEP request needs to be sent.
The PCE advertised is associated with the VPN instance to which the
BGP UPDATE applies.
3.3. Procedure at Path Computation Request:
When a router needs a path computed for a particular VPN and the
router is not able to perform the computation itself, it looks up
the address of the per-VPN PCE. If no address is found it cannot
perform the path computation and returns an error. If one or more
address is found it selects one according to local policy (see
[RFC4655] and [RFC5440]) and acts as a PCC to send the computation
request to the PCE according to [RFC5440].
4. Security Considerations
This document defines BGP extensions for PCE discovery across an
administrative domain. Hence the security of the PCE discovery relies
on the security of BGP within a single administrative domain.
Increased information dissemination with BGP makes the network more
vulnerable to any attack on BGP. Therefore the use of BGP security
mechanisms is RECOMMENDED.
The security issues for BGP are described in [RFC2385].
5. IANA Considerations
IANA maintains a registry of attribute types for the Path Attribute
called 'BGP Path Attributes'.
IANA is requested to assign a new type for the BGP PCE Discovery
Attribute type defined in Section 2.1 as follows:
K. Kumaki, et al. [Page 7]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
Value Code Reference
----- ----------------------- ---------
<TBD> PCE Discovery Attribute This.ID
6. References
6.1. Normative References
[RFC4271] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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.
[RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol
Generic Requirements", RFC 4657, September 2006.
[RFC4674] Le Roux, J.L. (Ed.), "Requirements for Path Computation
Element (PCE) Discovery", RFC 4674, October 2006.
[RFC5088] Le Roux, J.L., Vasseur, JP., Ikejiri, Y., and Zhang,
R., "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, J.L., Vasseur, JP., Ikejiri, Y., and Zhang,
R., "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5440] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", RFC 5440,
November 2008.
[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.
K. Kumaki, et al. [Page 8]
draft-kumaki-pce-bgp-disco-attribute-06 March 2010
[PCE-VPN] Yasukawa, S. and Farrel, A. "PCC-PCE Communication
Requirements for VPNs", draft-ietf-pce-vpn-req, work in
progress.
7. Acknowledgments
The author would like to express thanks to Makoto Nakamura, Adrian
Farrel, JP Vasseur, and Daniel King for their helpful and useful
comments and feedback.
8. Authors' Addresses
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, 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
Tomohiro Yamagata
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, Japan
Email: to-yamagata@kddi.com
Chikara Sasaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama 356-8502, Japan
Email: ch-sasaki@kddilabs.jp
K. Kumaki, et al. [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 03:21:07 |