draft-ietf-pce-inter-layer-req-10.txt   draft-ietf-pce-inter-layer-req-11.txt 
Network Working Group T. Takeda (Ed.)
Internet Draft NTT Network Working Group T. Takeda (Ed.)
Category: Informational A. Farrel Internet Draft NTT
Created: August 21, 2009 Old Dog Consulting Category: Informational A. Farrel
Expires: February 21, 2010 Created: February 26, 2010 Old Dog Consulting
Expires: August 26, 2010
PCC-PCE Communication and PCE Discovery Requirements for PCC-PCE Communication and PCE Discovery Requirements for
Inter-Layer Traffic Engineering Inter-Layer Traffic Engineering
draft-ietf-pce-inter-layer-req-10.txt draft-ietf-pce-inter-layer-req-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 11 skipping to change at page 2, line 14
This document complements the generic requirements and presents This document complements the generic requirements and presents
detailed sets of PCC-PCE communication protocol requirements and PCE detailed sets of PCC-PCE communication protocol requirements and PCE
discovery protocol requirements for inter-layer traffic engineering. discovery protocol requirements for inter-layer traffic engineering.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology..................................................3 1.1. Terminology..................................................3
2. Motivation for PCE-Based Inter-Layer Path Computation..........4 2. Motivation for PCE-Based Inter-Layer Path Computation..........4
3. PCC-PCE Communication and Discovery Requirements for 3. PCC-PCE Communication and Discovery Requirements for Inter-Layer
Inter-Layer Traffic Engineering................................5 Traffic Engineering...............................................5
3.1. PCC-PCE Communication........................................5 3.1. PCC-PCE Communication........................................5
3.1.1. Control of Inter-Layer Path Computation....................5 3.1.1. Control of Inter-Layer Path Computation....................5
3.1.2. Control of The Type of Path to be Computed.................5 3.1.2. Control of The Type of Path to be Computed.................5
3.1.3. Communication of Inter-Layer Constraints...................7 3.1.3. Communication of Inter-Layer Constraints...................6
3.1.4. Adaptation Capability......................................7 3.1.4. Adaptation Capability......................................7
3.1.5. Cooperation Between PCEs...................................7 3.1.5. Cooperation Between PCEs...................................7
3.1.6. Inter-Layer Diverse paths..................................7 3.1.6. Inter-Layer Diverse paths..................................7
3.2. Capabilities Advertisements for PCE Discovery................8 3.2. Capabilities Advertisements for PCE Discovery................7
3.3. Supported Network Models.....................................8 3.3. Supported Network Models.....................................8
4. Manageability considerations...................................8 4. Manageability considerations...................................8
4.1. Control of Function and Policy...............................8 4.1. Control of Function and Policy...............................8
4.2. Information and Data Models..................................9 4.2. Information and Data Models..................................8
4.3. Liveness Detection and Monitoring............................9 4.3. Liveness Detection and Monitoring............................9
4.4. Verifying Correct Operation..................................9 4.4. Verifying Correct Operation..................................9
4.5. Requirements on Other Protocols and Functional Components....9 4.5. Requirements on Other Protocols and Functional Components....9
4.6. Impact on Network Operation.................................10 4.6. Impact on Network Operation.................................10
5. Security Considerations.......................................10 5. Security Considerations.......................................10
6. IANA Considerations...........................................10 6. IANA Considerations...........................................10
7. Acknowledgments...............................................10 7. Acknowledgments...............................................10
8. References....................................................11 8. References....................................................10
8.1. Normative References........................................11 8.1. Normative References........................................10
8.2. Informative References......................................11 8.2. Informative References......................................11
9. Authors' Addresses............................................12 9. Authors' Addresses............................................12
1. Introduction 1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. network graph, and applying computational constraints.
A network may comprise multiple layers. These layers may represent A network may comprise multiple layers. These layers may represent
skipping to change at page 3, line 39 skipping to change at page 3, line 39
This is what we call Inter-layer traffic engineering. This includes This is what we call Inter-layer traffic engineering. This includes
mechanisms allowing computation of end-to-end paths across layers mechanisms allowing computation of end-to-end paths across layers
(known as inter-layer path computation), and mechanisms for control (known as inter-layer path computation), and mechanisms for control
and management of the VNT by setting up and releasing LSPs in the and management of the VNT by setting up and releasing LSPs in the
lower layers [RFC5212]. lower layers [RFC5212].
Inter-layer traffic engineering is included in the scope of the PCE Inter-layer traffic engineering is included in the scope of the PCE
architecture [RFC4655], and PCE can provide a suitable mechanism for architecture [RFC4655], and PCE can provide a suitable mechanism for
resolving inter-layer path computation issues. The applicability of resolving inter-layer path computation issues. The applicability of
the PCE-based path computation architecture to inter-layer traffic the PCE-based path computation architecture to inter-layer traffic
engineering is described in [PCE-INTER-LAYER-FRWK]. engineering is described in [RFC5623].
This document presents sets of requirements for communication between This document presents sets of requirements for communication between
path computation clients (PCCs) and PCEs using the PCE protocol path computation clients (PCCs) and PCEs using the PCE protocol
(PCEP), and for PCE discovery for inter-layer traffic engineering. It (PCEP), and for PCE discovery for inter-layer traffic engineering. It
supplements the generic requirements documented in [RFC4657] and supplements the generic requirements documented in [RFC4657] and
[RFC4674]. [RFC4674].
1.1. Terminology 1.1. Terminology
LSP: Label Switched Path. LSP: Label Switched Path.
skipping to change at page 5, line 11 skipping to change at page 5, line 10
between border LSRs, which are located on the boundary between the between border LSRs, which are located on the boundary between the
higher-layer and lower-layer networks, and that the ingress LSR does higher-layer and lower-layer networks, and that the ingress LSR does
not have topology visibility in the lower layer. If a single-layer not have topology visibility in the lower layer. If a single-layer
path computation is applied for the higher layer, the path path computation is applied for the higher layer, the path
computation fails. On the other hand, inter-layer path computation is computation fails. On the other hand, inter-layer path computation is
able to provide a route in the higher layer and a suggestion that a able to provide a route in the higher layer and a suggestion that a
lower-layer LSP be setup between border LSRs, considering both layers lower-layer LSP be setup between border LSRs, considering both layers
as TE topologies. as TE topologies.
Further discussion of the application of PCE to inter-layer path Further discussion of the application of PCE to inter-layer path
computation can be found in [PCE-INTER-LAYER-FRWK]. computation can be found in [RFC5623].
3. PCC-PCE Communication and Discovery Requirements for Inter-Layer 3. PCC-PCE Communication and Discovery Requirements for Inter-Layer
Traffic Engineering Traffic Engineering
This section sets out additional requirements specific to the This section sets out additional requirements specific to the
problems of multi-layer TE that are not covered in [RFC4657] or problems of multi-layer TE that are not covered in [RFC4657] or
[RFC4674]. [RFC4674].
3.1. PCC-PCE Communication 3.1. PCC-PCE Communication
skipping to change at page 5, line 41 skipping to change at page 5, line 40
A request from a PCC to a PCE MUST support the inclusion of an A request from a PCC to a PCE MUST support the inclusion of an
optional indication of whether inter-layer path computation is optional indication of whether inter-layer path computation is
allowed. In the absence of such an indication, the default is that allowed. In the absence of such an indication, the default is that
inter-layer path computation is not allowed. inter-layer path computation is not allowed.
3.1.2. Control of The Type of Path to be Computed 3.1.2. Control of The Type of Path to be Computed
The PCE computes and returns a path to the PCC that the PCC can use The PCE computes and returns a path to the PCC that the PCC can use
to build a higher-layer or lower-layer LSP once converted to an to build a higher-layer or lower-layer LSP once converted to an
Explicit Route Object (ERO) for use in RSVP-TE signaling. There are Explicit Route Object (ERO) for use in RSVP-TE signaling. There are
two options [PCE-INTER-LAYER-FRWK]. two options [RFC5623].
- Option 1: Mono-layer path. The PCE computes a "mono layer" path, - Option 1: Mono-layer path. The PCE computes a "mono layer" path,
i.e., a path that includes only TE-links from the same layer. i.e., a path that includes only TE-links from the same layer.
- Option 2: Multi-layer path. The PCE computes a "multi-layer" path, - Option 2: Multi-layer path. The PCE computes a "multi-layer" path,
i.e., a path that includes TE links from distinct layers [RFC4206]. i.e., a path that includes TE links from distinct layers [RFC4206].
It may be necessary or desirable for a PCC to control the type of It may be necessary or desirable for a PCC to control the type of
path that is produced by a PCE. For example, a PCC may know that it path that is produced by a PCE. For example, a PCC may know that it
is not possible for technological or policy reasons to signal a is not possible for technological or policy reasons to signal a
skipping to change at page 8, line 8 skipping to change at page 7, line 52
3.1.6. Inter-Layer Diverse paths 3.1.6. Inter-Layer Diverse paths
The PCE communication protocol MUST allow for the computation of The PCE communication protocol MUST allow for the computation of
diverse inter-Layer paths. A request from a PCC to a PCE MUST support diverse inter-Layer paths. A request from a PCC to a PCE MUST support
the inclusion of multiple path requests, with the desired level of the inclusion of multiple path requests, with the desired level of
diversity at each layer (link, node, SRLG). diversity at each layer (link, node, SRLG).
3.2. Capabilities Advertisements for PCE Discovery 3.2. Capabilities Advertisements for PCE Discovery
In the case where there are several PCEs with distinct capabilities In the case where there are several PCEs with distinct capabilities
available, a PCC has to select one or more appropriate PCEs. available, a PCC has to select one or more appropriate PCEs. For that
purpose, the PCE discovery mechanism MAY support the disclosure of
For that purpose, the PCE discovery mechanism MAY support the some detailed PCE capabilities. A PCE MAY (to be consistent with the
disclosure of some detailed PCE capabilities. A PCE MAY (to be above text and RFC4674) be able to advise the following inter-layer-
consistent with the above text and RFC4674) be able to advise the path-computation-related PCE capabilities:
following inter-layer-path-computation-related PCE capabilities:
- Support for inter-layer path computation - Support for inter-layer path computation
- Support for mono-layer/multi-layer paths - Support for mono-layer/multi-layer paths
- Support for inter-layer constraints - Support for inter-layer constraints
- Support for adaptation capability - Support for adaptation capability
- Support for inter-PCE communication - Support for inter-PCE communication
- Support for inter-layer diverse path computation - Support for inter-layer diverse path computation
3.3. Supported Network Models 3.3. Supported Network Models
skipping to change at page 9, line 35 skipping to change at page 9, line 28
the behavior of an individual PCECP request to the originating PCC. the behavior of an individual PCECP request to the originating PCC.
In particular, where a request is forwarded between multiple PCEs In particular, where a request is forwarded between multiple PCEs
neither the PCC nor the first PCE can monitor the liveness of all neither the PCC nor the first PCE can monitor the liveness of all
inter-PCE-PCE connections or of the PCEs themselves. In this case, inter-PCE-PCE connections or of the PCEs themselves. In this case,
suitable performance of the original PCEP request relies on each PCE suitable performance of the original PCEP request relies on each PCE
operating correct monitoring procedures and correlating any failures operating correct monitoring procedures and correlating any failures
back to the PCEP requests that are outstanding. These requirements back to the PCEP requests that are outstanding. These requirements
are no different from those for any cooperative PCE usage, and are are no different from those for any cooperative PCE usage, and are
expected to be already covered by general, and by inter-AS and inter- expected to be already covered by general, and by inter-AS and inter-
area implementations. Such a procedure is specified in [RFC5441]. area implementations. Such a procedure is specified in [RFC5441]. In
In addition, [PCEP-MON] specifies mechanisms to gather various state addition, [PCEP-MON] specifies mechanisms to gather various state
metrics along the path computation chain. metrics along the path computation chain.
4.4. Verifying Correct Operation 4.4. Verifying Correct Operation
There are no additional requirements beyond those expressed in There are no additional requirements beyond those expressed in
[RFC4657] for verifying the correct operation of the PCEP. Note that [RFC4657] for verifying the correct operation of the PCEP. Note that
verification of the correct operation of the PCE and its algorithms verification of the correct operation of the PCE and its algorithms
is out of scope for the protocol requirements, but a PCC MAY send the is out of scope for the protocol requirements, but a PCC MAY send the
same request to more than one PCE and compare the results. same request to more than one PCE and compare the results.
skipping to change at page 10, line 36 skipping to change at page 10, line 30
5. Security Considerations 5. Security Considerations
Inter-layer traffic engineering with PCE may raise new security Inter-layer traffic engineering with PCE may raise new security
issues when PCE-PCE communication is done between different layer issues when PCE-PCE communication is done between different layer
networks for inter-layer path computation. Security issues may also networks for inter-layer path computation. Security issues may also
exist when a single PCE is granted full visibility of TE information exist when a single PCE is granted full visibility of TE information
that applies to multiple layers. that applies to multiple layers.
The formal introduction of a VNT Manager component as described in The formal introduction of a VNT Manager component as described in
[PCE-INTER-LAYER-FRWK] provides the basis for the application of [RFC5623] provides the basis for the application of inter-layer
inter-layer security and policy. security and policy.
It is expected that solutions for inter-layer protocol extensions It is expected that solutions for inter-layer protocol extensions
will address these issues in detail. will address these issues in detail.
6. IANA Considerations 6. IANA Considerations
This Informational document makes no requests for IANA action. This Informational document makes no requests for IANA action.
7. Acknowledgments 7. Acknowledgments
skipping to change at page 11, line 43 skipping to change at page 11, line 36
RFC 5145, March 2008. RFC 5145, March 2008.
[RFC5146] K. Kumaki et al., "Interworking Requirements to Support [RFC5146] K. Kumaki et al., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146, March Operation of MPLS-TE over GMPLS Networks", RFC 5146, March
2008. 2008.
[RFC5212] K. Shiomoto et al., "Requirements for GMPLS-Based Multi- [RFC5212] K. Shiomoto et al., "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July
2008. 2008.
[PCE-INTER-LAYER-FRWK] E. Oki et al., "Framework for PCE-Based [RFC5623] E. Oki et al., "Framework for PCE-Based Inter-Layer MPLS
Inter-Layer MPLS and GMPLS Traffic Engineering", draft- and GMPLS Traffic Engineering", RFC 5623, September 2009.
ietf-pce-inter-layer-frwk (work in progress).
[PCEP-MIB] A. Koushik, and E. Stephan, "PCE communication protocol [PCEP-MIB] A. Koushik, and E. Stephan, "PCE communication protocol
(PCEP) Management Information Base", draft-ietf-pce-pcep- (PCEP) Management Information Base", draft-ietf-pce-pcep-
mib (work in progress). mib (work in progress).
[RFC5441] JP. Vasseur (Ed.), "A Backward-Recursive PCE-Based [RFC5441] JP. Vasseur (Ed.), "A Backward-Recursive PCE-Based
Computation (BRPC) Procedure to Compute Shortest Computation (BRPC) Procedure to Compute Shortest
Constrained Inter-Domain Traffic Engineering Label Switched Constrained Inter-Domain Traffic Engineering Label Switched
Paths", RFC 5441, April 2009. Paths", RFC 5441, April 2009.
[PCEP-MON] JP. Vasseur (Ed.), "A set of monitoring tools for Path [PCEP-MON] JP. Vasseur (Ed.), "A set of monitoring tools for Path
Computation Element based Architecture", draft-ietf-pce- Computation Element based Architecture", draft-ietf-pce-
Monitoring (work in progress). monitoring (work in progress).
9. Authors' Addresses 9. Authors' Addresses
Eiji Oki Eiji Oki
University of Electro-Communications University of Electro-Communications
Tokyo, Japan Tokyo, Japan
Email: oki@ice.uec.ac.jp Email: oki@ice.uec.ac.jp
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom R&D, France Telecom R&D,
skipping to change at page 12, line 46 skipping to change at page 12, line 37
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Tomonori Takeda Tomonori Takeda
NTT NTT
3-9-11 Midori-cho, 3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan Musashino-shi, Tokyo 180-8585, Japan
Email: takeda.tomonori@lab.ntt.co.jp Email: takeda.tomonori@lab.ntt.co.jp
Full Copyright Statement Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info)
Please review these documents carefully, as they describe your rights in effect on the date of publication of this document. Please
and restrictions with respect to this document. review these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the Simplified BSD
License.
 End of changes. 17 change blocks. 
31 lines changed or deleted 30 lines changed or added

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