draft-ietf-pce-applicability-actn-07.txt   draft-ietf-pce-applicability-actn-08.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: April 25, 2019 D. Ceccarelli Expires: June 8, 2019 D. Ceccarelli
Ericsson Ericsson
October 22, 2018 December 5, 2018
Applicability of Path Computation Element (PCE) for Abstraction and Applicability of Path Computation Element (PCE) for Abstraction and
Control of TE Networks (ACTN) Control of TE Networks (ACTN)
draft-ietf-pce-applicability-actn-07 draft-ietf-pce-applicability-actn-08
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 Communication Protocol (PCEP) provides The Path Computation Element (PCE) is component, application, or
mechanisms for Path Computation Elements (PCEs) to perform path network node that is capable of computing a network path or route
computations in response to Path Computation Clients (PCCs) requests. 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 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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on June 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 6 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 7
2. Architectural Considerations . . . . . . . . . . . . . . . . 7 2. Architectural Considerations . . . . . . . . . . . . . . . . 7
2.1. Multi domain coordination via Hierarchy . . . . . . . . . 7 2.1. Multi Domain Coordination via Hierarchy . . . . . . . . . 7
2.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Customer mapping . . . . . . . . . . . . . . . . . . . . 9 2.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
3. Interface Considerations . . . . . . . . . . . . . . . . . . 10 3. Interface Considerations . . . . . . . . . . . . . . . . . . 10
4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
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 Elements (PCEs) [RFC4655] to provides mechanisms for Path Computation Clients (PCCs) to request a
perform path computations in response to Path Computation Clients Path Computation Element (PCE) [RFC4655] to perform path
(PCCs) requests. 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
multiple domains has been identified as a key motivation for PCE multiple domains has been identified as a key motivation for PCE
development. development.
A stateful PCE [RFC8231] is capable of considering, for the purposes A stateful PCE [RFC8231] is capable of considering, for the purposes
of path computation, not only the network state in terms of links and of path computation, not only the network state in terms of links and
nodes (referred to as the Traffic Engineering Database or TED) but nodes (referred to as the Traffic Engineering Database or TED) but
also the status of active services (previously computed paths, and also the status of active services (previously computed paths), and
currently reserved resources, stored in the Label Switched Paths currently reserved resources, stored in the Label Switched Paths
Database (LSP-DB). Database (LSP-DB).
[RFC8051] describes general considerations for a stateful PCE [RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as deployment and examines its applicability and benefits, as well as
its challenges and limitations through a number of use cases. its challenges and limitations through a number of use cases.
[RFC8231] describes a set of extensions to PCEP to provide stateful [RFC8231] describes a set of extensions to PCEP to provide stateful
control. A stateful PCE has access to not only the information control. A stateful PCE has access to not only the information
carried by the network's Interior Gateway Protocol (IGP), but also carried by the network's Interior Gateway Protocol (IGP), but also
skipping to change at page 4, line 5 skipping to change at page 4, line 5
programmed. It is possible to view this component as performing programmed. It is possible to view this component as performing
specific computations to place flows within the network given specific computations to place flows within the network given
knowledge of the availability of network resources, how other knowledge of the availability of network resources, how other
forwarding devices are programmed, and the way that other flows are forwarding devices are programmed, and the way that other flows are
routed. It is concluded in [RFC7399], that this is the same function routed. It is concluded in [RFC7399], that this is the same function
that a PCE might offer in a network operated using a dynamic control that a PCE might offer in a network operated using a dynamic control
plane. This is the function and purpose of a PCE, and the way that a plane. This is the function and purpose of a PCE, and the way that a
PCE integrates into a wider network control system including SDN is PCE integrates into a wider network control system including SDN is
presented in Application-Based Network Operation (ABNO) [RFC7491]. presented in Application-Based Network Operation (ABNO) [RFC7491].
1.1.2. PCE in multi-domain and multi-layer deployments 1.1.2. PCE in Multi-domain and Multi-layer Deployments
Computing paths across large multi-domain environments require Computing paths across large multi-domain environments requires
special computational components and cooperation between entities in special computational components and cooperation between entities in
different domains capable of complex path computation. The PCE different domains capable of complex path computation. The PCE
provides an architecture and a set of functional components to provides an architecture and a set of functional components to
address this problem space. A PCE may be used to compute end-to-end address this problem space. A PCE may be used to compute end-to-end
paths across multi-domain environments using a per-domain path paths across multi-domain environments using a per-domain path
computation technique [RFC5152]. The Backward recursive PCE based computation technique [RFC5152]. The Backward Recursive PCE based
path computation (BRPC) mechanism [RFC5441] defines a PCE-based path path computation (BRPC) mechanism [RFC5441] defines a PCE-based path
computation procedure to compute inter-domain constrained MPLS and computation procedure to compute inter-domain constrained MPLS and
GMPLS TE networks. However, both per-domain and BRPC techniques GMPLS TE networks. However, per-domain technique assumes that the
assume that the sequence of domains to be crossed from source to sequence of domains to be crossed from source to destination is
destination is known, either fixed by the network operator or known, either fixed by the network operator or obtained by other
obtained by other means. means. BRPC can work best with a known domain sequence, and it will
also work nicely with a small set of interconnected domains.
However, it doesn't work well for is a large set of interconnected
domains.
[RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can
be used for computing end-to-end paths for inter-domain MPLS Traffic be used for computing end-to-end paths for inter-domain MPLS Traffic
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.
skipping to change at page 4, line 44 skipping to change at page 4, line 47
(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 an hierarchy the protocol. The section 2.1.3 of [RFC8283] describe a hierarchy of
of PCE-based controller as per the Hierarchy of PCE framework defined PCE-based controller as per the Hierarchy of PCE framework defined in
in [RFC6805]. [RFC6805].
1.2. Abstraction and Control of TE Networks (ACTN) 1.2. Abstraction and Control of TE Networks (ACTN)
[I-D.ietf-teas-actn-requirements] describes the high-level ACTN [RFC8453] describes the high-level ACTN requirements and the
requirements. [RFC8453] describes the architecture model for ACTN architecture model for ACTN including the following entities:
including the entities (Customer Network Controller(CNC), Multi- Customer Network Controller(CNC), Multi-domain Service
domain Service Coordinator(MDSC), and Provisioning Network Controller Coordinator(MDSC), and Provisioning Network Controller (PNC) and
(PNC) and their interfaces. their interfaces.
The ACTN reference architecture identified a three-tier control The ACTN reference architecture identified a three-tier control
hierarchy as depicted in Figure 1: hierarchy as depicted in Figure 1:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| CNC | | CNC | | CNC | | CNC | | CNC | | CNC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
\ | / \ | /
\ | / \ | /
Boundary =============\==============|==============/============ Boundary =============\==============|==============/============
skipping to change at page 6, line 41 skipping to change at page 6, line 41
- - ( ) ( ) ----- - - ( ) ( ) -----
( ) ( Phys. ) ( Phys. ) ( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net ) --------- ( Net ) ( Net )
----- ----- ----- -----
CMI - (CNC-MDSC Interface) CMI - (CNC-MDSC Interface)
MPI - (MDSC-PNC Interface) MPI - (MDSC-PNC Interface)
Figure 1: ACTN Hierarchy Figure 1: ACTN Hierarchy
The two interfaces with respect to the MDSC, one north of the MDSC There are two interfaces with respect to the MDSC: one north of the
(CMI CNC-MDSC Interface) and one south (MPI MDSC-PNC Interface). A MDSC (the CNC-MDSC Interface : CMI), and one south (the MDSC-PNC
hierarchy of MDSC is possible with a recursive MPI interface. Interface : MPI). A hierarchy of MDSCs is possible with a recursive
MPI interface.
[RFC8454] provides an information model for ACTN interfaces. [RFC8454] provides an information model for ACTN interfaces.
1.3. PCE and ACTN 1.3. PCE and ACTN
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 the PCE architecture is applicable to ACTN. It also lists the
PCEP extensions that are needed to use PCEP as an ACTN interface. PCEP extensions that are needed to use PCEP as an ACTN interface.
This document also identifies any gaps in PCEP, that exist at the This document also identifies any gaps in PCEP, that exist at the
time of publication of this document. time of 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 2. Architectural Considerations
ACTN [RFC8453] architecture is based on hierarchy and recursiveness ACTN [RFC8453] architecture is based on hierarchy and recursiveness
of controllers. It defines three types of controllers (depending on of controllers. It defines three types of controllers (depending on
skipping to change at page 7, line 28 skipping to change at page 7, line 33
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 PCEP 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 PCEP. Operator may functions are not required to be implemented via PCE. Similarly,
this document presents the ways in which PCEP could be used as the
communications medium between funcitonl components. Operator 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 use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the H-PCE, but alternatively use RESTCONF [RFC8040] or BGP-LS [RFC7752]
topology and support abstraction function. to get access to the topology and support abstraction function.
2.1. Multi domain coordination via Hierarchy 2.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
skipping to change at page 8, line 8 skipping to change at page 8, line 16
[RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of
PCE with Parent PCE coordinating multi-domain path computation PCE with Parent PCE coordinating multi-domain path computation
function between Child PCE(s). It is easy to see how these function between Child PCE(s). It is easy to see how these
principles align, and thus how stateful H-PCE architecture can be principles align, and thus how stateful H-PCE architecture can be
used to realize ACTN. used to 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; E2E coordination function. This includes domain sequence selection; End-
path computation; Controller (PCE) initiated path setup and to-End (E2E) path computation; Controller (PCE) initiated path setup
reporting. This is also applicable to multi-layer coordination in and reporting. This is also applicable to multi-layer coordination
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 2.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 include abstract topology created as per the domain. This also includes the abstract topology created as per the
customer service connectivity requests and represented as a network customer service connectivity requests and represented as a network
slice allocated to each customer. slice 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 approaches for learning [I-D.dhodylee-pce-pcep-ls] proposes another approach for learning
and maintaining the Link-State and TE information as an alternative and maintaining the Link-State and TE information as an alternative
to IGPs and BGP flooding, using PCEP itself. The child PCE can use to IGPs and BGP flooding, using PCEP itself. The child PCE can use
this mechanism to transport Link-State and TE information from child this mechanism to transport Link-State and TE information from child
PCE to a Parent PCE using PCEP. PCE 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
skipping to change at page 9, line 21 skipping to change at page 9, line 30
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 2.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 network provisioning request to the PNC. That is,
the customer requests/commands are mapped into network provisioning the customer requests/commands are mapped into network provisioning
requests that can be sent to the PNC. Specifically, it provides requests that can be sent to the PNC. Specifically, it provides
mapping and translation of a customer's service request into a set of mapping and translation of a customer's service request into a set of
parameters that are specific to a network type and technology such parameters that are specific to a network type and technology such
that network configuration process is made possible. 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 LSR. The child PCE further propagates the initiate request to the Label
customer request is received by the MDSC (parent PCE) and based on Switching Router (LSR). The customer request is received by the MDSC
the business logic, global abstracted topology, network conditions (parent PCE) and based on the business logic, global abstracted
and local policy, the MDSC (parent PCE) translates this into per topology, network conditions and local policy, the MDSC (parent PCE)
domain LSP initiation request that a PNC (child PCE) can understand translates this into per domain LSP initiation request that a PNC
and act on. This can be done via the PCInitiate message. (child PCE) can understand and act on. This can be done via the
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 2.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.
skipping to change at page 10, line 51 skipping to change at page 11, line 13
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.
o In case of hierarchy of MDSC, the MPI is applied recursively. In case of hierarchy of MDSC, the MPI is applied recursively. From
From an abstraction point of view, the top level MDSC which an abstraction point of view, the top level MDSC which interfaces the
interfaces the CNC operates on a higher level of abstraction CNC operates on a higher level of abstraction (i.e., less granular
(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 describe how PCE and PCEP could help realize ACTN on The Section 4 describes how PCE and PCEP could help realize ACTN on
the MPI. the MPI.
4. Realizing ACTN with PCE (and PCEP) 4. 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 the Figure 2, there are 4 domains, each with
its own PNC and a MDSC at top. The PNC and MDSC need PCE as a its own PNC and a MDSC at top. The PNC and MDSC need PCE as a
important function. The PNC (or child PCE) already uses PCEP to important function. The PNC (or child PCE) already uses PCEP to
communicate to the network device. It can utilize the PCEP as the communicate to the network device. It can utilize the PCEP as the
MPI to communicate between controllers too. MPI to communicate between controllers too.
skipping to change at page 13, line 31 skipping to change at page 13, line 31
(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 the 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 2.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 resulted 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
skipping to change at page 15, line 7 skipping to change at page 15, line 7
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 PNC would convert the path received from the
device (with physical nodes and links) into abstract path (based device (with physical nodes and links) into abstract path (based
on the abstract topology generated before with abstract nodes and on the abstract topology generated before with abstract nodes and
links) and reported to the MDSC. links) and reported to the MDSC.
5. IANA Considerations 5. IANA Considerations
This is an informational document and thus does not have any IANA This document makes no requests for IANA action.
allocations to be made.
6. Security Considerations 6. Security Considerations
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 list
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, use When PCEP is used on the MPI, this interface needs to be secured.
of [RFC8253] is RECOMENDED. Each PCEP extension listed in this That can be achieved using the procdecures described in [RFC8253].
document, presents its individual security considerations, which Each PCEP extension listed in this document, presents its individual
continue to apply. security considerations, which continue to apply.
7. Acknowledgments 7. 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 8. References
8.1. Normative References 8.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<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>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805, of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012, DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>. <https://www.rfc-editor.org/info/rfc6805>.
skipping to change at page 16, line 17 skipping to change at page 16, line 17
[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>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing Inter- Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<https://www.rfc-editor.org/info/rfc5152>. <https://www.rfc-editor.org/info/rfc5152>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi- M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008, DOI 10.17487/RFC5212, July 2008,
skipping to change at page 18, line 25 skipping to change at page 18, line 19
<https://www.rfc-editor.org/info/rfc8283>. <https://www.rfc-editor.org/info/rfc8283>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
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-05 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in
progress), June 2018. progress), October 2018.
[I-D.ietf-teas-actn-requirements] [I-D.ietf-teas-actn-requirements]
Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K.
Lee, "Requirements for Abstraction and Control of TE Lee, "Requirements for Abstraction and Control of TE
Networks", draft-ietf-teas-actn-requirements-09 (work in Networks", draft-ietf-teas-actn-requirements-09 (work in
progress), March 2018. 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., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and
O. Dios, "Applicability of the Path Computation Element to O. Dios, "Applicability of the Path Computation Element to
skipping to change at page 19, line 9 skipping to change at page 18, line 51
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-05 (work in progress),
September 2018. September 2018.
[I-D.leedhody-pce-vn-association] [I-D.leedhody-pce-vn-association]
Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP
Extensions for Establishing Relationships Between Sets of Extensions for Establishing Relationships Between Sets of
LSPs and Virtual Networks", draft-leedhody-pce-vn- LSPs and Virtual Networks", draft-leedhody-pce-vn-
association-05 (work in progress), June 2018. association-06 (work in progress), October 2018.
[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-03 (work in procedures", draft-litkowski-pce-state-sync-04 (work in
progress), April 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 Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and
J. Hardwick, "Path Computation Element communication J. Hardwick, "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-03 (work in progress),
June 2018. June 2018.
[I-D.lee-pce-lsp-stitching-hpce] [I-D.lee-pce-lsp-stitching-hpce]
Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions
 End of changes. 40 change blocks. 
78 lines changed or deleted 86 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/