draft-ietf-pce-brpc-04.txt   draft-ietf-pce-brpc-05.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: September 3, 2007 BT Infonet Expires: December 20, 2007 BT Infonet
N. Bitar N. Bitar
Verizon Verizon
JL. Le Roux JL. Le Roux
France Telecom France Telecom
March 2, 2007 June 18, 2007
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-04.txt draft-ietf-pce-brpc-05.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 September 3, 2007. This Internet-Draft will expire on December 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The ability to compute shortest constrained Traffic Engineering (TE) The ability to compute shortest constrained 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 22 skipping to change at page 3, line 22
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. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9
7. Usage in conjunction with per-domain path computation . . . . 9 7. Usage in conjunction with per-domain path computation . . . . 9
8. BRPC procedure completion failure . . . . . . . . . . . . . . 10 8. BRPC procedure completion failure . . . . . . . . . . . . . . 10
9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Diverse end-to-end path computation . . . . . . . . . . . 10 9.1. Diverse end-to-end path computation . . . . . . . . . . . 10
9.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 11 9.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 11
10. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11 10. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11
11. Path Computation failure . . . . . . . . . . . . . . . . . . . 11 11. Path Computation failure . . . . . . . . . . . . . . . . . . . 11
12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 12 12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 11
13. Manageability Considerations . . . . . . . . . . . . . . . . . 12 13. Manageability Considerations . . . . . . . . . . . . . . . . . 12
13.1. Control of Function and Policy . . . . . . . . . . . . . . 12 13.1. Control of Function and Policy . . . . . . . . . . . . . . 12
13.2. Information and Data Models . . . . . . . . . . . . . . . 12 13.2. Information and Data Models . . . . . . . . . . . . . . . 12
13.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 13.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12
13.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13 13.4. Verifying Correct Operation . . . . . . . . . . . . . . . 12
13.5. Requirements on Other Protocols and Functional 13.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 13 Components . . . . . . . . . . . . . . . . . . . . . . . . 13
13.6. Impact on Network Operation . . . . . . . . . . . . . . . 13 13.6. Impact on Network Operation . . . . . . . . . . . . . . . 13
13.7. Path computation chain monitoring . . . . . . . . . . . . 13 13.7. Path computation chain monitoring . . . . . . . . . . . . 13
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14.1. New flag of the RP object . . . . . . . . . . . . . . . . 13 14.1. New flag of the RP object . . . . . . . . . . . . . . . . 13
14.2. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 14 14.2. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 14
15. Security Considerations . . . . . . . . . . . . . . . . . . . 14 15. Security Considerations . . . . . . . . . . . . . . . . . . . 14
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 6, line 8 skipping to change at page 6, line 8
- 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
policy agreement, in order to translate such constraints across policy agreement, in order to translate such constraints across
domain boundaries during the inter-PCE communication process. domain boundaries during the inter-PCE communication process.
- Each AS can be made of several IGP areas. The path computation - Each AS can be made of several IGP areas. The path computation
procedure described in this document applies to the case of a single procedure described in this document applies to the case of a single
AS made of multiple IGP areas, multiples ASes made of a single IGP AS made of multiple IGP areas, multiple ASes made of a single IGP
area or any combination of the above. For the sake of simplicity, area or any combination of the above. For the sake of simplicity,
each AS will be considered to be made of a single area in this each AS will be considered to be made of a single area in this
document. The case of an Inter-AS TE LSP spanning multiple ASes document. The case of an Inter-AS TE LSP spanning multiple ASes
where some of those ASes are themselves made of multiple IGP areas where some of those ASes are themselves made of multiple IGP areas
can be easily derived from this case by applying the BRPC procedure can be 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 that are outside of the scope of this document. some means that are outside of the scope of this document.
skipping to change at page 8, line 37 skipping to change at page 8, line 37
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 used in order to retrieve the the later case, various techniques can be used in order to retrieve
computed explicit paths on a per domain basis during the signaling the computed explicit paths on a per domain basis during the
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.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.
skipping to change at page 9, line 32 skipping to change at page 9, line 32
appropriately set the O bit of the RP object. appropriately set the O bit of the RP object.
6. 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 [RFC4655]). compliant with the PCE architecture defined in [RFC4655]).
That said, a straitghforward 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.
7. 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 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-
skipping to change at page 10, line 27 skipping to change at page 10, line 27
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 9. Applicability
As discussed in section Section 3, the requirements for inter-area As discussed in Section 3, the requirements for inter-area and
and inter-AS MPLS Traffic Engineering have been developed by the inter-AS MPLS Traffic Engineering have been developed by the Traffic
Traffic Engineering Working Group (TE WG) and have been stated in Engineering Working Group (TE WG) and have been stated in [RFC4105]
[RFC4105] and [RFC4216], respectively. Among the set of and [RFC4216], respectively. Among the set of requirements, both
requirements, both documents indicate the need for some solution documents indicate the need for some solution providing the ability
providing the ability to compute an optimal (shortest) constrained to compute an optimal (shortest) constrained inter-domain TE LSP and
inter-domain TE LSP and to compute a set of diverse inter-domain TE to compute a set of diverse inter-domain TE LSPs.
LSPs.
9.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
skipping to change at page 11, line 35 skipping to change at page 11, line 34
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 procedures defined in [I-D.ietf-pce-pcep] apply where the path in use
(if available on the head-end) is provided as part of the path (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 11. Path Computation failure
If a PCE requires to relay a path computation request acccording 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 unvailable" set. Computation chain unavailable" set.
0x04: BRPC Path computation chain unavailable 0x04: BRPC Path computation chain unavailable
12. Metric normalization 12. 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
skipping to change at page 13, line 19 skipping to change at page 13, line 13
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 path (the path that would
be obtained in the absence of multiple domains). be obtained in the absence of multiple domains).
13.5. Requirements on Other Protocols and Functional Components 13.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
developped for PCEP. developed for PCEP.
13.6. Impact on Network Operation 13.6. Impact on Network Operation
The BRPC procudure 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 13.7. Path computation chain monitoring
[I-D.vasseur-pce-monitoring] specifies a set of mechanisms that can [I-D.vasseur-pce-monitoring] specifies a set of mechanisms that can
be used to gather PCE state metrics. Because BRPC is a Multiple-PCE be used to gather PCE state metrics. Because BRPC is a Multiple-PCE
path computation techniques, such mechanims 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 14. IANA Considerations
14.1. New flag of the RP object 14.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.
skipping to change at page 14, line 30 skipping to change at page 14, line 27
Name of bit: BRPC Path computation chain unavailable Name of bit: BRPC Path computation chain unavailable
Bit number (suggested value): 0x04 Bit number (suggested value): 0x04
15. Security Considerations 15. 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 condditions 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 16. Acknowledgements
The authors would like to thank Arthi Ayyangar, Dimitri Papadimitriou The authors would like to thank Arthi Ayyangar, Dimitri
and Siva Sivabalan for their useful comments. A special thank to Papadimitriou, Siva Sivabalan and Meral Shirazipour for their useful
Adrian Farrel for his useful comments and suggestions. comments. A special thank to Adrian Farrel for his useful comments
and suggestions.
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.ietf-pce-pcep] [I-D.ietf-pce-pcep]
Roux, J. and J. Vasseur, "Path Computation Element (PCE) Roux, J. and J. Vasseur, "Path Computation Element (PCE)
communication Protocol (PCEP)", draft-ietf-pce-pcep-06 communication Protocol (PCEP)", draft-ietf-pce-pcep-07
(work in progress), February 2007. (work in progress), March 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 17.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 using a key based Inter-Domain Path Computation using a key based
mechanism", draft-bradford-pce-path-key-02 (work in mechanism", draft-bradford-pce-path-key-02 (work in
progress), January 2007. 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., "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-04 (work in draft-ietf-ccamp-inter-domain-pd-path-comp-05 (work in
progress), February 2007. progress), April 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-05 (work in draft-ietf-ccamp-inter-domain-rsvp-te-06 (work in
progress), March 2007. progress), April 2007.
[I-D.ietf-pce-disco-proto-isis] [I-D.ietf-pce-disco-proto-isis]
Roux, J., "IS-IS protocol extensions for Path Computation Roux, J., "IS-IS protocol extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-isis-02 (work in progress), draft-ietf-pce-disco-proto-isis-05 (work in progress),
February 2007. May 2007.
[I-D.ietf-pce-disco-proto-ospf] [I-D.ietf-pce-disco-proto-ospf]
Roux, J., "OSPF protocol extensions for Path Computation Roux, J., "OSPF protocol extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-ospf-02 (work in progress), draft-ietf-pce-disco-proto-ospf-05 (work in progress),
February 2007. May 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-01 (work in draft-ietf-pce-manageability-requirements-01 (work in
progress), March 2007. progress), March 2007.
[I-D.vasseur-pce-monitoring] [I-D.vasseur-pce-monitoring]
Roux, J. and J. Vasseur, "A set of monitoring tools for Vasseur, J., "A set of monitoring tools for Path
Path Computation Element based Architecture", Computation Element based Architecture",
draft-vasseur-pce-monitoring-02 (work in progress), draft-vasseur-pce-monitoring-03 (work in progress),
March 2007. May 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,
 End of changes. 23 change blocks. 
42 lines changed or deleted 42 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/