draft-ietf-pce-pcecp-interarea-reqs-03.txt   draft-ietf-pce-pcecp-interarea-reqs-04.txt 
Network Working Group J.-L. Le Roux (Editor) Network Working Group J.-L. Le Roux (Editor)
Internet Draft France Telecom Internet Draft France Telecom
Category: Informational Category: Informational
October 2006 November 2006
PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area
(G)MPLS Traffic Engineering Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering
draft-ietf-pce-pcecp-interarea-reqs-03.txt draft-ietf-pce-pcecp-interarea-reqs-04.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 other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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.
Abstract Abstract
For scalability purposes a network may comprise multiple IGP areas. For scalability purposes a network may comprise multiple Interior
An inter-area TE-LSP is an LSP that transits through at least two IGP Gateway Protocol (IGP) areas. An inter-area Traffic Engineered-Label
areas. In a multi-area network, topology visibility remains local to Switched Path (TE-LSP) is an LSP that transits through at least two
a given area, and a head-end LSR cannot compute alone an inter-area IGP areas. In a multi-area network, topology visibility remains local
shortest constrained path. One key application of the Path to a given area, and a head-end Label Switching Router (LSR) cannot
Computation Element (PCE) based architecture is the computation of compute an inter-area shortest constrained path. One key application
inter-area TE-LSP paths. This document lists a detailed set of PCE of the Path Computation Element (PCE) based architecture is the
Communication Protocol (PCECP) specific requirements for support of computation of inter-area TE-LSP paths. The PCE Communication
inter-area TE-LSP path computation. It complements generic Protocol (PCECP) is used to communicate computation requests from
requirements for a PCE Communication Protocol. Path Computation Clients (PCC) to PCEs, and to return computed paths
in responses. This document lists a detailed set of PCECP specific
requirements for support of inter-area TE-LSP path computation. It
complements the generic requirements for a PCE Communication
Protocol.
Conventions used in this document Conventions used in this document
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. document are to be interpreted as described in RFC-2119.
Table of Contents Table of Contents
1. Contributors................................................3 1. Terminology.................................................3
2. Terminology.................................................3 2. Introduction................................................3
3. Introduction................................................3 3. Motivations for PCE-based Inter-Area Path Computation.......4
4. Motivations for PCE-based Inter-Area Path Computation.......4 4. Detailed Inter-Area Specific Requirements on PCECP..........5
5. Detailed Inter-Area Specific Requirements on PCECP..........5 4.1. Control and Recording of Area Crossing......................5
5.1. Control and recording of area crossing......................5 4.2. Area Recording..............................................5
5.2. Area Recording..............................................6 4.3. Strict Explicit Path and Loose Path.........................6
5.3. Strict Explicit Path and Loose Path.........................6 4.4. PCE-list Enforcement and Recording in Multiple PCE
5.4. PCE-list Enforcement and Recording in Multiple PCE Computation.................................................6
Computation...............................................6 4.5. Inclusion of Area IDs in Request............................6
5.5. Inclusion of Area IDs in Request............................6 4.6. Area Inclusion/Exclusion....................................7
5.6. Inter-area Diverse Path computation.........................7 4.7. Inter-area Diverse Path computation.........................7
5.7. Inter-area Policies.........................................7 4.8. Inter-area Policies.........................................7
6. Manageability Considerations................................8 5. Manageability Considerations................................8
7. Security Considerations.....................................8 6. Security Considerations.....................................8
8. Acknowledgments.............................................8 7. Acknowledgments.............................................8
9. IANA Considerations.........................................8 8. IANA Considerations.........................................8
10. References..................................................8 9. References..................................................8
10.1. Normative References........................................8 9.1. Normative References........................................8
10.2. Informative References......................................8 9.2. Informative References......................................8
11. Editor Address:.............................................9 10. Editor Address:.............................................9
12. Contributors' Addresses.....................................9 11. Contributors' Addresses.....................................9
13. Intellectual Property Statement............................10 12. Intellectual Property Statement............................10
1. Contributors
The following are the authors that contributed to the present
document:
Jerry Ash (AT&T)
Nabil Bitar (Verizon)
Dean Cheng (Cisco)
Kenji Kumaki (KDDI)
J.L. Le Roux (France Telecom)
Eiji Oki (NTT)
Raymond Zhang (BT Infonet)
Renhai Zhang (Huawei)
2. Terminology 1. Terminology
LSR: Label Switching Router. LSR: Label Switching Router.
LSP: MPLS Label Switched Path. LSP: MPLS Label Switched Path.
TE-LSP: Traffic Engineering Label Switched Path. TE-LSP: Traffic Engineering Label Switched Path.
IGP area: OSPF Area or IS-IS level. IGP area: OSPF Area or IS-IS level.
ABR: IGP Area Border Router, a router that is attached to more ABR: IGP Area Border Router, a router that is attached to more
skipping to change at page 3, line 49 skipping to change at page 3, line 35
or network node) that is capable of computing a network path or or network node) that is capable of computing a network path or
route based on a network graph and applying computational route based on a network graph and applying computational
constraints. constraints.
PCC: Path Computation Client, any application that request path PCC: Path Computation Client, any application that request path
computation to be performed by a PCE. computation to be performed by a PCE.
PCECP: PCE Communication Protocol, a protocol for communication PCECP: PCE Communication Protocol, a protocol for communication
between PCCs and PCEs, and between PCEs. between PCCs and PCEs, and between PCEs.
3. Introduction ERO: RSVP-TE Explicit Route Object. It encodes the explicit path
followed by a TE-LSP.
2. Introduction
[RFC4105] lists a set of motivations and requirements for setting up [RFC4105] lists a set of motivations and requirements for setting up
TE-LSPs across IGP area boundaries. These LSPs are called inter-area TE-LSPs across IGP area boundaries. These LSPs are called inter-area
TE-LSPs. These requirements include the computation of inter- TE-LSPs. These requirements include the computation of inter-
area shortest constrained paths with key guideline being to respect area shortest constrained paths with key guideline being to respect
the IGP hierarchy concept, and particularly the containment of the IGP hierarchy concept, and particularly the containment of
topology information. The main challenge with inter-area MPLS-TE topology information. The main challenge with inter-area MPLS-TE lies
relies actually on path computation. Indeed the head-end LSR cannot in path computation. Indeed the head-end LSR cannot compute an
compute a constrained path across areas, as its topology visibility explicit path across areas, as its topology visibility is limited to
is limited to its own area. its own area.
Inter-area path computation is one of the key applications of the PCE Inter-area path computation is one of the key applications of the PCE
based architecture [RFC4655]. The computation of optimal inter-area based architecture [RFC4655]. The computation of optimal inter-area
paths may be achieved using the services of one or more PCEs. paths may be achieved using the services of one or more PCEs.
Such PCE-based inter-area path computation could rely for instance on Such PCE-based inter-area path computation could rely for instance on
a single multi-area PCE that has the TE database of all the areas in a single multi-area PCE that has the TE database of all the areas in
the IGP domain and can directly compute an end-to-end constrained the IGP domain and can directly compute an end-to-end constrained
shortest path. Alternatively, this could rely on the cooperation shortest path. Alternatively, this could rely on the cooperation
between PCEs whereby each PCE covers one or more IGP areas and the between PCEs whereby each PCE covers one or more IGP areas and the
full set of PCEs covers all areas. full set of PCEs covers all areas.
The generic requirements for a PCE Communication Protocol (PCECP), The generic requirements for a PCE Communication Protocol (PCECP),
which allows a PCC to send path computation requests to a PCE and the which allows a PCC to send path computation requests to a PCE and the
PCE to sent path computation responses to a PCC, are set forth in PCE to send path computation responses to a PCC, are set forth in
[RFC4657]. The use of a PCE-based approach for inter-area path [RFC4657]. The use of a PCE-based approach for inter-area path
computation implies specific requirements on a PCE Communication computation implies specific requirements on a PCE Communication
Protocol, in addition to the generic requirements already listed in Protocol, in addition to the generic requirements already listed in
[RFC4657]. This document complements these generic requirements by [RFC4657]. This document complements these generic requirements by
listing a detailed set of PCECP requirements specific to inter-area listing a detailed set of PCECP requirements specific to inter-area
path computation. path computation.
It is expected that a solution for a PCECP satisfies these It is expected that PCECP procedures be defined to satisfy these
requirements. requirements.
Note that PCE-based inter-area path computation may require a Note that PCE-based inter-area path computation may require a
mechanism for an automatic PCE discovery across areas, which is out mechanism for automatic PCE discovery across areas, which is out of
of the scope of this document. Detailed requirements for such a the scope of this document. Detailed requirements for such a
mechanism are discussed in [RFC4674]. mechanism are discussed in [RFC4674].
4. Motivations for PCE-based Inter-Area Path Computation 3. Motivations for PCE-based Inter-Area Path Computation
IGP hierarchy allows improving IGP scalability, by dividing the IGP IGP hierarchy enables improved IGP scalability, by dividing the IGP
domain into areas and limiting the flooding scope of topology domain into areas and limiting the flooding scope of topology
information to area boundaries. A router in an area has full topology information to within area boundaries. A router in an area has full
information for its own area but only reachability to destinations in topology information for its own area but only information about
other areas._ Thus, a head-end LSR cannot compute an end-to-end reachability to destinations in other areas._ Thus, a head-end LSR
constrained path that traverses more than one IGP area. cannot compute an end-to-end path that crosses the boundary of its
IGP area(s).
A solution for computing inter-area TE-LSP path currently relies on a A current solution for computing inter-area TE-LSP path relies on a
per domain path computation ([PD-COMP]). It is based on loose hop per domain path computation ([PD-COMP]). It is based on loose hop
routing with an ERO expansion on each ABR. This can allow setting up routing with an ERO expansion on each ABR. This allows an LSP to be
a constrained path, but faces two major limitations: set up following a constrained path, but faces two major limitations:
- This does not allow computing an optimal constrained path; - This does guarantee the use of an optimal constrained path;
- This may lead to several crankback signaling messages and - This may lead to several crankback signaling messages and hence
hence delay the LSP setup, and also invoke possible alternate delay the LSP setup, and may also invoke possible alternate routing
routing activities. activities.
Note that, here, by optimal constrained path we mean the shortest Note that, here, by optimal constrained path we mean the shortest
constrained path across multiple areas, taking into account either constrained path across multiple areas, taking into account either
the IGP or TE metric [METRIC]. In other words, such a path is the the IGP or TE metric [METRIC]. In other words, such a path is the
path that would have been computed by making use of some CSPF path that would have been computed by making use of some CSPF
algorithm in the absence of multiple IGP areas. algorithm in the absence of multiple IGP areas.
The PCE based architecture [RFC4655] is well suited to inter-area The PCE based architecture [RFC4655] is well suited to inter-area
path computation, as it allows overcoming the path computation path computation, as it allows the path computation limitations
limitations resulting from the limited topology visibility, by resulting from the limited topology visibility to be overcome by
introducing path computation entities with more topology visibility, introducing path computation entities with more topology visibility,
or by allowing cooperation between path computation entities in each or by allowing cooperation between path computation entities in each
area. area.
There are two main approaches for the computation of an inter-area There are two main approaches for the computation of an inter-area
optimal path: optimal path:
- Single PCE computation: The path is computed by a single PCE that - Single PCE computation: The path is computed by a single PCE that
has topology visibility in all areas and can alone compute an end- has topology visibility in all areas and can compute an end-
to-end optimal constrained path. to-end optimal constrained path on its own.
- Multiple PCE computation with inter-PCE communication: the path - Multiple PCE computation with inter-PCE communication: The path
computation is distributed on multiple PCEs, which have partial computation is distributed on multiple PCEs, which have partial
topology visibility. They compute path segments in their areas of topology visibility. They compute path segments in their domains of
visibility and collaborate with each other so as to arrive at an visibility and collaborate with each other so as to arrive at an
end-to-end optimal constrained path. Such collaboration is ensured end-to-end optimal constrained path. Such collaboration is ensured
thanks to inter-PCE communication. thanks to inter-PCE communication.
Note that the use of a PCE-based approach, to perform inter-area path Note that the use of a PCE-based approach, to perform inter-area path
computation implies specific functional requirements in a PCECP, in computation implies specific functional requirements in a PCECP, in
addition to the generic requirements listed in [RFC4657]. These addition to the generic requirements listed in [RFC4657]. These
specific requirements are discussed in next section. specific requirements are discussed in next section.
5. Detailed Inter-Area Specific Requirements on PCECP 4. Detailed Inter-Area Specific Requirements on PCECP
This section lists a set of additional requirements for the PCECP This section lists a set of additional requirements for the PCECP
that complement requirements listed in [RFC4657] and are specific to that complement requirements listed in [RFC4657] and are specific to
inter-area (G)MPLS TE path computation. inter-area (G)MPLS TE path computation.
5.1. Control and recording of area crossing 4.1. Control and Recording of Area Crossing
In addition to the path constraints specified in [RFC4657], the In addition to the path constraints specified in [RFC4657], the
request message MUST allow indicating whether area crossing is request message MUST allow indicating whether area crossing is
allowed or not. allowed or not. Indeed, when the source and destination reside in the
Indeed, when the source and destination reside in the same IGP area, same IGP area, there may be intra-area and inter-area feasible paths.
there may be intra-area and inter-area feasible paths. As set forth As set forth in [RFC4105], if the shortest path is an inter-area
in [RFC4105], if the shortest path is an inter-area path, an operator path, an operator either may want to avoid, as far as possible,
either may want to avoid, as far as possible, crossing areas and thus crossing areas and thus may prefer selecting a sub-optimal intra-area
may prefer selecting a sub-optimal intra-area path or, conversely, path or, conversely, may prefer to use a shortest path, even if it
may prefer to use a shortest path, even if it crosses areas. crosses areas.
Also, when the source and destinations reside in the same area it may Also, when the source and destination reside in the same area it may
be useful to know whether the returned path is an inter-area path. be useful to know whether the returned path is an inter-area path.
Hence the response message MUST allow indicating whether the computed Hence the response message MUST allow indicating whether the computed
path is crossing areas. path is crossing areas.
5.2. Area Recording 4.2. Area Recording
It may be useful for the PCC to know the set of areas crossed by an It may be useful for the PCC to know the set of areas crossed by an
inter-area path and the corresponding path segments. Hence the inter-area path and the corresponding path segments. Hence the
response message MUST support the inclusion of the identifiers of the response message MUST allow identifying the crossed areas. Also the
crossed areas and MUST allow identifying the corresponding path response message MUST allow segmenting the returned path and marking
segments. each segment so that it is possible to tell which piece of the path
lie within which area.
5.3. Strict Explicit Path and Loose Path 4.3. Strict Explicit Path and Loose Path
A Strict Explicit Path is defined as a set of strict hops, while a A Strict Explicit Path is defined as a set of strict hops, while a
Loose Path is defined as a set of at least one loose hop and zero, Loose Path is defined as a set of at least one loose hop and zero,
one ore more strict hops. An inter-area path may be strictly explicit one or more strict hops. An inter-area path may be strictly explicit
or loose (e.g. a list of ABRs as loose hops). It may be useful to or loose (e.g. a list of ABRs as loose hops). It may be useful to
indicate to the PCE if a Strict Explicit path is required or not. indicate to the PCE if a Strict Explicit path is required or not.
Hence the PCECP request message MUST allow indicating whether a Hence the PCECP request message MUST allow indicating whether a
Strict Explicit Path is required/desired. Strict Explicit Path is required/desired.
5.4. PCE-list Enforcement and Recording in Multiple PCE Computation 4.4. PCE-list Enforcement and Recording in Multiple PCE Computation
In case of multiple-PCE inter-area path computation, a PCC may want In case of multiple-PCE inter-area path computation, a PCC may want
to indicate a preferred list of PCEs to be used. Hence the PCECP to indicate a preferred list of PCEs to be used, one per area.
request message MUST support the inclusion of a list of preferred In each area the preferred PCE should be tried before another PCE be
PCEs. Note that this requires that a PCC in one area have knowledge selected. Note that if there is no preferred PCE indicated for an
of PCEs in other areas. This could rely on configuration or on a PCE area, any PCE in that area may be used.
discovery mechanism, allowing discovery across area boundaries (see
[RFC4674]). Hence the PCECP request message MUST support the inclusion of a list
of preferred PCEs per area. Note that this requires that a PCC in one
area have knowledge of PCEs in other areas. This could rely on
configuration or on a PCE discovery mechanism, allowing discovery
across area boundaries (see [RFC4674]).
Also it would be useful to know the list of PCEs which effectively Also it would be useful to know the list of PCEs which effectively
participated in the computation. Hence the request message MUST participated in the computation. Hence the request message MUST
support a request for PCE recording and the response message MUST support a request for PCE recording and the response message MUST
support the recording of the set of one or more PCEs that took part support the recording of the set of one or more PCEs that took part
in the computation. in the computation.
It may also be useful to know the path segments computed by each PCE. It may also be useful to know the path segments computed by each PCE.
Hence the request message SHOULD allow a request for the Hence the request message SHOULD allow a request for the
identification of path segments computed by a PCE, and the response identification of path segments computed by a PCE, and the response
message SHOULD allow identifying the path segments computed by each message SHOULD allow identifying the path segments computed by each
PCE. PCE.
5.5. Inclusion of Area IDs in Request 4.5. Inclusion of Area IDs in Request
The knowledge of the areas in which the source and destination lie The knowledge of the areas in which the source and destination lie
would allow selection of appropriate cooperating PCEs. A PCE may not would allow selection of appropriate cooperating PCEs. A PCE may not
be able to determine the location of the source and destination and be able to determine the location of the source and destination and
in such a case it would be useful that a PCC indicates the source and in such a case it would be useful that a PCC indicates the source and
destination area IDs. destination area IDs.
For that purpose the request message MUST support the inclusion of For that purpose the request message MUST support the inclusion of
the source and destination area IDs. Note that this information could the source and destination area IDs. Note that this information could
be learned by the PCC through configuration. be learned by the PCC through configuration.
5.6. Inter-area Diverse Path computation 4.6. Area Inclusion/Exclusion
In some situations it may be useful to include one or more area(s) in
the path. It may also be useful to exclude one or more area(s) from
the path (e.g. request for a path between LSRs in two stub areas
connected to the same ABR(s), which must not cross the backbone
area). Hence the request message MUST allow indicating a set of one
or more area(s) that must be explicitly included in the path, and a
set of one or more area(s) that must be explicitly excluded from the
path.
4.7. Inter-area Diverse Path computation
For various reasons, including protection and load balancing, the For various reasons, including protection and load balancing, the
computation of diverse inter-area paths may be required. computation of diverse inter-area paths may be required.
There are various levels of diversity in an inter-area context: There are various levels of diversity in an inter-area context:
-Per-area diversity (intra-area path segments are link, node or -Per-area diversity (intra-area path segments are link, node or
SRLG disjoint) SRLG disjoint)
-Inter-area diversity (end-to-end inter-area paths are link, -Inter-area diversity (end-to-end inter-area paths are link,
node or SRLG disjoint) node or SRLG disjoint)
Note that two paths may be disjoint in the backbone area but non- Note that two paths may be disjoint in the backbone area but non-
skipping to change at page 7, line 34 skipping to change at page 7, line 45
as the level of inter-area diversity (shared ABRs or ABR as the level of inter-area diversity (shared ABRs or ABR
disjointness). disjointness).
The response message MUST allow indicating the level of diversity of The response message MUST allow indicating the level of diversity of
a set of computed loose paths. a set of computed loose paths.
Note that specific objective functions may be requested for diverse Note that specific objective functions may be requested for diverse
path computation, such as minimizing the cumulated cost of a set of path computation, such as minimizing the cumulated cost of a set of
diverse paths as set forth in [RFC4657]. diverse paths as set forth in [RFC4657].
5.7. Inter-area Policies 4.8. Inter-area Policies
In addition to the policy requirements discussed in [RFC4657], the In addition to the policy requirements discussed in [RFC4657], the
application of inter-area path computation policies requires some application of inter-area path computation policies requires some
additional information to be carried in the PCECP request messages: additional information to be carried in the PCECP request messages.
The request message MUST allow for the inclusion of the address of
- The request message MUST allow for the inclusion of the address of
the originating PCC. This may be useful in a multiple PCE the originating PCC. This may be useful in a multiple PCE
computation, so as to apply policies not only based on the PCECP computation, so as to apply policies not only based on the PCECP peer
peer but also based on the originating PCC; but also based on the originating PCC.
- The request message MUST allow indicating whether area/AS crossing
is allowed or not.
Note that work on supported policy models and the corresponding Note that work on supported policy models and the corresponding
requirements/implications is being undertaken as a separate work item requirements/implications is being undertaken as a separate work item
in the PCE working group ([PCE-POL-FMWK]). in the PCE working group ([PCE-POL-FMWK]).
6. Manageability Considerations 5. Manageability Considerations
The inter-area application does not imply new manageability The inter-area application implies some new manageability
requirements beyond those already defined in [RFC4657]. requirements in addition to those already listed in [RFC4657]. The
PCECP PCC and PCE MIB modules MUST allow recording the proportion of
inter-area requests and the success rate of inter-area requests. The
PCEP PCC MIB module MUST also allow recording the performances of a
PCE chain (minimum, maximum and average response time), in case of
multiple-PCE inter-area path computation.
7. Security Considerations A built in diagnostic tool MUST be defined to monitor the
performances of a PCE chain, in case of multiple-PCE inter-area path
computation. It MUST allow determining the minimum maximum and
average response time globally for the chain, and on a per PCE basis.
6. Security Considerations
IGP areas are administrated by the same entity. Hence the inter-area IGP areas are administrated by the same entity. Hence the inter-area
application does not imply a new trust model, or new security issues application does not imply a new trust model, or new security issues
beyond those already defined in [RFC4657]. beyond those already defined in [RFC4657].
8. Acknowledgments 7. Acknowledgments
We would also like to thank Adrian Farrel, Jean-Philippe Vasseur, We would also like to thank Adrian Farrel, Jean-Philippe Vasseur,
Bruno Decraene, Yannick Le Louedec, Dimitri Papadimitriou and Lou Bruno Decraene, Yannick Le Louedec, Dimitri Papadimitriou and Lou
Berger for their useful comments and suggestions. Berger for their useful comments and suggestions.
9. IANA Considerations 8. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
10. References 9. References
10.1. Normative References 9.1. Normative References
[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.
[RFC4105] Le Roux J.L., Vasseur J.P., Boyle, J., et al. "Requirements [RFC4105] Le Roux J.L., Vasseur J.P., Boyle, J., et al. "Requirements
for inter-area MPLS-TE" RFC 4105, June 2005. for inter-area MPLS-TE" RFC 4105, June 2005.
[RFC4655] A. Farrel, JP. Vasseur and J. Ash, “Path Computation [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "Path Computation
Element (PCE) Based Architecture”, RFC4655, August 2006. Element (PCE) Based Architecture", RFC4655, August 2006.
[RFC4657] J. Ash, J.L Le Roux et. al., “PCE Communication Protocol
Generic Requirements”, RFC4657, September 2006.
10.2. Informative References [RFC4657] J. Ash, J.L Le Roux et. al., "PCE Communication Protocol
Generic Requirements", RFC4657, September 2006.
[RFC4674] J.L. Le Roux et. al., “Requirements for Path Computation 9.2. Informative References
Element (PCE) Discovery”, RFC4674, October 2006. [RFC4674] J.L. Le Roux et. al., "Requirements for Path Computation
Element (PCE) Discovery", RFC4674, October 2006.
[PD-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., "A Per-domain path [PD-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., "A Per-domain path
computation method for computing Inter-domain Traffic Engineering computation method for computing Inter-domain Traffic Engineering
(TE) Label Switched Path (LSP)", work in progress. (TE) Label Switched Path (LSP)", work in progress.
[ID-RSVP] Ayyangar, A., Vasseur, J.P., "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions", work in progress.
[PCE-POL-FMWK] I. Bryskin, D. Papadimitriou, L. Berger " Policy- [PCE-POL-FMWK] I. Bryskin, D. Papadimitriou, L. Berger " Policy-
Enabled Path Computation Framework", draft-ietf-pce-policy-enabled- Enabled Path Computation Framework", draft-ietf-pce-policy-enabled-
path-comp, work in progress. path-comp, work in progress.
11. Editor Address [METRIC] Le Faucheur et al., "Use of Interior Gateway Protocol (IGP)
Metric as a second MPLS Traffic Engineering (TE) Metric", RFC3785,
May 2004.
10. Editor Address
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ft.com Email: jeanlouis.leroux@orange-ftgroup.com
12. Contributors' Addresses 11. Contributors' Addresses
Jerry Ash Jerry Ash
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578 Phone: +1-(732)-420-4578
Email: gash@att.com Email: gash@att.com
Nabil Bitar Nabil Bitar
skipping to change at page 9, line 52 skipping to change at page 10, line 14
Phone: +81-3-6678-3103 Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
Eiji Oki Eiji Oki
NTT NTT
Midori-cho 3-9-11 Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN Musashino-shi, Tokyo 180-8585, JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Raymond Zhang Raymond Zhang
BT INFONET Services Corporation BT
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90245 USA El Segundo, CA 90245
Email: raymond_zhang@bt.infonet.com USA
raymond.zhang@bt.com
Renhai Zhang Renhai Zhang
Huawei Technologies Huawei Technologies
No. 3 Xinxi Road, Shangdi, No. 3 Xinxi Road, Shangdi,
Haidian District, Haidian District,
Beijing City, Beijing City,
P. R. China P. R. China
Email: zhangrenhai@huawei.com Email: zhangrenhai@huawei.com
13. Intellectual Property Statement 12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 10, line 38 skipping to change at page 10, line 54
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2006). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
 End of changes. 55 change blocks. 
146 lines changed or deleted 168 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/