draft-ietf-pce-applicability-actn-08.txt   draft-ietf-pce-applicability-actn-09.txt 
PCE Working Group D. Dhody PCE Working Group D. Dhody
Internet-Draft Y. Lee Internet-Draft Y. Lee
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: June 8, 2019 D. Ceccarelli Expires: September 8, 2019 D. Ceccarelli
Ericsson Ericsson
December 5, 2018 March 7, 2019
Applicability of Path Computation Element (PCE) for Abstraction and Applicability of the Path Computation Element (PCE) to the Abstraction
Control of TE Networks (ACTN) and Control of TE Networks (ACTN)
draft-ietf-pce-applicability-actn-08 draft-ietf-pce-applicability-actn-09
Abstract Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network (VN) operations needed to orchestrate, control and virtual network (VN) operations needed to orchestrate, control and
manage large-scale multi-domain TE networks so as to facilitate manage large-scale multi-domain TE networks so as to facilitate
network programmability, automation, efficient resource sharing, and network programmability, automation, efficient resource sharing, and
end-to-end virtual service aware connectivity and network function end-to-end virtual service aware connectivity and network function
virtualization services. virtualization services.
The Path Computation Element (PCE) is component, application, or The Path Computation Element (PCE) is a component, application, or
network node that is capable of computing a network path or route network node that is capable of computing a network path or route
based on a network graph and applying computational constraints. The based on a network graph and applying computational constraints. The
PCE serves requests from Path Computation Clients (PCCs) that PCE serves requests from Path Computation Clients (PCCs) that
communicate with it over a local API or using the Path Computation communicate with it over a local API or using the Path Computation
Element Communication Protocol (PCEP). Element Communication Protocol (PCEP).
This document examines the applicability of PCE to the ACTN This document examines the applicability of PCE to the ACTN
framework. framework.
Status of This Memo Status of This Memo
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 8, 2019. This Internet-Draft will expire on September 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Background Information . . . . . . . . . . . . . . . . . . . 2
1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2 1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2
1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3 1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3
1.1.2. PCE in Multi-domain and Multi-layer Deployments . . . 4 1.1.2. PCE in Multi-domain and Multi-layer Deployments . . . 4
1.1.3. Relationship to PCE Based Central Control . . . . . . 4 1.1.3. Relationship to PCE Based Central Control . . . . . . 4
1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Architectural Considerations . . . . . . . . . . . . . . . . 7 3. Architectural Considerations . . . . . . . . . . . . . . . . 7
2.1. Multi Domain Coordination via Hierarchy . . . . . . . . . 7 3.1. Multi-Domain Coordination via Hierarchy . . . . . . . . . 8
2.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9 3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
3. Interface Considerations . . . . . . . . . . . . . . . . . . 10 4. Interface Considerations . . . . . . . . . . . . . . . . . . 11
4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Additional Information . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Background Information
1.1. Path Computation Element (PCE) 1.1. Path Computation Element (PCE)
The Path Computation Element Communication Protocol (PCEP) [RFC5440] The Path Computation Element Communication Protocol (PCEP) [RFC5440]
provides mechanisms for Path Computation Clients (PCCs) to request a provides mechanisms for Path Computation Clients (PCCs) to request a
Path Computation Element (PCE) [RFC4655] to perform path Path Computation Element (PCE) [RFC4655] to perform path
computations. computations.
The ability to compute shortest constrained TE LSPs in Multiprotocol The ability to compute shortest constrained TE LSPs in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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
Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the
domain sequence is not known. Within the Hierarchical PCE (H-PCE) domain sequence is not known. Within the Hierarchical PCE (H-PCE)
architecture, the Parent PCE (P-PCE) is used to compute a multi- architecture, the Parent PCE (P-PCE) is used to compute a multi-
domain path based on the domain connectivity information. A Child domain path based on the domain connectivity information. A Child
PCE (C-PCE) may be responsible for a single domain or multiple PCE (C-PCE) may be responsible for a single domain or multiple
domains, it is used to compute the intra-domain path based on its domains, it is used to compute the intra-domain path based on its
domain topology information. domain topology information.
[I-D.ietf-pce-stateful-hpce] state the considerations for stateful [I-D.ietf-pce-stateful-hpce] state the considerations for stateful
PCE(s) in hierarchical PCE architecture. In particular, the behavior PCEs in hierarchical PCE architecture. In particular, the behavior
changes and additions to the existing stateful PCE mechanisms changes and additions to the existing stateful PCE mechanisms
(including PCE- initiated LSP setup and active PCE usage) in the (including PCE- initiated LSP setup and active PCE usage) in the
context of networks using the H-PCE architecture. context of networks using the H-PCE architecture.
[RFC5623] describes a framework for applying the PCE-based [RFC5623] describes a framework for applying the PCE-based
architecture to inter-layer to (G)MPLS TE. It provides suggestions architecture to inter-layer to (G)MPLS TE. It provides suggestions
for the deployment of PCE in support of multi-layer networks. It for the deployment of PCE in support of multi-layer networks. It
also describes the relationship between PCE and a functional also describes the relationship between PCE and a functional
component in charge of the control and management of the Virtual component in charge of the control and management of the Virtual
Network Topology (VNT) [RFC5212], called the VNT Manager (VNTM). Network Topology (VNT) [RFC5212], called the VNT Manager (VNTM).
1.1.3. Relationship to PCE Based Central Control 1.1.3. Relationship to PCE Based Central Control
[RFC8283] introduces the architecture for PCE as a central controller [RFC8283] introduces the architecture for PCE as a central controller
(PCECC), it further examines the motivations and applicability for (PCECC), it further examines the motivations and applicability for
PCEP as a southbound interface, and introduces the implications for PCEP as a southbound interface, and introduces the implications for
the protocol. The section 2.1.3 of [RFC8283] describe a hierarchy of the protocol. Section 2.1.3 of [RFC8283] describe a hierarchy of
PCE-based controller as per the Hierarchy of PCE framework defined in PCE-based controller as per the Hierarchy of PCE framework defined in
[RFC6805]. [RFC6805].
1.2. Abstraction and Control of TE Networks (ACTN) 1.2. Abstraction and Control of TE Networks (ACTN)
[RFC8453] describes the high-level ACTN requirements and the [RFC8453] describes the high-level ACTN requirements and the
architecture model for ACTN including the following entities: architecture model for ACTN including the entities Customer Network
Customer Network Controller(CNC), Multi-domain Service Controller (CNC), Multi-domain Service Coordinator (MDSC), and
Coordinator(MDSC), and Provisioning Network Controller (PNC) and Provisioning Network Controller (PNC) and their interfaces.
their interfaces.
The ACTN reference architecture identified a three-tier control The ACTN reference architecture is shown in Figure 1 which is
hierarchy as depicted in Figure 1: reproduced here from [RFC8453] for convenience. [RFC8453] remains
the definitive reference for the ACTN architecture. As depicted in
Figure 1, the ACTN architecture identifies a three-tier hierarchy.
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| CNC | | CNC | | CNC | | CNC | | CNC | | CNC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
\ | / \ | /
\ | / \ | /
Boundary =============\==============|==============/============ Boundary =============\==============|==============/============
Between \ | / Between \ | /
Customer & ------- | CMI ------- Customer & ------- | CMI -------
Network Operator \ | / Network Operator \ | /
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Figure 1: ACTN Hierarchy Figure 1: ACTN Hierarchy
There are two interfaces with respect to the MDSC: one north of the There are two interfaces with respect to the MDSC: one north of the
MDSC (the CNC-MDSC Interface : CMI), and one south (the MDSC-PNC MDSC (the CNC-MDSC Interface : CMI), and one south (the MDSC-PNC
Interface : MPI). A hierarchy of MDSCs is possible with a recursive Interface : MPI). A hierarchy of MDSCs is possible with a recursive
MPI interface. MPI interface.
[RFC8454] provides an information model for ACTN interfaces. [RFC8454] provides an information model for ACTN interfaces.
1.3. PCE and ACTN 2. Introduction
Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network (VN) operations needed to orchestrate, control and
manage large-scale multi-domain TE networks so as to facilitate
network programmability, automation, efficient resource sharing, and
end-to-end virtual service aware connectivity and network function
virtualization services.
The Path Computation Element (PCE) is a component, application, or
network node that is capable of computing a network path or route
based on a network graph and applying computational constraints. The
PCE serves requests from Path Computation Clients (PCCs) that
communicate with it over a local API or using the Path Computation
Element Communication Protocol (PCEP).
This document examines the PCE and ACTN architecture and describes This document examines the PCE and ACTN architecture and describes
how the PCE architecture is applicable to ACTN. It also lists the how PCE architecture is applicable to ACTN. It also lists the PCEP
PCEP extensions that are needed to use PCEP as an ACTN interface. extensions that are needed to use PCEP as an ACTN interface. This
This document also identifies any gaps in PCEP, that exist at the document also identifies any gaps in PCEP, that exist at the time of
time of publication of this document. publication of this document.
Further, ACTN, Stateful H-PCE, and PCECC are based on the same basic Further, ACTN, stateful H-PCE, and PCECC are based on the same basic
hierarchy framework and thus compatible with each other. hierarchy framework and thus compatible with each other.
2. Architectural Considerations 3. Architectural Considerations
ACTN [RFC8453] architecture is based on hierarchy and recursiveness The ACTN architecture [RFC8453] is based on hierarchy and
of controllers. It defines three types of controllers (depending on recursiveness of controllers. It defines three types of controllers
the functionalities they implement). The main functionalities are - (depending on the functionalities they implement). The main
functionalities are -
o Multi domain coordination o Multi-domain coordination
o Abstraction o Abstraction
o Customer mapping/translation o Customer mapping/translation
o Virtual service coordination o Virtual service coordination
Section 3 of [RFC8453] describes these functions. Section 3 of [RFC8453] describes these functions.
It should be noted that, this document lists all possible ways in It should be noted that this document lists all possible ways in
which PCE could be used for each of the above functions, but all which PCE could be used for each of the above functions, but all
functions are not required to be implemented via PCE. Similarly, functions are not required to be implemented via PCE. Similarly,
this document presents the ways in which PCEP could be used as the this document presents the ways in which PCEP could be used as the
communications medium between funcitonl components. Operator may communications medium between functional components. Operators may
choose to use the PCEP for multi domain coordination via stateful choose to use the PCEP for multi-domain coordination via stateful
H-PCE, but alternatively use RESTCONF [RFC8040] or BGP-LS [RFC7752] H-PCE, but alternatively use RESTCONF [RFC8040] or BGP-LS [RFC7752]
to get access to the topology and support abstraction function. to get access to the topology and support abstraction function.
2.1. Multi Domain Coordination via Hierarchy 3.1. Multi-Domain Coordination via Hierarchy
With the definition of domain being "everything that is under the With the definition of domain being "everything that is under the
control of the single logical controller", as per [RFC8453], it is control of the single logical controller", as per [RFC8453], it is
needed to have a control entity that oversees the specific aspects of needed to have a control entity that oversees the specific aspects of
the different domains and to build a single abstracted end-to-end the different domains and to build a single abstracted end-to-end
network topology in order to coordinate end-to-end path computation network topology in order to coordinate end-to-end path computation
and path/service provisioning. and path/service provisioning.
The MDSC in ACTN framework realizes this function by coordinating the The MDSC in ACTN framework realizes this function by coordinating the
per-domain PNCs in a hierarchy of controllers. It also needs to per-domain PNCs in a hierarchy of controllers. It also needs to
detach from the underlying network technology and express customer detach from the underlying network technology and express customer
concerns by business needs. concerns by business needs.
[RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of [RFC6805] and [I-D.ietf-pce-stateful-hpce] describe a hierarchy of
PCE with Parent PCE coordinating multi-domain path computation PCEs with the Parent PCE coordinating multi-domain path computation
function between Child PCE(s). It is easy to see how these function between Child PCEs. It is easy to see how these principles
principles align, and thus how stateful H-PCE architecture can be align, and thus how the stateful H-PCE architecture can be used to
used to realize ACTN. realize ACTN.
The Per domain stitched LSP in the Hierarchical stateful PCE The per domain stitched LSP in the Hierarchical stateful PCE
architecture, described in Section 3.3.1 of architecture, described in Section 3.3.1 of
[I-D.ietf-pce-stateful-hpce] is well suited for multi-domain [I-D.ietf-pce-stateful-hpce] is well suited for multi-domain
coordination function. This includes domain sequence selection; End- coordination function. This includes domain sequence selection; End-
to-End (E2E) path computation; Controller (PCE) initiated path setup to-End (E2E) path computation; Controller (PCE) initiated path setup
and reporting. This is also applicable to multi-layer coordination and reporting. This is also applicable to multi-layer coordination
in case of IP+optical networks. in case of IP+optical networks.
[I-D.litkowski-pce-state-sync] describes the procedures to allow a [I-D.litkowski-pce-state-sync] describes the procedures to allow a
stateful communication between PCEs for various use-cases. The stateful communication between PCEs for various use-cases. The
procedures and extensions are also applicable to Child and Parent PCE procedures and extensions are also applicable to Child and Parent PCE
communication and thus useful for ACTN as well. communication and thus useful for ACTN as well.
2.2. Abstraction 3.2. Abstraction
To realize ACTN, an abstracted view of the underlying network To realize ACTN, an abstracted view of the underlying network
resources needs to be built. This includes global network-wide resources needs to be built. This includes global network-wide
abstracted topology based on the underlying network resources of each abstracted topology based on the underlying network resources of each
domain. This also includes the abstract topology created as per the domain. This also includes abstract topology created as per the
customer service connectivity requests and represented as a network customer service connectivity requests and represented as a VN slice
slice allocated to each customer. allocated to each customer.
In order to compute and provide optimal paths, PCEs require an In order to compute and provide optimal paths, PCEs require an
accurate and timely Traffic Engineering Database (TED). accurate and timely Traffic Engineering Database (TED).
Traditionally this TED has been obtained from a link state (LS) Traditionally this TED has been obtained from a link state (LS)
routing protocol supporting traffic engineering extensions. PCE may routing protocol supporting traffic engineering extensions. PCE may
construct its TED by participating in the IGP ([RFC3630] and construct its TED by participating in the IGP ([RFC3630] and
[RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An
alternative is offered by BGP-LS [RFC7752]. alternative is offered by BGP-LS [RFC7752].
In case of H-PCE [RFC6805], the parent PCE needs to build the domain In case of H-PCE [RFC6805], the Parent PCE needs to build the domain
topology map of the child domains and their interconnectivity. topology map of the child domains and their interconnectivity.
[RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that [RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that
BGP-LS could be used as a "northbound" TE advertisement from the BGP-LS could be used as a "northbound" TE advertisement from the
child PCE to the parent PCE. Child PCE to the Parent PCE.
[I-D.dhodylee-pce-pcep-ls] proposes another approach for learning [I-D.dhodylee-pce-pcep-ls] proposes another approach for learning and
and maintaining the Link-State and TE information as an alternative maintaining the Link-State and TE information as an alternative to
to IGPs and BGP flooding, using PCEP itself. The child PCE can use IGPs and BGP flooding, using PCEP itself. The Child PCE can use this
this mechanism to transport Link-State and TE information from child mechanism to transport Link-State and TE information from Child PCE
PCE to a Parent PCE using PCEP. to a Parent PCE using PCEP.
In ACTN, there is a need to control the level of abstraction based on In ACTN, there is a need to control the level of abstraction based on
the deployment scenario and business relationship between the the deployment scenario and business relationship between the
controllers. The mechanism used to disseminate information from PNC controllers. The mechanism used to disseminate information from PNC
(child PCE) to MDSC (parent PCE) should support abstraction. (Child PCE) to MDSC (Parent PCE) should support abstraction.
[RFC8453] describes a few alternative approaches of abstraction. The [RFC8453] describes a few alternative approaches of abstraction. The
resulting abstracted topology can be encoded using the PCEP-LS resulting abstracted topology can be encoded using the PCEP-LS
mechanisms [I-D.dhodylee-pce-pcep-ls] and its optical network mechanisms [I-D.dhodylee-pce-pcep-ls] and its optical network
extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is an attractive extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is an attractive
option when the operator would wish to have a single control plane option when the operator would wish to have a single control plane
protocol (PCEP) to achieve ACTN functions. protocol (PCEP) to achieve ACTN functions.
[RFC8453] discusses two ways to build abstract topology from an MDSC [RFC8453] discusses two ways to build abstract topology from an MDSC
standpoint with interaction with PNCs. The primary method is called standpoint with interaction with PNCs. The primary method is called
automatic generation of abstract topology by configuration. With automatic generation of abstract topology by configuration. With
this method, automatic generation is based on the abstraction/ this method, automatic generation is based on the abstraction/
summarization of the whole domain by the PNC and its advertisement on summarization of the whole domain by the PNC and its advertisement on
the MPI. The secondary method is called on-demand generation of the MPI. The secondary method is called on-demand generation of
supplementary topology via Path Compute Request/Reply. This method supplementary topology via Path Compute Request/Reply. This method
may be needed to obtain further complementary information such as may be needed to obtain further complementary information such as
potential connectivity from child PCEs in order to facilitate an end- potential connectivity from Child PCEs in order to facilitate an end-
to-end path provisioning. PCEP is well suited to support both to-end path provisioning. PCEP is well suited to support both
methods. methods.
2.3. Customer Mapping 3.3. Customer Mapping
In ACTN, there is a need to map customer virtual network (VN) In ACTN, there is a need to map customer virtual network (VN)
requirements into network provisioning request to the PNC. That is, requirements into a network provisioning request to the PNC. That
the customer requests/commands are mapped into network provisioning is, the customer requests/commands are mapped by the MDSC into
requests that can be sent to the PNC. Specifically, it provides network provisioning requests that can be sent to the PNC.
mapping and translation of a customer's service request into a set of Specifically, the MDSC provides mapping and translation of a
parameters that are specific to a network type and technology such customer's service request into a set of parameters that are specific
that network configuration process is made possible. to a network type and technology such that network configuration
process is made possible.
[RFC8281] describes the setup, maintenance and teardown of PCE- [RFC8281] describes the setup, maintenance and teardown of PCE-
initiated LSPs under the stateful PCE model, without the need for initiated LSPs under the stateful PCE model, without the need for
local configuration on the PCC, thus allowing for a dynamic network local configuration on the PCC, thus allowing for a dynamic network
that is centrally controlled and deployed. To instantiate or delete that is centrally controlled and deployed. To instantiate or delete
an LSP, the PCE sends the Path Computation LSP Initiate Request an LSP, the PCE sends the Path Computation LSP Initiate Request
(PCInitiate) message to the PCC. As described in (PCInitiate) message to the PCC. As described in
[I-D.ietf-pce-stateful-hpce], for inter-domain LSP in Hierarchical [I-D.ietf-pce-stateful-hpce], for inter-domain LSP in Hierarchical
PCE architecture, the initiation operations can be carried out at the PCE architecture, the initiation operations can be carried out at the
parent PCE. In which case, after parent PCE finishes the E2E path Parent PCE. In which case, after Parent PCE finishes the E2E path
computation, it can send the PCInitiate message to the child PCE, the computation, it can send the PCInitiate message to the Child PCE, the
child PCE further propagates the initiate request to the Label Child PCE further propagates the initiate request to the Label
Switching Router (LSR). The customer request is received by the MDSC Switching Router (LSR). The customer request is received by the MDSC
(parent PCE) and based on the business logic, global abstracted (Parent PCE) and based on the business logic, global abstracted
topology, network conditions and local policy, the MDSC (parent PCE) topology, network conditions and local policy, the MDSC (Parent PCE)
translates this into per domain LSP initiation request that a PNC translates this into per domain LSP initiation request that a PNC
(child PCE) can understand and act on. This can be done via the (Child PCE) can understand and act on. This can be done via the
PCInitiate message. PCInitiate message.
PCEP extensions for associating opaque policy between PCEP peer PCEP extensions for associating opaque policy between PCEP peer
[I-D.ietf-pce-association-policy] can be used. [I-D.ietf-pce-association-policy] can be used.
2.4. Virtual Service Coordination 3.4. Virtual Service Coordination
Virtual service coordination function in ACTN incorporates customer Virtual service coordination function in ACTN incorporates customer
service-related information into the virtual network service service-related information into the virtual network service
operations in order to seamlessly operate virtual networks while operations in order to seamlessly operate virtual networks while
meeting customer's service requirements. meeting customer's service requirements.
[I-D.leedhody-pce-vn-association] describes the need for associating [I-D.leedhody-pce-vn-association] describes the need for associating
a set of LSPs with a VN "construct" to facilitate VN operations in a set of LSPs with a VN "construct" to facilitate VN operations in
PCE architecture. This association allows the PCEs to identify which PCE architecture. This association allows the PCEs to identify which
LSPs belong to a certain VN. LSPs belong to a certain VN.
skipping to change at page 10, line 35 skipping to change at page 11, line 5
This association based on VN is useful for various optimizations at This association based on VN is useful for various optimizations at
the VN level which can be applied to all the LSPs that are part of the VN level which can be applied to all the LSPs that are part of
the VN slice. During path computation, the impact of a path for an the VN slice. During path computation, the impact of a path for an
LSP is compared against the paths of other LSPs in the VN. This is LSP is compared against the paths of other LSPs in the VN. This is
to make sure that the overall optimization and SLA of the VN rather to make sure that the overall optimization and SLA of the VN rather
than of a single LSP. Similarly, during re-optimization, advanced than of a single LSP. Similarly, during re-optimization, advanced
path computation algorithm and optimization technique can be path computation algorithm and optimization technique can be
considered for all the LSPs belonging to a VN/customer and optimize considered for all the LSPs belonging to a VN/customer and optimize
them all together. them all together.
3. Interface Considerations 4. Interface Considerations
As per [RFC8453], to allow virtualization and multi domain As per [RFC8453], to allow virtualization and multi-domain
coordination, the network has to provide open, programmable coordination, the network has to provide open, programmable
interfaces, in which customer applications can create, replace and interfaces, in which customer applications can create, replace and
modify virtual network resources and services in an interactive, modify virtual network resources and services in an interactive,
flexible and dynamic fashion while having no impact on other flexible and dynamic fashion while having no impact on other
customers. The two ACTN interfaces are - customers. The two ACTN interfaces are -
o The CNC-MDSC Interface (CMI) is an interface between a Customer o The CNC-MDSC Interface (CMI) is an interface between a Customer
Network Controller and a Multi Domain Service Coordinator. It Network Controller and a Multi-Domain Service Coordinator. It
requests the creation of the network resources, topology or requests the creation of the network resources, topology or
services for the applications. The MDSC may also report potential services for the applications. The MDSC may also report potential
network topology availability if queried for current capability network topology availability if queried for current capability
from the Customer Network Controller. from the Customer Network Controller.
o The MDSC-PNC Interface (MPI) is an interface between a Multi o The MDSC-PNC Interface (MPI) is an interface between a Multi-
Domain Service Coordinator and a Provisioning Network Controller. Domain Service Coordinator and a Provisioning Network Controller.
It communicates the creation request, if required, of new It communicates the creation request, if required, of new
connectivity of bandwidth changes in the physical network, via the connectivity of bandwidth changes in the physical network, via the
PNC. In multi-domain environments, the MDSC needs to establish PNC. In multi-domain environments, the MDSC needs to establish
multiple MPIs, one for each PNC, as there are multiple PNCs multiple MPIs, one for each PNC, as there are multiple PNCs
responsible for its domain control. responsible for its domain control.
In case of hierarchy of MDSC, the MPI is applied recursively. From In the case of hierarchy MDSCs, the MPI is applied recursively. From
an abstraction point of view, the top level MDSC which interfaces the an abstraction point of view, the top level MDSC which interfaces the
CNC operates on a higher level of abstraction (i.e., less granular CNC operates on a higher level of abstraction (i.e., less granular
level) than the lower level MSDCs. level) than the lower level MSDCs.
PCEP is especially suitable on the MPI as it meets the requirement PCEP is especially suitable on the MPI as it meets the requirement
and the functions as set out in the ACTN framework [RFC8453]. Its and the functions as set out in the ACTN framework [RFC8453]. Its
recursive nature is well suited via the multi-level hierarchy of PCE. recursive nature is well suited via the multi-level hierarchy of PCE.
PCEP can also be applied to the CMI as the CNC can be a path PCEP can also be applied to the CMI as the CNC can be a path
computation client while the MDSC can be a path computation server. computation client while the MDSC can be a path computation server.
The Section 4 describes how PCE and PCEP could help realize ACTN on Section 5 describes how PCE and PCEP could help realize ACTN on the
the MPI. MPI.
4. Realizing ACTN with PCE (and PCEP) 5. Realizing ACTN with PCE (and PCEP)
As per the example in the Figure 2, there are 4 domains, each with As per the example in Figure 2, there are 4 domains, each with its
its own PNC and a MDSC at top. The PNC and MDSC need PCE as a own PNC and an MDSC on top. The PNC and MDSC need PCE as a important
important function. The PNC (or child PCE) already uses PCEP to function. The PNC (or Child PCE) already uses PCEP to communicate to
communicate to the network device. It can utilize the PCEP as the the network device. It can utilize the PCEP as the MPI to
MPI to communicate between controllers too. communicate between controllers too.
****** ******
..........*MDSC*.............................. ..........*MDSC*..............................
. ****** .. MPI . . ****** .. MPI .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
skipping to change at page 12, line 39 skipping to change at page 12, line 39
| | | |
|DOMAIN 3 B| |DOMAIN 3 B|
+---------------+ +---------------+
MDSC -> Parent PCE MDSC -> Parent PCE
PNC -> Child PCE PNC -> Child PCE
MPI -> PCEP MPI -> PCEP
Figure 2: ACTN with PCE Figure 2: ACTN with PCE
o Building Domain Topology at MDSC: PNC (or child PCE) needs to have o Building Domain Topology at MDSC: PNC (or Child PCE) needs to have
the TED to compute path in its domain. As described in the TED to compute path in its domain. As described in
Section 2.2, it can learn the topology via IGP or BGP-LS. PCEP-LS Section 3.2, it can learn the topology via IGP or BGP-LS. PCEP-LS
is also a proposed mechanism to carry link state and traffic is also a proposed mechanism to carry link state and traffic
engineering information within PCEP. A mechanism to carry engineering information within PCEP. A mechanism to carry
abstracted topology while hiding technology specific information abstracted topology while hiding technology specific information
between PNC and MDSC is described in [I-D.dhodylee-pce-pcep-ls]. between PNC and MDSC is described in [I-D.dhodylee-pce-pcep-ls].
At the end of this step the MDSC (or parent PCE) has the At the end of this step the MDSC (or Parent PCE) has the
abstracted topology from each of its PNC (or child PCE). This abstracted topology from each of its PNC (or Child PCE). This
could be as simple as a domain topology map as described in could be as simple as a domain topology map as described in
[RFC6805] or it can have full topology information of all domains. [RFC6805] or it can have full topology information of all domains.
The latter is not scalable and thus an abstracted topology of each The latter is not scalable and thus an abstracted topology of each
domain interconnected by inter-domain links is the most common domain interconnected by inter-domain links is the most common
case. case.
* Topology Change: When the PNC learns of any topology change, * Topology Change: When the PNC learns of any topology change,
the PNC needs to decide if the change needs to be notified to the PNC needs to decide if the change needs to be notified to
the MDSC. This is dependent on the level of abstraction the MDSC. This is dependent on the level of abstraction
between the MDSC and the PNC. between the MDSC and the PNC.
o VN Instantiate: MDSC is requested to instantiate a VN, the minimal o VN Instantiate: When an MDSC is requested to instantiate a VN, the
information that is required would be a VN identifier and a set of minimal information that is required would be a VN identifier and
end points. Various path computation, setup constraints and a set of end points. Various path computation, setup constraints
objective functions may also be provided. In PCE terms, a VN and objective functions may also be provided. In PCE terms, a VN
Instantiate can be considered as a set of paths belonging to the Instantiate can be considered as a set of paths belonging to the
same VN. As described in Section 2.4 and same VN. As described in Section 3.4 and
[I-D.leedhody-pce-vn-association] the VN association can help in [I-D.leedhody-pce-vn-association] the VN association can help in
identifying the set of paths that belong to a VN. The rest of the identifying the set of paths that belong to a VN. The rest of the
information like the endpoints, constraints and objective function information like the endpoints, constraints and objective function
(OF) is already defined in PCEP in terms of a single path. (OF) is already defined in PCEP in terms of a single path.
* Path Computation: As per the example in the Figure 2, the VN * Path Computation: As per the example in Figure 2, the VN
instantiate requires two end to end paths between (A in Domain instantiate requires two end to end paths between (A in Domain
1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The
MDSC (or parent PCE) triggers the end to end path computation MDSC (or Parent PCE) triggers the end to end path computation
for these two paths. MDSC can do path computation based on the for these two paths. MDSC can do path computation based on the
abstracted domain topology that it already has or it may use abstracted domain topology that it already has or it may use
the H-PCE procedures (Section 2.1) using the PCReq and PCRep the H-PCE procedures (Section 3.1) using the PCReq and PCRep
messages to get the end to end path with the help of the child messages to get the end to end path with the help of the Child
PCEs (PNC). Either way, the resultant E2E paths may be broken PCEs (PNC). Either way, the resultant E2E paths may be broken
into per-domain paths. into per-domain paths.
* A-B: (A-B13,B13-B31,B31-B) * A-B: (A-B13,B13-B31,B31-B)
* A-C: (A-B13,B13-B31,B34-B43,B43-C) * A-C: (A-B13,B13-B31,B34-B43,B43-C)
* Per Domain Path Instantiation: Based on the above path * Per Domain Path Instantiation: Based on the above path
computation, MDSC can issue the path instantiation request to computation, MDSC can issue the path instantiation request to
each PNC via PCInitiate message (see each PNC via PCInitiate message (see
[I-D.ietf-pce-stateful-hpce] and [I-D.ietf-pce-stateful-hpce] and
[I-D.leedhody-pce-vn-association]). A suitable stitching [I-D.leedhody-pce-vn-association]). A suitable stitching
mechanism would be used to stitch these per domain LSPs. One mechanism would be used to stitch these per domain LSPs. One
such mechanism is described in such mechanism is described in
[I-D.lee-pce-lsp-stitching-hpce], where PCEP is extended to [I-D.dugeon-pce-stateful-interdomain], where PCEP is extended
support stitching in stateful H-PCE context. to support stitching in stateful H-PCE context.
* Per Domain Path Report: Each PNC should report the status of * Per Domain Path Report: Each PNC should report the status of
the per-domain LSP to the MDSC via PCRpt message, as per the the per-domain LSP to the MDSC via PCRpt message, as per the
Hierarchy of stateful PCE ([I-D.ietf-pce-stateful-hpce]). The Hierarchy of stateful PCE ([I-D.ietf-pce-stateful-hpce]). The
status of the end to end LSP (A-B and A-C) is made up when all status of the end to end LSP (A-B and A-C) is made up when all
the per domain LSP are reported up by the PNCs. the per domain LSP are reported up by the PNCs.
* Delegation: It is suggested that the per domain LSPs are * Delegation: It is suggested that the per domain LSPs are
delegated to respective PNC, so that they can control the path delegated to respective PNC, so that they can control the path
and attributes based on each domain network conditions. and attributes based on each domain network conditions.
* State Synchronization: The state needs to be synchronized * State Synchronization: The state needs to be synchronized
between the parent PCE and child PCE. The mechanism described between the Parent PCE and Child PCE. The mechanism described
in [I-D.litkowski-pce-state-sync] can be used. in [I-D.litkowski-pce-state-sync] can be used.
o VN Modify: MDSC is requested to modify a VN, for example the o VN Modify: MDSC is requested to modify a VN, for example the
bandwidth for VN is increased. This may trigger path computation bandwidth for VN is increased. This may trigger path computation
at MDSC as described in the previous step and can trigger an at MDSC as described in the previous step and can trigger an
update to existing per-intra-domain path (via PCUpd message) or update to existing per-intra-domain path (via PCUpd message) or
creation (or deletion) of a per-domain path (via PCInitiate creation (or deletion) of a per-domain path (via PCInitiate
message). As described in [I-D.ietf-pce-stateful-hpce], this message). As described in [I-D.ietf-pce-stateful-hpce], this
should be done in make-before-break fashion. should be done in make-before-break fashion.
o VN Delete: MDSC is requested to delete a VN, in this case, based o VN Delete: MDSC is requested to delete a VN, in this case, based
on the E2E paths and the resulting per-domain paths need to be on the E2E paths and the resulting per-domain paths need to be
removed (via PCInitiate message). removed (via PCInitiate message).
o VN Update (based on network changes): Any change in the per-domain o VN Update (based on network changes): Any change in the per-domain
LSP are reported to the MDSC (via PCRpt message) as per LSP is reported to the MDSC (via PCRpt message) as per
[I-D.ietf-pce-stateful-hpce]. This may result in changes in the [I-D.ietf-pce-stateful-hpce]. This may result in changes in the
E2E path or VN status. This may also trigger a re-optimization E2E path or VN status. This may also trigger a re-optimization
leading to a new per-domain path, update to existing path, or leading to a new per-domain path, update to existing path, or
deletion of the path. deletion of the path.
o VN Protection: The VN protection/restoration requirements, need to o VN Protection: The VN protection/restoration requirements, need to
applied to each E2E path as well as each per domain path. The applied to each E2E path as well as each per domain path. The
MDSC needs to play a crucial role in coordinating the right MDSC needs to play a crucial role in coordinating the right
protection/restoration policy across each PNC. The existing protection/restoration policy across each PNC. The existing
protection/restoration mechanism of PCEP can be applied on each protection/restoration mechanism of PCEP can be applied on each
path. path.
o In case PNC generates an abstract topology to the MDSC, the o In case PNC generates an abstract topology to the MDSC, the
PCInitiate/PCUpd messages from the MDSC to a PNC will contain a PCInitiate/PCUpd messages from the MDSC to a PNC will contain a
path with abstract nodes and links. PNC would need to take that path with abstract nodes and links. PNC would need to take that
as an input for path computation to get a path with physical nodes as an input for path computation to get a path with physical nodes
and links. Similarly PNC would convert the path received from the and links. Similarly, a PNC would convert the path received from
device (with physical nodes and links) into abstract path (based the device (with physical nodes and links) into abstract path
on the abstract topology generated before with abstract nodes and (based on the abstract topology generated before with abstract
links) and reported to the MDSC. nodes and links) and reported to the MDSC.
5. IANA Considerations 6. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
6. Security Considerations 7. Security Considerations
Various security considerations for PCEP are described in [RFC5440],
[RFC6952], and [RFC8253]. Further, this document lists various
extensions of PCEP that are applicable, each of them specify various
security considerations which continue to apply here.
The ACTN framework described in [RFC8453] defines key components and The ACTN framework described in [RFC8453] defines key components and
interfaces for managed traffic engineered networks. It also list interfaces for managed traffic engineered networks. It also lists
various security considerations such as request and control of various security considerations such as request and control of
resources, confidentially of the information, and availability of resources, confidentially of the information, and availability of
function which should be taken into consideration. function which should be taken into consideration.
When PCEP is used on the MPI, this interface needs to be secured. As per [RFC8453], securing the request and control of resources,
That can be achieved using the procdecures described in [RFC8253]. confidentiality of the information, and availability of function
Each PCEP extension listed in this document, presents its individual should all be critical security considerations when deploying and
security considerations, which continue to apply. operating ACTN platforms. From a security and reliability
perspective, ACTN may encounter many risks such as malicious attack
and rogue elements attempting to connect to various ACTN components
(with PCE being one of them). Furthermore, some ACTN components
represent a single point of failure and threat vector and must also
manage policy conflicts and eavesdropping of communication between
different ACTN components. [RFC8453] further states that all
protocols used to realize the ACTN framework should have rich
security features, and customer, application and network data should
be stored in encrypted data stores.
7. Acknowledgments When PCEP is used as an ACTN interface, the security of PCEP provided
by Transport Layer Security (TLS) [RFC8253], as per the
recommendations and best current practices in [RFC7525], is used.
As per [RFC8453], regarding the MPI, a PKI- based mechanism is
suggested, such as building a TLS or HTTPS connection between the
MDSC and PNCs, to ensure trust between the physical network layer
control components and the MDSC. Which MDSC the PNC exports topology
information to, and the level of detail (full or abstracted), should
also be authenticated, and specific access restrictions and topology
views should be configurable and/or policy based. When PCEP is used
in MPI, the security functions as per [RFC8253] are used to fulfill
these requirements.
As per [RFC8453], regarding the CMI, suitable authentication and
authorization of each CNC connecting to the MDSC will be required.
If PCEP is used in CMI, the security functions as per [RFC8253] can
be used to support peer authentication, message encryption, and
integrity checks.
8. Acknowledgments
The authors would like to thank Jonathan Hardwick for the inspiration The authors would like to thank Jonathan Hardwick for the inspiration
behind this document. Further thanks to Avantika for her comments behind this document. Further thanks to Avantika for her comments
with suggested text. with suggested text.
8. References Thanks to Adrian Farrel and Daniel King for their substantial
reviews.
8.1. Normative References 9. References
9.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
skipping to change at page 16, line 5 skipping to change at page 16, line 41
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>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
8.2. Informative References 9.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>. <https://www.rfc-editor.org/info/rfc4203>.
skipping to change at page 17, line 5 skipping to change at page 17, line 38
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>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS "Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <https://www.rfc-editor.org/info/rfc5623>. September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>. <https://www.rfc-editor.org/info/rfc7399>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>. <https://www.rfc-editor.org/info/rfc7491>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[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,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
skipping to change at page 18, line 22 skipping to change at page 19, line 22
Yoon, "Information Model for Abstraction and Control of TE Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>. September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[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-06 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-teas-actn-requirements]
Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K.
Lee, "Requirements for Abstraction and Control of TE
Networks", draft-ietf-teas-actn-requirements-09 (work in
progress), March 2018.
[I-D.ietf-pce-inter-area-as-applicability] [I-D.ietf-pce-inter-area-as-applicability]
King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and King, D. and H. Zheng, "Applicability of the Path
O. Dios, "Applicability of the Path Computation Element to Computation Element to Inter-Area and Inter-AS MPLS and
Inter-Area and Inter-AS MPLS and GMPLS Traffic GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as-
Engineering", draft-ietf-pce-inter-area-as- applicability-07 (work in progress), December 2018.
applicability-06 (work in progress), July 2016.
[I-D.dhodylee-pce-pcep-ls] [I-D.dhodylee-pce-pcep-ls]
Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for
Distribution of Link-State and TE Information.", draft- Distribution of Link-State and TE Information.", draft-
dhodylee-pce-pcep-ls-11 (work in progress), June 2018. dhodylee-pce-pcep-ls-13 (work in progress), February 2019.
[I-D.lee-pce-pcep-ls-optical] [I-D.lee-pce-pcep-ls-optical]
Lee, Y., Zheng, H., Ceccarelli, D., weiw@bupt.edu.cn, w., Lee, Y., Zheng, H., Ceccarelli, D., weiw@bupt.edu.cn, w.,
Park, P., and B. Yoon, "PCEP Extension for Distribution of Park, P., and B. Yoon, "PCEP Extension for Distribution of
Link-State and TE information for Optical Networks", Link-State and TE information for Optical Networks",
draft-lee-pce-pcep-ls-optical-05 (work in progress), draft-lee-pce-pcep-ls-optical-07 (work in progress), March
September 2018. 2019.
[I-D.leedhody-pce-vn-association] [I-D.leedhody-pce-vn-association]
Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP Lee, Y., Zhang, X., and D. Ceccarelli, "PCEP Extensions
Extensions for Establishing Relationships Between Sets of for Establishing Relationships Between Sets of LSPs and
LSPs and Virtual Networks", draft-leedhody-pce-vn- Virtual Networks", draft-leedhody-pce-vn-association-07
association-06 (work in progress), October 2018. (work in progress), February 2019.
[I-D.litkowski-pce-state-sync] [I-D.litkowski-pce-state-sync]
Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Litkowski, S., Sivabalan, S., and D. Dhody, "Inter
Stateful Path Computation Element communication Stateful Path Computation Element communication
procedures", draft-litkowski-pce-state-sync-04 (work in procedures", draft-litkowski-pce-state-sync-04 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-pce-association-policy] [I-D.ietf-pce-association-policy]
Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J.,
J. Hardwick, "Path Computation Element communication and M. Negi, "Path Computation Element communication
Protocol extension for associating Policies and LSPs", Protocol extension for associating Policies and LSPs",
draft-ietf-pce-association-policy-03 (work in progress), draft-ietf-pce-association-policy-05 (work in progress),
June 2018. February 2019.
[I-D.lee-pce-lsp-stitching-hpce] [I-D.dugeon-pce-stateful-interdomain]
Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
for Stitching LSPs in Hierarchical Stateful PCE Model", Extension for Stateful Inter-Domain Tunnels", draft-
draft-lee-pce-lsp-stitching-hpce-01 (work in progress), dugeon-pce-stateful-interdomain-02 (work in progress),
December 2017. March 2019.
[EXP] Casellas, R., Vilalta, R., Martinez, R., Munoz, R., Zheng,
H., and Y. Lee, "Experimental Validation of the ACTN
architecture for flexi-grid optical networks using Active
Stateful Hierarchical PCEs", 19th International Conference
on Transparent Optical Networks (ICTON) , July 2017,
<http://www.cttc.es/publication/experimental-validation-
of-the-actn-architecture-for-flexi-grid-optical-networks-
using-active-stateful-hierarchical-pces/>.
Appendix A. Additional Information
In the paper [EXP], the application of the ACTN architecture is
presented to demonstrate the control of a multi-domain flexi-grid
optical network, by proposing, adopting and extending -
o the Hierarchical active stateful PCE architectures and protocols
o the PCEP protocol to support efficient and incremental link state
topological reporting, known as PCEP-LS
o the per link partitioning of the optical spectrum based on
variable-sized allocated frequency slots enabling network sharing
and virtualization
o the use of a model-based interface to dynamically request the
instantiation of virtual networks for specific clients / tenants.
The design and the implementation of the testbed are reported in
order to validate the approach.
Authors' Addresses Authors' Addresses
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
 End of changes. 75 change blocks. 
153 lines changed or deleted 243 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/