draft-ietf-pce-brpc-09.txt   rfc5441.txt 
Networking Working Group JP. Vasseur, Ed. Network Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Request for Comments: 5441 Cisco Systems, Inc
Intended status: Standards Track R. Zhang Category: Standards Track R. Zhang
Expires: October 16, 2008 BT Infonet BT Infonet
N. Bitar N. Bitar
Verizon Verizon
JL. Le Roux JL. Le Roux
France Telecom France Telecom
April 14, 2008 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute
Shortest Constrained Inter-Domain Traffic Engineering
A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Label Switched Paths
Shortest Constrained Inter-domain Traffic Engineering Label Switched
Paths
draft-ietf-pce-brpc-09.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
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 This document specifies an Internet standards track protocol for the
Task Force (IETF), its areas, and its working groups. Note that Internet community, and requests discussion and suggestions for
other groups may also distribute working documents as Internet- improvements. Please refer to the current edition of the "Internet
Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
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 Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/ietf/1id-abstracts.txt. document authors. All rights reserved.
The list of Internet-Draft Shadow Directories can be accessed at This document is subject to BCP 78 and the IETF Trust's Legal
http://www.ietf.org/shadow.html. 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.
This Internet-Draft will expire on October 16, 2008. 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.
Abstract Abstract
The ability to compute shortest constrained Traffic Engineering Label The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains (where a Generalized MPLS (GMPLS) networks across multiple domains has been
domain is a collection of network elements within a common sphere of identified as a key requirement. In this context, a domain is a
address management or path computational responsibility such as an collection of network elements within a common sphere of address
IGP area or an Autonomous Systems) has been identified as a key management or path computational responsibility such as an IGP area
requirement. This document specifies a procedure relying on the use or an Autonomous Systems. This document specifies a procedure
of multiple Path Computation Elements (PCEs) to compute such inter- relying on the use of multiple Path Computation Elements (PCEs) to
domain shortest constrained paths across a predetermined sequence of compute such inter-domain shortest constrained paths across a
domains, using a backward recursive path computation technique. This predetermined sequence of domains, using a backward-recursive path
technique preserves confidentiality across domains, which is computation technique. This technique preserves confidentiality
sometimes required when domains are managed by different Service across domains, which is sometimes required when domains are managed
Providers. by different service providers.
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].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5 3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Domain Path Selection . . . . . . . . . . . . . . . . . . 7 4.1. Domain Path Selection . . . . . . . . . . . . . . . . . . 6
4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 7 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 6
5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 8
6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 10 6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10 7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10
8. Usage In Conjunction With Per-domain Path Computation . . . . 11 8. Usage in Conjunction with Per-Domain Path Computation . . . . 10
9. BRPC Procedure Completion Failure . . . . . . . . . . . . . . 11 9. BRPC Procedure Completion Failure . . . . . . . . . . . . . . 10
10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Diverse end-to-end path computation . . . . . . . . . . . 12 10.1. Diverse End-to-End Path Computation . . . . . . . . . . . 11
10.2. Path Optimality . . . . . . . . . . . . . . . . . . . . . 12 10.2. Path Optimality . . . . . . . . . . . . . . . . . . . . . 12
11. Reoptimization Of An Inter-domain TE LSP . . . . . . . . . . . 13 11. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . 12
12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 13 12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 12
13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 13 13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 12
14. Manageability Considerations . . . . . . . . . . . . . . . . . 14 14. Manageability Considerations . . . . . . . . . . . . . . . . . 13
14.1. Control of Function And Policy . . . . . . . . . . . . . . 14 14.1. Control of Function and Policy . . . . . . . . . . . . . . 13
14.2. Information And Data Models . . . . . . . . . . . . . . . 14 14.2. Information and Data Models . . . . . . . . . . . . . . . 13
14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14 14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13
14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 14 14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13
14.5. Requirements on Other Protocols and Functional 14.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 15 Components . . . . . . . . . . . . . . . . . . . . . . . . 14
14.6. Impact on Network Operation . . . . . . . . . . . . . . . 15 14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14
14.7. Path Computation Chain Monitoring . . . . . . . . . . . . 15 14.7. Path Computation Chain Monitoring . . . . . . . . . . . . 14
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
15.1. New Flag Of The RP Object . . . . . . . . . . . . . . . . 15 15.1. New Flag of the RP Object . . . . . . . . . . . . . . . . 14
15.2. New Error-Type And Error-Value . . . . . . . . . . . . . . 15 15.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 14
15.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 16 15.3. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15
16. Security Considerations . . . . . . . . . . . . . . . . . . . 16 16. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
18.1. Normative References . . . . . . . . . . . . . . . . . . . 16 18.1. Normative References . . . . . . . . . . . . . . . . . . . 16
18.2. Informative References . . . . . . . . . . . . . . . . . . 17 18.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
The requirements for inter-area and inter-AS MPLS Traffic Engineering The requirements for inter-area and inter-AS MPLS Traffic Engineering
(TE) have been developed by the Traffic Engineering Working Group (TE (TE) have been developed by the Traffic Engineering Working Group (TE
WG) and have been stated in [RFC4105] and [RFC4216], respectively. WG) and have been stated in [RFC4105] and [RFC4216], respectively.
The framework for inter-domain Multiprotocol Label Switching (MPLS) The framework for inter-domain Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) has been provided in [RFC4726]. Traffic Engineering (TE) has been provided in [RFC4726].
[RFC5152] defines a technique for establishing an inter-domain [RFC5152] defines a technique for establishing an inter-domain
Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the
path is computed during the signalling process on a per-domain basis path is computed during the signaling process on a per-domain basis
by the entry boundary node of each domain (each node responsible for by the entry boundary node of each domain (each node responsible for
triggering the computation of a section of an inter-domain TE LSP triggering the computation of a section of an inter-domain TE LSP
path is always along the path of such TE LSP). This path computation path is always along the path of such TE LSP). This path computation
technique fulfills some of the requirements stated in [RFC4105] and technique fulfills some of the requirements stated in [RFC4105] and
[RFC4216] but not all of them. In particular, it cannot guarantee to [RFC4216] but not all of them. In particular, it cannot guarantee to
find an optimal (shortest) inter-domain constrained path. find an optimal (shortest) inter-domain constrained path.
Furthermore, it cannot be efficiently used to compute a set of inter- Furthermore, it cannot be efficiently used to compute a set of inter-
domain diversely routed TE LSPs. domain diversely routed TE LSPs.
The Path Computation Element (PCE) architecture is defined in The Path Computation Element (PCE) architecture is defined in
skipping to change at page 4, line 40 skipping to change at page 3, line 46
Qualifying a path as optimal requires some clarification. Indeed, a Qualifying a path as optimal requires some clarification. Indeed, a
globally optimal TE LSP placement usually refers to a set of TE LSPs globally optimal TE LSP placement usually refers to a set of TE LSPs
whose placements optimize the network resources with regards to a whose placements optimize the network resources with regards to a
specified objective function (e.g., a placement that reduces the specified objective function (e.g., a placement that reduces the
maximum or average network load while satisfying the TE LSP maximum or average network load while satisfying the TE LSP
constraints). In this document, an optimal inter-domain constrained constraints). In this document, an optimal inter-domain constrained
TE LSP is defined as the shortest path satisfying the set of required TE LSP is defined as the shortest path satisfying the set of required
constraints that would be obtained in the absence of multiple domains constraints that would be obtained in the absence of multiple domains
(in other words, in a totally flat IGP network between the source and (in other words, in a totally flat IGP network between the source and
destination of the TE LSP). Note that this requires to use destination of the TE LSP). Note that this requires the use of
consistent metric schemes in each domain (see section Section 13). consistent metric schemes in each domain (see Section 13).
1.1. 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].
2. Terminology 2. Terminology
ABR: Area Border Routers. Routers used to connect two IGP areas ABR: Area Border Routers. Routers used to connect two IGP areas
(areas in OSPF or levels in IS-IS). (areas in OSPF or levels in IS-IS).
ASBR: Autonomous System Border Routers. Routers used to connect ASBR: Autonomous System Border Router. Router used to connect
together ASes of the same or different Service Providers via one or together ASes of the same or different service providers via one or
more Inter-AS links. more inter-AS links.
Boundary Node (BN): a boundary node is either an ABR in the context Boundary Node (BN): a boundary node is either an ABR in the context
of inter-area Traffic Engineering or an ASBR in the context of of inter-area Traffic Engineering or an ASBR in the context of
inter-AS Traffic Engineering. inter-AS Traffic Engineering.
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along
a determined sequence of domains. a determined sequence of domains.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
a determined sequence of domains. a determined sequence of domains.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
LSR: Label Switching Router. Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
LSP: Label Switched Path. LSP: Label Switched Path.
LSR: Label Switching Router.
PCC: Path Computation Client. Any client application requesting a PCC: Path Computation Client. Any client application requesting a
path computation to be performed by the Path Computation Element. path computation to be performed by a Path Computation Element.
PCE (Path Computation Element): an entity (component, application or PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints. based on a network graph and applying computational constraints.
PCE(i) is a PCE with the scope of domain(i). PCE(i) is a PCE with the scope of domain(i).
TED: Traffic Engineering Database. TED: Traffic Engineering Database.
VSPT: Virtual Shortest Path Tree. VSPT: Virtual Shortest Path Tree.
The notion of contiguous, stitched and nested TE LSPs is defined in The notion of contiguous, stitched, and nested TE LSPs is defined in
[RFC4726] and will not be repeated here. [RFC4726] and will not be repeated here.
3. General Assumptions 3. General Assumptions
In the rest of this document, we make the following set of In the rest of this document, we make the following set of
assumptions common to inter-area and inter-AS MPLS TE: assumptions common to inter-area and inter-AS MPLS TE:
o Each IGP area or Autonomous System (AS) is assumed to be Traffic o Each IGP area or Autonomous System (AS) is assumed to be Traffic
Engineering enabled. Engineering enabled.
o No topology or resource information is distributed between domains o No topology or resource information is distributed between domains
(as mandated per [RFC4105] and [RFC4216]), which is critical to (as mandated per [RFC4105] and [RFC4216]), which is critical to
preserve IGP/BGP scalability and confidentiality. preserve IGP/BGP scalability and confidentiality.
o While certain constraints like bandwidth can be used across o While certain constraints like bandwidth can be used across
different domains, other TE constraints like resource affinity, different domains, other TE constraints (such as resource
color, metric, etc. as listed in [RFC2702] could be translated at affinity, color, metric, etc. [RFC2702]) could be translated at
domain boundaries. If required, it is assumed that, at the domain domain boundaries. If required, it is assumed that, at the domain
boundary nodes, there will exist some sort of local mapping based boundary nodes, there will exist some sort of local mapping based
on policy agreement, in order to translate such constraints across on policy agreement, in order to translate such constraints across
domain boundaries during the inter-PCE communication process. domain boundaries during the inter-PCE communication process.
o Each AS can be made of several IGP areas. The path computation o Each AS can be made of several IGP areas. The path computation
procedure described in this document applies to the case of a procedure described in this document applies to the case of a
single AS made of multiple IGP areas, multiple ASes made of a single AS made of multiple IGP areas, multiple ASes made of a
single IGP area or any combination of the above. For the sake of single IGP area, or any combination of the above. For the sake of
simplicity, each AS will be considered to be made of a single area simplicity, each AS will be considered to be made of a single area
in this document. The case of an Inter-AS TE LSP spanning in this document. The case of an inter-AS TE LSP spanning
multiple ASes where some of those ASes are themselves made of multiple ASes, where some of those ASes are themselves made of
multiple IGP areas can be easily derived from this case by multiple IGP areas, can be easily derived from this case by
applying the BRPC procedure described in this document, applying the BRPC procedure described in this document,
recursively. recursively.
o The domain path (set of domains traversed to reach the destination o The domain path (the set of domains traversed to reach the
domain) is either administratively pre-determined or discovered by destination domain) is either administratively predetermined or
some means that is outside of the scope of this document. discovered by some means that is outside of the scope of this
document.
4. BRPC Procedure 4. BRPC Procedure
The BRPC procedure is a Multiple-PCE path computation technique as The BRPC procedure is a multiple-PCE path computation technique as
described in [RFC4655]. A possible model consists of hosting the PCE described in [RFC4655]. A possible model consists of hosting the PCE
function on boundary nodes (e.g., ABR or ASBR) but this is not function on boundary nodes (e.g., ABR or ASBR), but this is not
mandated by the BRPC procedure. mandated by the BRPC procedure.
The BRPC procedure relies on communication between cooperating PCEs. The BRPC procedure relies on communication between cooperating PCEs.
In particular, the PCC sends a PCReq to a PCE in its domain. The In particular, the PCC sends a PCReq to a PCE in its domain. The
request is forwarded between PCEs, domain-by-domain until the PCE request is forwarded between PCEs, domain-by-domain, until the PCE
responsible for the domain containing the LSP destination is reached. responsible for the domain containing the LSP destination is reached.
The PCE in the destination domain creates a tree of potential paths The PCE in the destination domain creates a tree of potential paths
to the destination (the Virtual Shortest Path Tree - VSPT) and passes to the destination (the Virtual Shortest Path Tree - VSPT) and passes
this back to the previous PCE in a PCRep. Each PCE in turn adds to this back to the previous PCE in a PCRep. Each PCE in turn adds to
the VSPT and passes it back until the PCE in the source domain uses the VSPT and passes it back until the PCE in the source domain uses
the VSPT to select an end-to-end path that it sends to the PCC. the VSPT to select an end-to-end path that the PCE sends to the PCC.
The BRPC procedure does not make any assumption with regards to the The BRPC procedure does not make any assumption with regards to the
nature of the inter-domain TE LSP that could be contiguous, nested or nature of the inter-domain TE LSP that could be contiguous, nested,
stitched. or stitched.
Furthermore, no assumption is made on the actual path computation Furthermore, no assumption is made on the actual path computation
algorithm in use by a PCE (e.g., it can be any variant of CSPF or an algorithm in use by a PCE (e.g., it can be any variant of Constrained
algorithm based on linear-programming to solve multi-constraint Shortest Path First (CSPF) or an algorithm based on linear
optimization problems). programming to solve multi-constraint optimization problems).
4.1. Domain Path Selection 4.1. Domain Path Selection
The PCE-based BRPC procedure applies to the computation of an optimal The PCE-based BRPC procedure applies to the computation of an optimal
constrained inter-domain TE LSP. The sequence of domains to be constrained inter-domain TE LSP. The sequence of domains to be
traversed is either administratively pre-determined or discovered by traversed is either administratively predetermined or discovered by
some means that is outside of the scope of this document. The PCC some means that is outside of the scope of this document. The PCC
MAY indicate the sequence of domains to be traversed using the IRO MAY indicate the sequence of domains to be traversed using the
defined in [I-D.ietf-pce-pcep] so that it is available to all PCEs. Include Route Object (IRO) defined in [RFC5440] so that it is
Note also that a sequence of PCEs MAY be enforced by policy on the available to all PCEs. Note also that a sequence of PCEs MAY be
PCC and this constraint can be carried in the PCEP path computation enforced by policy on the PCC, and this constraint can be carried in
request (as defined in [I-D.ietf-pce-monitoring]). the PCEP path computation request (as defined in [PCE-MONITOR]).
The BRPC procedure guarantees to compute the optimal path across a The BRPC procedure guarantees to compute the optimal path across a
specific sequence of traversed domains (which constitutes an specific sequence of traversed domains (which constitutes an
additional constraint). In the case of an arbitrary set of meshed additional constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute the optimal path domains, the BRPC procedure can be used to compute the optimal path
across each domain set in order to get the optimal constrained path across each domain set in order to get the optimal constrained path
between the source and the destination of the TE LSP. The BRPC between the source and the destination of the TE LSP. The BRPC
procedure can also be used across a subset of all domain sequences, procedure can also be used across a subset of all domain sequences,
and the best path among these sequences can then be selected. and the best path among these sequences can then be selected.
4.2. Mode of Operation 4.2. Mode of Operation
Definition of VSPT(i) Definition of VSPT(i)
In each domain i: In each domain i:
o There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- o There is a set of X-en(i) entry BNs noted BN-en(k,i) where
en(k,i) is the kth entry BN of domain(i). BN-en(k,i) is the kth entry BN of domain(i).
o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN- o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where
ex(k,i) is the kth exit BN of domain(i). BN-ex(k,i) is the kth exit BN of domain(i).
VSPT(i): MP2P (MultiPoint To Point) tree returned by PCE(i) to VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to
PCE(i-1): PCE(i-1):
Root (TE LSP destination) Root (TE LSP destination)
/ I \ / | \
BN-en(1,i) BN-en(2,i) ... BN-en(j,i). BN-en(1,i) BN-en(2,i) ... BN-en(j,i).
Where [X-en(i)] is the number of entry BNs in domain i where [X-en(i)] is the number of
and j<= [X-en(i)] entry BNs in domain i and j<= [X-en(i)]
Figure 1: MP2P Tree
Figure 1 - MP2P Tree
Each link of tree VSPT(i) represents the shortest constrained path Each link of tree VSPT(i) represents the shortest constrained path
between BN-en(j,i) and the TE LSP destination that satisfies the set between BN-en(j,i) and the TE LSP destination that satisfies the set
of required constraints for the TE LSP (bandwidth, affinities, ...). of required constraints for the TE LSP (bandwidth, affinities, etc.).
These are path segments to reach the TE LSP destination from BN- These are path segments to reach the TE LSP destination from
en(j,i). BN-en(j,i).
Note that PCE(i) only considers the entry BNs of domain(i). That is Note that PCE(i) only considers the entry BNs of domain(i), i.e.,
only the BNs that provide connectivity from domain(i-1). That is, only the BNs that provide connectivity from domain(i-1). In other
the set BN-en(k,i) is only made of those BNs that provide words, the set BN-en(k,i) is only made of those BNs that provide
connectivity from domain (i-1) to domain(i). Furthermore, some BNs connectivity from domain (i-1) to domain(i). Furthermore, some BNs
may be excluded according to policy constraints (either due to local may be excluded according to policy constraints (either due to local
policy or policies signaled in the path computation request). policy or policies signaled in the path computation request).
Step 1: the PCC needs to first determine the PCE capable of serving Step 1:
its path computation request (this can be done thanks to local First, the PCC needs to determine the PCE capable of serving its path
configuration or via IGP discovery (see [RFC5088] and [RFC5089])). computation request (this can be done with local configuration or via
The path computation request is then relayed until reaching a PCE(n) IGP discovery (see [RFC5088] and [RFC5089])). The path computation
such that the TE LSP destination resides in the domain(n). At each request is then relayed until reaching a PCE(n) such that the TE LSP
step of the process, the next PCE can either be statically configured destination resides in the domain(n). At each step of the process,
or dynamically discovered via IGP/BGP extensions. If no next PCE can the next PCE can either be statically configured or dynamically
be found or the next hop PCE of choice is unavailable, the procedure discovered via IGP/BGP extensions. If no next PCE can be found or
stops and a path computation error is returned (see Section 9). If the next-hop PCE of choice is unavailable, the procedure stops and a
PCE(i-1) discovers multiple PCEs for the adjacent domain(i), PCE(i) path computation error is returned (see Section 9). If PCE(i-1)
may select a subset of these PCEs based on some local policies or discovers multiple PCEs for the adjacent domain(i), PCE(i) may select
heuristics. The PCE selection process is outside of the scope of a subset of these PCEs based on some local policies or heuristics.
this document. The PCE selection process is outside of the scope of this document.
Step 2: PCE(n) computes VSPT(n) made of the list of shortest Step 2:
PCE(n) computes VSPT(n), the tree made of the list of shortest
constrained paths between every BN-en(j,n) and the TE LSP destination constrained paths between every BN-en(j,n) and the TE LSP destination
using a suitable path computation algorithm (e.g. CSPF) and returns using a suitable path computation algorithm (e.g., CSPF) and returns
the computed VSPT(n) to PCE(n-1). the computed VSPT(n) to PCE(n-1).
Step i: Step i:
For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the
- For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the
shortest constrained paths between each BN-en(j,i) and the TE LSP shortest constrained paths between each BN-en(j,i) and the TE LSP
destination. It does this by considering its own TED and the destination. It does this by considering its own TED and the
information in VSPT(i+1). information in VSPT(i+1).
In the case of Inter-AS TE LSP computation, this requires to also add In the case of inter-AS TE LSP computation, this also requires adding
the inter-AS TE links connecting the domain(i) to the domain(i+1). the inter-AS TE links that connect the domain(i) to the domain(i+1).
Step n
Finally PCE(1) computes the end-to-end shortest constrained path from Step n:
the source to the destination and returns the corresponding path to Finally, PCE(1) computes the end-to-end shortest constrained path
the requesting PCC in the form of a PCRep message as defined in from the source to the destination and returns the corresponding path
[I-D.ietf-pce-pcep]. to the requesting PCC in the form of a PCRep message as defined in
[RFC5440].
Each branch of the VSPT tree (path) may be returned in the form of an Each branch of the VSPT tree (path) may be returned in the form of an
explicit path (in which case all the hops along the path segment are explicit path (in which case, all the hops along the path segment are
listed) or a loose path (in which case only the BN is specified) so listed) or a loose path (in which case, only the BN is specified) so
as to preserve confidentiality along with the respective cost. In as to preserve confidentiality along with the respective cost. In
the later case, various techniques can be used in order to retrieve the latter case, various techniques can be used in order to retrieve
the computed explicit paths on a per domain basis during the the computed explicit paths on a per-domain basis during the
signaling process thanks to the use of path keys as described in signaling process, thanks to the use of path keys as described in
[I-D.ietf-pce-path-key]. [PATH-KEY].
A PCE that can compute the requested path for more than one A PCE that can compute the requested path for more than one
consecutive domain on the path SHOULD perform this computation for consecutive domain on the path SHOULD perform this computation for
all such domains before passing the PCRep to the previous PCE in the all such domains before passing the PCRep to the previous PCE in the
sequence. sequence.
BRPC guarantees to find the optimal (shortest) constrained inter- BRPC guarantees to find the optimal (shortest) constrained inter-
domain TE LSP according to a set of defined domains to be traversed. domain TE LSP according to a set of defined domains to be traversed.
Note that other variants of the BRPC procedure relying on the same Note that other variants of the BRPC procedure relying on the same
principles are also possible. principles are also possible.
Note also that in case of ECMP paths, more than one path could be Note also that in case of Equal Cost Multi-Path (ECMP) paths, more
returned to the requesting LSR. than one path could be returned to the requesting PCC.
5. PCEP Protocol Extensions 5. PCEP Protocol Extensions
The BRPC procedure requires the specification of a new flag of the RP The BRPC procedure requires the specification of a new flag of the RP
object carried within the PCReq message (defined in object carried within the PCReq message (defined in [RFC5440]) to
[I-D.ietf-pce-pcep]) to specify that the shortest paths satisfying specify that the shortest paths satisfying the constraints from the
the constraints from the destination to the set of entry boundary destination to the set of entry boundary nodes are requested (such a
nodes are requested (such set of paths forms the downstream VSPT as set of paths forms the downstream VSPT as specified in Section 4.2).
specified in Section 4.2).
The following new flag of the RP object is defined: The following new flag of the RP object is defined:
VSPT Flag VSPT Flag
Bit Number Name Flag Bit Number Name Flag
7 VSPT 25 VSPT
When set, the VSPT Flag indicates that the PCC requests the When set, the VSPT Flag indicates that the PCC requests the
computation of an inter-domain TE LSP using the BRPC procedure computation of an inter-domain TE LSP using the BRPC procedure
defined in this document. defined in this document.
Because path segments computed by a downstream PCE in the context of Because path segments computed by a downstream PCE in the context of
the BRPC procedure MUST be provided along with their respective path the BRPC procedure MUST be provided along with their respective path
costs, the C flag of the METRIC object carried within the PCReq costs, the C flag of the METRIC object carried within the PCReq
message MUST be set. It is the choice of the requester to message MUST be set. It is the choice of the requester to
appropriately set the O bit of the RP object. appropriately set the O bit of the RP object.
6. VSPT Encoding 6. VSPT Encoding
The VSPT is returned within a PCRep message. The encoding consists The VSPT is returned within a PCRep message. The encoding consists
of a non-ordered lists of EROs where each ERO represents a path of a non-ordered list of Explicit Route Objects (EROs) where each ERO
segment from a BN to the destination specified in the END-POINT represents a path segment from a BN to the destination specified in
object of the corresponding PCReq message. the END-POINT object of the corresponding PCReq message.
Example: Example:
<---- area 1 ----><---- area 0 -----><------ area 2 ------> <---- area 1 ----><---- area 0 -----><------ area 2 ------>
ABR1-A-B-+ ABR1-A-B-+
| | | |
ABR2-----D ABR2-----D
| | | |
ABR3--C--+ ABR3--C--+
Figure 2 - An Example of VPST Encoding Using a Set of EROs Figure 2: An Example of VSPT Encoding Using a Set of EROs
In the simple example shown in figure 2, if we make the assumption In the simple example shown in Figure 2, if we make the assumption
that a constrained path exists between each ABR and the destination that a constrained path exists between each ABR and the destination
D, the VSPT computed by a PCE serving area 2 consists of the D, the VSPT computed by a PCE serving area 2 consists of the
following non-ordered set of EROs: following non-ordered set of EROs:
o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP
address)-D(TE Router ID) address)-D(TE Router ID)
o ERO2: ABR2(TE Router ID)-D(TE Router ID) o ERO2: ABR2(TE Router ID)-D(TE Router ID)
o ERO3: ABR3(TE Router ID)-C(interface IP adress)-D(TE Router ID) o ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID)
The PCReq message, PCRep message, PCEP END-POINT and ERO objects are The PCReq message, PCRep message, PCEP END-POINT object, and ERO
defined in [I-D.ietf-pce-pcep] object are defined in [RFC5440].
7. Inter-AS TE Links 7. Inter-AS TE Links
In the case of Inter-AS TE LSP path computation, the BRPC procedure In the case of inter-AS TE LSP path computation, the BRPC procedure
requires the knowledge of the traffic engineering attributes of the requires the knowledge of the traffic engineering attributes of the
Inter-AS TE links: the process by which the PCE acquires this inter-AS TE links. The process by which the PCE acquires this
information is out of the scope of the BRPC procedure, which is information is out of the scope of the BRPC procedure, which is
compliant with the PCE architecture defined in [RFC4655]. compliant with the PCE architecture defined in [RFC4655].
That said, a straightforward solution consists of allowing the ASBRs That said, a straightforward solution consists of allowing the ASBRs
to flood the TE information related to the inter-ASBR links although to flood the TE information related to the inter-ASBR links although
no IGP TE is enabled over those links (there is no IGP adjacency over no IGP TE is enabled over those links (there is no IGP adjacency over
the inter-ASBR links). This allows the PCE of a domain to get entire the inter-ASBR links). This allows the PCE of a domain to get entire
TE visibility up to the set of entry ASBRs in the downstream domain TE visibility up to the set of entry ASBRs in the downstream domain
(see the IGP extensions defined in (see the IGP extensions defined in [RFC5316] and [RFC5392]).
[I-D.ietf-ccamp-isis-interas-te-extension] and
[I-D.ietf-ccamp-ospf-interas-te-extension]).
8. Usage In Conjunction With Per-domain Path Computation 8. Usage in Conjunction with Per-Domain Path Computation
The BRPC procedure may be used to compute path segments in The BRPC procedure may be used to compute path segments in
conjunction with other path computation techniques (such as the per- conjunction with other path computation techniques (such as the per-
domain path computation technique defined in [RFC5152]) to compute domain path computation technique defined in [RFC5152]) to compute
the end-to-end path. In this case end-to-end path optimality can no the end-to-end path. In this case, end-to-end path optimality can no
longer be guaranteed. longer be guaranteed.
9. BRPC Procedure Completion Failure 9. BRPC Procedure Completion Failure
If the BRPC procedure cannot be completed because a PCE along the If the BRPC procedure cannot be completed because a PCE along the
domain does not recognize the procedure (VSPT flag of the RP object), domain does not recognize the procedure (VSPT flag of the RP object),
as stated in [I-D.ietf-pce-pcep], the PCE sends a PCErr message to as stated in [RFC5440], the PCE sends a PCErr message to the upstream
the upstream PCE with an Error-Type=4 (not supported object), Error- PCE with an Error-Type=4 (Not supported object), Error-value=4
value-4 (Unsupported paramater). The PCE may include the parent (Unsupported parameter). The PCE may include the parent object (RP
object (RP object) up to and including (but no further than) the object) up to and including (but no further than) the unknown or
unknown or unsupported parameter. In this case where the unknown or unsupported parameter. In this case where the unknown or unsupported
unsupported parameter is a bit flag (VSPT flag), the included RP parameter is a bit flag (VSPT flag), the included RP object should
object should contain the whole bit flag field with all bits after contain the whole bit flag field with all bits after the parameter at
the parameter at issue set to zero. The corresponding path issue set to zero. The corresponding path computation request is
computation request is then cancelled by the PCE without further then cancelled by the PCE without further notification.
notification.
If the BRPC procedure cannot be completed because a PCE along the If the BRPC procedure cannot be completed because a PCE along the
domain path recognises but does not support the procedure, it MUST domain path recognizes but does not support the procedure, it MUST
return a PCErr message to the upstream PCE with an Error-Type "BRPC return a PCErr message to the upstream PCE with an Error-Type "BRPC
procedure completion failure". procedure completion failure".
The PCErr message MUST be relayed to the requesting PCC. The PCErr message MUST be relayed to the requesting PCC.
PCEP-ERROR objects are used to report a PCEP protocol error and are PCEP-ERROR objects are used to report a PCEP protocol error and are
characterized by an Error-Type which specifies the type of error and characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error an Error-value that provides additional information about the error
type. Both the Error-Type and the Error-Value are managed by IANA. type. Both the Error-Type and the Error-value are managed by IANA.
A new Error-Type is defined that relates to the BRPC procedure. A new Error-Type is defined that relates to the BRPC procedure.
Error-type Meaning Error-Type Meaning
13 BRPC procedure completion failure 13 BRPC procedure completion failure
Error-value Error-value
1: BRPC procedure not supported by one or more PCEs 1: BRPC procedure not supported by one or more PCEs
along the domain path along the domain path
10. Applicability 10. Applicability
As discussed in Section 3, the requirements for inter-area and As discussed in Section 3, the requirements for inter-area and
inter-AS MPLS Traffic Engineering have been developed by the Traffic inter-AS MPLS Traffic Engineering have been developed by the Traffic
Engineering Working Group (TE WG) and have been stated in [RFC4105] Engineering Working Group (TE WG) and have been stated in [RFC4105]
and [RFC4216], respectively. Among the set of requirements, both and [RFC4216], respectively. Among the set of requirements, both
documents indicate the need for some solution providing the ability documents indicate the need for some solution that provides the
to compute an optimal (shortest) constrained inter-domain TE LSP and ability to compute an optimal (shortest) constrained inter-domain TE
to compute a set of diverse inter-domain TE LSPs. LSP and to compute a set of diverse inter-domain TE LSPs.
10.1. Diverse end-to-end path computation 10.1. Diverse End-to-End Path Computation
PCEP (see [I-D.ietf-pce-pcep]) allows a PCC to request the PCEP (see [RFC5440]) allows a PCC to request the computation of a set
computation of a set of diverse TE LSPs thanks to the SVEC object by of diverse TE LSPs by setting the SVEC object's flags L, N, or S to
setting the flags L, N or S to request link, node or SRLG diversity request link, node, or SRLG (Shared Risk Link Group) diversity,
respectively. Such requests MUST be taken into account by each PCE respectively. Such requests MUST be taken into account by each PCE
along the path computation chain during the VSPT computation. In the along the path computation chain during the VSPT computation. In the
context of the BRPC procedure, a set of diversely routed TE LSPs context of the BRPC procedure, a set of diversely routed TE LSPs
between two LSRs can be computed since the paths segments of the VSPT between two LSRs can be computed since the path segments of the VSPT
are simultaneously computed by a given PCE. The BRPC procedure are simultaneously computed by a given PCE. The BRPC procedure
allows for the computation of diverse paths under various objective allows for the computation of diverse paths under various objective
functions (such as minimizing the sum of the costs of the N diverse functions (such as minimizing the sum of the costs of the N diverse
paths, etc). paths, etc.).
By constrast, with a 2-step approach consisting of computing the By contrast, with a 2-step approach consisting of computing the first
first path followed by the computation of the second path after path followed by computing the second path after having removed the
having removed the set of network elements traversed by the first set of network elements traversed by the first path (if that does not
path (if that does not violate confidentiality preservation), one violate confidentiality preservation), one cannot guarantee that a
cannot guarantee that a solution will be found even if such solution solution will be found even if such solution exists. Furthermore,
exists. Furthermore, even if a solution is found, it may not be the even if a solution is found, it may not be the most optimal one with
most optimal one with respect to an objective function such as respect to an objective function such as minimizing the sum of the
minimizing the sum of the paths costs, bounding the path delays of paths' costs, bounding the path delays of both paths, and so on.
both paths and so on. Finally, it must be noted that such a 2-step Finally, it must be noted that such a 2-step path computation
path computation approach is usually less efficient in term of approach is usually less efficient in terms of signaling delays since
signalling delays since it requires two serialized TE LSP set up. it requires that two serialized TE LSPs be set up.
10.2. Path Optimality 10.2. Path Optimality
BRPC guarantees that the optimal (shortest) constrained inter-domain BRPC guarantees that the optimal (shortest) constrained inter-domain
path will always be found subject to policy constraints. When path will always be found, subject to policy constraints. Both in
combined with other local path computation techniques (e.g. in the the case where local path computation techniques are used (such as to
case of stitched/nested TE LSP) and in the case where a domain has build stitched or nested TE LSPs), and in the case where a domain has
more than one BN-en or more than one BN-ex, optimality after some more than one BN-en or more than one BN-ex, it is only possible to
network change within the domain can only be guaranteed by re- guarantee optimality after some network change within the domain by
executing the BRPC procedure. completely re-executing the BRPC procedure.
11. Reoptimization Of An Inter-domain TE LSP 11. Reoptimization of an Inter-Domain TE LSP
The ability to reoptimize an existing inter-domain TE LSP path has The ability to reoptimize an existing inter-domain TE LSP path has
been explicitly listed as a requirement in [RFC4105] and [RFC4216]. been explicitly listed as a requirement in [RFC4105] and [RFC4216].
In the case of a TE LSP reoptimization request, the reoptimization In the case of a TE LSP reoptimization request, the reoptimization
procedure defined in [I-D.ietf-pce-pcep] applies where the path in procedure defined in [RFC5440] applies when the path in use (if
use (if available on the head-end) is provided as part of the path available on the head-end) is provided as part of the path
computation request in order for the PCEs involved in the computation request so that the PCEs involved in the reoptimization
reoptimization request to avoid double bandwidth accounting. request can avoid double bandwidth accounting.
12. Path Computation Failure 12. Path Computation Failure
If a PCE requires to relay a path computation request according to If a PCE requires to relay a path computation request according to
the BRPC procedure defined in this document to a downstream PCE and the BRPC procedure defined in this document to a downstream PCE and
no such PCE is available, the PCE MUST send a negative path no such PCE is available, the PCE MUST send a negative path
computation reply to the requester using a PCReq message as specified computation reply to the requester using a PCReq message as specified
in [I-D.ietf-pce-pcep] that contains a NO-PATH object. In such case, in [RFC5440] that contains a NO-PATH object. In such case, the
the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [RFC5440])
[I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path with the newly defined bit named "BRPC path computation chain
Computation chain unavailable" set. unavailable" set.
Bit number Name Flag Bit number Name Flag
4 BRPC Path computation chain unavailable 28 BRPC path computation chain unavailable
13. Metric Normalization 13. Metric Normalization
In the case of inter-area TE, the same IGP/TE metric scheme is In the case of inter-area TE, the same IGP/TE metric scheme is
usually adopted for all the IGP areas (e.g., based on the link-speed, usually adopted for all the IGP areas (e.g., based on the link-speed,
propagation delay or some other combination of link attributes). propagation delay, or some other combination of link attributes).
Hence, the proposed set of mechanisms always computes the shortest Hence, the proposed set of mechanisms always computes the shortest
path across multiple areas obeying the required set of constraints path across multiple areas that obey the required set of constraints
with respect to a specified objective function. Conversely, in the with respect to a specified objective function. Conversely, in the
case of Inter-AS TE, in order for this path computation to be case of inter-AS TE, in order for this path computation to be
meaningful, metric normalization between ASes may be required. One meaningful, metric normalization between ASes may be required. One
solution to avoid IGP metric modification would be for the Service solution to avoid IGP metric modification would be for the service
Providers to agree on a TE metric normalization scheme and use the TE providers to agree on a TE metric normalization scheme and use the TE
metric for TE LSP path computation (in that case, this must be metric for TE LSP path computation (in that case, the use of the TE
requested in the PCEP Path computation request) using the METRIC metric must be requested in the PCEP path computation request) using
object (defined in [I-D.ietf-pce-pcep]). the METRIC object (defined in [RFC5440]).
14. Manageability Considerations 14. Manageability Considerations
This section follows the guidance of This section follows the guidance of [PCE-MANAGE].
[I-D.ietf-pce-manageability-requirements].
14.1. Control of Function And Policy 14.1. Control of Function and Policy
The only configurable item is the support of the BRPC procedure on a The only configurable item is the support of the BRPC procedure on a
PCE. The support of the BRPC procedure by the PCE MAY be controlled PCE. The support of the BRPC procedure by the PCE MAY be controlled
by a policy module governing the conditions under which a PCE should by a policy module governing the conditions under which a PCE should
participate to the BRPC procedure (origin of the requests, number of participate in the BRPC procedure (origin of the requests, number of
requests per second, ...). If the BRPC is not supported/allowed on a requests per second, etc.). If the BRPC is not supported/allowed on
PCE, it MUST send a PCErr message as specified in Section 9. a PCE, it MUST send a PCErr message as specified in Section 9.
14.2. Information And Data Models 14.2. Information and Data Models
A BRPC MIB module will be specified in a separate document. A BRPC MIB module will be specified in a separate document.
14.3. Liveness Detection and Monitoring 14.3. Liveness Detection and Monitoring
The BRPC procedure is a Multiple-PCE path computation technique and The BRPC procedure is a multiple-PCE path computation technique and,
as such a set of PCEs are involved in the path computation chain. If as such, a set of PCEs are involved in the path computation chain.
the path computation chain is not operational either because at least If the path computation chain is not operational either because at
one PCE does not support the BRPC procedure or because one of the least one PCE does not support the BRPC procedure or because one of
PCEs that must be involved in the path computation chain is not the PCEs that must be involved in the path computation chain is not
available, procedures are defined to report such failures in available, procedures are defined to report such failures in Sections
Section 9 and Section 12 respectively. Furthermore, a built-in 9 and 12, respectively. Furthermore, a built-in diagnostic tool to
diagnostic tool to check the availability and performances of a PCE check the availability and performances of a PCE chain is defined in
chain is defined in [I-D.ietf-pce-monitoring]. [PCE-MONITOR].
14.4. Verifying Correct Operation 14.4. Verifying Correct Operation
Verifying the correct operation of BRPC can be performed by Verifying the correct operation of BRPC can be performed by
monitoring a set of parameters. A BRPC implementation SHOULD provide monitoring a set of parameters. A BRPC implementation SHOULD provide
the following parameters: the following parameters:
o Number of successful BRPC Procedure completions on a per PCE peer o Number of successful BRPC procedure completions on a per-PCE-peer
basis, basis
o Number of BRPC procedure completion failures because the VSPT flag o Number of BRPC procedure completion failures because the VSPT flag
was not recognized (on a per PCE peer basis), was not recognized (on a per-PCE-peer basis)
o Number of BRPC procedure completetion failures because the BRPC o Number of BRPC procedure completion failures because the BRPC
procedure was not supported (on a per PCE peer basis), procedure was not supported (on a per-PCE-peer basis)
14.5. Requirements on Other Protocols and Functional Components 14.5. Requirements on Other Protocols and Functional Components
The BRPC procedure does not put any new requirements on other The BRPC procedure does not put any new requirements on other
protocol. That said, since the BRPC procedure relies on the PCEP protocols. That said, since the BRPC procedure relies on the PCEP
protocol, there is a dependency between BRPC and PCEP; consequently protocol, there is a dependency between BRPC and PCEP; consequently,
the BRPC procedure inherently makes use of the management functions the BRPC procedure inherently makes use of the management functions
developed for PCEP. developed for PCEP.
14.6. Impact on Network Operation 14.6. Impact on Network Operation
The BRPC procedure does not have any significant impact on network The BRPC procedure does not have any significant impact on network
operation: indeed, BRPC is a Multiple-PCE path computation scheme as operation: indeed, BRPC is a multiple-PCE path computation scheme as
defined in [RFC4655] and does not differ from any other path defined in [RFC4655] and does not differ from any other path
computation request. computation request.
14.7. Path Computation Chain Monitoring 14.7. Path Computation Chain Monitoring
[I-D.ietf-pce-monitoring] specifies a set of mechanisms that can be [PCE-MONITOR] specifies a set of mechanisms that can be used to
used to gather PCE state metrics. Because BRPC is a Multiple-PCE gather PCE state metrics. Because BRPC is a multiple-PCE path
path computation techniques, such mechanism could be advantageously computation technique, such mechanisms could be advantageously used
used in the context of the BRPC procedure to check the liveness of in the context of the BRPC procedure to check the liveness of the
the path computation chain, locate a faulty component, monitor the path computation chain, locate a faulty component, monitor the
overall performance and so on. overall performance, and so on.
15. IANA Considerations 15. IANA Considerations
15.1. New Flag Of The RP Object 15.1. New Flag of the RP Object
A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is A new flag of the RP object (specified in [RFC5440]) is defined in
defined in this document. this document. IANA maintains a registry of RP object flags in the
"RP Object Flag Field" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
VSPT Flag IANA has allocated the following value:
Bit Number Name Flag Reference
7 VSPT This document
15.2. New Error-Type And Error-Value Bit Description Reference
25 VSPT This document
A new Error-Type is defined in this document (Error-Type and Error- 15.2. New Error-Type and Error-Value
value to be assigned by IANA).
Error-type Meaning Reference IANA maintains a registry of Error-Types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error
Types and Values" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
A new Error-value is defined for the Error-Type "Not supported
object" (type 4).
Error-Type Meaning and error values Reference
4 Not supported object
Error-value=4: Unsupported parameter This document
A new Error-Type is defined in this document as follows:
Error-Type Meaning Reference
13 BRPC procedure completion failure This document 13 BRPC procedure completion failure This document
Error-value
1: BRPC procedure not supported by
one a PCE along the domain path
15.3. New Flag Of The NO-PATH-VECTOR TLV Error-value=1: BRPC procedure not This document
supported by one or more PCEs along
the domain path
A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) 15.3. New Flag of the NO-PATH-VECTOR TLV
is specified in this document.
Bit number Meaning Reference A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is
specified in this document.
4 BRPC Path computation This document IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the
"NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry.
IANA has allocated the following allocation value:
Bit number Meaning Reference
4 BRPC path computation This document
chain unavailable chain unavailable
16. Security Considerations 16. Security Considerations
The BRPC procedure relies on the use of the PCEP protocol and as such The BRPC procedure relies on the use of the PCEP protocol and as such
is subjected to the potential attacks listed in section 11 of is subjected to the potential attacks listed in Section 10 of
[I-D.ietf-pce-pcep]. In addition to the security mechanisms [RFC5440]. In addition to the security mechanisms described in
described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping, [RFC5440] with regards to spoofing, snooping, falsification, and
falsification and Denial of Service, an implementation MAY support a denial of service, an implementation MAY support a policy module
policy module governing the conditions under which a PCE should governing the conditions under which a PCE should participate in the
participate to the BRPC procedure. BRPC procedure.
The BRPC procedure does not increase the information exchanged The BRPC procedure does not increase the information exchanged
between ASes and preserves topology confidentiality, in compliance between ASes and preserves topology confidentiality, in compliance
with [RFC4105] and [RFC4216]. with [RFC4105] and [RFC4216].
17. Acknowledgements 17. Acknowledgments
The authors would like to thank Arthi Ayyangar, Dimitri The authors would like to thank Arthi Ayyangar, Dimitri
Papadimitriou, Siva Sivabalan, Meral Shirazipour and Mach Chen for Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for
their useful comments. A special thank to Adrian Farrel for his their useful comments. A special thanks to Adrian Farrel for his
useful comments and suggestions. useful comments and suggestions.
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.ietf-pce-pcep]
Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri,
Y., Kumaki, K., Vasseur, J., and J. Roux, "Path
Computation Element (PCE) Communication Protocol (PCEP)",
draft-ietf-pce-pcep-12 (work in progress), March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
18.2. Informative References [RFC5440] Vasseur, J., Ed. and J. Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)",
RFC 5440, April 2009.
[I-D.ietf-ccamp-isis-interas-te-extension] 18.2. Informative References
Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-AS Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering",
draft-ietf-ccamp-isis-interas-te-extension-02 (work in
progress), April 2008.
[I-D.ietf-ccamp-ospf-interas-te-extension] [PATH-KEY] Bradford, R., Vasseur, J., and A. Farrel, "Preserving
Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Topology Confidentiality in Inter-Domain Path
Support of Inter-AS Multiprotocol Label Switching (MPLS) Computation Using a Key-Based Mechanism", Work in
and Generalized MPLS (GMPLS) Traffic Engineering", Progress, November 2008.
draft-ietf-ccamp-ospf-interas-te-extension-05 (work in
progress), April 2008.
[I-D.ietf-pce-manageability-requirements] [PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in
Farrel, A., "Inclusion of Manageability Sections in PCE PCE Working Group Drafts", Work in Progress,
Working Group Drafts", January 2009.
draft-ietf-pce-manageability-requirements-03 (work in
progress), February 2008.
[I-D.ietf-pce-monitoring] [PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
monitoring tools for Path Computation Element based monitoring tools for Path Computation Element based
Architecture", draft-ietf-pce-monitoring-01 (work in Architecture", Work in Progress, November 2008.
progress), February 2008.
[I-D.ietf-pce-path-key]
Bradford, R. and J. Vasseur, "Preserving Topology
Confidentiality in Inter-Domain Path Computation Using a
Key-Based Mechanism", draft-ietf-pce-path-key-02 (work in
progress), February 2008.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
McManus, "Requirements for Traffic Engineering Over MPLS", J. McManus, "Requirements for Traffic Engineering Over
RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements
Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. for Inter-Area MPLS Traffic Engineering", RFC 4105,
June 2005.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous
(AS) Traffic Engineering (TE) Requirements", RFC 4216, System (AS) Traffic Engineering (TE) Requirements",
November 2005. RFC 4216, November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path
Element (PCE)-Based Architecture", RFC 4655, August 2006. Computation Element (PCE)-Based Architecture",
RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element "IS-IS Protocol Extensions for Path Computation
(PCE) Discovery", RFC 5089, January 2008. Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-
Path Computation Method for Establishing Inter-Domain Domain Path Computation Method for Establishing Inter-
Traffic Engineering (TE) Label Switched Paths (LSPs)", Domain Traffic Engineering (TE) Label Switched Paths
RFC 5152, February 2008. (LSPs)", RFC 5152, February 2008.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com EMail: jpv@cisco.com
Raymond Zhang Raymond Zhang
BT Infonet BT Infonet
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90025 El Segundo, CA 90025
USA USA
Email: raymond_zhang@bt.infonet.com EMail: raymond.zhang@bt.com
Nabil Bitar Nabil Bitar
Verizon Verizon
40 Sylvan Road 117 West Street
Waltham, MA 02145 Waltham, MA 02451
USA USA
Email: nabil.bitar@verizon.com EMail: nabil.n.bitar@verizon.com
JL Le Roux JL Le Roux
France Telecom France Telecom
2, Avenue Pierre-Marzin 2, Avenue Pierre-Marzin
Lannion, 22307 Lannion, 22307
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ft.com EMail: jeanlouis.leroux@orange-ftgroup.com
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
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.
 End of changes. 131 change blocks. 
355 lines changed or deleted 364 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/