draft-ietf-pce-brpc-06.txt   draft-ietf-pce-brpc-07.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: Standards Track R. Zhang Intended status: Standards Track R. Zhang
Expires: March 7, 2008 BT Infonet Expires: August 11, 2008 BT Infonet
N. Bitar N. Bitar
Verizon Verizon
JL. Le Roux JL. Le Roux
France Telecom France Telecom
September 4, 2007 February 8, 2008
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-06.txt draft-ietf-pce-brpc-07.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 7, 2008. This Internet-Draft will expire on August 11, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The ability to compute shortest constrained Traffic Engineering (TE) The ability to compute shortest constrained Traffic Engineering Label
Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
and Generalized MPLS (GMPLS) networks across multiple domains (where Generalized MPLS (GMPLS) networks across multiple domains (where a
a domain is referred to as a collection of network elements within a domain is referred to as a collection of network elements within a
common sphere of address management or path computational common sphere of address management or path computational
responsibility such as IGP areas and Autonomous Systems) has been responsibility such as IGP areas and Autonomous Systems) has been
identified as a key requirement . This document specifies a identified as a key requirement. This document specifies a procedure
procedure relying on the use of multiple Path Computation Elements relying on the use of multiple Path Computation Elements (PCEs) in
(PCEs) in order to compute such inter-domain shortest constrained order to compute such inter-domain shortest constrained paths along a
paths along a determined sequence of domains, using a backward determined sequence of domains, using a backward recursive path
recursive path computation technique while preserving confidentiality computation technique while preserving confidentiality across
across domains, which is sometimes required when domains are managed domains, which is sometimes required when domains are managed by
by different Service Providers. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Domain path selection . . . . . . . . . . . . . . . . . . 6 4.1. Domain path selection . . . . . . . . . . . . . . . . . . 6
4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 7 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 7
5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9
6. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9 6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Usage in conjunction with per-domain path computation . . . . 9 7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10
8. BRPC procedure completion failure . . . . . . . . . . . . . . 10 8. Usage in conjunction with per-domain path computation . . . . 10
9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 9. BRPC procedure completion failure . . . . . . . . . . . . . . 10
9.1. Diverse end-to-end path computation . . . . . . . . . . . 10 10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 11 10.1. Diverse end-to-end path computation . . . . . . . . . . . 11
10. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11 10.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 12
11. Path Computation failure . . . . . . . . . . . . . . . . . . . 11 11. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 12
12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 11 12. Path Computation failure . . . . . . . . . . . . . . . . . . . 12
13. Manageability Considerations . . . . . . . . . . . . . . . . . 12 13. Metric normalization . . . . . . . . . . . . . . . . . . . . . 12
13.1. Control of Function and Policy . . . . . . . . . . . . . . 12 14. Manageability Considerations . . . . . . . . . . . . . . . . . 13
13.2. Information and Data Models . . . . . . . . . . . . . . . 12 14.1. Control of Function and Policy . . . . . . . . . . . . . . 13
13.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 14.2. Information and Data Models . . . . . . . . . . . . . . . 13
13.4. Verifying Correct Operation . . . . . . . . . . . . . . . 12 14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13
13.5. Requirements on Other Protocols and Functional 14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13
Components . . . . . . . . . . . . . . . . . . . . . . . . 13 14.5. Requirements on Other Protocols and Functional
13.6. Impact on Network Operation . . . . . . . . . . . . . . . 13 Components . . . . . . . . . . . . . . . . . . . . . . . . 14
13.7. Path computation chain monitoring . . . . . . . . . . . . 13 14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 14.7. Path computation chain monitoring . . . . . . . . . . . . 14
14.1. New flag of the RP object . . . . . . . . . . . . . . . . 13 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14.2. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 14 15.1. New flag of the RP object . . . . . . . . . . . . . . . . 14
15. Security Considerations . . . . . . . . . . . . . . . . . . . 14 15.2. new Error-Type and Error-Value . . . . . . . . . . . . . . 14
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 15.3. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 16. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17.1. Normative References . . . . . . . . . . . . . . . . . . . 14 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
17.2. Informative References . . . . . . . . . . . . . . . . . . 15 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
18.1. Normative References . . . . . . . . . . . . . . . . . . . 15
18.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Proposed Status and Discussion [To Be Removed Appendix A. Proposed Status and Discussion [To Be Removed
Upon Publication] . . . . . . . . . . . . . . . . . . 16 Upon Publication] . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. 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 ASes of the same or different ASBR: routers used to connect together ASes of the same or different
Service Provider(s) via one or more Inter-AS links. Service Provider(s) 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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
during the signalling process on a per-domain basis by the entry during the signalling process on a per-domain basis by the entry
boundary node of each domain (each node in charge of computing a boundary node of each domain (each node in charge of computing a
section of an inter-domain TE LSP path is always along the path of section of an inter-domain TE LSP path is always along the path of
such TE LSP). Such path computation technique fulfills some of the such TE LSP). Such path computation technique fulfills some of the
requirements stated in [RFC4105] and [RFC4216] but not all of them. requirements stated in [RFC4105] and [RFC4216] but not all of them.
In particular, it cannot guarantee to find an optimal (shortest) In particular, it cannot guarantee to find an optimal (shortest)
inter-domain constrained path. Furthermore, it cannot be efficiently inter-domain constrained path. Furthermore, it cannot be efficiently
used to compute a set of inter-domain diversely routed TE LSPs. used to compute a set of inter-domain diversely routed TE LSPs.
The PCE architecture is defined in [RFC4655]. The aim of this The PCE architecture is defined in [RFC4655]. The aim of this
document is to describe a PCE-based TE LSP computation procedure to document is to describe a PCE-based path computation procedure to
compute optimal inter-domain constrained (G)MPLS TE LSPs. compute optimal inter-domain constrained (G)MPLS TE LSPs.
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). destination of the TE LSP).
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:
- Each IGP area or AS is assumed to be Traffic Engineering enabled - Each IGP area or Autonomous System (AS) is assumed to be Traffic
(i.e. running OSPF-TE or ISIS-TE and RSVP-TE). Engineering enabled (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.
- While certain constraints like bandwidth can be used across - While certain constraints like bandwidth can be used across
different domains, other TE constraints like resource affinity, different domains, other TE constraints like resource affinity,
color, metric, etc. as listed in [RFC2702] could be translated at color, metric, etc. as listed in [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 on boundary nodes, there will exist some sort of local mapping based on
skipping to change at page 6, line 27 skipping to change at page 6, line 27
domain) is either administratively pre-determined or discovered by domain) is either administratively pre-determined or discovered by
some means that are outside of the scope of this document. some means that are 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 does not make any assumptions 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 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 (e.g., it can be any variant of CSPF or an
based on linear-programming to solve multi-constraints optimization algorithm based on linear-programming to solve multi-constraints
problems and so on). 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 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 sequence of traversed domains (which optimal path across a specific sequence 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 the optimal optimal path across each domain set in order to get the optimal
constrained path between the source and the destination of the TE constrained path between the source and the destination of the TE
LSP. The BRPC procedure can also be used across a subset of all LSP. The BRPC procedure can also be used across a subset of all
domain sequences, and the best path among these sequences is then domain sequences, and the best path among these sequences can then be
selected. 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:
* 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).
skipping to change at page 7, line 27 skipping to change at page 7, line 27
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 \ / 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 BN in domain i Where [X-en(i)] is the number of entry BN in domain i
and j<= [X-en(i)] and j<= [X-en(i)]
Each link of tree VSPT(i) represents the shortest path between BN- Figure 1 - MP2P Tree
en(j,i) (identified by its TE Router-ID) and the destination that
satisfies the set of required constraints for the TE LSP (bandwidth, Each link of tree VSPT(i) represents the shortest constrained path
affinities, ...). These are path segments to reach the destination between BN-en(j,i) (identified by its TE Router-ID) and the TE LSP
from BN-en(j,i). destination that satisfies the set of required constraints for the TE
LSP (bandwidth, affinities, ...). These are path segments to reach
the TE LSP destination from BN-en(j,i).
Note that PCE(i) only considers the entry BNs that provide Note that PCE(i) only considers the entry BNs that provide
connectivity from domain(i-1). That is, the set BN-en(k,i-1) is only connectivity from domain(i-1). That is, the set BN-en(k,i-1) is only
made of those BNs that provide connectivity from domain (i-1) to made of those BNs that provide connectivity from domain (i-1) to
domain(i). Furthermore, some BNs may be excluded according to policy domain(i). Furthermore, some BNs may be excluded according to policy
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 (this can be done thanks to local its path computation request (this can be done thanks to local
configuration or via IGP discovery (see configuration or via IGP discovery (see [RFC5088] and [RFC5089])).
[I-D.ietf-pce-disco-proto-ospf] and The path computation request is then relayed until reaching a PCE(n)
[I-D.ietf-pce-disco-proto-isis])). The path computation request is such that the TE LSP destination resides in the domain(n). At each
then relayed until reaching a PCE(n) such that the TE LSP destination step of the process, the next PCE can either be statically configured
resides in the domain(n). At each step of the process, the next PCE or dynamically discovered via IGP/BGP extensions. If no next PCE can
can either be statically configured or dynamically discovered via be found or the next hop PCE of choice is unavailable, the procedure
IGP/BGP extensions. If no next PCE can be found or the next hop PCE stops and a path computation error is returned (see Section 9). If
of choice is unavailable, the procedure stops and a path computation multiple PCEs are discovered, the PCE may select a subset of these
error is returned (see Section 8). If multiple PCEs are discovered, PCEs based on some local policies or heuristics. The PCE selection
the PCE may select a subset of these PCEs based on some local process is outside of the scope of this document. Note also that a
policies or heuristics. Note also that a sequence of PCEs might be sequence of PCEs might be enforced by policy on the PCC and this
enforced by policy on the PCC and this constraint can be carried in constraint can be carried in the PCEP path computation request (as
the PCEP path computation request (as defined in defined in [I-D.ietf-pce-monitoring]).
[I-D.vasseur-pce-monitoring]).
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).
Step i: Step i:
- For i=n-1 to 2: PCE(i) concatenates the topology of domain(i) - For i=n-1 to 2: PCE(i) concatenates the topology of domain(i)
(using its TED) with the received VSPT(i+1). In the case of Inter-AS (using its TED) with the received VSPT(i+1).
TE LSP computation, this requires to also add the inter-AS TE links
connecting the domain(i) to the domain(i+1). Then PCE(i) computes In the case of Inter-AS TE LSP computation, this requires to also add
VSPT(i) (MP2P (Multi-Point to Point) tree made of the shortest the inter-AS TE links connecting the domain(i) to the domain(i+1).
constrained paths between each BN-en(j,i) and the TE LSP
destination). Then PCE(i) computes VSPT(i) (MP2P (Multi-Point to Point) tree made
of the shortest constrained paths between each BN-en(j,i) and the TE
LSP destination).
End End
Finally PCE(1) computes the end-to-end shortest constrained path from Finally PCE(1) computes the end-to-end shortest constrained path from
the source to the destination and returns the corresponding path to the source to the destination and returns the corresponding path to
the requesting PCC in the form of a PCRep message as defined in the requesting PCC in the form of a PCRep message as defined in
[I-D.ietf-pce-pcep]. [I-D.ietf-pce-pcep].
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 BR is specified) so listed) or a loose path (in which case only the BR 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 later 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.bradford-pce-path-key]. [I-D.ietf-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.
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
[I-D.ietf-pce-pcep]), the aim of which is to specify that the [I-D.ietf-pce-pcep]) to specify that the shortest paths satisfying
shortest path(s) satisfying the constraints from the destination to the constraints from the destination to the set of entry boundary
the set of entry boundary nodes are requested (such set of path(s) nodes are requested (such set of paths forms the downstream VSPT as
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: VSPT (V) flag: The following new flag of the RP object is defined:
0x60. When set, this indicates that the PCC requests the computation
of an inter-domain TE LSP using the BRPC procedure. VSPT Flag
Bit Number Name Flag
7 VSPT
When set, the VSPT Flag indicates that the PCC requests the
computation of an inter-domain TE LSP using the BRPC procedure
defined in this document.
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 METRIC object carried within the path cost(s), the C flag of the METRIC object carried within the
PCReq message MUST be set. It is the choice of the requester to PCReq 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. Inter-AS TE Links 6. VSPT Encoding
The VSPT is returned within a PCRep message. The encoding consists
of a non-ordered lists of EROs where each ERO represents a path
segment from an ABR to the destination specified in the END-POINT
object of the corresponding PCReq message.
Example:
<---- area 1 ----><---- area 0 -----><------ area 2 ------>
ABR1-A-B-+
| |
ABR2-----D
| |
ABR3--C--+
Figure 2 - An Example of VPST Encoding Using a Set of EROs
In the simple example shown in figure 2, if we make the assumption
that a constrained path exists between each ABR and the destination
D, the VSPT computed by a PCE serving area 2 consists of the
following non-ordered set of EROs:
o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP
address)-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)
The PCERep message, PCRep message, PCEP END-POINT and ERO objects are
defined in [I-D.ietf-pce-pcep]
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 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 (see the IGP extensions defined in
[I-D.ietf-ccamp-isis-interas-te-extension] and
[I-D.ietf-ccamp-ospf-interas-te-extension]).
7. 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 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.
8. 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 path does not support the procedure, a PCErr message MUST be domain path does not support the procedure, a PCErr message MUST be
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
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
9. 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 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.
9.1. Diverse end-to-end path computation 10.1. Diverse end-to-end path computation
PCEP allows a PCC to request the computation of a set of diverse TE PCEP (see [I-D.ietf-pce-pcep]) allows a PCC to request the
LSPs thanks to the SVEC object by setting the flags L, N or S to computation of a set of diverse TE LSPs thanks to the SVEC object by
request link, node or SRLG diversity respectively. Such request MUST setting the flags L, N or S to request link, node or SRLG diversity
be taken into account by each PCE along the path computation chain respectively. Such request MUST be taken into account by each PCE
during the VSPT computation. In the context of the BRPC procedure, a along the path computation chain during the VSPT computation. In the
set of diversely routed TE LSP between two LSRs can be computed since context of the BRPC procedure, a set of diversely routed TE LSP
the paths segment(s) of the VSPT are simultaneously computed by a between two LSRs can be computed since the paths segment(s) of the
given PCE. The BRPC procedure allows for the computation of diverse VSPT are simultaneously computed by a given PCE. The BRPC procedure
paths under various objective functions (such as minimizing the sum allows for the computation of diverse paths under various objective
of the costs of the N diverse paths, etc) thus avoiding the well- functions (such as minimizing the sum of the costs of the N diverse
known "trapping" problem. Indeed, with a 2-step approach consisting paths, etc).
of computing the first path followed by the computation of the second
path after having removed the set of network elements traversed by
the first path (if that does not violate confidentiality
preservation), one cannot guarantee that a solution will be found
even if such solution exists. Furthermore, even if a solution is
found, it may not be the most optimal one with respect to an
objective 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 such a 2-step path computation approach is usually less
efficient in term of signalling delays since it requires two
serialized TE LSP set up.
9.2. Path optimality By constrast, with a 2-step approach consisting of computing the
first path followed by the computation of the second path after
having removed the set of network elements traversed by the first
path (if that does not violate confidentiality preservation), one
cannot guarantee that a solution will be found even if such solution
exists. Furthermore, even if a solution is found, it may not be the
most optimal one with respect to an objective 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 such a 2-step
path computation approach is usually less efficient in term of
signalling delays since it requires two serialized TE LSP set up.
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. 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.
10. 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
procedures defined in [I-D.ietf-pce-pcep] apply where the path in use procedure defined in [I-D.ietf-pce-pcep] applies where the path in
(if available on the head-end) is provided as part of the path use (if available on the head-end) is provided as part of the path
computation request in order for the PCEs involved in the computation request in order for the PCEs involved in the
reoptimization request to avoid double bandwidth accounting. reoptimization request to avoid double bandwidth accounting.
11. 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 [I-D.ietf-pce-pcep] that contains a NO-PATH object. In such case,
the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in
[I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path [I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path
Computation chain unavailable" set. Computation chain unavailable" set.
0x04: BRPC Path computation chain unavailable Bit number Name Flag
4 BRPC Path computation chain unavailable
12. 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 obeying the required set of constraints
with respect to a well-specified objective function. Conversely, in with respect to a specified objective function. Conversely, in the
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, a metric normalization between ASes may be required. One meaningful, a metric normalization between ASes 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 Service
agree on a TE metric normalization scheme and use the TE metric for Providers to agree on a TE metric normalization scheme and use the TE
TE LSP path computation (in that case, this must be requested in the metric for TE LSP path computation (in that case, this must be
PCEP Path computation request) thanks to the METRIC object (defined requested in the PCEP Path computation request) thanks to the METRIC
in [I-D.ietf-pce-pcep]). object (defined in [I-D.ietf-pce-pcep]).
13. Manageability Considerations 14. Manageability Considerations
This section is compliant with This section follows the guidance of
[I-D.ietf-pce-manageability-requirements]. [I-D.ietf-pce-manageability-requirements].
13.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 to the BRPC procedure (origin of the requests, number of
requests per second, ...). If the BRPC is not supported/allowed on a requests per second, ...). If the BRPC is not supported/allowed on a
PCE, it MUST send a PCErr message as specified in Section 8. PCE, it MUST send a PCErr message as specified in Section 9.
13.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.
13.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. If
the path computation chain is not operational either because at least the path computation chain is not operational either because at least
one PCE does not support the BRPC procedure or because one of the one PCE does not support the BRPC procedure or because one of the
PCEs that must be involved in the path computation chain is not 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
Section 8 and Section 11 respectively. Furthermore, a built in Section 9 and Section 12 respectively. Furthermore, a built-in
diagnostic tool to check the availability and performances of a PCE diagnostic tool to check the availability and performances of a PCE
chain is defined in [I-D.vasseur-pce-monitoring]. chain is defined in [I-D.ietf-pce-monitoring].
13.4. Verifying Correct Operation 14.4. Verifying Correct Operation
Verifying the correct operation of BRPC can be done by looking at the Verifying the correct operation of BRPC can be done by looking at the
TEDs related to the various domains traversed by a TE LSP at the time TEDs related to the various domains traversed by a TE LSP at the time
the BRPC procedure was invoked and verify that the path computed by the BRPC procedure was invoked and verify that the path computed by
the BRPC procedure is the expected optimal path (the path that would the BRPC procedure is the expected optimal inter-domain constrained
be obtained in the absence of multiple domains). path (the path that would be obtained in the absence of multiple
domains).
13.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 protocol. 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.
13.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.
13.7. Path computation chain monitoring 14.7. Path computation chain monitoring
[I-D.vasseur-pce-monitoring] specifies a set of mechanisms that can [I-D.ietf-pce-monitoring] specifies a set of mechanisms that can be
be used to gather PCE state metrics. Because BRPC is a Multiple-PCE used to gather PCE state metrics. Because BRPC is a Multiple-PCE
path computation techniques, such mechanism could be advantageously path computation techniques, such mechanism could be advantageously
used in the context of the BRPC procedure to check the liveness of used in the context of the BRPC procedure to check the liveness of
the path computation chain, locate a faulty component, monitor the the path computation chain, locate a faulty component, monitor the
overall performance and so on. overall performance and so on.
14. IANA Considerations 15. IANA Considerations
14.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 [I-D.ietf-pce-pcep]) is
defined in this document. defined in this document.
Name: VSPT (V) VSPT Flag
Bit Number Name Flag Reference
Bit Number: 10 7 VSPT This document
Value: 0x60
When set, this indicates that the PCC requests the computation of an 15.2. new Error-Type and Error-Value
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 Reference
13 BRPC procedure completion failure 13 BRPC procedure completion failure This document
Error-value Error-value
1: BRPC procedure not supported by one or PCEs 1: BRPC procedure not supported by
along the domain path one a PCE along the domain path
14.2. New flag of the NO-PATH-VECTOR TLV 15.3. New flag of the NO-PATH-VECTOR TLV
A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep])
is specified in this document. is specified in this document.
Defining RFC: draft-ietf-pce-pcep (to be replaced by RFC number when pusblished) Bit number Meaning Reference
Name of bit: BRPC Path computation chain unavailable
Bit number (suggested value): 0x04
15. Security Considerations 4 BRPC Path computation This document
chain unavailable
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 11 of
[I-D.ietf-pce-pcep]. In addition to the security mechanisms [I-D.ietf-pce-pcep]. In addition to the security mechanisms
described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping, described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping,
falsification and Denial of Service, an implementation MAY support a falsification and Denial of Service, an implementation MAY support a
policy module governing the conditions under which a PCE should policy module governing the conditions under which a PCE should
participate to the BRPC procedure. participate to the 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].
16. Acknowledgements 17. Acknowledgements
The authors would like to thank Arthi Ayyangar, Dimitri The authors would like to thank Arthi Ayyangar, Dimitri
Papadimitriou, Siva Sivabalan and Meral Shirazipour for their useful Papadimitriou, Siva Sivabalan and Meral Shirazipour for their useful
comments. A special thank to Adrian Farrel for his useful comments comments. A special thank to Adrian Farrel for his useful comments
and suggestions. and suggestions.
17. References 18. References
17.1. Normative References 18.1. Normative References
[I-D.ietf-pce-pcep] [I-D.ietf-pce-pcep]
Roux, J. and J. Vasseur, "Path Computation Element (PCE) Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri,
communication Protocol (PCEP)", draft-ietf-pce-pcep-08 Y., Kumaki, K., Vasseur, J., and J. Roux, "Path
(work in progress), July 2007. Computation Element (PCE) communication Protocol (PCEP)",
draft-ietf-pce-pcep-09 (work in progress), November 2007.
[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.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
17.2. Informative References 18.2. Informative References
[I-D.bradford-pce-path-key]
Bradford, R., "Preserving Topology Confidentiality in
Inter-Domain Path Computation using a key based
mechanism", draft-bradford-pce-path-key-02 (work in
progress), January 2007.
[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., Ayyangar, A., and R. Zhang, "A Per-domain
establishing Inter-domain Traffic Engineering (TE) Label path computation method for establishing Inter-domain
Switched Paths (LSPs)", Traffic Engineering (TE) Label Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-05 (work in draft-ietf-ccamp-inter-domain-pd-path-comp-06 (work in
progress), April 2007. progress), November 2007.
[I-D.ietf-ccamp-inter-domain-rsvp-te] [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A., "Inter domain Multiprotocol Label Switching Ayyangar, A., "Inter domain Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering -
RSVP-TE extensions", RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-06 (work in draft-ietf-ccamp-inter-domain-rsvp-te-07 (work in
progress), April 2007. progress), September 2007.
[I-D.ietf-pce-disco-proto-isis] [I-D.ietf-ccamp-isis-interas-te-extension]
Roux, J., "IS-IS protocol extensions for Path Computation Chen, M. and R. Zhang, "ISIS Extensions in Support of
Element (PCE) Discovery", Inter-AS Multiprotocol Label Switching (MPLS) and
draft-ietf-pce-disco-proto-isis-06 (work in progress), Generalized MPLS (GMPLS) Traffic Engineering",
June 2007. draft-ietf-ccamp-isis-interas-te-extension-00 (work in
progress), February 2008.
[I-D.ietf-pce-disco-proto-ospf] [I-D.ietf-ccamp-ospf-interas-te-extension]
Roux, J., "OSPF protocol extensions for Path Computation Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Element (PCE) Discovery", Support of Inter-AS Multiprotocol Label Switching (MPLS)
draft-ietf-pce-disco-proto-ospf-06 (work in progress), and Generalized MPLS (GMPLS) Traffic Engineering",
June 2007. draft-ietf-ccamp-ospf-interas-te-extension-02 (work in
progress), November 2007.
[I-D.ietf-pce-manageability-requirements] [I-D.ietf-pce-manageability-requirements]
Farrel, A., "Inclusion of Manageability Sections in PCE Farrel, A., "Inclusion of Manageability Sections in PCE
Working Group Drafts", Working Group Drafts",
draft-ietf-pce-manageability-requirements-02 (work in draft-ietf-pce-manageability-requirements-02 (work in
progress), August 2007. progress), August 2007.
[I-D.vasseur-pce-monitoring] [I-D.ietf-pce-monitoring]
Vasseur, J., "A set of monitoring tools for Path Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
Computation Element based Architecture", monitoring tools for Path Computation Element based
draft-vasseur-pce-monitoring-03 (work in progress), Architecture", draft-ietf-pce-monitoring-01 (work in
May 2007. progress), February 2008.
[I-D.ietf-pce-path-key]
Bradford, R., "Preserving Topology Confidentiality in
Inter-Domain Path Computation Using a Key-Based
Mechanism", draft-ietf-pce-path-key-01 (work in progress),
September 2007.
[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.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic 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,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008.
Appendix A. Proposed Status and Discussion [To Be Removed Upon Appendix A. Proposed Status and Discussion [To Be Removed Upon
Publication] Publication]
This Internet-Draft is being submitted for eventual publication as an This Internet-Draft is being submitted for eventual publication as an
RFC with a proposed status of Standard. Discussion of this proposal RFC with a proposed status of Standard. Discussion of this proposal
should take place on the following mailing list: pce@ietf.org. should take place on the following mailing list: pce@ietf.org.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
skipping to change at page 18, line 7 skipping to change at page 19, line 7
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-ft.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 74 change blocks. 
203 lines changed or deleted 261 lines changed or added

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