INTERNET DRAFT Vijayanand C
Expiration Date: January 2007 HCL Technologies
Somen Bhattacharya
Avici Systems
BGP Protocol extensions for PCE Discovery across Autonomous systems
draft-vijay-somen-pce-disco-proto-bgp-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 Internet Society (2006).
Abstract
It is desirable for a PCC to dynamically discover a PCE and its
capabilities for computing paths which span multiple areas and
autonomous systems. When the path to be computed spans across
multiple IGP domains or autonomous systems it is advantageous to use
BGP to distribute information about PCEs. This document describes
means to carry PCE discovery information using Multi-protocol
extensions of BGP(MP-BGP).
1. Introduction
The motivation for using PCE-based model for path computation in
MPLS networks is clearly detailed in [PCE-ARCH]. This model supports
separation of PCC and PCC. This also requires that PCC be aware of
PCE in its own domain and that in other domains for computing paths
spanning multiple domains, eg.as in inter-domain TE LSPs. The means
to discover PCE in the same IGP domain are described in [PCE-IGP-
DISCO], wherein the IGP is used to flood information on the PCE
capabilities. In order to discover PCEs across IGP domains and
autonomous systems a more scalable model than IGP flooding is
Vijayanand C [Page 1]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
required. This is also relevant since operators have policies
governing the import and export of routing information across their
domains. BGP is well suited for carring PCE information across
domains and autonomous systems.
This document describes how PCE information can be carried in
MP-REACH-NLRI of BGP update messages. The PCE Discovery TLV and PCE
Status TLV defined in [PCE-ARCH],which represent the state and
status of PCE, will be carried in the NLRI information of the MP-
REACH NLRI.
The PCE information is described in section 3 and BGP specific
procedures and interactions with IGP are described in section 4.
2. Terminology
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 [RFC-WORDS].
The reader is assumed to be familiar with the terminology in [PCE-
ARCH] and [PCE-IGP-DISCO]
AS - Autonomous system
ASBR - Autonomous System Border Router
Inter-AS TE LSP - A TE LSP whose path crosses one or more ASes
or sub ASes
NLRI - Network Layer Reachability Information
PCC - Path Computation Client. An entity or application
requesting path computation from a Path computation
element
PCE - Path Computation Element. An entity or application
capable of computing paths over a network topology
subject to constraints.
TE LSPs - Traffic Engineered Label Switched Path
3. PCE Information
The PCE information advertised includes PCE discovery information
and PCE status information.
This document describes extensions to the PCE discovery
information that is defined in [PCE-DISCO-IGP} that is to be carried
in BGP .
3.1 PCE Discovery Information
Vijayanand C August 2006 [page 2 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
The PCE discovery information consists of PCE location, PCE
inter-domain functions, PCE domain visibility, PCE destination
domains and a set of general PCECP capabilities. These are described
in [PCE-DISCO-IGP} and the same TLVs as used for OSPF can be used
for BGP. In addition to the definitions in [PCE-DISCO-IGP] we define
new capability flags for PCE in the path computation capabilities
TLV. We also define additional sub-TLVs to the PCE discovery sub-
TLVs for redundant PCE discovery.
The PCE discovery TLV carries the path computation capabilities
sub-TLV which is described and extended below.
3.1.1 Path Computation Capabilities Sub-TLV
The path computation capability PATH-COMP-CAP sub-TLV is carried
in the PCE discovery TLV. This is used to advertise path computation
specific capabilities of the PCE. It MAY include optional sub-TLVs
to encode more complex capabilities. We define additional
capabilities in the path computation capabilities flag of the path
computation capabilities sub-TLV.
Two more additional capabilities flag are defined to extend the
definitions of diverse path computation capabilities to consider
inter-AS paths.
In general the path diversity level can be categorized as:
. Intra-area diversity - the path segments are link, node or SRLG
disjoint inside an IGP area.
. Inter-area diversity - the end-to-end paths are link, node and
SRLG disjoint across area borders.
. Intra-AS diversity - the path segments are link, node, SRLG or
area disjoint inside an AS.
. Inter-AS diversity - the end-to-end paths are link, node, SRLG
or area disjoint across AS borders.
The format of the PATH-COMP-CAP sub-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Computation Capabilities Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vijayanand C August 2006 [page 3 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
Type To be assigned by IANA (suggested value =1)
Length Variable.
Value This comprises a 32 bit flag. Bits are indexed from
the most significant to the least significant, where
each bit represents one path computation capability.
Optional TLVs may be defined to specify more complex
capabilities. Three optional sub-TLVs are currently
defined.
IANA is requested to manage the space of the Path Commutation
Capabilities 32-bit flag.
The following bits are to be assigned by IANA:
Bit Capabilities
0 G bit: Capability to handle GMPLS link contraints
1 B bit: Capability to compute bidirectional paths
2 D bit: Capability to compute link/node/SRLG diverse
paths
3 L bit: Capability to compute load-balanced paths
4 S bit: Capability to compute a set of paths in a
synchronized Manner
5 O bit: Support for multiple objective functions
6 P bit: Capability to handle path constraints (e.g. hop
count, metric bound)
7 DRA bit: Capability to compute inter-area diverse paths
8 DAS bit: Capability to compute intra-AS diverse paths
9 DRS bit: Capability to compute inter-AS diverse paths
10 C bit: Capability to handle inter-AS policy constraints
11 T bit: Capabilty to handle diff-serv aware TE requests
9-31 Reserved for future use.
In addition to the capabilities defined in [PCE-DISCO-IGP] the
following new capability bits are defined in this document.
The DRA bit indicates the capability of the PCE to compute
inter-area diverse paths that are end-to-end node-disjoint across
area borders.
The DAS bit indicates the capability of the PCE to compute intra-AS
diverse paths in which path segments within an AS are node-disjoint
but end-to-end paths across AS borders are not node-disjoint.
The DRS bit indicates the capability of the PCE to compute inter-AS
Vijayanand C August 2006 [page 4 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
diverse paths in which path segments are end-to-end link, node, SRLG
or area disjoint across the AS borders.
The C bit indicates the capability of the PCE to handle inter-AS
policy constraints in the PCC computation request. This MAY be
requests containing constraints to avoid certain AS or sub-AS or
certain inter-AS links or certain ASBRs.
The T bit indicates the capability of the PCE to handle computation
requests for diff-serv aware TE LSPs. These requests would contain
information on the diff serv class type of the requested LSP in
addition to the other TE constraints.
3.1.2 PCE Redundancy Discovery
When multiple PCEs participate in the computation of an inter-
domain path each PCE MAY be responsible to compute one or more path
segments that span through specific domains. In such scenarios it
MAY be desirable to have redundant backup PCEs that can be used in
the event of failure of one or more primary PCEs. Thus the PCE
discovery mechanism should allow a PCE to indicate a set of one or
more alternate backup PCEs that can be chosen in case the given PCE
fails. Two new sub-TLVs have been defined that can be optionally
present in the PCE discovery TLV. These two sub-TLVs can be used for
the discovery of such redundancy information satisfying dynamic PCE
discovery requirements set forth in [PCE-DISC-REQ].
3.1.2.1 ALTERNATE-PCES sub-TLV
The ALTERNATE-PCES sub-TLV specifies the set of PCEs as an alternate
to a given primary PCE for path computation purposes. One or more
alternate PCE can be selected when the given primary PCE fails. It
contains a set of one or more PCE-ADDRESS sub-TLVs where each sub-
TLV is used to identify an alternate PCE. This is an optional sub-
TLV and one or more such instances MAY be included in the PCED TLV.
The ALTERNATE-PCES sub-TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PCE-ADDRESS sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA (suggested value=5)
Length Variable.
Value This comprises a set of one or more PCE-ADDRESS sub-
Vijayanand C August 2006 [page 5 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
TLVs where each sub-TLV identifies an alternate PCE
that can perform the same path computational functions
as a given primary PCE when the given PCE fails.
The ALTERNATE-PCES sub-TLV if present MUST include at least one PCE-
ADDRESS sub-TLV.
3.1.2.2 PRIMARY-PCES sub-TLV
The PRIMARY-PCES sub-TLV specifies the set of primary PCEs for which
the given PCE acts as an alternate PCE for path computation
purposes. When any of the primary PCEs in the set fails the
alternate PCE can be chosen for the same kind of path computation
functions as the primaries do. It contains a set of one or more PCE-
ADDRESS sub-TLVs where each sub-TLV is used to identify a primary
PCE. This is an optional sub-TLV and one or more such instances MAY
be included in the PCED TLV.
The PRIMARY-PCES sub-TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PCE-ADDRESS sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA (suggested value=6)
Length Variable.
Value This comprises a set of one or more PCE-ADDRESS
sub-TLVs where each sub-TLV identifies a primary PCE
for which the given PCE represents an alternate PCE
with the same kind of path computational capabilities
as the primary.
The PRIMARY-PCES sub-TLV if present MUST include at least one PCE-
ADDRESS sub-TLV.
4. BGP Specific Procedures
The PCE discovery TLV and PCE Status TLV will be carried in the
MP-Reach NLRI of BGP update messages. BGP speakers shall encode this
in a new <AFI,SAFI> value <TBD,TBD>, which shall be advertised in
the list of address families supported by the speaker in its open
message. When the PCE is first advertised or when its capabilities,
Vijayanand C August 2006 [page 6 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
scope changes the PCE Discovery TLV and its relevant sub TLVs will
be carried in the MP-REACH-NLRI. When the PCE experiences congestion
or when its congestion status changes it can originate only the PCE
status TLV, containing the Address sub-TLV and congestion status
sub-TLV in the MP-REACH-NLRI. Since the congestion status changes
more frequently than the PCE capabilities, the PCE status TLV is
likely to be sent more frequently in the MP-REACH-NLRI.
Multiple PCE discovery TLV and PCE status TLV may be carried in
the same MP-REACH NLRI if they share the same next-hop in the Multi-
protocol extensions attribute. Multiple MP-REACH-NLRI may be sent in
the same update message when they share the same AS-path attributes.
The PCE information can be directly injected into BGP by
configuration or the PCE information carried by the IGP( OSPF or
ISIS) as in [PCE-IGP-DISCO] can be redistributed into BGP through
suitable configuration. Since BGP may not be used in all the
routers the PCE information carried in BGP can be redistributed
selectively into the IGP so that all the potential PCCs can discover
the PCEs.
When an administrator or operator deactivates the PCE the
corresponding PCE information has to be withdrawn. This can be
accomplished by sending the PCE discovery TLV in the MP-UNREACH-NLRI
attribute of the BGP Update message.
The PCE information can be distributed across AS boundaries
using E-BGP sessions. BGP policy can be used to control the import
and export of PCE information similar to existing controls over the
distribution of normal BGP routes. The normal BGP decision process
will not be applied to the received PCE information.
4.1 Encoding PCE TLVs in MP-REACH-NLRI
The PCE information is carried in the NLRI of the Multiprotocol
extensions attribute described in [MP-BGP]. The Address Family
Identifier (AFI) and Subsequent Address Identifier(SAFI) will be set
to <TBD,TBD>. The next hop field will be filled in as per usual BGP
processing rules to enable reachability to the PCE. The next hop
address will belong to the same family( IPv4 or IPv6) as the address
family in the PCE Discovery TLV.
The Network Layer Reachability Information will be encoded as <
Length, List of TLV >.
+---------------------------+
| Length (2 octets) |
+---------------------------+
| List of TLVs(variable) |
Vijayanand C August 2006 [page 7 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
+---------------------------+
The meaning of the fields is described as follows:
a) Length :
The length in bytes of the list of TLVs carried in the NLRI
b) List of TLVs :
This contains a list of TLVs each of which can be a PCE
Discovery TLV or PCE Status TLV. The encoding of the PCE
discovery TLV and its sub-TLVs and the encoding of the PCE status
TLV will be same as that of the corresponding OSPF PCE TLVs
described in [PCE-DISCO-IGP] with the extensions proposed in this
document
4.2 Encoding PCE Discovery TLVs in MP-UNREACH-NLRI
The PCE information is carried in the NLRI of the Multiprotocol
extensions attribute. The Address Family Identifier (AFI) and
Subsequent Address Identifier(SAFI) will be set to <TBD,TBD>.
The Network Layer Reachability Information will be encoded as <
Length, List of TLV >.
+---------------------------+
| Length (2 octets) |
+---------------------------+
| List of TLVs(variable) |
+---------------------------+
The meaning of the fields is described as follows:
c) Length :
The length in bytes of the list of TLVs carried in the NLRI
d) List of TLVs :
This contains a list of PCE Discovery TLVs. The PCE
discovery TLV will contain the PCE-address-sub-TLV defined in
Vijayanand C August 2006 [page 8 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
[PCE-DISCO-IGP] corresponding to the PCE whose information is
withdrawn.
5. Interoperability Considerations
BGP speakers which support this feature shall advertise the
<AFI,SAFI> corresponding to the PCE Information in the list of
address families supported by the speaker. This can be advertised in
the Capabilities Optional parameter[BGP-CAP] of the open message
sent to the peer. A BGP speaker shall not advertise PCE information
to a speaker which does not support the <AFI,SAFI> as advertised in
its capabilities.
6. Acknowledgements
The authors wish to place on record their sincere gratitude for
the support extended by Balaji Radhakrishnan during this work.
7. IANA considerations
IANA is requested to assign a separate SAFI number to be used
in the MP-REACH-NLRI attribute for PCE discovery.
8. Security Considerations
This extension to BGP does not change the underlying security
issues inherent in the existing BGP [Heffernan].
9. Authors Address
Vijayanand C
HCL Technologies Ltd.
No.184, NSK Salai,
Vadapalani,Chennai -26
India.
Phone - 91 44 23728366 ext:1357
Email : vijayc@hcl.in
Somen Bhattacharya,
Avici Systems.
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone - 1 978 964 2606
Vijayanand C August 2006 [page 9 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
Email: somen@avici.com
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture, work in
progress.
[PCE-DISC-REQ] J.L. Le Roux,Requirements for Path Computation
Element (PCE) Discovery, draft-ietf-pce-discovery-reqs-05.txt,
work in progress.
[PCE-DISCO-IGP] J.L. Le Roux, J.P. Vasseur, Yuichi Ikejir,
Raymond Zhang, IGP Protocol extensions for Path computation
Element Discovery, draft-ietf-pce-disco-proto-igp,
work in progress
[BGP-CAP] R. Chandra, J. Scudder, Capabilities advertisement
with BGP-4, RFC3392,November 2002
[MP-BGP] T.Bates,Y.Rekhter,R.Chandra,D.Katz, Multiprotocol
Extensions for BGP-4,RFC2858,June2000.
[Heffernan] Heffernan, A., "Protection of BGP Sessions via the
TCP MD5 Signature Option", RFC 2385, August 1998.
Intellectual Property Statement
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.
Vijayanand C August 2006 [page 10 ]
INTERNET DRAFT BGP extensions for PCE discovery August 2006
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Vijayanand C August 2006 [page 11 ]