draft-ietf-pce-brpc-00.txt   draft-ietf-pce-brpc-01.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Informational R. Zhang Intended status: Informational R. Zhang
Expires: March 4, 2007 BT Infonet Expires: April 21, 2007 BT Infonet
N. Bitar N. Bitar
Verizon Verizon
JL. Le Roux JL. Le Roux
France Telecom France Telecom
August 31, 2006 October 18, 2006
A Backward Recursive PCE-based Computation (BRPC) procedure to compute A Backward Recursive PCE-based Computation (BRPC) procedure to compute
shortest inter-domain Traffic Engineering Label Switched Paths shortest inter-domain Traffic Engineering Label Switched Paths
draft-ietf-pce-brpc-00.txt draft-ietf-pce-brpc-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2007. This Internet-Draft will expire on April 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The ability to compute constrained shortest Traffic Engineering (TE) The ability to compute constrained shortest Traffic Engineering (TE)
Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) networks across multiple domains (where and Generalized MPLS (GMPLS) networks across multiple domains (where
skipping to change at page 3, line 7 skipping to change at page 3, line 7
by different Service Providers. by different Service Providers.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6
5. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Domain path selection . . . . . . . . . . . . . . . . . . 6
5.1. Domain path selection . . . . . . . . . . . . . . . . . . 6 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 6
5.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 7 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 8
6. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9 6. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9
7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9 7. Usage in conjunction with per-domain path computation . . . . 9
8. Usage in conjunction with per-domain path computation . . . . 9 8. BRPC procedure completion failure . . . . . . . . . . . . . . 9
9. BRPC procedure completion failure . . . . . . . . . . . . . . 10 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Diverse end-to-end path computation . . . . . . . . . . . 10
10.1. Diverse end-to-end path computation . . . . . . . . . . . 10 9.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 10
10.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 11 10. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11
11. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11 11. Metric normalization . . . . . . . . . . . . . . . . . . . . . 11
12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 11 12. Manageability Considerations . . . . . . . . . . . . . . . . . 11
13. Manageability Considerations . . . . . . . . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12
15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 16.1. Normative References . . . . . . . . . . . . . . . . . . . 12
17.1. Normative References . . . . . . . . . . . . . . . . . . . 12 16.2. Informative References . . . . . . . . . . . . . . . . . . 12
17.2. Informative References . . . . . . . . . . . . . . . . . . 13
17.3. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Proposed Status and Discussion [To Be Removed Appendix A. Proposed Status and Discussion [To Be Removed
Upon Publication] . . . . . . . . . . . . . . . . . . 14 Upon Publication] . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. History
The aim of this document is to specify a Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest constrained inter-
domain (G)MPLS TE LSP. Such procedure had been initially documented
in draft-vasseur-ccamp-inter-domain-path-comp (Scenario 2) and is now
moved to a separated document in the light of the progress made by
the PCE Working Group.
2. Terminology 1. Terminology
ABR: routers used to connect two IGP areas (areas in OSPF or levels ABR: routers used to connect two IGP areas (areas in OSPF or levels
in IS-IS). in IS-IS).
ASBR: routers used to connect together ASs of a different or the same ASBR: routers used to connect together ASs of a different or the same
Service Provider via one or more Inter-AS links. Service Provider via one or 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 TE or an ASBR in the context of inter-AS TE. of inter- area TE or an ASBR in the context of inter-AS TE.
skipping to change at page 5, line 5 skipping to change at page 4, line 42
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
[I-D.ietf-ccamp-inter-domain-framework] and will not be repeated [I-D.ietf-ccamp-inter-domain-framework] and will not be repeated
here. here.
3. Introduction 2. Introduction
The requirements for inter-area and inter-AS MPLS Traffic Engineering The requirements for inter-area and inter-AS MPLS Traffic Engineering
have been developed by the Traffic Engineering Working Group (TE WG) have been developed by the Traffic Engineering Working Group (TE WG)
and have been stated in [RFC4105] and [RFC4216], respectively. and have been stated in [RFC4105] and [RFC4216], respectively.
The framework for inter-domain MPLS Traffic Engineering has been The framework for inter-domain MPLS Traffic Engineering has been
provided in [I-D.ietf-ccamp-inter-domain-framework]. provided in [I-D.ietf-ccamp-inter-domain-framework].
[I-D.ietf-ccamp-inter-domain-pd-path-comp] defines a technique for [I-D.ietf-ccamp-inter-domain-pd-path-comp] defines a technique for
establishing inter-domain (G)MPLS TE LSP whereby the path is computed establishing inter-domain (G)MPLS TE LSP whereby the path is computed
skipping to change at page 5, line 40 skipping to change at page 5, line 29
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). destination of the TE LSP).
4. 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:
- Each IGP area or AS is assumed to be Traffic Engineering enabled - Each IGP area or AS is assumed to be Traffic Engineering enabled
(i.e. running OSPF-TE or ISIS-TE and RSVP-TE). (i.e. running OSPF-TE or ISIS-TE and RSVP-TE).
- No topology or resource information is distributed between domains - 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.
skipping to change at page 6, line 30 skipping to change at page 6, line 19
each AS will be considered to be comprised of a single area in this each AS will be considered to be comprised of a single area in this
document. The case of an Inter-AS TE LSP spanning multiple ASs where document. The case of an Inter-AS TE LSP spanning multiple ASs where
some of those ASs are themselves made of multiple IGP areas can be some of those ASs are themselves made of multiple IGP areas can be
easily derived from this case by applying the BRPC procedure easily derived from this case by applying the BRPC procedure
described in this document, recursively. described in this document, recursively.
- The domain path (set of domains traversed to reach the destination - The domain path (set of domains traversed to reach the destination
domain) is either administratively pre-determined or discovered by domain) is either administratively pre-determined or discovered by
some means (outside of the scope of this document). some means (outside of the scope of this document).
5. 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 [I-D.ietf-pce-architecture]. A possible model consists described in [RFC4655]. A possible model consists of hosting the PCE
of hosting the PCE function on boundary nodes (e.g., ABR or ASBR) but function on boundary nodes (e.g., ABR or ASBR) but this is not
this is not mandated by the BRPC procedure. mandated by the BRPC procedure.
The BRPC procedure does not make any assumptions with regards to the The BRPC procedure does not make any assumptions 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 or
stitched. 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 (it can be any variant of CSPF, algorithm algorithm in use by a PCE (it can be any variant of CSPF, algorithm
based on linear-programming to solve multi-constraints optimization based on linear-programming to solve multi-constraints optimization
problems and so on). problems and so on).
5.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 can either be determined a priori or during the path traversed can either be determined a priori or during the path
computation procedure. The BRPC procedure guarantees to compute the computation procedure. The BRPC procedure guarantees to compute the
optimal path across a specific set of traversed domains (which optimal path across a specific set of traversed domains (which
constitutes an additional constraint). In the case of an arbitrary constitutes an additional constraint). In the case of an arbitrary
set of meshed domains, the BRPC procedure can be used to compute the set of meshed domains, the BRPC procedure can be used to compute the
optimal path across each domain set in order to get to optimal optimal path across each domain set in order to get to optimal
constrained path between the source and the destination of the TE constrained path between the source and the destination of the TE
LSP. LSP.
5.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:
* There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- * There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN-
en(k,i) is the kth entry BN of domain(i). en(k,i) is the kth entry BN of domain(i).
* There is a set of X-ex(i) exit BN noted BN-ex(k,i) where BN-ex(k,i) * There is a set of X-ex(i) exit BN noted BN-ex(k,i) where BN-ex(k,i)
is the kth exit BN of domain(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):
skipping to change at page 8, line 7 skipping to change at page 7, line 41
constraints (either due to local policy or policies signaled in the constraints (either due to local policy or policies signaled in the
path computation request). path computation request).
Step 1: the PCC needs to first determine the PCE capable of serving Step 1: the PCC needs to first determine the PCE capable of serving
its path computation request. The path computation request is then its path computation request. The path computation request is then
relayed until reaching a PCE(n) such that the TE LSP destination relayed until reaching a PCE(n) such that the TE LSP destination
resides in the domain(n). At each step of the process, the next PCE resides in the domain(n). At each step of the process, the next PCE
can either be statically configured or dynamically discovered via can either be statically configured or dynamically discovered via
IGP/BGP extensions. If no next PCE can be found or the next hop PCE IGP/BGP extensions. If no next PCE can be found or the next hop PCE
of choice is unavailable, the procedure stops and a path computation of choice is unavailable, the procedure stops and a path computation
error is returned (see section Section 9). If multiple PCEs are error is returned (see section Section 8). If multiple PCEs are
discovered, the PCE may select a subset of these PCEs based on some discovered, the PCE may select a subset of these PCEs based on some
local policies or heuristics. Note also that a sequence of PCEs local policies or heuristics. Note also that a sequence of PCEs
might be enforced by policy on the PCC and this constraint can be might be enforced by policy on the PCC and this constraint can be
either carried in the PCEP path computation request (defined in either carried in the PCEP path computation request (defined in
[I-D.ietf-pce-pcep]. [I-D.ietf-pce-pcep].
Step 2: PCE(n) computes VSPT(n) made of the list of shortest Step 2: PCE(n) computes VSPT(n) made of the list of shortest
constrained path(s) between every BN-en(j,n) and the TE LSP constrained path(s) between every BN-en(j,n) and the TE LSP
destination using a suitable path computation algorithm (e.g. CSPF) destination using a suitable path computation algorithm (e.g. CSPF)
and returns the computed VSPT(n) to PCE(n-1). and returns the computed VSPT(n) to PCE(n-1).
skipping to change at page 9, line 5 skipping to change at page 8, line 40
[I-D.bradford-pce-path-key]. [I-D.bradford-pce-path-key].
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 ECMP paths, more than one path could be
returned to the requesting LSR. returned to the requesting LSR.
6. 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
[I-D.ietf-pce-pcep]), the aim of which is to specify that the [I-D.ietf-pce-pcep]), the aim of which is to specify that the
shortest path(s) satisfying the constraints from the destination to shortest path(s) satisfying the constraints from the destination to
the set of entry boundary nodes are requested (such set of path(s) the set of entry boundary nodes are requested (such set of path(s)
forms the downstream VSPT as specified in Section 5.2). forms the downstream VSPT as specified in Section 4.2).
The following new flag of the RP object is defined: VSPT (V) flag: The following new flag of the RP object is defined: VSPT (V) flag:
0x20. When set, this indicates that the PCC requests the computation 0x20. When set, this indicates that the PCC requests the computation
of an inter-domain TE LSP using the BRPC procedure. of an inter-domain TE LSP using the BRPC procedure.
Because path segment(s) computed by a downstream PCE in the context Because path segment(s) computed by a downstream PCE in the context
of the BRPC procedure must be provided along with their respective of the BRPC procedure must be provided along with their respective
path cost(s), the C flag of the RP object carried within the PCReq path cost(s), the C flag of the RP 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.
7. Inter-AS TE Links 6. 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 compliant with the PCE architecture defined in [RFC4655]).
[I-D.ietf-pce-architecture]).
That said, a straitghforward solution consists of allowing the ASBRs That said, a straitghforward solution consists of allowing the ASBRs
to flood the TE information related to the inter-ASBR link(s) to flood the TE information related to the inter-ASBR link(s)
although no IGP TE is enabled over those links (there is no IGP although no IGP TE is enabled over those links (there is no IGP
adjacency over the inter-ASBR links). This allows the PCE of a adjacency over the inter-ASBR links). This allows the PCE of a
domain to get entire TE visibility up to the set of entry ASBRs in domain to get entire TE visibility up to the set of entry ASBRs in
the downstream domain. the downstream domain.
8. Usage in conjunction with per-domain path computation 7. Usage in conjunction with per-domain path computation
The BRPC procedure may be used to compute path segments and could be The BRPC procedure may be used to compute path segments and could be
used in conjunction with other path computation techniques (such as used in conjunction with other path computation techniques (such as
the per-domain path computation technique defined in the per-domain path computation technique defined in
[I-D.ietf-ccamp-inter-domain-pd-path-comp]) to compute the end-to-end [I-D.ietf-ccamp-inter-domain-pd-path-comp]) to compute the end-to-end
path. In this case end-to-end path optimality can no longer be path. In this case end-to-end path optimality can no longer be
guaranteed. guaranteed.
9. BRPC procedure completion failure 8. 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 path does not support the procedure, a PCErr message is domain path does not support the procedure, a PCErr message is
returned to the upstream PCE with a Error-Type "BRPC procedure returned to the upstream PCE with a Error-Type "BRPC procedure
completion failure". The PCErr message MUST be relayed to the completion failure". The PCErr message MUST be relayed to the
requesting PCC. 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 which 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
10 BRPC procedure completion failure 10 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 9. 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 providing the ability
to compute an optimal (shortest) constrained inter-domain TE LSP and to compute an optimal (shortest) constrained inter-domain TE LSP and
to compute a set of diverse inter-domain TE LSPs. to compute a set of diverse inter-domain TE LSPs.
10.1. Diverse end-to-end path computation 9.1. Diverse end-to-end path computation
PCEP allows a PCC to request the computation of a set of diverse TE PCEP allows a PCC to request the computation of a set of diverse TE
LSPs thanks to the SVEC object by setting the flags L, N or S to LSPs thanks to the SVEC object by setting the flags L, N or S to
request link, node or SRLG diversity respectively. Such request MUST request link, node or SRLG diversity respectively. Such request MUST
be taken into account by each PCE along the path computation chain be taken into account by each PCE along the path computation chain
during the VSPT computation. In the context of the BRPC procedure, a during the VSPT computation. In the context of the BRPC procedure, a
set of diversely routed TE LSP between two LSRs can be computed since set of diversely routed TE LSP between two LSRs can be computed since
the paths segment(s) of the VSPT are simultaneously computed by a the paths segment(s) of the VSPT are simultaneously computed by a
given PCE. The BRPC path procedure allows for the computation of given PCE. The BRPC path procedure allows for the computation of
diverse paths under various objective functions (such as minimizing diverse paths under various objective functions (such as minimizing
skipping to change at page 11, line 12 skipping to change at page 10, line 46
traversed by the first path (if that does not violate confidentiality traversed by the first path (if that does not violate confidentiality
preservation), one cannot guarantee that a solution will be found preservation), one cannot guarantee that a solution will be found
even if such solution exists. Furthermore, even if a solution is even if such solution exists. Furthermore, even if a solution is
found, it may not be the most optimal one with respect to objective found, it may not be the most optimal one with respect to objective
function such as minimizing the sum of the paths costs, bounding the function such as minimizing the sum of the paths costs, bounding the
path delays of both paths and so on. Finally, it must be noted that path delays of both paths and so on. Finally, it must be noted that
such a 2-step path computation approach is usually less efficient in such a 2-step path computation approach is usually less efficient in
term of signalling delays since it requires two serialized TE LSP set term of signalling delays since it requires two serialized TE LSP set
up. up.
10.2. Path optimality 9.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. When
combined with other local path computation techniques (e.g. in the combined with other local path computation techniques (e.g. in the
case of stitched/nested TE LSP) and in the case where a domain has case of stitched/nested TE LSP) and in the case where a domain has
more than one BR-en or more than one BR-ex, optimality after some more than one BR-en or more than one BR-ex, optimality after some
network change within the domain can only be guaranteed by re- network change within the domain can only be guaranteed by re-
executing the BRPC procedure. executing the BRPC procedure.
11. Reoptimization of an inter-domain TE LSP 10. 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, regular procedures In the case of a TE LSP reoptimization request, regular procedures
apply as defined in PCEP where the path in use (if available on the apply as defined in PCEP where the path in use (if available on the
head-end) is provided within the path computation request in order head-end) is provided within the path computation request in order
for the PCEs involved in the reoptimization request to avoid double for the PCEs involved in the reoptimization request to avoid double
bandwidth accounting. bandwidth accounting.
12. Metric normalization 11. 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 obeying the required set of constraints
with respect to a well-specified objective function. Conversely, in with respect to a well-specified objective function. Conversely, in
the case of Inter-AS TE, in order for this path computation to be the case of Inter-AS TE, in order for this path computation to be
meaningful, a metric normalization between ASs may be required. One meaningful, a metric normalization between ASs may be required. One
solution to avoid IGP metric modification would be for the SPs to solution to avoid IGP metric modification would be for the SPs to
agree on a TE metric normalization scheme and use the TE metric for agree on a TE metric normalization scheme and use the TE metric for
TE LSP path computation (in that case, this must be requested in the TE LSP path computation (in that case, this must be requested in the
PCEP Path computation request) thanks to the COST object. PCEP Path computation request) thanks to the COST object.
13. Manageability Considerations 12. Manageability Considerations
To be added in a further revision of this document. To be added in a further revision of this document.
14. IANA Considerations 13. IANA Considerations
A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is
defined in this document. defined in this document.
Name: VSPT (V) Name: VSPT (V)
Value: 0x20. Value: 0x20.
When set, this indicates that the PCC requests the computation of an When set, this indicates that the PCC requests the computation of an
inter-domain TE LSP using the BRPC procedure. inter-domain TE LSP using the BRPC procedure.
A new Error-Type is defined in this document (Error-Type and Error- A new Error-Type is defined in this document (Error-Type and Error-
value to be assigned by IANA). value to be assigned by IANA).
Error-type Meaning Error-type Meaning
10 BRPC procedure completion failure 10 BRPC procedure completion failure
Error-value Error-value
1: BRPC procedure not supported by one or PCEs 1: BRPC procedure not supported by one or PCEs
along the domain path along the domain path
15. Security Considerations 14. Security Considerations
The BRPC procedure does not introduce any additional security issues The BRPC procedure does not introduce any additional security issues
beyond the ones related to inter-PCE communication. beyond the ones related to inter-PCE communication.
16. Acknowledgements 15. Acknowledgements
The authors would like to thank Arthi Ayyangar and Dimitri The authors would like to thank Arthi Ayyangar and Dimitri
Papadimitriou for their useful comments. A special thank to Adrian Papadimitriou for their useful comments. A special thank to Adrian
Farrel for his useful comments and suggestions. Farrel for his useful comments and suggestions.
17. References 16. References
17.1. Normative References
[I-D.ietf-pce-architecture] 16.1. Normative References
Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-05 (work in
progress), April 2006.
[I-D.ietf-pce-pcep] [I-D.ietf-pce-pcep]
Vasseur, J., "Path Computation Element (PCE) communication Vasseur, J., "Path Computation Element (PCE) communication
Protocol (PCEP) - Version 1", draft-ietf-pce-pcep-02 (work Protocol (PCEP) - Version 1", draft-ietf-pce-pcep-02 (work
in progress), June 2006. in progress), June 2006.
[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.
17.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
17.3. Informative References 16.2. Informative References
[I-D.bradford-pce-path-key] [I-D.bradford-pce-path-key]
Bradford, R., "Preserving Topology Confidentiality in Bradford, R., "Preserving Topology Confidentiality in
Inter-Domain Path Computation and Signaling", Inter-Domain Path Computation and Signaling",
draft-bradford-pce-path-key-00 (work in progress), draft-bradford-pce-path-key-00 (work in progress),
June 2006. June 2006.
[I-D.ietf-ccamp-inter-domain-framework] [I-D.ietf-ccamp-inter-domain-framework]
Farrel, A., "A Framework for Inter-Domain Multiprotocol Farrel, A., "A Framework for Inter-Domain Multiprotocol
Label Switching Traffic Engineering", Label Switching Traffic Engineering",
draft-ietf-ccamp-inter-domain-framework-05 (work in draft-ietf-ccamp-inter-domain-framework-06 (work in
progress), July 2006. progress), August 2006.
[I-D.ietf-ccamp-inter-domain-pd-path-comp] [I-D.ietf-ccamp-inter-domain-pd-path-comp]
Vasseur, J., "A Per-domain path computation method for Vasseur, J., "A Per-domain path computation method for
establishing Inter-domain Traffic Engineering (TE) Label establishing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)", Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-03 (work in draft-ietf-ccamp-inter-domain-pd-path-comp-03 (work in
progress), August 2006. progress), August 2006.
[I-D.ietf-ccamp-inter-domain-rsvp-te] [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in
progress), March 2006. progress), March 2006.
[I-D.ietf-pce-disco-proto-igp]
Roux, J., "IGP protocol extensions for Path Computation
Element (PCE) Discovery",
draft-ietf-pce-disco-proto-igp-02 (work in progress),
June 2006.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. 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 for
Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 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 System
(AS) Traffic Engineering (TE) Requirements", RFC 4216, (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005. November 2005.
 End of changes. 36 change blocks. 
84 lines changed or deleted 61 lines changed or added

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