One document matched: draft-kumaki-pce-bgp-disco-attribute-03.txt
Differences from draft-kumaki-pce-bgp-disco-attribute-02.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Category: standards track KDDI R&D Labs
Created: March 8, 2009 T. Murai
Expires: September 8, 2009 FURUKAWA NETWORK
SOLUTION CORP.
BGP protocol extensions for Path Computation Element (PCE) Discovery
in a BGP/MPLS IP-VPN
draft-kumaki-pce-bgp-disco-attribute-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
In order to provide an end-to-end MPLS TE LSP between customer sites
within a BGP/MPLS IP-VPN, it is highly desirable for a Path
Computation Element (PCE) to be able to dynamically discover a set
of Path Computation Elements (PCEs) that know VPN routes. In
BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE
information. This document defines a new attribute and describes how
PCE information can be carried using BGP.
Conventions used in this document
K.Kumaki, et al. [Page 1]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
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].
Table of Contents
1. Introduction..................................................2
2. Problem Statement.............................................3
3. Terminology...................................................3
4. PCE Discovery Information.....................................4
4.1 BGP PCE Discovery Attribute..............................4
4.1.1 The BGP PCE Discovery TLV...............................4
4.1.1.1 PCE-ADDRESS Sub-TLV...................................5
5. BGP Specific Procedure........................................6
6. Security Considerations.......................................7
7. IANA Considerations...........................................7
8. References....................................................7
8.1 Normative References......................................7
8.2 Informative References....................................7
9. Acknowledgments...............................................8
10. 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 [PCEP].
Requirements for PCE in BGP/MPLS IP-VPNs [E2E-RSVP-TE] are described.
In such a case, PCEs are quite useful to establish an end-to-end MPLS
TE LSP between customer sites. As described above, it is highly
desirable for a Path Computation Element (PCE) to be able to
dynamically discover a set of Path Computation Elements (PCEs) that
know VPN routes within a BGP/MPLS IP-VPN. In BGP/MPLS IP-VPNs, it is
advantageous to use BGP to distribute PCE information.
This document defines BGP PCE Discovery Attribute and describes how
PCE information can be carried in the Path Attributes of the UPDATE
message described in [RFC4271]. The BGP PCE discovery attribute is
defined in section 3 and BGP specific procedure is described in
section 4.
K.Kumaki, et al. [Page 2]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
2. Problem Statement
In order to establish an end-to-end MPLS TE LSP between customer
sites within a BGP/MPLS IP-VPN, our goal is for a PCE to discover a
set of PCEs that know VPN routes selectively and automatically. The
point here is that only specific PCEs that know VPN routes should be
discovered automatically.
Consider that a service provider offers customers an end-to-end MPLS
TE LSP within a BGP/MPLS IP-VPN. Also, it is assumed that all PEs are
PCE. In such a case, a tail-end address to establish the end-to-end
MPLS TE LSP is included in VPN routes, and the VPN routes are carried
by MP-BGP [RFC4760]. Actually, a PE that includes the VPN membership
receives the VPN routes and a BGP next hop (i.e., a PE address that
advertises the VPN routes). In that sense, it is natural for MP-BGP
to carry PCE addresses (PE addresses) that know the VPN routes.
In this document, therefore, BGP PCE Discovery Attribute is defined
to discover PCEs 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
AS: Autonomous System
RR: Route Reflector
IGP: Interior Gateway Protocol. Either of the two routing protocols
Open Shortest Path First (OSPF) or Intermediate System to
Intermediate System (ISIS).
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.
K.Kumaki, et al. [Page 3]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
4. PCE Discovery Information
The PCE discovery information consists of the PCE location, an IPv4
and/or IPv6 address that are used to reach the PCE.
Here, the PCE discovery attribute for PCE in the Path Attributes of
BGP is defined.
4.1 BGP PCE Discovery Attribute
The PCE information is carried in the Path Attributes of the UPDATE
message described in [RFC4271]. Here, the Transitive bit is defined
as transitive.
The Attribute Flags will be 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 will be set to some value. <TBD>
The Path Attributes will be encoded as < Length, List of TLV >.
+---------------------------+
| Length (2 octets) |
+---------------------------+
| List of TLVs(variable) |
+---------------------------+
The meaning of the fields is described as follows:
a) Length :
The length in bytes of the list of TLVs carried in the Path Attribute.
b) List of TLVs :
This contains a list of TLVs each of which can be a BGP PCE Discovery
TLV.
4.1.1 The BGP PCE Discovery TLV
The BGP PCE Discovery TLV (PCED TLV) contains a non-ordered set of
sub-TLVs.
K.Kumaki, et al. [Page 4]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
The format of the BGP PCED TLV That is composed of 2 octets for the
type, 2 octets specifying the TLV length, and a value field. The
Length field defines the length of the value portion in octets.
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 //
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1
Length: Variable
Value: This comprises one or more sub-TLVs
Two sub-TLVs are defined:
Sub-TLV type Length Name
1 variable PCE-ADDRESS sub-TLV
2 4 PATH-SCOPE sub-TLV
The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within
The PCED TLV.
The following sub-sections describe the sub-TLVs that may be carried
within the PCED TLV.
4.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 make use of 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 twice, when the PCE has both an IPv4 and IPv6
address. 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.
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 | |
K.Kumaki, et al. [Page 5]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
// PCE IP Address //
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-ADDRESS sub-TLV format
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.
5. BGP Specific Procedure
The PCE Discovery Attribute can be carried in the Path Attribute of
BGP update messages. It can be handled regardless of IPv4/IPv6 and
VPNv4/VPNv6 routes in BGP update message.
Transmission processing:
BGP speakers advertise the PCE address with routes. The PCE address
is included in Path Attribute of BGP update message as BGP PCE
Discovery attribute. It can be configurable whether to advertise the
PCE address or not.
PCE address decision:
If a BGP speaker is PCE capable, the PCE address is the same as an
assigned address for BGP speaker itself. It may be a vrf interface
address or a loopback address. If a BGP speaker is not PCE capable,
it is decided by configuration or another method. This method is out
of scope of this document.
Receiving processing:
BGP speakers that receive PCE Discovery Attributes register in their
RIB with routes.
Procedure at path computation request:
K.Kumaki, et al. [Page 6]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
This part describes an inner process within a router between BGP
process and path computation process. If the inquiry of a PCE address
is received from path computation process, the BGP process retrieve
the pertinent route of RIB, and returns the address of PCE Discovery
Attribute. Path computation process transmits path computation
request to this address. If this attribute is not in RIB, the BGP
process notify path computation process error. If two or more PCE
addresses of PCE Discovery Attribute exists, all the addresses are
returned to path computation process.
6. 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.
The security issues are described in the existing BGP. [RFC2385]
7. IANA Considerations
IANA will assign BGP PCE Discovery Attribute type.
8. References
8.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", RFC2385, August 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References
[RFC4760] Bates, T., Rekhter, Y., Chandra, R., and Katz, D.,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[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.
[PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", Work in
K.Kumaki, et al. [Page 7]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
Progress, 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", Work in Progress, October 2008.
9. Acknowledgments
The author would like to express thanks to Makoto Nakamura, Adrian
Farrel and JP Vasseur for their helpful and useful comments and
feedback.
10. 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
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.
K.Kumaki, et al. [Page 8]
draft-kumaki-pce-bgp-disco-attribute-03 March 2009
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
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 03:21:40 |