draft-ietf-pce-pcecp-interarea-reqs-04.txt   draft-ietf-pce-pcecp-interarea-reqs-05.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
November 2006 December 2006
PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area
Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Traffic Engineering
draft-ietf-pce-pcecp-interarea-reqs-04.txt draft-ietf-pce-pcecp-interarea-reqs-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 other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 38 skipping to change at page 2, line 38
Table of Contents Table of Contents
1. Terminology.................................................3 1. Terminology.................................................3
2. Introduction................................................3 2. Introduction................................................3
3. Motivations for PCE-based Inter-Area Path Computation.......4 3. Motivations for PCE-based Inter-Area Path Computation.......4
4. Detailed Inter-Area Specific Requirements on PCECP..........5 4. Detailed Inter-Area Specific Requirements on PCECP..........5
4.1. Control and Recording of Area Crossing......................5 4.1. Control and Recording of Area Crossing......................5
4.2. Area Recording..............................................5 4.2. Area Recording..............................................5
4.3. Strict Explicit Path and Loose Path.........................6 4.3. Strict Explicit Path and Loose Path.........................6
4.4. PCE-list Enforcement and Recording in Multiple PCE 4.4. PCE-list Enforcement and Recording in Multiple PCE
Computation.................................................6 Computation...............................................6
4.5. Inclusion of Area IDs in Request............................6 4.5. Inclusion of Area IDs in Request............................6
4.6. Area Inclusion/Exclusion....................................7 4.6. Area Inclusion/Exclusion....................................7
4.7. Inter-area Diverse Path computation.........................7 4.7. Inter-area Diverse Path computation.........................7
4.8. Inter-area Policies.........................................7 4.8. Inter-area Policies.........................................8
4.9. Loop Avoidance..............................................8
5. Manageability Considerations................................8 5. Manageability Considerations................................8
6. Security Considerations.....................................8 6. Security Considerations.....................................8
7. Acknowledgments.............................................8 7. Acknowledgments.............................................9
8. IANA Considerations.........................................8 8. IANA Considerations.........................................9
9. References..................................................8 9. References..................................................9
9.1. Normative References........................................8 9.1. Normative References........................................9
9.2. Informative References......................................8 9.2. Informative References......................................9
10. Editor Address:.............................................9 10. Editor Address:.............................................9
11. Contributors' Addresses.....................................9 11. Contributors' Addresses....................................10
12. Intellectual Property Statement............................10 12. Intellectual Property Statement............................11
1. 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.
skipping to change at page 6, line 44 skipping to change at page 6, line 46
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.
4.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 a PCE to select an appropriate downstream PCE. This would
be able to determine the location of the source and destination and be useful when the area ID(s) of a PCE (i.e. the area(s) where it has
in such a case it would be useful that a PCC indicates the source and visibility) is/are known, which can be achieved by the PCE Discovery
destination area IDs. Protocol (see [RFC4674]) or any other mean.
A PCE may not have any visibility of the source/destination area and
hence may not be able to determine the area of the
source/destination. In such a situation it would be useful that a PCC
indicates the source and destination area IDs in its request message.
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.
4.6. Area Inclusion/Exclusion 4.6. Area Inclusion/Exclusion
In some situations it may be useful to include one or more area(s) in In some situations, it may be useful that the request message
the path. It may also be useful to exclude one or more area(s) from indicate one or more area(s) that must be followed by the path to be
the path (e.g. request for a path between LSRs in two stub areas computed. It may also be useful that the request message indicate one
connected to the same ABR(s), which must not cross the backbone or more area(s) that must be avoided by the path to be computed (e.g.
area). Hence the request message MUST allow indicating a set of one request for a path between LSRs in two stub areas connected to the
or more area(s) that must be explicitly included in the path, and a same ABR(s), which must not cross the backbone area). Hence the
set of one or more area(s) that must be explicitly excluded from the request message MUST allow indicating a set of one or more area(s)
path. 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 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-
disjoint in peripheral areas. Also two paths may be node disjoint disjoint in peripheral areas. Also two paths may be node disjoint
within areas but may share ABRs, in which case path segments within within areas but may share ABRs, in which case path segments within
an area are node disjoint but end-to-end paths are not node-disjoint. an area are node disjoint but end-to-end paths are not node-disjoint.
The request message MUST allow requesting the computation of a set of The request message MUST allow requesting the computation of a set of
inter-area diverse paths between the same node pair or between inter-area diverse paths between the same node pair or between
distinct node pairs. It MUST allow indicating the required level of distinct node pairs. It MUST allow indicating the required level of
intra-area diversity (link, node, SRLG) on a per area basis, as well diversity of a set of inter-area paths (link, node, SRLG diversity),
as the level of inter-area diversity (shared ABRs or ABR as well as the required level of diversity of a set of intra-area
disjointness). segments of inter-area paths (link, node, SRLG diversity) on a per-
area basis.
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 inter-area loose paths (link, node, SRLG
diversity), globally, and on a per-area basis (link, node, SRLG
diversity of intra-area path segments).
Note that, in order to ensure SRLG consistency, SRLG identifiers
within the IGP domain should be assigned and allocated by the same
entity.
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].
4.8. 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 peer computation, so as to apply policies not only based on the PCECP peer
but also based on the originating PCC. but also based on the originating PCC.
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]).
4.9. Loop Avoidance
In case of multiple-PCE inter-area path computation, there may be
risks of PCECP request loops. A mechanism MUST be defined to detect
and correct PCECP request message loops. This may rely, for instance,
on the recording, in the request message, of the set of traversed
PCEs.
Also the returned path in a response message MUST be loop free.
5. Manageability Considerations 5. Manageability Considerations
The inter-area application implies some new manageability The inter-area application implies some new manageability
requirements in addition to those already listed in [RFC4657]. The requirements in addition to those already listed in [RFC4657]. The
PCECP PCC and PCE MIB modules MUST allow recording the proportion of PCECP PCC and PCE MIB modules MUST allow recording the proportion of
inter-area requests and the success rate of inter-area requests. The inter-area requests and the success rate of inter-area requests. The
PCEP PCC MIB module MUST also allow recording the performances of a PCEP PCC MIB module MUST also allow recording the performances of a
PCE chain (minimum, maximum and average response time), in case of PCE chain (minimum, maximum and average response time), in case of
multiple-PCE inter-area path computation. multiple-PCE inter-area path computation.
skipping to change at page 9, line 19 skipping to change at page 9, line 48
(TE) Label Switched Path (LSP)", work in progress. (TE) Label Switched Path (LSP)", 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.
[METRIC] Le Faucheur et al., "Use of Interior Gateway Protocol (IGP) [METRIC] Le Faucheur et al., "Use of Interior Gateway Protocol (IGP)
Metric as a second MPLS Traffic Engineering (TE) Metric", RFC3785, Metric as a second MPLS Traffic Engineering (TE) Metric", RFC3785,
May 2004. May 2004.
10. Editor Address 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-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
11. Contributors' Addresses 11. Contributors' Addresses
 End of changes. 12 change blocks. 
28 lines changed or deleted 52 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/