draft-ietf-pce-hierarchy-extensions-08.txt   draft-ietf-pce-hierarchy-extensions-09.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: June 7, 2019 O. Gonzalez de Dios Expires: August 7, 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
December 6, 2018 February 6, 2019
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-08 draft-ietf-pce-hierarchy-extensions-09
Abstract Abstract
The Hierarchical Path Computation Element (H-PCE) architecture is The Hierarchical Path Computation Element (H-PCE) architecture is
defined in RFC 6805. It provides a mechanism to derive an optimum defined in RFC 6805. It provides a mechanism to derive an optimum
end-to-end path in a multi-domain environment by using a hierarchical end-to-end path in a multi-domain environment by using a hierarchical
relationship between domains to select the optimum sequence of relationship between domains to select the optimum sequence of
domains and optimum paths across those domains. domains and optimum paths across those domains.
This document defines extensions to the Path Computation Element This document defines extensions to the Path Computation Element
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 June 7, 2019. This Internet-Draft will expire on August 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . .6
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 . . . . . . . . . . . . . . . .6 2.1.3. Multi-domain Metrics . . . . . . . . . . . . . . . .7
2.2. Parent PCE Capability Advertisement . . . . . . . . . . .7 2.2. Parent PCE Capability Advertisement . . . . . . . . . . .7
2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7 2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7
2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7 2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7
3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .8 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .8
3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8 3.1 Applicability to PCC-PCE Communications . . . . . . . . .8
3.1.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8 3.2. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8
3.1.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .9 3.2.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8
3.2. RP Object . . . . . . . . . . . . . . . . . . . . . . . .10 3.2.1.1 Backwards Compatibility . . . . . . . . . . . . . . .9
3.2.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .10
3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10 3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10
3.3. Objective Functions . . . . . . . . . . . . . . . . . . .11 3.2. RP Object . . . . . . . . . . . . . . . . . . . . . . . .11
3.3.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .11 3.2.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .11
3.3.2. OF Object . . . . . . . . . . . . . . . . . . . . . .12 3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .12
3.4. Metric Object . . . . . . . . . . . . . . . . . . . . . .13 3.3. Objective Functions . . . . . . . . . . . . . . . . . . .12
3.5. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .14 3.3.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .12
3.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . .14 3.3.2. OF Object . . . . . . . . . . . . . . . . . . . . . .13
3.6.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .14 3.4. Metric Object . . . . . . . . . . . . . . . . . . . . . .14
3.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .14 3.5. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .15
4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .15 3.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . .15
4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .15 3.6.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .15
4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .16 3.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .15
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .16 4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .16
6. Manageability Considerations . . . . . . . . . . . . . . . .16 4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .16
6.1. Control of Function and Policy . . . . . . . . . . . . .17 4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .17
6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .17 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .17
6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . .17 6. Manageability Considerations . . . . . . . . . . . . . . . .18
6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .18 6.1. Control of Function and Policy . . . . . . . . . . . . .18
6.2. Information and Data Models . . . . . . . . . . . . . . .18 6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .19
6.3. Liveness Detection and Monitoring . . . . . . . . . . . .18 6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . .18
6.4. Verify Correct Operations . . . . . . . . . . . . . . . .18 6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .19
6.5. Requirements On Other Protocols . . . . . . . . . . . . .19 6.2. Information and Data Models . . . . . . . . . . . . . . .19
6.6. Impact On Network Operations . . . . . . . . . . . . . .19 6.3. Liveness Detection and Monitoring . . . . . . . . . . . .19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .19 6.4. Verify Correct Operations . . . . . . . . . . . . . . . .19
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .19 6.5. Requirements On Other Protocols . . . . . . . . . . . . .20
7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .19 6.6. Impact On Network Operations . . . . . . . . . . . . . .20
7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .20
7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .20 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .20
7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .21 7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .20
7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .21 7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .21
7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .21 7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .21
7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .22 7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .22
7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .22 7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .22
7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .22 7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .22
8. Security Considerations . . . . . . . . . . . . . . . . . . .22 7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .23
9. Contributing Authors. . . . . . . . . . . . . . . . . . . . .23 7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .23
10. References . . . . . . . . . . . . . . . . . . . . . . . . .23 7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .23
10.1. Normative References . . . . . . . . . . . . . . . . . .23 8. Security Considerations . . . . . . . . . . . . . . . . . . .23
10.2. Informative References . . . . . . . . . . . . . . . . .24 9. Contributing Authors. . . . . . . . . . . . . . . . . . . . .24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .26 10. References . . . . . . . . . . . . . . . . . . . . . . . . .24
10.1. Normative References . . . . . . . . . . . . . . . . . .24
10.2. Informative References . . . . . . . . . . . . . . . . .26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .28
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
A1. Implementation Status . . . . . . . . . . . . . . . . . . .29
A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .29
A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .31
A1.3. H-PCE Proof of Concept developed by Huawei . . . . . . .32
1. Introduction 1. Introduction
The Path Computation Element communication Protocol (PCEP) provides The Path Computation Element communication Protocol (PCEP) provides
a mechanism for Path Computation Elements (PCEs) and Path Computation a mechanism for Path Computation Elements (PCEs) and Path Computation
Clients (PCCs) to exchange requests for path computation and Clients (PCCs) to exchange requests for path computation and
responses that provide computed paths. 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)
skipping to change at page 5, line 28 skipping to change at page 5, line 37
The hierarchical relationship model is described in [RFC6805]. It is The hierarchical relationship model is described in [RFC6805]. It is
applicable to environments with small groups of domains where applicable to environments with small groups of domains where
visibility from the ingress LSRs is limited. As highlighted in visibility from the ingress LSRs is limited. As highlighted in
[RFC7399] applying the hierarchical PCE model to large groups of [RFC7399] applying the hierarchical PCE model to large groups of
domains such as the Internet is not considered feasible or desirable. 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Requirements for H-PCE 2. Requirements for H-PCE
skipping to change at page 6, line 13 skipping to change at page 6, line 23
message needs to include: message needs to include:
o Qualification of PCE Requests (Section 4.8.1. of [RFC6805]); o Qualification of PCE Requests (Section 4.8.1. of [RFC6805]);
o Multi-domain Objective Functions (OF); o Multi-domain Objective Functions (OF);
o Multi-domain Metrics. o Multi-domain Metrics.
2.1.1. Qualification of PCEP Requests 2.1.1. Qualification of PCEP Requests
As described in section 4.8.1 of [RFC6805], the H-PCE architecture As described in Section 4.8.1 of [RFC6805], the H-PCE architecture
introduces new request qualifications, which are: introduces new request qualifications, which are:
o The ability for a child PCE to indicate that a path computation o The ability for a child PCE to indicate that a path computation
request sent to a parent PCE should be satisfied by a domain request sent to a parent PCE should be satisfied by a domain
sequence only, that is, not by a full end-to-end path. This allows sequence only, that is, not by a full end-to-end path. This allows
the child PCE to initiate a per-domain (PD) [RFC5152] or a the child PCE to initiate a per-domain (PD) [RFC5152] or a
backward recursive path computation (BRPC) [RFC5441]. backward recursive path computation (BRPC) [RFC5441].
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. The PCC may also want to specify the destination domain request. The PCC may also want to specify the destination domain
information in a PCEP request, if it is known. information in a PCEP request, if it is known.
o An inter domain path computed by parent PCE should be capable of o An inter domain path computed by parent PCE should be capable of
disallowing specific domain re-entry. disallowing specific domain re-entry.
2.1.2. Multi-domain Objective Functions 2.1.2. Multi-domain Objective Functions
For H-PCE inter-domain path computation, there is three new Objective For H-PCE inter-domain path computation, there are three new
Functions defined in this document: Objective Functions defined in this document:
o Minimize the number of Transit Domains (MTD) o Minimize the number of Transit Domains (MTD)
o Minimize the number of border nodes (MBN) o Minimize the number of border nodes (MBN)
o Minimize the number of Common Transit Domains (MCTD) o Minimize the number of Common Transit Domains (MCTD)
The PCC may specify the multi-domain Objective Function code to The PCC may specify the multi-domain Objective Function code to
use when requesting inter-domain path computation, it may also use when requesting inter-domain path computation, it may also
include intra-domain OFs, such as Minimum Cost Path (MCP) [RFC5441], include intra-domain OFs, such as Minimum Cost Path (MCP) [RFC5441],
which must be considered by participating child PCEs. which must be considered by participating child PCEs.
skipping to change at page 7, line 10 skipping to change at page 7, line 19
o Domain count (number of domains crossed); o Domain count (number of domains crossed);
o Border Node count. o Border Node count.
A PCC may be able to limit the number of domains crossed by applying A PCC may be able to limit the number of domains crossed by applying
a limit on these metrics. Details in Section 3.4. a limit on these metrics. Details in Section 3.4.
2.2. Parent PCE Capability Advertisement 2.2. Parent PCE Capability Advertisement
A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes
Capability" TLV, described in Section 3.1.1, in the OPEN Object to to use the procedures described in this document must advertise
advertise its support for PCEP extensions for H-PCE Capability. the fact and negotiate its role with its PCEP peers. It does this
using the "H-PCE Capability" TLV, described in Section 3.2.1, in the
Parent and child PCE relationships are likely to be configured. OPEN Object to advertise its support for PCEP extensions for H-PCE
However, as mentioned in [RFC6805], it would assist network operators Capability.
if the child and parent PCEs could indicate their H-PCE capabilities.
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. parent PCE capability or not.
2.3. PCE Domain Identification 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.
skipping to change at page 8, line 10 skipping to change at page 8, line 17
In the case when full domain diversity could not be achieved, it is In the case when full domain diversity could not be achieved, it is
helpful to minimize the commonly shared domains. Also, it is helpful to minimize the commonly 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 commonly shared domains. etc.) can still be applied inside the commonly shared domains.
3. PCEP Extensions 3. PCEP Extensions
This section defines extensions to PCEP [RFC5440] to support the This section defines extensions to PCEP [RFC5440] to support the
H-PCE procedures. H-PCE procedures.
3.1. OPEN object 3.1 Applicability to PCC-PCE Communications
Although the extensions defined in this document are intended
primarily for use between a child PCE and a parent PCE, they are
also applicable for communications between a PCC and its PCE.
Thus, the information that may be encoded in a PCReq can be sent
from a PCC towards the child PCE. This includes the RP object
(Section 3.3) and the Objective Function (OF) codes and objects
(Section 3.4). A PCC and a child PCE could also exchange the
capability (Section 3.2.1) during its session.
This allows a PCC to request paths that transit multiple
domains utilizing the capabilities defined in this document.
3.2. 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 the PCEP session establishment, the OPEN object. This way, during the PCEP session establishment, the
H-PCE capability and Domain information can be advertised. H-PCE capability and Domain information can be advertised.
3.1.1. H-PCE Capability TLV 3.2.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 |
skipping to change at page 8, line 47 skipping to change at page 9, line 29
P (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.
Unassigned bits MUST be set to 0 on transmission and MUST be ignored Unassigned bits MUST be set to 0 on transmission and MUST be ignored
on receipt. on receipt.
The inclusion of this TLV in an OPEN object indicates that the H-PCE The inclusion of this TLV in an OPEN object indicates that the H-PCE
extensions are supported by the PCEP speaker. The child PCE MUST extensions are supported by the PCEP speaker. The child PCE MUST
include this TLV and set the P flag. The parent PCE MUST include include this TLV and set the P flag. The parent PCE MUST include
this TLV and unset the P flag. The PCC MUST include this TLV to this TLV and unset the P flag.
indicate that it understands the H-PCE extensions with P flag unset.
The setting of the P flag (parent PCE request bit) would mean that
the PCEP speaker wants the peer to be a parent PCE, so in the case
of a PCC to Child-PCE relationship, neither entity would set the P
flag.
If both peers attempt to set the P flag then the session If both peers attempt to set the P flag then the session
establishment MUST fail, and the PCEP speaker MUST respond with PCErr establishment MUST fail, and the PCEP speaker MUST respond with PCErr
message using Error-Type 1: "PCEP Session Establishment Failure" as message using Error-Type 1: "PCEP Session Establishment Failure" as
per [RFC5440]. per [RFC5440].
If the PCE understands the H-PCE path computation request but did not If the PCE understands the H-PCE path computation request but did not
advertise its H-PCE capability, it MUST send a PCErr message with 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").
3.1.1.1 Backwards Compatibility 3.2.1.1 Backwards Compatibility
If the PCE does not understand an H-PCE path computation request as Section 7.1 of [RFC5440] requires that "Unrecognized TLVs MUST be
specified in this document, the PCE will ignore the H-PCE related ignored.
parameters, and behave as per [RFC5440].
3.1.2. Domain-ID TLV That means that a PCE that does not support this document but that
receives an Open Message containing an Open Object that includes
an H-PCE-CAPABILITIES TLV will ignore that TLV and will continue to
attempt to establish a PCEP session. It will, however, not include
the TLV in the Open message that it sends, so the H-PCE relationship
will not be created.
If a PCE does not support the extensions defined in this document but
receives them in a PCEP message (notwithstanding the fact that the
session was not established as supporting a H-PCE relationship), the
receiving PCE will ignore the H-PCE related parameters because they
are all encoded in TLVs within standard PCEP objects.
3.2.2. Domain-ID TLV
The Domain-ID TLV when used in the OPEN object, identify the domains The Domain-ID TLV when used in the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 42 skipping to change at page 11, line 43
Figure 3: H-PCE-FLAG TLV format Figure 3: H-PCE-FLAG TLV format
The type of the TLV is TBD3 (to be assigned by IANA), and it has a The type of the TLV is TBD3 (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):
S (Domain Sequence bit): if set, will signal that the child PCE S (Domain Sequence bit): if set, will signal that the child PCE
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 to 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.
Unassigned bits MUST be set to 0 on transmission and MUST be ignored Unassigned bits MUST be set to 0 on transmission and MUST be ignored
on receipt. on receipt.
The presence of the TLV indicates that the H-PCE based path The presence of the TLV indicates that the H-PCE based path
computation is requested as per this document. computation is requested as per this document.
skipping to change at page 11, line 4 skipping to change at page 12, line 7
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.
Unassigned bits MUST be set to 0 on transmission and MUST be ignored Unassigned bits MUST be set to 0 on transmission and MUST be ignored
on receipt. on receipt.
The presence of the TLV indicates that the H-PCE based path The presence of the TLV indicates that the H-PCE based path
computation is requested as per this document. computation is requested as per this document.
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 an RP object, indicates the Section 3.3.1. 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 are 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 If a Domain-id TLV is used in the RP object, and the destination is
not actually in the indicated domain, then the parent not actually in the indicated domain, then the parent
PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV 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 should be used, and a new bit number is assigned to indicate
"Destination not found in the indicated domain" (see section 3.7). "Destination not found in the indicated domain" (see Section 3.7).
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. Three new Objective is used by a PCE when it computes a path. Three new Objective
Functions are defined for H-PCE, these are: Functions are defined for H-PCE, these are:
o MTD o MTD
skipping to change at page 12, line 48 skipping to change at page 13, line 50
+ A set of paths {P1...Pm} have L transit domains that are + A set of paths {P1...Pm} have L transit domains that are
common to more than one path {Dpi,(i=1...L)}. common to more than one path {Dpi,(i=1...L)}.
+ Find a set of paths such that the value of L is minimized. + 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 codes 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 path computation performed by the parent PCE, it is inter-domain path computation performed by the parent PCE, it is
also necessary to specify the OF code that may be applied for the also necessary to specify the OF code that may be applied for the
intra-domain path computation performed by the child PCE. To intra-domain path computation performed by the child PCE. To
accommodate this, the OF-List TLV (described in section 2.1. of accommodate this, the OF-List TLV (described in Section 2.1. of
[RFC5541]) is included in the OF object as an optional TLV. [RFC5541]) is included in the OF object as an optional TLV.
The OF-List TLV allows encoding of multiple OF codes. When this TLV The OF-List TLV allows encoding of multiple OF codes. When this TLV
is included inside the OF object, only the first OF-code in the is included inside the OF object, only the first OF-code in the
OF-LIST TLV is considered. The parent PCE MUST use this OF code in OF-LIST TLV is considered. The parent PCE MUST use this OF code in
the OF object when sending the intra domain path computation request the OF object when sending the intra domain path computation request
to the child PCE. If the OF list TLV is included in the OF Object, 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 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 Objective Functions defined in this document, the OF Code inside the
OF List TLV MUST NOT include an H-PCE Objective Function. If this OF List TLV MUST NOT include an H-PCE Objective Function. If this
condition is not met, the PCEP speaker MUST respond with a PCErr condition is not met, the PCEP speaker MUST respond with a PCErr
message with Error-Type=10 (Reception of an invalid object) and message with Error-Type=10 (Reception of an invalid object) and
Error-Value=TBD15 (Incompatible OF codes in H-PCE). Error-Value=TBD15 (Incompatible OF codes in H-PCE).
If the Objective Functions defined in this document are unknown or If the Objective Functions defined in this document are unknown or
unsupported by a PCE, then the procedure as defined in [RFC5541] unsupported by a PCE, then the procedure as defined in [RFC5541]
is followed. is 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
of metric-value, metric-type (T field) and flags. This document of metric-value, metric-type (T field) and flags. This document
defines the following types for the METRIC object for H-PCE: defines 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. If the METRIC object encodes the number of border nodes in the path. If
skipping to change at line 1262 skipping to change at page 29, line 17
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 should 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. 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. 29 change blocks. 
80 lines changed or deleted 118 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/