INTERNET DRAFT Vijayanand
Expiration Date: April 2007 HCL Technologies
Somen Bhattacharya
Prasanna Kumar
Avici Systems
BGP Protocol extensions for PCE Discovery across
Autonomous systems
draft-vijay-somen-pce-disco-proto-bgp-03.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.
This Internet-Draft will expire on April, 2007.
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
Vijayanand, et al. [Page 1]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
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).
Requirements Language
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 RFC 2119 [RFC2119].
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 PCE.
A network may consists of a number of PCEs, spread
across multiple areas and domains, each with different
capabilities and scope. In such a scenario, it is highly
desirable to have a dynamic and automatic means for PCE
discovery. This would enable the PCC to be aware of PCE in
its own domain and the PCE in a domain be aware of PCEs in
other domains for computing paths spanning multiple
domains, eg. as in inter-domain TE LSPs. The mechanism
would also facilitate automatic detection of modification
of PCE information.This discovery information would be used
in selecting appropriate PCE for setting up PCEP session
bwtween PCEs.Detailed requirements on PCE discovery are
described in [PCE-DISC-REQ].
The means to discover PCE in the same IGP domain are
described in [PCE-DISCO-IGP], 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 required. This is
also relevant since operators have policies governing the
import and export of routing information across their
domains.
An efficient way for discovering PCEs across IGP
domains and Autonomous systems would be to use BGP for
carrying PCE discovery information.
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-DISCO-
IGP], which represent the state and status of PCE, will be
carried in the NLRI information of the MP-REACH NLRI.
Vijayanand, et al. October 2006 [page 2 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
The path-computation-capabilities TLV which is a sub-
TLV of PCE discovery TLV as defined in [PCE-DISCO-IGP] has
been extended to support additional capabilities.Additional
sub-TLVs have also been added to the PCE discovery TLV
to support alternate PCE discovery.
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-DISCO-IGP]
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.
Vijayanand, et al. October 2006 [page 3 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
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
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:
Vijayanand, et al. October 2006 [page 4 ]
INTERNET DRAFT BGP extensions for PCE discovery October2006
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Computation
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
Vijayanand, et al. October 2006 [page 5 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
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-ASdiverse 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-ASdiverse 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
Vijayanand, et al. October 2006 [page 6 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
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 |
Vijayanand, et al. October 2006 [page 7 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// 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-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 PCEfails.
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 //
Vijayanand, et al. October 2006 [page 8 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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> . The
new <AFI,SAFI> value 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, 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-DISCO-IGP] can be redistributed
into BGP through suitable configuration. Since BGP may not
Vijayanand, et al. October 2006 [page 9 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
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 discovery information corresponding to a PCE
typically needs to be distributed only to a few neighbouring
ASes.
The discovery information about a PCE can be uniquely
identified from the Address sub-TLV which is carried in both
the PCE Discovery TLV and PCE Status TLV. When the same PCE
discovery information is received from multiple BGP peers
the local BGP speaker shall select one of them using its
local BGP decision process applied on the AS-Path attributes.
This would result in consistently selecting the PCE discovery
information from one of the peers for a given policy
configuration, thereby any stale information would not be
injected into the PCE. The BGP speaker shall store only the
selected PCE discovery information and propagate it to its
peers.
The Nexthop carried in the MP-REACH-NLRI of the PCE
discovery information MAY be used to reach the PCE if the
PCE address is not advertised as a route in the BGP IPv4
update messages.
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 >.
Vijayanand, et al. October 2006 [page 10 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
+---------------------------+
| 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 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
Vijayanand, et al. October 2006 [page 11 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
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 [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' Addresses
Vijayanand C
HCL Technologies Ltd.
No.184, NSK Salai,
Vadapalani,Chennai -26
India.
Phone : 91 44 23728366 ext:1357
Email : vijayc@hcl.in
Vijayanand, et al. October 2006 [page 12 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
Somen Bhattacharya,
Avici Systems.
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: 1 978 964 2606
Email: somen@avici.com
Prasanna Kumar,
Avici Systems.
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: 1 978 964 2297
Email: pkumar@avici.com
10. References
10.1 Normative References
[RFC-WORDS] Bradner, S.,"Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[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,
workin progress,JUne 2006.
Vijayanand, et al. October 2006 [page 13 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
[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,
June 2000.
[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.
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.
Vijayanand, et al. October 2006 [page 14 ]
INTERNET DRAFT BGP extensions for PCE discovery October 2006
Full 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.
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.
Vijayanand, et al. October 2006 [page 15 ]