draft-ietf-pce-hierarchy-extensions-05.txt   draft-ietf-pce-hierarchy-extensions-06.txt 
PCE Working Group F. Zhang PCE Working Group F. Zhang
Internet-Draft Q. Zhao Internet-Draft Q. Zhao
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: January 16, 2019 O. Gonzalez de Dios Expires: May 6, 2019 O. Gonzalez de Dios
Telefonica I+D Telefonica I+D
R. Casellas R. Casellas
CTTC CTTC
D. King D. King
Old Dog Consulting Old Dog Consulting
July 15, 2018 November 5, 2018
Extensions to Path Computation Element Communication Protocol (PCEP) for Extensions to Path Computation Element Communication Protocol (PCEP) for
Hierarchical Path Computation Elements (PCE) Hierarchical Path Computation Elements (PCE)
draft-ietf-pce-hierarchy-extensions-05 draft-ietf-pce-hierarchy-extensions-06
Abstract Abstract
The Hierarchical Path Computation Element (H-PCE) architecture RFC The Hierarchical Path Computation Element (H-PCE) architecture is
6805, provides a mechanism to allow the optimum sequence of domains defined in RFC 6805. It provides a mechanism to derive an optimum
to be selected, and the optimum end-to-end path to be derived through end-to-end path in a multi-domain environment by using a hierarchical
the use of a hierarchical relationship between domains. relationship between domains to select the optimum sequence of
domains and optimum paths across those domains.
This document defines the Path Computation Element Protocol (PCEP) This document defines extensions to the Path Computation Element
extensions for the purpose of implementing necessary Hierarchical PCE Protocol (PCEP) to support Hierarchical PCE procedures.
procedures and protocol extensions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 16, 2019. This Internet-Draft will expire on May 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . .5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.3. Requirements Language . . . . . . . . . . . . . . . . . .5
2. Requirements for H-PCE . . . . . . . . . . . . . . . . . . . 5 2. Requirements for H-PCE . . . . . . . . . . . . . . . . . . .5
2.1. Path Computation Request . . . . . . . . . . . . . . . . 5 2.1. Path Computation Request . . . . . . . . . . . . . . . .5
2.1.1. Qualification of PCEP Requests . . . . . . . . . . . 6 2.1.1. Qualification of PCEP Requests . . . . . . . . . . .6
2.1.2. Multi-domain Objective Functions . . . . . . . . . . 6 2.1.2. Multi-domain Objective Functions . . . . . . . . . .6
2.1.3. Multi-domain Metrics . . . . . . . . . . . . . . . . 7 2.1.3. Multi-domain Metrics . . . . . . . . . . . . . . . .6
2.2. Parent PCE Capability Advertisement . . . . . . . . . . . 7 2.2. Parent PCE Capability Advertisement . . . . . . . . . . .6
2.3. PCE Domain Discovery . . . . . . . . . . . . . . . . . . 7 2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7
2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . . 8 2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7
3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .7
3.1. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8
3.1.1. H-PCE capability TLV . . . . . . . . . . . . . . . . 8 3.1.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8
3.1.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .9
3.2. RP object . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. RP Object . . . . . . . . . . . . . . . . . . . . . . . .10
3.2.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . . 10 3.2.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .10
3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10
3.3. Objective Functions . . . . . . . . . . . . . . . . . . . 11 3.3. Objective Functions . . . . . . . . . . . . . . . . . . .11
3.3.1. OF Codes . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .11
3.3.2. OF Object . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. OF Object . . . . . . . . . . . . . . . . . . . . . .12
3.4. Metric Object . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Metric Object . . . . . . . . . . . . . . . . . . . . . .13
3.5. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .13
3.6. PCEP-ERROR object . . . . . . . . . . . . . . . . . . . . 14 3.6. PCEP-ERROR object . . . . . . . . . . . . . . . . . . . .14
3.6.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . . 14 3.6.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .14
3.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . 15 3.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .14
4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . . 15 4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .15
4.1. OPEN Procedure between Child PCE and Parent PCE . . . . . 15 4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .15
4.2. Procedure to obtain Domain Sequence . . . . . . . . . . . 16 4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .16
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 16 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .16
6. Manageability Considerations . . . . . . . . . . . . . . . . 17 6. Manageability Considerations . . . . . . . . . . . . . . . .16
6.1. Control of Function and Policy . . . . . . . . . . . . . 17 6.1. Control of Function and Policy . . . . . . . . . . . . .17
6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .17
6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . . 18 6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . .17
6.1.3. Policy Control . . . . . . . . . . . . . . . . . . . 18 6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .17
6.2. Information and Data Models . . . . . . . . . . . . . . . 18 6.2. Information and Data Models . . . . . . . . . . . . . . .18
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18 6.3. Liveness Detection and Monitoring . . . . . . . . . . . .18
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 19 6.4. Verify Correct Operations . . . . . . . . . . . . . . . .18
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 19 6.5. Requirements On Other Protocols . . . . . . . . . . . . .19
6.6. Impact On Network Operations . . . . . . . . . . . . . . 19 6.6. Impact On Network Operations . . . . . . . . . . . . . .19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .19
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 19 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .19
7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . . 20 7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .19
7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . . 20 7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .20
7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . . 20 7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .21
7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . . 21 7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .21
7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . . 21 7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .21
7.7. New PCEP Error-Types and Values . . . . . . . . . . . . . 22 7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .22
7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . . 22 7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .22
7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . . 22 7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .22
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . .22
9.1. Inter-layer traffic engineering with H-PCE . . . . . . . 23 9. Contributing Authors. . . . . . . . . . . . . . . . . . . . .23
9.2. Telefonica Netphony (Open Source PCE) . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . .23
9.3. Implementation 3: H-PCE Proof of Concept developed by 10.1. Normative References . . . . . . . . . . . . . . . . . .23
Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . .24
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 A1. Implementation Status . . . . . . . . . . . . . . . . . . .28
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .28
11.2. Informative References . . . . . . . . . . . . . . . . . 28 A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 A1.3. Implementation 3: H-PCE Proof of Concept developed by
Huawei . . . . . . . . . . . . . . . . . . . . . . . . .31
1. Introduction 1. Introduction
The Path Computation Element communication Protocol (PCEP) provides The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path a mechanism for Path Computation Elements (PCEs) and Path Computation
computations in response to Path Computation Clients' (PCCs) Clients (PCCs) to exchange requests for path computation and
requests. responses that provide computed paths.
The capability to compute the routes of end-to-end inter-domain MPLS The capability to compute the routes of end-to-end inter-domain MPLS
Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs)
is expressed as requirements in [RFC4105] and [RFC4216]. This is expressed as requirements in [RFC4105] and [RFC4216]. This
capability may be realized by a PCE [RFC4655]. The methods for capability may be realized by a PCE [RFC4655]. The methods for
establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are
documented in [RFC4726]. documented in [RFC4726].
[RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can
be used for computing end-to-end paths for inter-domain MPLS Traffic be used for computing end-to-end paths for inter-domain MPLS Traffic
skipping to change at page 5, line 4 skipping to change at page 4, line 46
This document defines the PCEP extensions for the purpose of This document defines the PCEP extensions for the purpose of
implementing Hierarchical PCE procedures, which are described in implementing Hierarchical PCE procedures, which are described in
[RFC6805]. [RFC6805].
1.1. Scope 1.1. Scope
The following functions are out of scope of this document. The following functions are out of scope of this document.
o Determination of Destination Domain (section 4.5 of [RFC6805]) o Determination of Destination Domain (section 4.5 of [RFC6805])
* via collection of reachability information from child domain;
* via a collection of reachability information from child domain;
* via requests to the child PCEs to discover if they contain the * via requests to the child PCEs to discover if they contain the
destination node; destination node;
* or any other methods. * or any other methods.
o Parent Traffic Engineering Database (TED) methods (section 4.4 of o Parent Traffic Engineering Database (TED) methods (section 4.4 of
[RFC6805]) [RFC6805])
o Learning of Domain connectivity and boundary nodes (BN) addresses. o Learning of Domain connectivity and boundary nodes (BN) addresses.
o Stateful PCE Operations. (Refer [I-D.ietf-pce-stateful-hpce]) o Stateful PCE Operations. (Refer [I-D.ietf-pce-stateful-hpce])
The hierarchical relationship model is described in [RFC6805]. It is
applicable to environments with small groups of domains where
visibility from the ingress LSRs is limited. As highlighted in
[RFC7399] applying the hierarchical PCE model to large groups of
domains such as the Internet is not considered feasible or desirable.
1.2. Terminology 1.2. Terminology
This document uses the terminology defined in [RFC4655], [RFC5440] This document uses the terminology defined in [RFC4655], [RFC5440]
and the additional terms defined in section 1.4 of [RFC6805]. and the additional terms defined in section 1.4 of [RFC6805].
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 6, line 26 skipping to change at page 6, line 26
o As stated in [RFC6805], section 4.5, if a PCC knows the egress o As stated in [RFC6805], section 4.5, if a PCC knows the egress
domain, it can supply this information as the path computation domain, it can supply this information as the path computation
request. It SHOULD be possible to specify the destination domain request. It SHOULD be possible to specify the destination domain
information in a PCEP request, if it is known. information in a PCEP request, if it is known.
o It MAY be possible to indicate that the inter domain path computed o It MAY be possible to indicate that the inter domain path computed
by parent PCE should disallow domain re-entry. by parent PCE should disallow domain re-entry.
2.1.2. Multi-domain Objective Functions 2.1.2. Multi-domain Objective Functions
For inter-domain path computation, there is one new objective For H-PCE inter-domain path computation, there is three new Objective
Function which is defined in section 1.3.1 and 4.1 of [RFC6805]: Functions defined in this document:
o Minimize the number of domains crossed. A domain can be either an
Autonomous System (AS) or an Internal Gateway Protocol (IGP) area
depending on the type of multi-domain network hierarchical PCE is
applied to.
Another objective Function to minimize the number of border nodes is
also defined in this document.
During the PCEP session establishment procedure, the parent PCE needs
to be capable of indicating the Objective Functions (OF) [RFC5541]
capability in the Open message. This capability information may then
be announced by child PCEs, and used for selecting the PCE when a PCC
wants a path that satisfies one or multiple inter-domain objective
functions.
When a PCC requests a PCE to compute an inter-domain path, the PCC
needs to be capable of indicating the new objective functions for
inter-domain path. Note that a given child PCE may also act as a
parent PCE (for some other child PCE).
For the reasons described previously, new OF codes need to be defined
for the new inter-domain objective functions. Then the PCE can
notify its new inter-domain objective functions to the PCC by
carrying them in the OF-list TLV which is carried in the OPEN object.
The PCC can specify which objective function code to use, which is o Minimize the number of Transit Domains (MTD)
carried in the OF object when requesting a PCE to compute an inter- o Minimize the number of border nodes (MBN)
domain path. o Minimize the number of Common Transit Domains (MCTD)
A parent PCE MUST be capable of ensuring homogeneity, across domains, The PCC may specify the multi-domain Objective Function code to
when applying OF codes for strict OF intra-domain requests. use when requesting inter-domain path computation, it may also
include intra-domain OFs, such as Minimum Cost Path (MCP) [RFC5441],
which must be considered by participating child PCEs
2.1.3. Multi-domain Metrics 2.1.3. Multi-domain Metrics
For inter-domain path computation, there are several path metrics of For inter-domain path computation, there are several path metrics of
interest. interest.
o Domain count (number of domains crossed); o Domain count (number of domains crossed);
o Border Node count. o Border Node count.
skipping to change at page 7, line 40 skipping to change at page 7, line 18
During the PCEP session establishment procedure, the child PCE needs During the PCEP session establishment procedure, the child PCE needs
to be capable of indicating to the parent PCE whether it requests the to be capable of indicating to the parent PCE whether it requests the
parent PCE capability or not. Also, during the PCEP session parent PCE capability or not. Also, during the PCEP session
establishment procedure, the parent PCE needs to be capable of establishment procedure, the parent PCE needs to be capable of
indicating whether its parent capability can be provided or not. indicating whether its parent capability can be provided or not.
A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE
Capability" TLV, described in Section 3.1.1, in the OPEN Object to Capability" TLV, described in Section 3.1.1, in the OPEN Object to
advertise its support for PCEP extensions for H-PCE Capability. advertise its support for PCEP extensions for H-PCE Capability.
2.3. PCE Domain Discovery 2.3. PCE Domain Identification
A PCE domain is a single domain with an associated PCE. Although it A PCE domain is a single domain with an associated PCE. Although it
is possible for a PCE to manage multiple domains simultaneously. The is possible for a PCE to manage multiple domains simultaneously. The
PCE domain could be an IGP area or AS. PCE domain could be an IGP area or AS.
The PCE domain identifiers MAY be provided during the PCEP session The PCE domain identifiers MAY be provided during the PCEP session
establishment procedure. establishment procedure.
2.4. Domain Diversity 2.4. Domain Diversity
skipping to change at page 8, line 29 skipping to change at page 7, line 51
example, a pair of paths should choose different transit Autonomous example, a pair of paths should choose different transit Autonomous
System (AS) because of some policy considerations. System (AS) because of some policy considerations.
In case when full domain diversity could not be achieved, it is In case when full domain diversity could not be achieved, it is
helpful to minimize the common shared domains. Also it is helpful to minimize the common shared domains. Also it is
interesting to note that other scope of diversity (node, link, SRLG interesting to note that other scope of diversity (node, link, SRLG
etc) can still be applied inside the common shared domains. etc) can still be applied inside the common shared domains.
3. PCEP Extensions 3. PCEP Extensions
This section defines PCEP extensions to ([RFC5440]) so as to support This section defines extensions to PCEP [RFC5440] to support the
the H-PCE procedures. H-PCE procedures.
3.1. OPEN object 3.1. OPEN object
Two new TLVs are defined in this document to be carried within an Two new TLVs are defined in this document to be carried within an
OPEN object. This way, during PCEP session establishment, the H-PCE OPEN object. This way, during PCEP session establishment, the H-PCE
capability and Domain information can be advertised. capability and Domain information can be advertised.
3.1.1. H-PCE capability TLV 3.1.1. H-PCE Capability TLV
The H-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN The H-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN
Object [RFC5440] to exchange H-PCE capability of PCEP speakers. Object [RFC5440] to exchange H-PCE capability of PCEP speakers.
Its format is shown in the following figure: Its format is shown in the following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type= TBD1 | Length=4 | | Type= TBD1 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|R| | Flags |P|
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: H-PCE-CAPABILITY TLV format Figure 1: H-PCE-CAPABILITY TLV format
The type of the TLV is TBD1 (to be assigned by IANA) and it has a The type of the TLV is TBD1 (to be assigned by IANA) and it has a
fixed length of 4 octets. fixed length of 4 octets.
The value comprises a single field - Flags (32 bits): The value comprises a single field - Flags (32 bits):
R (Parent PCE Request bit): if set, will signal that the child PCE P (Parent PCE Request bit): if set, will signal that the child PCE
wishes to use the peer PCE as a parent PCE. wishes to use the peer PCE as a parent PCE.
I (Parent PCE Indication bit): if set, will signal that the PCE The inclusion of this TLV in an OPEN object indicates that the H-PCE
can be used as a parent PCE by the peer PCE.
The inclusion of this TLV in an OPEN object indicate that the H-PCE
extensions are supported by the PCEP speaker. The PCC MAY include extensions are supported by the PCEP speaker. The PCC MAY include
this TLV to indicate that it understands the H-PCE extensions. The this TLV to indicate that it understands the H-PCE extensions. The
Child PCE MUST include this TLV and set the R flag (and unset the I parent PCE MUST include this TLV and set the P flag.
flag) on the PCEP session towards the Parent PCE. The Parent PCE
MUST include this TLV and set the I flag and unset the R flag on the
PCEP session towards the child PCE. The parent-child PCEP session is
set to be established only when this capability is advertised.
If such capability is not exchanged and the parent PCE receive a "H- If both peers attempt to set the P flag then the session
PCE path computation request", it MUST send a PCErr message with establishment MUST fail, using Error-Type 1: "PCEP Session
Establishment Failure" [RFC5440].
If the PCE understands a H-PCE path computation request, but did not
advertise its H-PCE capability, it MUST send a PCErr message with
Error-Type=TBD8 (H-PCE error) and Error-Value=1 (Parent PCE Error-Type=TBD8 (H-PCE error) and Error-Value=1 (Parent PCE
Capability not advertised). Capability not advertised). If the PCE does not understand or
support the H-PCE request.
3.1.1.1 Backwards Compatibility
If the PCE does not understand a H-PCE path computation request as
specified in this document, the PCE will ignore the H-PCE related
prameters, and behave as per [RFC5440] for any intra-domain Objective
Functions.
3.1.2. Domain-ID TLV 3.1.2. Domain-ID TLV
The Domain-ID TLV when used in OPEN object identify the domain(s) The Domain-ID TLV when used in OPEN object identify the domains
served by the PCE. The child PCE uses this mechanism to inform the served by the PCE. The child PCE uses this mechanism to inform the
domain information to the parent PCE. domain information to the parent PCE.
The Domain-ID TLV is defined below: The Domain-ID TLV is defined below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type= TBD2 | Length | | Type= TBD2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 30 skipping to change at page 9, line 45
variable Length of the value portion. The value part comprises of - variable Length of the value portion. The value part comprises of -
Domain Type (8 bits): Indicates the domain type. Four types of Domain Type (8 bits): Indicates the domain type. Four types of
domain are currently defined: domain are currently defined:
* Type=1: the Domain ID field carries a 2-byte AS number. Padded * Type=1: the Domain ID field carries a 2-byte AS number. Padded
with trailing zeros to a 4-byte boundary. with trailing zeros to a 4-byte boundary.
* Type=2: the Domain ID field carries a 4-byte AS number. * Type=2: the Domain ID field carries a 4-byte AS number.
* Type=3: the Domain ID field carries an 4-byte OSPF area ID. * Type=3: the Domain ID field carries a 4-byte OSPF area ID.
* Type=4: the Domain ID field carries (2-byte Area-Len, variable * Type=4: the Domain ID field carries (2-byte Area-Len, variable
length IS-IS area ID). Padded with trailing zeros to a 4-byte length IS-IS area ID). Padded with trailing zeros to a 4-byte
boundary. boundary.
Reserved: Zero at transmission; ignored at receipt. Reserved: Zero at transmission; ignored at receipt.
Domain ID (variable): Indicates an IGP Area ID or AS number. It Domain ID (variable): Indicates an IGP Area ID or AS number. It
can be 2 bytes, 4 bytes or variable length depending on the domain can be 2 bytes, 4 bytes or variable length depending on the domain
identifier used. It is padded with trailing zeros to a 4-byte identifier used. It is padded with trailing zeros to a 4-byte
boundary. boundary.
In case a PCE serves more than one domain, multiple Domain-ID TLV is In case a PCE serves more than one domain, multiple Domain-ID TLV is
included for each domain it serves. included for each domain it serves.
3.2. RP object 3.2. RP Object
3.2.1. H-PCE-FLAG TLV 3.2.1. H-PCE-FLAG TLV
The H-PCE-FLAG TLV is an optional TLV associated with the RP Object The H-PCE-FLAG TLV is an optional TLV associated with the RP Object
[RFC5440] to indicate the H-PCE path computation request and options. [RFC5440] to indicate the H-PCE path computation request and options.
Its format is shown in the following figure: Its format is shown in the following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 11, line 33 skipping to change at page 10, line 48
wishes to get only the domain sequence in the path computation wishes to get only the domain sequence in the path computation
reply. Refer section 3.7 of [RFC7897] for details. reply. Refer section 3.7 of [RFC7897] for details.
D (Disallow Domain Re-entry bit): if set, will signal that the D (Disallow Domain Re-entry bit): if set, will signal that the
computed path does not enter a domain more than once. computed path does not enter a domain more than once.
3.2.2. Domain-ID TLV 3.2.2. Domain-ID TLV
The usage of Domain-ID TLV carried in an OPEN object is used to The usage of Domain-ID TLV carried in an OPEN object is used to
indicate a (list of) managed domains and is described in indicate a (list of) managed domains and is described in
Section 3.1.2. This TLV when carried in a RP object, indicates the Section 3.1.2. This TLV when carried in an RP object, indicates the
destination domain ID. If a PCC knows the egress domain, it can destination domain ID. If a PCC knows the egress domain, it can
supply this information in the PCReq message. The format and supply this information in the PCReq message. The format and
procedure of this TLV is defined in Section 3.1.2. procedure of this TLV are defined in Section 3.1.2.
If a Domain-id TLV is used in the RP object, and the destination is
not actually in the indicated domain, then the parent
PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV
should be used, and a new bit number is assigned to indicate
"Destination not found in the indicated domain".
3.3. Objective Functions 3.3. Objective Functions
3.3.1. OF Codes 3.3.1. OF Codes
[RFC5541] defines a mechanism to specify an objective function that [RFC5541] defines a mechanism to specify an Objective Function that
is used by a PCE when it computes a path. Two new objective is used by a PCE when it computes a path. Three new Objective
functions are defined for the H-PCE experiment. Functions are defined for H-PCE, these are:
o MTD o MTD
* Name: Minimize the number of Transit Domains (MTD) * Name: Minimize the number of Transit Domains (MTD)
* Objective Function Code - TBD4 (to be assigned by IANA) * Objective Function Code - TBD4 (to be assigned by IANA)
* Description: Find a path P such that it passes through the * Description: Find a path P such that it passes through the
least number of transit domains. least number of transit domains.
* Objective functions are formulated using the following * Objective functions are formulated using the following
terminology: terminology:
+ A network comprises a set of N domains {Di, (i=1...N)}. + A network comprises a set of N domains {Di, (i=1...N)}.
+ A path P passes through K domains {Dpi,(i=1...K)}. + A path P passes through K unique domains {Dpi,(i=1...K)}.
+ Find a path P such that the value of K is minimized. + Find a path P such that the value of K is minimized.
o MBN o MBN
* Name: Minimize the number of border nodes. * Name: Minimize the number of border nodes.
* Objective Function Code - TBD5 (to be assigned by IANA) * Objective Function Code - TBD5 (to be assigned by IANA)
* Description: Find a path P such that it passes through the * Description: Find a path P such that it passes through the
least number of border nodes. least number of border nodes.
* Objective functions are formulated using the following * Objective functions are formulated using the following
terminology: terminology:
+ A network comprises a set of N nodes {Ni, (i=1...N)}. + A network comprises a set of N links {Li, (i=1...N)}.
+ A path P is a list of K nodes {Npi,(i=1...K)}. + A path P is a list of K links {Lpi,(i=1...K)}.
+ B(N) if a function that determine if the node is a border + D(Lpi) if a function that determines if the links Lpi
node. B(Ni) = 1 if Ni is border node; B(Nk) = 0 if Nk is and Lpi+1 belong to different domains, D(Li) = 1 if link
not a border node. Li and Li+1 belong to different domains, D(Lk) = 0 if
link Lk and Lk+1 belong to the same domain.
+ The number of border node in a path P is denoted by B(P), + The number of border node in a path P is denoted by B(P),
where B(P) = sum{B(Npi),(i=1...K)}. where B(P) = sum{D(Lpi),(i=1...K-1)}.
+ Find a path P such that B(P) is minimized. + Find a path P such that B(P) is minimized.
There is one objective function that applies to a set of syncronized
path computation requests to increase the domain diversity:
MCTD MCTD
o Name: Minimize the number of Common Transit Domains. o Name: Minimize the number of Common Transit Domains
o Objective Function Code: TBD13 o Objective Function Code - TBD12 (to be assigned by IANA)
o Description: Find a set of paths such that it passes through the o Description: Find a set of paths such that it passes through the
least number of common transit domains. least number of common transit domains.
+ A network comprises a set of N domains {Di, (i=1...N)}.
+ A path P passes through K unique domains {Dpi,(i=1...K)}.
+ A set of paths {P1...Pm} have L transit domains that are
common to more than one path {Dpi,(i=1...L)}.
+ Find a set of paths such that the value of L is minimized.
3.3.2. OF Object 3.3.2. OF Object
The OF (Objective Function) object [RFC5541] is carried within a The OF (Objective Function) object [RFC5541] is carried within a
PCReq message so as to indicate the desired/required objective PCReq message so as to indicate the desired/required objective
function to be applied by the PCE during path computation. As per function to be applied by the PCE during path computation. As per
section 3.2 of [RFC5541] a single OF object may be included in a path section 3.2 of [RFC5541] a single OF object may be included in a path
computation request. computation request.
The new OF code described in Section 3.3.1 are applicable at the The new OF codes described in Section 3.3.1 are applicable at the
inter-domain level (parent), it is also necessary to specify the OF inter-domain path computation performed by the parent PCE, it is
code that may be applied at the intra-domain (child) path computation also necessary to specify the OF code that may be applied for the
level. To accommodate this, the OF-List TLV (described in section intra-domain path computation performed by the child PCE. To
2.1. of [RFC5541]) is included in the OF object as an optional TLV. accommodate this, the OF-List TLV (described in section 2.1. of
[RFC5541]) is included in the OF object as an optional TLV.
OF-List TLV allow encoding of multiple OF codes. When this TLV is The OF-List TLV allows encoding of multiple OF codes. When this TLV
included inside the OF object, only the first OF-code in the OF-LIST is included inside the OF object, only the first OF-code in the
TLV is considered. The parent PCE MUST use this OF code in the OF OF-LIST TLV is considered. The parent PCE MUST use this OF code in
object when sending the intra domain path computation request to the the OF object when sending the intra domain path computation request
child PCE. to the child PCE. If the OF list TLV is included in the OF Object,
the OF Code inside the OF Object MUST include one of the H-PCE
Objective Functions defined in this document, the OF Code inside the
OF List TLV MUST NOT include an H-PCE Objective Function.
If the objective functions defined in this document are unknown/ If the Objective Functions defined in this document are unknown or
unsupported by a PCE, then the procedure as defined in [RFC5541] is unsupported by a PCE, then the procedure as defined in [RFC5541]
followed. should be followed.
3.4. Metric Object 3.4. Metric Object
The METRIC object is defined in section 7.8 of [RFC5440], comprising The METRIC object is defined in section 7.8 of [RFC5440], comprising
metric-value, metric-type (T field) and flags. This document defines metric-value, metric-type (T field) and flags. This document defines
the following types for the METRIC object for H-PCE: the following types for the METRIC object for H-PCE:
o T=TBD6: Domain count metric (number of domains crossed); o T=TBD6: Domain count metric (number of domains crossed);
o T=TBD7: Border Node count metric (number of border nodes crossed). o T=TBD7: Border Node count metric (number of border nodes crossed).
The domain count metric type of the METRIC object encodes the number The domain count metric type of the METRIC object encodes the number
of domain crossed in the path. The border node count metric type of of domain crossed in the path. The border node count metric type of
the METRIC object encodes the number of border nodes in the path. the METRIC object encodes the number of border nodes in the path. If
a domain is rentered, then domain should be double counted.
A PCC or child PCE MAY use these metric in PCReq message an inter- A PCC or child PCE MAY use these metric in PCReq message an inter-
domain path meeting the number of domain or border nodes requirement. domain path meeting the number of domain or border nodes requirement.
As per [RFC5440], in this case, the B bit is set to suggest a bound As per [RFC5440], in this case, the B bit is set to suggest a bound
(a maximum) for the metric that must not be exceeded for the PCC to (a maximum) for the metric that must not be exceeded for the PCC to
consider the computed path as acceptable. consider the computed path as acceptable.
A PCC or child PCE MAY also use this metric to ask the PCE to A PCC or child PCE MAY also use this metric to ask the PCE to
optimize the metric during inter-domain path computation. In this optimize the metric during inter-domain path computation. In this
case, the B flag is cleared. case, the B flag is cleared.
The Parent PCE MAY use these metric in a PCRep message along with a The Parent PCE MAY use these metric in a PCRep message along with a
NO-PATH object in the case where the PCE cannot compute a path NO-PATH object in the case where the PCE cannot compute a path
meeting this constraint. A PCE MAY also use this metric to send the meeting this constraint. A PCE MAY also use this metric to send the
computed end to end metric in a reply message. computed end to end metric in a reply message.
3.5. SVEC Object 3.5. SVEC Object
[RFC5440] defines SVEC object which includes flags for the potential [RFC5440] defines SVEC object which includes flags for the potential
dependency between the set of path computation requests (Link, Node dependency between the set of path computation requests (Link, Node
and SRLG diverse). This document proposes a new flag O for domain and SRLG diverse). This document defines a new flag O for domain
diversity. diversity.
Following new bit is added in the Flags field: The following new bit is added to the Flags field:
o O (Domain diverse) bit - TBD12 : when set, this indicates that the o O (Domain diverse) bit - TBD12 : when set, this indicates that the
computed paths corresponding to the requests specified by the computed paths corresponding to the requests specified by the
following RP objects MUST NOT have any transit domain(s) in following RP objects MUST NOT have any transit domains in
common. common.
The Domain Diverse O-bit can be used in Hierarchical PCE path The Domain Diverse O-bit can be used in Hierarchical PCE path
computation to compute synchronized domain diverse end to end path or computation to compute synchronized domain diverse end to end path or
diverse domain sequences. diverse domain sequences.
When domain diverse O bit is set, it is applied to the transit When domain diverse O bit is set, it is applied to the transit
domains. The other bit in SVEC object (N, L, S etc) MAY be set and domains. The other bit in SVEC object (N, L, S etc) MAY be set and
MUST still be applied in the ingress and egress shared domain. MUST still be applied in the ingress and egress shared domain.
skipping to change at page 15, line 23 skipping to change at page 15, line 12
Three new bit flags are defined to be carried in the Flags field in Three new bit flags are defined to be carried in the Flags field in
the NO-PATH-VECTOR TLV carried in the NO-PATH Object. the NO-PATH-VECTOR TLV carried in the NO-PATH Object.
o Bit number TBD9: When set, the parent PCE indicates that o Bit number TBD9: When set, the parent PCE indicates that
destination domain unknown; destination domain unknown;
o Bit number TBD10: When set, the parent PCE indicates unresponsive o Bit number TBD10: When set, the parent PCE indicates unresponsive
child PCE(s); child PCE(s);
o Bit number TBD11: When set, the parent PCE indicates no available o Bit number TBD11: When set, the parent PCE indicates no available
resource available in one or more domain(s). resource available in one or more domains.
4. H-PCE Procedures 4. H-PCE Procedures
4.1. OPEN Procedure between Child PCE and Parent PCE 4.1. OPEN Procedure between Child PCE and Parent PCE
If a child PCE wants to use the peer PCE as a parent, it MUST set the If a child PCE wants to use the peer PCE as a parent, it MUST set the
R (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the R (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the
OPEN object carried in the Open message during the PCEP session OPEN object carried in the Open message during the PCEP session
initialization procedure. initialization procedure.
skipping to change at page 15, line 49 skipping to change at page 15, line 38
The child PCE MAY also report its list of domain IDs to the parent The child PCE MAY also report its list of domain IDs to the parent
PCE by specifying them in the Domain-ID TLVs in the OPEN object PCE by specifying them in the Domain-ID TLVs in the OPEN object
carried in the Open message during the PCEP session initialization carried in the Open message during the PCEP session initialization
procedure. procedure.
The OF codes defined in this document can be carried in the OF-list The OF codes defined in this document can be carried in the OF-list
TLV of the OPEN object. If the OF-list TLV carries the OF codes, it TLV of the OPEN object. If the OF-list TLV carries the OF codes, it
means that the PCE is capable of implementing the corresponding means that the PCE is capable of implementing the corresponding
objective functions. This information can be used for selecting a objective functions. This information can be used for selecting a
proper parent PCE when a child PCE wants to get a path that satisfies proper parent PCE when a child PCE wants to get a path that satisfies
a certain objective function. a certain Objective Function.
When a specific child PCE sends a PCReq to a peer PCE that requires When a specific child PCE sends a PCReq to a peer PCE that requires
parental activity and H-PCE capability flags were not set in the parental activity and H-PCE capability flags were not set in the
session establishment procedure as described above, the peer PCE session establishment procedure as described above, the peer PCE
should send a PCErr message to the child PCE and specify the error- should send a PCErr message to the child PCE and specify the error-
type=TBD (H-PCE error) and error-value=1 (parent PCE capability was type=TBD (H-PCE error) and error-value=1 (parent PCE capability was
not advertised) in the PCEP-ERROR object. not advertised) in the PCEP-ERROR object.
When a specific child PCE sends a PCReq to a peer PCE that requires When a specific child PCE sends a PCReq to a peer PCE that requires
parental activity and the peer PCE does not want to act as the parent parental activity and the peer PCE does not want to act as the parent
for it, the peer PCE should send a PCErr message to the child PCE and for it, the peer PCE should send a PCErr message to the child PCE and
specify the error-type=TBD (H-PCE error) and error-value=2 (parent specify the error-type=TBD (H-PCE error) and error-value=2 (parent
PCE capability cannot be provided) in the PCEP-ERROR object. PCE capability cannot be provided) in the PCEP-ERROR object.
4.2. Procedure to obtain Domain Sequence 4.2. Procedure to Obtain Domain Sequence
If a child PCE only wants to get the domain sequence for a multi- If a child PCE only wants to get the domain sequence for a multi-
domain path computation from a parent PCE, it can set the Domain Path domain path computation from a parent PCE, it can set the Domain Path
Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq
message. The parent PCE which receives the PCReq message tries to message. The parent PCE which receives the PCReq message tries to
compute a domain sequence for it (instead for E2E path). If the compute a domain sequence for it (instead of the E2E path). If the
domain path computation succeeds the parent PCE sends a PCRep message domain path computation succeeds the parent PCE sends a PCRep message
which carries the domain sequence in the ERO to the child PCE. Refer which carries the domain sequence in the ERO to the child PCE. Refer
[RFC7897] for more details about domain sub-objects in the ERO. [RFC7897] for more details about domain sub-objects in the ERO.
Otherwise it sends a PCReq message which carries the NO-PATH object Otherwise, it sends a PCReq message which carries the NO-PATH object
to the child PCE. to the child PCE.
5. Error Handling 5. Error Handling
A PCE that is capable of acting as a parent PCE might not be A PCE that is capable of acting as a parent PCE might not be
configured or willing to act as the parent for a specific child PCE. configured or willing to act as the parent for a specific child PCE.
This fact could be determined when the child sends a PCReq that This fact could be determined when the child sends a PCReq that
requires parental activity, and could result in a negative response requires parental activity, and could result in a negative response
in a PCEP Error (PCErr) message and indicate the hierarchy PCE error- in a PCEP Error (PCErr) message and indicate the hierarchy PCE error-
type=TBD8 (H-PCE error) and suitable error-value. (Section 3.6) type=TBD8 (H-PCE error) and suitable error-value. (Section 3.6)
Additionally, the parent PCE may fail to find the multi-domain path Additionally, the parent PCE may fail to find the multi-domain path
or domain sequence due to one or more of the following reasons: or domain sequence due to one or more of the following reasons:
o A child PCE cannot find a suitable path to the egress; o A child PCE cannot find a suitable path to the egress;
o The parent PCE do not hear from a child PCE for a specified time; o The parent PCE do not hear from a child PCE for a specified time;
o The objective functions specified in the path request cannot be o The Objective Functions specified in the path request cannot be
met. met.
In this case, the parent PCE MAY need to send a negative path In this case, the parent PCE MAY need to send a negative path
computation reply specifying the reason. This can be achieved by computation reply specifying the reason. This can be achieved by
including NO-PATH object in the PCRep message. Extension to NO-PATH including NO-PATH object in the PCRep message. Extension to NO-PATH
object is needed to include the aforementioned reasons described in object is needed to include the aforementioned reasons described in
Section 3.7. Section 3.7.
6. Manageability Considerations 6. Manageability Considerations
skipping to change at page 17, line 36 skipping to change at page 17, line 26
Control and function will need to be carefully managed in a H-PCE Control and function will need to be carefully managed in a H-PCE
network. A child PCE will need to be configured with the address of network. A child PCE will need to be configured with the address of
its parent PCE. It is expected that there will only be one or two its parent PCE. It is expected that there will only be one or two
parents of any child. parents of any child.
The parent PCE also needs to be aware of the child PCEs for all child The parent PCE also needs to be aware of the child PCEs for all child
domains that it can see. This information is most likely to be domains that it can see. This information is most likely to be
configured (as part of the administrative definition of each domain). configured (as part of the administrative definition of each domain).
Discovery of the relationships between parent PCEs and child PCEs Discovery of the relationships between parent PCEs and child PCEs
does not form part of the hierarchical PCE architecture. Mechanisms do not form part of the hierarchical PCE architecture. Mechanisms
that rely on advertising or querying PCE locations across domain or that rely on advertising or querying PCE locations across domain or
provider boundaries are undesirable for security, scaling, provider boundaries are undesirable for security, scaling,
commercial, and confidentiality reasons. Specific behavior of the commercial, and confidentiality reasons. The specific behavior of
child and parent PCE are described in the following sub-sections. the child and parent PCE are described in the following sub-sections.
6.1.1. Child PCE 6.1.1. Child PCE
Support of the hierarchical procedure will be controlled by the Support of the hierarchical procedure will be controlled by the
management organization responsible for each child PCE. A child PCE management organization responsible for each child PCE. A child PCE
must be configured with the address of its parent PCE in order for it must be configured with the address of its parent PCE in order for it
to interact with its parent PCE. The child PCE must also be to interact with its parent PCE. The child PCE must also be
authorized to peer with the parent PCE. authorized to peer with the parent PCE.
6.1.2. Parent PCE 6.1.2. Parent PCE
skipping to change at page 19, line 36 skipping to change at page 19, line 22
6.6. Impact On Network Operations 6.6. Impact On Network Operations
The hierarchical PCE procedure is a multiple-PCE path computation The hierarchical PCE procedure is a multiple-PCE path computation
scheme. Subsequent requests to and from the child and parent PCEs do scheme. Subsequent requests to and from the child and parent PCEs do
not differ from other path computation requests and should not have not differ from other path computation requests and should not have
any significant impact on network operations. any significant impact on network operations.
7. IANA Considerations 7. IANA Considerations
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry. This document requests IANA actions to allocate code
points for the protocol elements defined in this document.
7.1. PCEP TLV Type Indicators 7.1. PCEP TLV Type Indicators
IANA Manages the PCEP TLV code point registry (see [RFC5440]). This IANA Manages the PCEP TLV code point registry (see [RFC5440]). This
is maintained as the "PCEP TLV Type Indicators" sub-registry of the is maintained as the "PCEP TLV Type Indicators" sub-registry of the
"Path Computation Element Protocol (PCEP) Numbers" registry. "Path Computation Element Protocol (PCEP) Numbers" registry.
This document defines three new PCEP TLVs. IANA is requested to make This document defines three new PCEP TLVs. IANA is requested to make
the following allocation: the following allocation:
Type TLV name References Type TLV name References
skipping to change at page 20, line 16 skipping to change at page 20, line 4
This document requests that a new sub-registry, named " H-PCE- This document requests that a new sub-registry, named " H-PCE-
CAPABILITY TLV Flag Field", is created within the "Path Computation CAPABILITY TLV Flag Field", is created within the "Path Computation
Element Protocol (PCEP) Numbers" registry to manage the Flag field in Element Protocol (PCEP) Numbers" registry to manage the Flag field in
the H-PCE-CAPABILITY TLV of the PCEP OPEN object. the H-PCE-CAPABILITY TLV of the PCEP OPEN object.
New values are to be assigned by Standards Action [RFC5226]. Each New values are to be assigned by Standards Action [RFC5226]. Each
bit should be tracked with the following qualities: bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
-------------------------------------------------- --------------------------------------------------
31 R (Parent PCE Request bit) This I.D. 31 P (Parent PCE bit) This I.D.
30 I (Parent PCE Indication bit) This I.D.
7.3. Domain-ID TLV Domain type 7.3. Domain-ID TLV Domain type
This document requests that a new sub-registry, named " Domain-ID TLV This document requests that a new sub-registry, named " Domain-ID TLV
Domain type", is created within the "Path Computation Element Domain type", is created within the "Path Computation Element
Protocol (PCEP) Numbers" registry to manage the Domain-Type field of Protocol (PCEP) Numbers" registry to manage the Domain-Type field of
the Domain-ID TLV. the Domain-ID TLV.
Value Meaning Value Meaning
----------------------------------------------- -----------------------------------------------
skipping to change at page 21, line 32 skipping to change at page 21, line 20
IANA is requested to make the following allocations: IANA is requested to make the following allocations:
Code Code
Point Name Reference Point Name Reference
------------------------------------------------------ ------------------------------------------------------
TBD4 Minimum number of Transit This I.D. TBD4 Minimum number of Transit This I.D.
Domains (MTD) Domains (MTD)
TBD5 Minimize number of Border This I.D. TBD5 Minimize number of Border This I.D.
Nodes (MBN) Nodes (MBN)
TBD13 Minimize the number of This I.D. TBD12 Minimize the number of This I.D.
Common Transit Domains. Common Transit Domains.
(MCTD) (MCTD)
7.6. METRIC Types 7.6. METRIC Types
IANA maintains one sub-registry for "METRIC object T field". Two new IANA maintains one sub-registry for "METRIC object T field". Two new
metric types are defined in this document for the METRIC object metric types are defined in this document for the METRIC object
(specified in [RFC5440]). (specified in [RFC5440]).
IANA is requested to make the following allocations: IANA is requested to make the following allocations:
skipping to change at page 22, line 45 skipping to change at page 22, line 28
one or more domain one or more domain
7.9. SVEC Flag 7.9. SVEC Flag
IANA maintains a registry of bit flags carried in the PCEP SVEC IANA maintains a registry of bit flags carried in the PCEP SVEC
object as defined in [RFC5440]. IANA Is requested to assign one new object as defined in [RFC5440]. IANA Is requested to assign one new
bit flag as follows: bit flag as follows:
Bit Number Name Flag Reference Bit Number Name Flag Reference
------------------------------------------------------ ------------------------------------------------------
TBD13 Domain Diverse This I.D. TBD12 Domain Diverse This I.D.
7.10. NO-PATH VECTOR TLV Bit Flag
IANA maintains a registry of bit flags carried in the PCEP NO-PATH-
VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440]. IANA
assigned a new bit flag as follows:
Bit Number Name Flag Reference
------------------------------------------------------
TBD Destination not found This I.D.
in the indicated domain
8. Security Considerations 8. Security Considerations
The hierarchical PCE procedure relies on PCEP and inherits the The hierarchical PCE procedure relies on PCEP and inherits the
security requirements defined in [RFC5440]. As PCEP operates over security requirements defined in [RFC5440]. As PCEP operates over
TCP, it may also make use of TCP security mechanisms, such as TCP-AO TCP, it may also make use of TCP security mechanisms, such as TCP
or [RFC8253]. Authentication Option (TCP-AO) [RFC5925] or Transport Layer
Security (TLS) [RFC8253].
H-PCE operation also relies on information used to build the TED. H-PCE operation also relies on information used to build the TED.
Attacks on a parent or child PCE may be achieved by falsifying or Attacks on a parent or child PCE may be achieved by falsifying or
impeding this flow of information. If the child PCE listens to the impeding this flow of information. If the child PCE listens to the
IGP or BGP-LS for populating the TED, then normal IGP or BGP-LS IGP or BGP-LS for populating the TED, then normal IGP or BGP-LS
security measures may be applied, and it should be noted that an IGP security measures may be applied, and it should be noted that an IGP
routing system is generally assumed to be a trusted domain such that routing system is generally assumed to be a trusted domain such that
router subversion is not a risk. The parent PCE TED is constructed router subversion is not a risk. The parent PCE TED is constructed
as described in this document and may involve: as described in this document and may involve:
skipping to change at page 23, line 41 skipping to change at page 23, line 31
significant security and confidentiality risk especially when the significant security and confidentiality risk especially when the
child domains are controlled by different commercial concerns. PCEP child domains are controlled by different commercial concerns. PCEP
allows individual PCEs to maintain confidentiality of their domain allows individual PCEs to maintain confidentiality of their domain
path information using path-keys [RFC5520], and the H-PCE path information using path-keys [RFC5520], and the H-PCE
architecture is specifically designed to enable as much isolation of architecture is specifically designed to enable as much isolation of
domain topology and capabilities information as is possible. domain topology and capabilities information as is possible.
For further considerations of the security issues related to inter-AS For further considerations of the security issues related to inter-AS
path computation, see [RFC5376]. path computation, see [RFC5376].
9. Implementation Status 9. Contributing Authors
The H-PCE architecture and protocol procedures describe in this I-D
were implemented and tested for a variety of optical research
applications.
9.1. Inter-layer traffic engineering with H-PCE
This work was led by:
o Ramon Casellas [ramon.casellas@cttc.es]
o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)
The H-PCE instances (parent and child) were multi-threaded
asynchronous processes. Implemented in C++11, using C++ Boost
Libraries. The targeted system used to deploy and run H-PCE
applications was a POSIX system (Debian GNU/Linux operating system).
Some parts of the software may require a Linux Kernel, the
availability of a Routing Controller running collocated in the same
host and the usage of libnetfilter / libipq and GNU/Linux firewalling
capabilities. Most of the functionality, including algorithms is
done by means of plugins (e.g., as shared libraries or .so files in
Unix systems).
The CTTC PCE supports the H-PCE architecture, but also supports
stateful PCE with active capabilities, as an OpenFlow controller, and
has dedicated plugins to support monitoring, BRPC, P2MP, path keys,
back end PCEs. Management of the H-PCE entities was supported via
HTTP and CLI via Telnet.
Further details of the H-PCE prototyping and experimentation can be
found in the following scientific papers:
R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I.
Morita, "Inter-layer traffic engineering with hierarchical-PCE in
MPLS-TP over wavelength switched optical networks" , Optics
Express, Vol. 20, No. 28, December 2012.
R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I.
Morita, M. Msurusawa, "Dynamic virtual link mesh topology
aggregation in multi-domain translucent WSON with hierarchical-
PCE", Optics Express Journal, Vol. 19, No. 26, December 2011.
R. Casellas, R. Munoz, R. Martinez, R. Vilalta, L. Liu, T.
Tsuritani, I. Morita, V. Lopez, O. Gonzalez de Dios, J. P.
Fernandez-Palacios, "SDN based Provisioning Orchestration of
OpenFlow/GMPLS Flexi-grid Networks with a Stateful Hierarchical
PCE", in Proceedings of Optical Fiber Communication Conference and
Exposition (OFC), 9-13 March, 2014, San Francisco (EEUU).
Extended Version to appear in Journal Of Optical Communications
and Networking January 2015
F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov,
P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical
PCE Architecture in a Distributed Multi-Platform Control Plane
Testbed" , in Proceedings of Optical Fiber Communication
Conference and Exposition (OFC) and The National Fiber Optic
Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles,
California (USA).
R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I.
Morita, M. Tsurusawa, "Dynamic Virtual Link Mesh Topology
Aggregation in Multi-Domain Translucent WSON with Hierarchical-
PCE", in Proceedings of 37th European Conference and Exhibition on
Optical Communication (ECOC 2011), 18-22 September 2011, Geneve (
Switzerland).
R. Casellas, R. Munoz, R. Martinez, "Lab Trial of Multi-Domain
Path Computation in GMPLS Controlled WSON Using a Hierarchical
PCE", in Proceedings of OFC/NFOEC Conference (OFC2011), 10 March
2011, Los Angeles (USA).
9.2. Telefonica Netphony (Open Source PCE)
The Telefonica Netphony PCE is an open source Java-based
implementation of a Path Computation Element, with several flavours,
and a Path Computation Client. The PCE follows a modular
architecture and allows to add customized algorithms. The PCE has
also stateful and remote initiation capabilities. In current
version, three components can be built, a domain PCE (aka child PCE),
a parent PCE (ready for the H-PCE architecture) and a PCC (path
computation client).
This work was led by:
o Oscar Gonzalez de Dios [oscar.gonzalezdedios@telefonica.com]
o Victor Lopez Alvarez [victor.lopezalvarez@telefonica.com]
o Telefonica I+D, Madrid, Spain
The PCE code is publicly available in a GitHub repository:
o https://github.com/telefonicaid/netphony-pce
The PCEP protocol encodings are located in the following repository:
o https://github.com/telefonicaid/netphony-network protocols
The traffic engineering database and a BGP-LS speaker to fill the
database is located in:
o https://github.com/telefonicaid/netphony-topology
The parent and child PCE are multi-threaded java applications. The
path computation uses the jgrapht free Java class library (0.9.1)
that provides mathematical graph-theory objects and algorithms.
Current version of netphony PCE runs on java 1.7 and 1.8, and has
been tested in GNU/Linux, Mac OS-X and Windows environments. The
management of the parent and domain PCEs is supported though CLI via
Telnet, and configured via XML files.
Further details of the netphony H-PCE prototyping and experimentation
can be found in the following research papers:
o O. Gonzalez de Dios, R. Casellas, F. Paolucci, A. Napoli, L.
Gifre, A. Dupas, E, Hugues-Salas, R. Morro, S. Belotti, G.
Meloni, T. Rahman, V.P Lopez, R. Martinez, F. Fresi, M. Bohn,
S. Yan, L. Velasco, . Layec and J. P. Fernandez-Palacios:
Experimental Demonstration of Multivendor and Multidomain EON With
Data and Control Interoperability Over a Pan-European Test Bed, in
Journal of Lightwave Technology, Dec. 2016, Vol. 34, Issue 7, pp.
1610-1617.
o O. Gonzalez de Dios, R. Casellas, R. Morro, F. Paolucci, V.
Lopez, R. Martinez, R. Munoz, R. Villalta, P. Castoldi:
"Multi-partner Demonstration of BGP-LS enabled multi-domain EON,
in Journal of Optical Communications and Networking, Dec. 2015,
Vol. 7, Issue 12, pp. B153-B162.
o F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov,
P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical
PCE Architecture in a Distributed Multi-Platform Control Plane
Testbed" , in Proceedings of Optical Fiber Communication
Conference and Exposition (OFC) and The National Fiber Optic
Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles,
California (USA).
9.3. Implementation 3: H-PCE Proof of Concept developed by Huawei
Huawei developed this H-PCE on the Huawei Versatile Routing Platform
(VRP) to experiment with the hierarchy of PCE. Both end to end path
computation as well as computation for domain-sequence are supported.
This work was led by:
o Udayasree Pallee [udayasreereddy@gmail.com]
o Dhruv Dhody [dhruv.ietf@gmail.com]
o Huawei Technologies, Bangalore, India
Further work on stateful H-PCE [I-D.ietf-pce-stateful-hpce] is being
carried out on ONOS.
10. Contributing Authors
Xian Zhang Xian Zhang
Huawei Huawei
EMail: zhang.xian@huawei.com EMail: zhang.xian@huawei.com
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
11. References 10. References
11.1. Normative References 10.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing Inter- Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
skipping to change at page 28, line 5 skipping to change at page 24, line 29
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009, DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>. <https://www.rfc-editor.org/info/rfc5541>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 10.2. Informative References
[RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed.,
"Requirements for Inter-Area MPLS Traffic Engineering", "Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, DOI 10.17487/RFC4105, June 2005, RFC 4105, DOI 10.17487/RFC4105, June 2005,
<https://www.rfc-editor.org/info/rfc4105>. <https://www.rfc-editor.org/info/rfc4105>.
[RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements", System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, DOI 10.17487/RFC4216, November 2005, RFC 4216, DOI 10.17487/RFC4216, November 2005,
<https://www.rfc-editor.org/info/rfc4216>. <https://www.rfc-editor.org/info/rfc4216>.
skipping to change at page 29, line 12 skipping to change at page 25, line 32
DOI 10.17487/RFC5520, April 2009, DOI 10.17487/RFC5520, April 2009,
<https://www.rfc-editor.org/info/rfc5520>. <https://www.rfc-editor.org/info/rfc5520>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC) "A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441, Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009, DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/info/rfc5441>. <https://www.rfc-editor.org/info/rfc5441>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805, of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012, DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>. <https://www.rfc-editor.org/info/rfc6805>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>. <https://www.rfc-editor.org/info/rfc7420>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
skipping to change at page 29, line 45 skipping to change at page 27, line ?
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-08 (work in progress), June 2018. yang-09 (work in progress), October 2018.
[I-D.ietf-pce-stateful-hpce] [I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D.,
and O. Dios, "Hierarchical Stateful Path Computation and O. Dios, "Hierarchical Stateful Path Computation
Element (PCE).", draft-ietf-pce-stateful-hpce-05 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in
progress), June 2018. progress), June 2018.
Authors' Addresses Authors' Addresses
Fatai Zhang Fatai Zhang
Huawei Huawei
Huawei Base, Bantian, Longgang District Huawei Base, Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
China China
skipping to change at line 1379 skipping to change at page 28, line 25
Barcelona, Castelldefels Barcelona, Castelldefels
Spain Spain
EMail: ramon.casellas@cttc.es EMail: ramon.casellas@cttc.es
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
UK UK
EMail: daniel@olddog.co.uk EMail: daniel@olddog.co.uk
Appendix
A1. Implementation Status
The H-PCE architecture and protocol procedures describe in this I-D
were implemented and tested for a variety of optical research
applications.
The Appendix shold be removed before publication.
A1.1. Inter-layer traffic engineering with H-PCE
This work was led by:
o Ramon Casellas [ramon.casellas@cttc.es]
o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)
The H-PCE instances (parent and child) were multi-threaded
asynchronous processes. Implemented in C++11, using C++ Boost
Libraries. The targeted system used to deploy and run H-PCE
applications was a POSIX system (Debian GNU/Linux operating system).
Some parts of the software may require a Linux Kernel, the
availability of a Routing Controller running collocated in the same
host and the usage of libnetfilter / libipq and GNU/Linux firewalling
capabilities. Most of the functionality, including algorithms is
done by means of plugins (e.g., as shared libraries or .so files in
Unix systems).
The CTTC PCE supports the H-PCE architecture, but also supports
stateful PCE with active capabilities, as an OpenFlow controller, and
has dedicated plugins to support monitoring, BRPC, P2MP, path keys,
back end PCEs. Management of the H-PCE entities was supported via
HTTP and CLI via Telnet.
Further details of the H-PCE prototyping and experimentation can be
found in the following scientific papers:
R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I.
Morita, "Inter-layer traffic engineering with hierarchical-PCE in
MPLS-TP over wavelength switched optical networks" , Optics
Express, Vol. 20, No. 28, December 2012.
R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I.
Morita, M. Msurusawa, "Dynamic virtual link mesh topology
aggregation in multi-domain translucent WSON with hierarchical-
PCE", Optics Express Journal, Vol. 19, No. 26, December 2011.
R. Casellas, R. Munoz, R. Martinez, R. Vilalta, L. Liu, T.
Tsuritani, I. Morita, V. Lopez, O. Gonzalez de Dios, J. P.
Fernandez-Palacios, "SDN based Provisioning Orchestration of
OpenFlow/GMPLS Flexi-grid Networks with a Stateful Hierarchical
PCE", in Proceedings of Optical Fiber Communication Conference and
Exposition (OFC), 9-13 March, 2014, San Francisco (EEUU).
Extended Version to appear in Journal Of Optical Communications
and Networking January 2015
F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov,
P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical
PCE Architecture in a Distributed Multi-Platform Control Plane
Testbed" , in Proceedings of Optical Fiber Communication
Conference and Exposition (OFC) and The National Fiber Optic
Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles,
California (USA).
R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I.
Morita, M. Tsurusawa, "Dynamic Virtual Link Mesh Topology
Aggregation in Multi-Domain Translucent WSON with Hierarchical-
PCE", in Proceedings of 37th European Conference and Exhibition on
Optical Communication (ECOC 2011), 18-22 September 2011, Geneve (
Switzerland).
R. Casellas, R. Munoz, R. Martinez, "Lab Trial of Multi-Domain
Path Computation in GMPLS Controlled WSON Using a Hierarchical
PCE", in Proceedings of OFC/NFOEC Conference (OFC2011), 10 March
2011, Los Angeles (USA).
A1.2. Telefonica Netphony (Open Source PCE)
The Telefonica Netphony PCE is an open source Java-based
implementation of a Path Computation Element, with several flavours,
and a Path Computation Client. The PCE follows a modular
architecture and allows to add customized algorithms. The PCE has
also stateful and remote initiation capabilities. In current
version, three components can be built, a domain PCE (aka child PCE),
a parent PCE (ready for the H-PCE architecture) and a PCC (path
computation client).
This work was led by:
o Oscar Gonzalez de Dios [oscar.gonzalezdedios@telefonica.com]
o Victor Lopez Alvarez [victor.lopezalvarez@telefonica.com]
o Telefonica I+D, Madrid, Spain
The PCE code is publicly available in a GitHub repository:
o https://github.com/telefonicaid/netphony-pce
The PCEP protocol encodings are located in the following repository:
o https://github.com/telefonicaid/netphony-network protocols
The traffic engineering database and a BGP-LS speaker to fill the
database is located in:
o https://github.com/telefonicaid/netphony-topology
The parent and child PCE are multi-threaded java applications. The
path computation uses the jgrapht free Java class library (0.9.1)
that provides mathematical graph-theory objects and algorithms.
Current version of netphony PCE runs on java 1.7 and 1.8, and has
been tested in GNU/Linux, Mac OS-X and Windows environments. The
management of the parent and domain PCEs is supported though CLI via
Telnet, and configured via XML files.
Further details of the netphony H-PCE prototyping and experimentation
can be found in the following research papers:
o O. Gonzalez de Dios, R. Casellas, F. Paolucci, A. Napoli, L.
Gifre, A. Dupas, E, Hugues-Salas, R. Morro, S. Belotti, G.
Meloni, T. Rahman, V.P Lopez, R. Martinez, F. Fresi, M. Bohn,
S. Yan, L. Velasco, . Layec and J. P. Fernandez-Palacios:
Experimental Demonstration of Multivendor and Multidomain EON With
Data and Control Interoperability Over a Pan-European Test Bed, in
Journal of Lightwave Technology, Dec. 2016, Vol. 34, Issue 7, pp.
1610-1617.
o O. Gonzalez de Dios, R. Casellas, R. Morro, F. Paolucci, V.
Lopez, R. Martinez, R. Munoz, R. Villalta, P. Castoldi:
"Multi-partner Demonstration of BGP-LS enabled multi-domain EON,
in Journal of Optical Communications and Networking, Dec. 2015,
Vol. 7, Issue 12, pp. B153-B162.
o F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov,
P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical
PCE Architecture in a Distributed Multi-Platform Control Plane
Testbed" , in Proceedings of Optical Fiber Communication
Conference and Exposition (OFC) and The National Fiber Optic
Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles,
California (USA).
A1.3. Implementation 3: H-PCE Proof of Concept developed by Huawei
Huawei developed this H-PCE on the Huawei Versatile Routing Platform
(VRP) to experiment with the hierarchy of PCE. Both end to end path
computation as well as computation for domain-sequence are supported.
This work was led by:
o Udayasree Pallee [udayasreereddy@gmail.com]
o Dhruv Dhody [dhruv.ietf@gmail.com]
o Huawei Technologies, Bangalore, India
Further work on stateful H-PCE [I-D.ietf-pce-stateful-hpce] is being
carried out on ONOS.
 End of changes. 68 change blocks. 
337 lines changed or deleted 221 lines changed or added

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