draft-ietf-pce-applicability-actn-09.txt   draft-ietf-pce-applicability-actn-10.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: September 8, 2019 D. Ceccarelli Expires: September 9, 2019 D. Ceccarelli
Ericsson Ericsson
March 7, 2019 March 08, 2019
Applicability of the Path Computation Element (PCE) to the Abstraction Applicability of the Path Computation Element (PCE) to the Abstraction
and Control of TE Networks (ACTN) and Control of TE Networks (ACTN)
draft-ietf-pce-applicability-actn-09 draft-ietf-pce-applicability-actn-10
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.
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 September 8, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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. Background Information . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2 2. Background Information . . . . . . . . . . . . . . . . . . . 3
1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3 2.1. Path Computation Element (PCE) . . . . . . . . . . . . . 3
1.1.2. PCE in Multi-domain and Multi-layer Deployments . . . 4 2.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 4
1.1.3. Relationship to PCE Based Central Control . . . . . . 4 2.1.2. PCE in Multi-domain and Multi-layer Deployments . . . 4
1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5 2.1.3. Relationship to PCE Based Central Control . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
3. Architectural Considerations . . . . . . . . . . . . . . . . 7 3. Architectural Considerations . . . . . . . . . . . . . . . . 7
3.1. Multi-Domain Coordination via Hierarchy . . . . . . . . . 8 3.1. Multi-Domain Coordination via Hierarchy . . . . . . . . . 7
3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9 3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
4. Interface Considerations . . . . . . . . . . . . . . . . . . 11 4. Interface Considerations . . . . . . . . . . . . . . . . . . 10
5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Additional Information . . . . . . . . . . . . . . . 21 Appendix A. Additional Information . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Background Information 1. Introduction
1.1. Path Computation Element (PCE) Abstraction and Control of TE Networks (ACTN) [RFC8453] 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) [RFC4655] 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
how PCE architecture is applicable to ACTN. It also lists the PCEP
extensions that are needed to use PCEP as an ACTN interface. This
document also identifies any gaps in PCEP, that exist at the time of
publication of this document.
Further, ACTN, stateful H-PCE [I-D.ietf-pce-stateful-hpce], and PCE
as a central controller (PCECC) [RFC8283] are based on the same basic
hierarchy framework and thus compatible with each other.
2. Background Information
2.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
multiple domains has been identified as a key motivation for PCE multiple domains has been identified as a key motivation for PCE
development. development.
skipping to change at page 3, line 35 skipping to change at page 4, line 12
computations. The additional state allows the PCE to compute computations. The additional state allows the PCE to compute
constrained paths while considering individual LSPs and their constrained paths while considering individual LSPs and their
interactions. [RFC8281] describes the setup, maintenance and interactions. [RFC8281] describes the setup, maintenance and
teardown of PCE-initiated LSPs under the stateful PCE model. teardown of PCE-initiated LSPs under the stateful PCE model.
[RFC8231] also describes the active stateful PCE. The active PCE [RFC8231] also describes the active stateful PCE. The active PCE
functionality allows a PCE to reroute an existing LSP or make changes functionality allows a PCE to reroute an existing LSP or make changes
to the attributes of an existing LSP, or a PCC to delegate control of to the attributes of an existing LSP, or a PCC to delegate control of
specific LSPs to a new PCE. specific LSPs to a new PCE.
1.1.1. Role of PCE in SDN 2.1.1. Role of PCE in SDN
Software-Defined Networking (SDN) [RFC7149] refers to a separation Software-Defined Networking (SDN) [RFC7149] refers to a separation
between the control elements and the forwarding components so that between the control elements and the forwarding components so that
software running in a centralized system called a controller, can act software running in a centralized system called a controller, can act
to program the devices in the network to behave in specific ways. A to program the devices in the network to behave in specific ways. A
required element in an SDN architecture is a component that plans how required element in an SDN architecture is a component that plans how
the network resources will be used and how the devices will be the network resources will be used and how the devices will be
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 2.1.2. PCE in Multi-domain and Multi-layer Deployments
Computing paths across large multi-domain environments requires 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
skipping to change at page 4, line 47 skipping to change at page 5, line 24
(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 2.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. 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) 2.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 entities Customer Network architecture model for ACTN including the entities Customer Network
Controller (CNC), Multi-domain Service Coordinator (MDSC), and Controller (CNC), Multi-domain Service Coordinator (MDSC), and
Provisioning Network Controller (PNC) and their interfaces. Provisioning Network Controller (PNC) and their interfaces.
The ACTN reference architecture is shown in Figure 1 which is The ACTN reference architecture is shown in Figure 1 which is
reproduced here from [RFC8453] for convenience. [RFC8453] remains reproduced here from [RFC8453] for convenience. [RFC8453] remains
the definitive reference for the ACTN architecture. As depicted in the definitive reference for the ACTN architecture. As depicted in
Figure 1, the ACTN architecture identifies a three-tier hierarchy. Figure 1, the ACTN architecture identifies a three-tier hierarchy.
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.
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
how PCE architecture is applicable to ACTN. It also lists the PCEP
extensions that are needed to use PCEP as an ACTN interface. This
document also identifies any gaps in PCEP, that exist at the time of
publication of this document.
Further, ACTN, stateful H-PCE, and PCECC are based on the same basic
hierarchy framework and thus compatible with each other.
3. Architectural Considerations 3. Architectural Considerations
The ACTN architecture [RFC8453] is based on hierarchy and The ACTN architecture [RFC8453] is based on hierarchy and
recursiveness of controllers. It defines three types of controllers recursiveness of controllers. It defines three types of controllers
(depending on the functionalities they implement). The main (depending on the functionalities they implement). The main
functionalities are - functionalities are -
o Multi-domain coordination o Multi-domain coordination
o Abstraction o Abstraction
 End of changes. 14 change blocks. 
44 lines changed or deleted 45 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/