One document matched: draft-kumaki-pce-bgp-disco-attribute-01.txt
Differences from draft-kumaki-pce-bgp-disco-attribute-00.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Category: standard track KDDI R&D Labs
Created: April 18, 2008 T. Murai
Expires: October 18, 2008 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-01.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 Path Computation Clients (PCCs) to be
able to dynamically discover a set of Path Computation Elements
(PCEs) when PCCs/PCEs request a path computation to PCEs within an
AS and across ASs. In such a scenario, specifically BGP/MPLS IP-VPNs,
it is advantageous to use BGP to distribute PCE information. This
K.Kumaki, et al. [Page 1]
draft-kumaki-pce-bgp-disco-attribute-01 April 2008
document defines a new attribute and describes how PCE information
can be carried using BGP.
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. PCE Information...............................................4
3.1 BGP PCE Discovery Attribute..............................4
4. BGP Specific Procedure........................................5
5. Security Considerations.......................................5
6. IANA Considerations...........................................6
7. References....................................................6
7.1 Normative References.......................................6
7.2 Informative References.....................................6
8. Acknowledgments................................................6
9. Author's Addresses.............................................6
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].
In order for a PCC and PCE to communicate, the PCC must know the
location of the PCE. Also, in order for PCEs to communicate, the PCE
must know the location of another PCE as well. Actually, a number of
PCEs can be contained in BGP/MPLS IP-VPNs, where it is assumed that a
PCC will be CE and a PCE will be PE. Requirements for PCE in BGP/MPLS
IP-VPN [E2E-RSVP-TE] are described. In that sense, it is highly
desirable to have a mechanism for dynamic PCE discovery. Here, our
aim is to discover PCEs selectively and automatically in BGP/MPLS IP-
VPNs. The point here is that all PCEs are not necessarily discovered
automatically and only specific PCEs that know VPN routes should be
discovered automatically. However, if a PCE discovers other PCEs by
IGP discovery [RFC5088] [RFC5089], the PCE establishes PCEP sessions
for discovered PCEs. In a BGP/MPLS IP-VPN, PCEs should not establish
full mesh PCEP sessions regardless of VPN routes. The disadvantage is
a scalability of PCE based on the number of PCEP sessions. Therefore,
in order to discover PCEs, BGP will be extended based on RFC4364 and
needs to carry PCE information. Specifically, a PCE address for a
VPNv4/VPNv6 tail-end address(es) (VPNv4/VPNv6 route(s)) is required.
K.Kumaki, et al. [Page 2]
draft-kumaki-pce-bgp-disco-attribute-01 April 2008
Afterwards, PCEs discover the PCE address or some PCE addresses
automatically and establish PCEP session(s) for discovered PCE(s).
As described in [PCE-DISCO-BGP], PCE discovery information consists
of PCE location, PCE inter-domain functions, PCE domain visibility,
PCE destination domains and a set of general PCECP capabilities. The
PCE discovery information is described in [RFC5088] and [RFC5089],
and the same TLVs can be used for BGP. Therefore, in order to
establish a BGP session, a BGP speaker needs to have this capability.
However, if RRs are deployed in BGP/MPLS IP-VPNs, service providers
need to upgrade all RRs to recognize this capability. From the
service provider perspective, it is not desirable to upgrade all RRs
in order to add only one function (i.e., PCE function). Therefore,
BGP PCE discovery attribute is defined in this document. In this case,
needless to say, RRs are not required to upgrade and only PEs that
speaks PCE protocol are required to upgrade.
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.
2. 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.
K.Kumaki, et al. [Page 3]
draft-kumaki-pce-bgp-disco-attribute-01 April 2008
PE: Provider Edge: Provider Edge Equipment that has direct
connections to CEs from the Layer3 point of view.
3. PCE Information
The PCE discovery information as described in [PCE-DISCO-BGP]
consists of PCE location, PCE inter-domain functions, PCE domain
visibility, PCE destination domains and a set of general PCECP
capabilities. The PCE discovery information is described in [RFC5088]
and [RFC5089], and the same TLVs can be used for BGP.
Here, the PCE discovery attribute for PCE in the Path Attributes of
BGP is defined.
3.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 non-transitive. However, it is a future work though the transitive
bit can be defined as 1 (transitive).
The Attribute Flags will be set as follows:
The Optional bit set to 1(optional).
The Transitive bit set to 0(non-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 PCE Discovery TLV.
The encoding of the PCE discovery TLV and its sub-TLVs will be the
K.Kumaki, et al. [Page 4]
draft-kumaki-pce-bgp-disco-attribute-01 April 2008
same as that of the corresponding OSPF PCE TLVs described in
[RFC5088] and [RFC5089].
4. 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:
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.
5. 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]
K.Kumaki, et al. [Page 5]
draft-kumaki-pce-bgp-disco-attribute-01 April 2008
6. IANA Considerations
IANA will assign BGP PCE Discovery Attribute type.
7. References
7.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.
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.
[PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE)
communication Protocol (PCEP) - Version 1", Work in
Progress, March 2008.
[RFC5088] Le Roux, J.L., Vasseur, J.-P., Ikejiri, Y., Zhang, R.,
"OSPF protocol extensions for Path Computation Element
(PCE) Discovery", RFC5088, January 2008.
[RFC5089] Le Roux, J.L., Vasseur, J.-P., Ikejiri, Y., Zhang, R.,
"IS-IS protocol extensions for Path Computation Element
(PCE) Discovery", RFC5089, January 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, April 2008.
[PCE-DISCO-BGP] Vijayanand, C., Bhattacharya, S. and Kumar, P., "BGP
Protocol extensions for PCE Discovery across
Autonomous systems", Work in Progress, June 2007.
8. Acknowledgments
The author would like to express thanks to Makoto Nakamura for his
helpful and useful comments and feedback.
9. Author's Addresses
K.Kumaki, et al. [Page 6]
draft-kumaki-pce-bgp-disco-attribute-01 April 2008
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
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
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
K.Kumaki, et al. [Page 7]
draft-kumaki-pce-bgp-disco-attribute-01 April 2008
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, et al. [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 03:21:08 |