One document matched: draft-zhao-teas-pce-control-function-00.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
vim: set softtabstop=2 shiftwidth=2 expandtab
version=20150108
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2702 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2702.xml">
<!ENTITY RFC3985 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3985.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4427 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4427.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC6805 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6805.xml">
<!ENTITY RFC7025 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7025.xml">
<!ENTITY RFC7399 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7399.xml">
<!ENTITY RFC7420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7420.xml">
<!ENTITY RFC7432 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY RFC7491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7491.xml">
<!ENTITY RFC7665 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7665.xml">
]>
<rfc category="info" docName="draft-zhao-teas-pce-control-function-00" ipr="trust200902">
<front>
<title abbrev="PCE-CC Architecture">An Architecture for Use of PCE and PCEP in a Network with Central Control</title>
<author fullname="Adrian Farrel" initials="A." surname="Farrel" role="editor">
<organization>Juniper Networks</organization>
<address>
<email>adrian@olddog.co.uk</email>
</address>
</author>
<author fullname="Quintin Zhao" initials="Q." surname="Zhao" role="editor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>125 Nagog Technology Park</street>
<city>Acton</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>quintin.zhao@huawei.com</email>
</address>
</author>
<author fullname="Robin Li" initials="R." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Road</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<author fullname="Chao Zhou" initials="C." surname="Zhou">
<organization>Cisco Systems</organization>
<address>
<email>chao.zhou@cisco.com</email>
</address>
</author>
<date year="2016" />
<area>Routing</area>
<workgroup>TEAS Working Group</workgroup>
<keyword>PCE</keyword>
<keyword>SDN</keyword>
<abstract>
<t>The Path Computation Element (PCE) has become established as a core component
of Software Defined Networking (SDN) systems. It can compute optimal paths
for traffic across a network for any definition of "optimal" and can also
monitor changes in resource availability and traffic demands to update the
paths.</t>
<t>Conventionally, the PCE has been used to derive paths for MPLS Label Switched
Paths (LSPs). These paths are supplied using the Path Computation Element
Communication Protocol (PCEP) to the head end of the LSP for signaling in the
MPLS network.</t>
<t>SDN has a far broader applicability than just signaled MPLS traffic engineered
networks, and the PCE may be used to determine paths in a wide range of use
cases including static LSPs, segment routing, service function chaining (SFC),
and indeed any form of routed or switched network. It is, therefore reasonable
to consider PCEP as a general southbound control protocol for use in these
environments to allow the PCE to be fully enabled as a central controller.</t>
<t>This document briefly introduces the architecture for PCE as a central controller,
examines the motivations and applicability for PCEP as a southbound interface, and
introduces the implications for the protocol. This document does not describe the
use cases in detail and does not define protocol extensions: that work is left for
other documents.</t>
</abstract>
</front>
<middle>
<!-- === Introduction === -->
<section anchor="introduction" title="Introduction">
<t>The Path Computation Element (PCE) <xref target="RFC4655" /> was developed to
offload path computation function from routers in an MPLS traffic engineered
network. Since then, the role and function of the PCE has grown to cover
a number of other uses (such as GMPLS <xref target="RFC7025" />) and to allow
delegated control <xref target="I-D.ietf-pce-stateful-pce" /> and PCE-initiated
use of network resources <xref target="I-D.ietf-pce-pce-initiated-lsp" />.</t>
<t>According to <xref target="RFC7399" />, Software Defined Networking (SDN) refers
to a separation between the control elements and the forwarding components so
that software running in a centralized system called a controller, can act 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 the network
resources will be used and how the devices will be programmed. It is possible
to view this component as performing specific computations to place flows within
the network given knowledge of the availability of network resources, how other
forwarding devices are programmed, and the way that other flows are routed. 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 presented in <xref target="RFC7491" />.</t>
<t>In early PCE implementations, where the PCE was used to derive paths for MPLS
Label Switched Paths (LSPs), paths were requested by network elements and the results
of the path computations were supplied to network elements using the Path Computation
Element Communication Protocol (PCEP) <xref target="RFC5440" />. This protocol was
later extended to allow a PCE to send unsolicited requests to the network for LSP
establishment <xref target="I-D.ietf-pce-pce-initiated-lsp" />.</t>
<t>SDN has a far broader applicability than just signaled MPLS or GMPLS traffic engineered
networks. The PCE component in an SDN system may be used to determine paths in a wide
range of use cases including static LSPs, segment routing
<xref target="I-D.ietf-spring-segment-routing" />, service function chaining (SFC)
<xref target="RFC7665" />, and indeed any form of routed or switched network. It is,
therefore reasonable to consider PCEP as a general southbound control protocol for use
in these environments to allow the PCE to be fully enabled as a central controller.</t>
<t>This document introduces the architecture for PCE as a central controller,
examines the motivations and applicability for PCEP as a southbound interface, and
introduces the implications for the protocol. This document dos not describe the
use cases in detail and does not define protocol extensions: that work is left for
other documents.</t>
</section>
<section anchor="architecture" title="Architecture">
<t>The architecture for the use of PCE within centralized control of a network is based
on the understanding that a PCE can determine how connections should be placed and how
resources should be used within the network, and that the PCE can then cause those
connections to be established. <xref target="ctrl_plane_figure" /> shows how
this control relationship works in a network with an active control plane. This is a
familiar view for those who have read and understood <xref target="RFC4655" /> and
<xref target="I-D.ietf-pce-pce-initiated-lsp" />.</t>
<t>In this mode of operation, the central controller is asked to create connectivity
by a network orchestrator, a service manager, an Operations Support System (OSS),
a Network Management Station (NMS), or some other application. The PCE-based
controller computes paths with awareness of the network topology, the available
resources, and the other services supported in the network. This information is
held in the Traffic Engineering Database (TED) and other databases available to
the PCE. Then the PCE sends a request using PCEP to one of the Network Elements
(NEs), and that NE uses a control plane to establish the requested connections and
reserve the network resources.</t>
<figure anchor="ctrl_plane_figure" title="Architecture for Central Controller with Control Plane">
<artwork>
<![CDATA[
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-based |<---| TED |
| Controller | -----
| |
------------
^
PCEP|
v
---- ---- ---- ----
| NE |<------->| NE |<--->| NE |<--->| NE |
---- Control ---- ---- ----
Plane
]]>
</artwork>
</figure>
<t>Although the architecture shown in <xref target="ctrl_plane_figure" />
represents a form of SDN, one objective of SDN in some environments is to remove
the dependency on a control plane. A transition architecture toward this goal is
presented in <xref target="RFC7491" /> and is shown in <xref target="sbi_arch_figure" />.
In this case, services are still requested in the same way, and the PCE-based controller
still requests use of the network using PCEP. The main difference is that the consumer
of the PCEP messages is a Network Controller that provisions the resources and instructs
the data plane using Southbound Interface (SBI) that provides an interface to each NE.</t>
<figure anchor="sbi_arch_figure" title="Architecture Including a Network Controller">
<artwork align="center">
<![CDATA[
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-based |<---| TED |
| Controller | -----
| |
------------
^
| PCEP
v
------------
| Network |
| Controller |
/------------\
SBI / ^ ^ \
/ | | \
/ v v \
----/ ---- ---- \----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
]]>
</artwork>
</figure>
<t>The approach in <xref target="sbi_arch_figure" /> delivers the SDN
functionality but is overly complicated and insufficiently flexible.
<list style="symbols">
<t>The complication is created by the use of two controllers in a
hierarchical organization, and the resultant use of two protocols
in a southbound direction.</t>
<t>The lack of flexibility arises from the assumed or required lack of
a control plane.</t>
</list></t>
<t>This document describes an architecture that reduces the number of components
and is flexible to a number of deployment models and use cases. In this
hybrid approach (shown in <xref target="architecture_figure" />) the network
controller is PCE-enabled and can also speak PCEP as the SBI (i.e., it can
communicate with each node along the path using PCEP). That means that the
controller can communicate with a conventional control plane-enabled NE using
PCEP and can also use the same protocol to program individual NEs. In this
way the PCE-based controller can control a wider range of networks and deliver
many different functions as described in <xref target="applicability" />.</t>
<t>PCEP is essentially already capable of acting as an SBI and only small, use case-
specific modifications to the protocol are needed to support this architecture.
The implications for the protocol are discussed further in <xref target="protocols" />.</t>
<figure anchor="architecture_figure" title="Architecture for Node-by-Node Central Control">
<artwork align="center">
<![CDATA[
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-based |<---| TED |
| Controller | -----
| |
/------------\
PCEP / ^ ^ \
/ | | \
/ v v \
/ ---- ---- \
/ | NE | | NE | \
----/ ---- ---- \----
| NE | | NE |
---- ----
^ ---- ---- ^
:......>| NE |...| NE |<....:
Control Plane ---- ----
]]>
</artwork>
</figure>
<section anchor="scaling" title="Resilience and Scaling">
<t>Systems with central controllers are vulnerable to two problems:
failure or overload of the single controller. These concerns are
not unique to the use of a PCE-based controller but need to be
addressed in this document before the PCE-based controller
architecture can be considered for use in all but the smallest
networks.</t>
<t>There are three architectural mechanisms that can be applied to
address these issues. The mechanisms are described separately
for clarity, but a deployment use may any combination of the
approaches.</t>
<t>For simplicity of illustration, these three approaches are shown in the sections
that follow without a control plane. However, the general, hybrid approach of
<xref target="architecture_figure" /> is applicable in each case.</t>
<section anchor="partition" title="Partitioned Network">
<t>The first and simplest approach to handling controller overload or scalability
is to use multiple controllers, each responsible for a part of the network. We
can call the resultant areas of control "domains."</t>
<t>This approach is shown in <xref target="partitioned_network" />. It can clearly
address some of the scaling and overload concerns since each controller now only
has responsibility for a subset of the network elements. But this comes at a cost
because end-to-end connections require coordination between the controllers.
Furthermore, this technique does not remove the single-point-of-failure concern
even if it does reduce the impact on the network of the failure of a single controller.</t>
<t>Note that PCEP is designed to work as a PCE-to-PCE protocol as well as a PCE-to-PCC
protocol, so it should be possible to use it to coordinate between PCE-based controllers
in this model.</t>
<figure anchor="partitioned_network" title="Multiple Controllers on a Partitioned Network">
<artwork align="center">
<![CDATA[
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| |
v v
------------ Coord- ------------
----- | | ination | | -----
| TED |--->| PCE-based |<-------->| PCE-based |<---| TED |
----- | Controller | | Controller | -----
| | | |
/------------ ------------\
/ ^ ^ ^ ^ \
/ | | | | \
| | | | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
]]>
</artwork>
</figure>
</section>
<section anchor="multiple" title="Multiple Parallel Controllers">
<t>Multiple parallel controllers may be deployed as shown in <xref target="multi_controller" />.
Each controller is capable of controlling all of the network elements thus the failure of
any one controller will not leave the network unmanageable and, in normal circumstances,
the load can be distributed across the controllers.</t>
<t>To achieve full redundancy and to be able to continue to provide full function in the event
of the failure a controller, the controllers must synchronize with each other. This is
nominally a simple task if there are just two controllers, but can actually be quite complex
if state changes in the network are not to be lost. Furthermore, if there are more than two
controllers, the synchronization between controllers can become a hard problem.</t>
<t>Synchronization issues are often off-loaded as "database synchronization" problems because
distributed database packages have already had to address these challenges. In networking the
problem may also be addressed by collecting the state from the network (effectively using the
network as a database) using normal routing protocols such as OSPF, IS-IS, and BGP.</t>
<figure anchor="multi_controller" title="Multiple Redundant Controllers">
<artwork align="center">
<![CDATA[
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| ___________________ |
| | Synchronization | |
v v v v
------------ ------------
| | ----- | |
| PCE-based |<---| TED |--->| PCE-based |
| Controller | ----- | Controller |
| |__ ...........| |
------------\ \_:__ :------------
^ ^ \___: \ .....: ^ ^
| | .....:\ \_:___ ..: :
| |__:___ \___:_ \_:___ :
| ....: | .....: | ..: | :
| : | : | :
v v v v v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
]]>
</artwork>
</figure>
</section>
<section anchor="hierarchy" title="Hierarchical Controllers">
<t><xref target="hierarchical_controller" /> shows an approach with
hierarchical controllers. This approach was developed for PCEs in
<xref target="RFC6805" /> and appears in various SDN architectures
where a "parent PCE", an "orchestrator", or "super controller" takes
responsibility for a high-level view of the network before distributing
tasks to lower level PCEs or controllers.</t>
<t>On its own, this approach does little to protect against the failure of
a controller, but it can make significant improvements in loading and
scaling of the individual controllers. It also offers a good way to
support end-to-end connectivity across multiple administrative or
technology-specific domains.</t>
<t>Note that this model can recurse arbitrarily with one PCE-based controller
acting as the parent of of another set of PCE-based controllers.</t>
<figure anchor="hierarchical_controller" title="Hierarchical Controllers">
<artwork align="center">
<![CDATA[
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| Parent | -----
| PCE-based |<---| TED |
| Controller | -----
| |
------------
^ ^
| |
v v
------------ ------------
----- | | | | -----
| TED |--->| PCE-based | | PCE-based |<---| TED |
----- | Controller | | Controller | -----
/| | | |\
/ ------------ ------------ \
/ ^ ^ ^ ^ \
/ | | | | \
/ | | | | \
| | | :: | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
]]>
</artwork>
</figure>
</section>
</section>
</section>
<section anchor="applicability" title="Applicability">
<t>This section gives a very high-level introduction to the applicability of a
PCE-based centralized controller. There is no attempt to explain each use case
in detail, and the inclusion of a use case is not intended to suggest that
deploying a PCE-based controller is a mandatory or recommended approach. The
sections below are provided as a stimulus to discussion of the applicability of
a PCE-based controller and it is expected that separate documents will be
written to develop the use cases in which there is interest for implementation
and deployment. As described in <xref target="protocols" /> specific enhancements
to PCEP may be needed for some of these use cases and it is expected that the
documents that develop each use case will also address any extensions to PCEP.</t>
<t>The rest of this section is divided into two sub-sections. The first approaches
the question of applicability from a consideration of the network technology. The
second looks at the high-level functions that can be delivered by using a PCE-based
controller.</t>
<t>As previously mentioned, this section is intended to just make suggestions. Thus the
material supplied is very brief. The omission of a use case is in no way meant to
imply some limit on the applicability of PCE-based control.</t>
<section anchor="tech-appl" title="Technology-Oriented Applicability">
<t>This section provides a list of use cases based on network technology.</t>
<section anchor="control-plane" title="Applicability to Control Plane Operated Networks">
<t>This mode of operation is the common approach for an active, stateful PCE to control
a traffic engineered MPLS or GMPLS network <xref target="I-D.ietf-pce-stateful-pce" />.
Note that the PCE-based controller determines what LSPs are needed and where to place
them. PCEP is used to instruct the head end of each LSP, and the head end signals in
the control plane to set up the LSP.</t>
</section>
<section anchor="static-LSPs" title="Static LSPs in MPLS">
<t>Static LSPs are provisioned without the use of a control plane. This means that
they are established using management plane or "manual" configuration.</t>
<t>Static LSPs can be provisioned as 1-hop, micro-LSPs at each node along the path of
an end-to-end path LSP. Each router along the path must be told what label forwarding
instructions to program and what resources to reserve. The PCE-based controller keeps
a view of the network and determines the paths of the end-to-end LSPs just as it does
for the use case described in <xref target="control-plane" />, but the controller uses
PCEP to communicate with each router along the path of the end-to-end LSP. In this
case the PCE-based controller will take responsibility for managing some part of the
MPLS label space for each of the routers that it controls.</t>
</section>
<section anchor="multicast" title="MPLS Multicast">
<t>Multicast LSPs may be provisioned with a control plane or as static LSPs. No extra
considerations apply above those in <xref target="control-plane" /> and
<xref target="static-LSPs" /> except, of course, to note that the PCE must also
include the instructions about where the LSP branches, i.e., where packets must be
copied.</t>
</section>
<section anchor="transport-SDN" title="Transport SDN">
<t>Transport SDN (T-SDN) is the application of SDN techniques to transport networks.
In this respect a transport network is a network built from any technology below
the IP layer and designed to carry traffic transparently in a connection-oriented
way. Thus, an MPLS traffic engineering network is a transport network although
it is more common to consider technologies such as Time Division Multiplexing
(TDM) and Optical Transport Networks (OTN).</t>
<t>Transport networks may be operated with or without a control plane and may have
point-to-point or point-to-multipoint connections. Thus, all of the considerations
in <xref target="control-plane" />, <xref target="static-LSPs" />, and
<xref target="multicast" /> apply. It may be the case that additional technology-
specific parameters are needed to configure the NEs and these parameters will need
to be carried in the PCEP messages.</t>
</section>
<section anchor="segment-routing" title="Segment Routing">
<t>Segment routing is described in <xref target="I-D.ietf-spring-segment-routing" />.
It relies on a series of forwarding instructions being placed in the header or a
packet: at each hop in the network a router looks at the first instruction and
may continue to forward the packet unchanged, strip the top instruction and forward
the packet, or strip the top instruction, insert some additional instructions, and
forward the packet.</t>
<t>The segment routing architecture supports operations that can be used to steer
packet flows in a network thus providing a form of traffic engineering. A PCE-based
controller can be responsible for computing the paths for packet flows in a segment
routing network, for configuring the forwarding actions on the routers, and for
telling the edge routers what instructions to attach to packets as they enter the
network. These last two operations can be achieved using PCEP and the PCE-based
controller will assume responsibility for managing the space of labels or path
identifiers used to determine how packets are forwarded.</t>
</section>
<section anchor="sfc" title="Service Function Chaining">
<t>Service Function Chaining (SFC) is described in <xref target="RFC7665" />. It is
the process of directing traffic in a network such that it passes through specific
hardware devices or virtual machines (known as service function nodes) that can
perform particular desired functions on the traffic. The set of functions to be
performed and the locations at which they are to be performed is known as service
function chain. Each packet is marked as belonging to a specific chain and that
marking lets each successive service function node know which functions to perform
and to which service function node to send the packet next.</t>
<t>To operate an SFC network the service function nodes must be configured to understand
the packet markings and the edge nodes must be told how to mark packets entering the
network. Additionally it may be necessary to establish tunnels between service function
nodes to carry the traffic.</t>
<t>Planning an SFC network requires load balancing between service function nodes and
traffic engineering across the network that connects them. These are operations that
can be performed by a PCE-based controller, and that controller can use PCEP to
program the network and install the service function chains and any required tunnels.</t>
</section>
</section>
<section anchor="high-appl" title="High-Level Applicability">
<t>This section provides a list of the high-level functions that can be delivered by using
a PCE-based controller.</t>
<section anchor="te" title="Traffic Engineering">
<t>According to <xref target="RFC2702" />, Traffic Engineering (TE) is concerned with
performance optimization of operational networks. In general, it encompasses the
application of technology and scientific principles to the measurement, modeling,
characterization, control of Internet traffic, and the application of such
knowledge and techniques to achieve specific performance objectives.</t>
<t>From a practical point of view this involves having an understanding of the topology
of the network, the characteristics of the nodes and links in the network, and the
traffic demands and flows across the network. It also requires that actions can be
taken to ensure that traffic follows specific paths through the network.</t>
<t>PCE was specifically developed to address TE in an MPLS network, and so a PCE-based
controller is well suited to analyze TE problems and supply answers that can be
installed in the network using PCEP. PCEP can be responsible for initiating paths
across the network through a control plane, or for installing state in the network
node by node such as in a Segment Routed network (see <xref target="segment-routing" />)
or by configuring IGP metrics.</t>
</section>
<section anchor="traffic" title="Traffic Classification">
<t>Traffic classification is an important part of traffic engineering. It is the
process of looking at a packet to determine how it should be treated as it is forwarded
through the network. It applies in many scenarios including MPLS traffic engineering
(where it determines what traffic is forwarded onto which LSPs), segment routing (where
it is used to select which set of forwarding instructions to add to a packet), and
service function chaining (where it indicates along which service function chain a
packet should be forwarded).</t>
<t>Traffic classification is closely linked to the computational elements of planning for the
network functions just listed because it determines how traffic load is balanced and
distributed through the network. Therefore, selecting what traffic classification should
be performed by a router is an important part of the work done by a PCE-based controller.</t>
<t>Instructions can be passed from the controller to the routers using PCEP. These instructions
tell the routers how to map traffic to paths or connections. The instructions may use the
concept of a Frowarding Equivalence Class (FEC).</t>
</section>
<section anchor="services" title="Service Delivery">
<t>Various network services may be offered over a network. These include protection services
(including end-to-end protection <xref target="RFC4427" />, restoration after failure,
and fast reroute <xref target="RFC4090" />), Virtual Private Network (VPN) service (such as
Layer 3 VPNs <xref target="RFC4364" /> or Ethernet VPNs <xref target="RFC7432" />), or
Pseudowires <xref target="RFC3985" />.</t>
<t>Delivering services over a network in an optimal way requires coordination in the way that
network resources are allocated to support the services. A PCE-based central control can
consider the whole network and all components of a service at once when planning how to
deliver the service. It can then use PCEP to manage the network resources and to install
the necessary associations between those resources.</t>
</section>
</section>
</section>
<section anchor="protocols" title="Protocol Implications">
<t>PCEP is push-pull protocol that is designed to move requests and responses between a server (the
PCE) and Path Computation Clients (PCCs - the network elements). In particular, it has a message
(PCInitiate <xref target="I-D.ietf-pce-pce-initiated-lsp" />) that can be sent by the PCE to install
state or cause actions at the PCC, and a response message (PCRpt) that is used to confirm the
request.</t>
<t>As such, no substantial changes to PCEP are required to support the concept of a PCE-based controller.
The only work needed will be small extensions to carry additional or specific information elements
for the individual use cases. Where possible, consistent with the general principles of how protocols
are extended, any additions to the protocol should be made in a generic way such that they are open
to use in a range of applications.</t>
<t>It is anticipated that new documents will be produced for each use case dependent on support and
demand. Such documents will explain the use case and define the necessary protocol extensions.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Security considerations for a PCE-based controller are little different from those for any other
PCE system. That is, the operation relies heavily on the use and security of PCEP and so consideration
should be given to the security features discussed in <xref target="RFC5440" /> and the additional
mechanisms described in <xref target="I-D.ietf-pce-pceps" />.</t>
<t>It should be observed that the trust model of a network that operates with out a control plane is
different from one with a control plane. The conventional "chain of trust" used with a control plane
is replaced by individual trust relationships between the controller and each individual NE. This
model may be considerably easier to manage and so is more likely to be operated with a high level
of security. However debate will rage over overall system security and the opportunity for attacks
in an architecture with a central controller since the network can be vulnerable to denial of service
attacks on the controller, and the forwarding system may be harmed by attacks on the messages sent
to individual routers. In short, while the interactions with a PCE-based controller are not
substantially different from those in any other SDN architecture, the security implications of SDN
are still open for discussion. The IRTF's SDN Research Group (SDNRG) continues to discuss this
topic.</t>
<t>It is expected that each new document that is produced for a specific use case will also include
considerations of the security impacts of the use of a PCE-based central controller on the network
type and services being managed.</t>
</section>
<section anchor="manageability" title="Manageability Considerations">
<t>The architecture described in this document is a management architecture: the PCE-based controller
is a management component that controls the network through a southbound management protocol (PCEP).</t>
<t>RFC 5440 <xref target="RFC5440" /> contains a substantive manageability considerations section that
examines how a PCE-based system and a PCE-enabled system may be managed. A MIB module for PCEP was
published as RFC 7420 <xref target="RFC7420"/> and a YANG module for PCEP has also been proposed
<xref target="I-D.pkd-pce-pcep-yang" />.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document makes no requests for IANA action.</t>
</section>
<section anchor="contrib" title="Contributors">
<t>The following people contributed to discussions that led to the
development of this document:</t>
<figure>
<artwork align="left">
<![CDATA[
Cyril Margaria
Email: cmargaria@juniper.net
Sudhir Cheruathur
Email: scheruathur@juniper.net
Dhruv Dhody
Email: dhruv.dhody@huawei.com
Daniel King
Email: daniel@olddog.co.uk
Iftekhar Hussain
Email: IHussain@infinera.com
Anurag Sharma
Email: AnSharma@infinera.com
Eric Wu
Email: eric.wu@huawei.com
]]>
</artwork>
</figure>
</section>
<section anchor="acks" title="Acknowledgements">
<t>The ideas in this document owe a lot to the work started by the
authors of <xref target="I-D.zhao-teas-pcecc-use-cases"/> and
<xref target="I-D.zhao-pce-pcep-extension-for-pce-controller"/>.
The authors of this document fully acknowledge the prior work and
thank those involved for opening the discussion. The individuals
concerned are: King Ke, Luyuan Fang, Chao Zhou, Boris Zhang,
Zhenbin Li.</t>
<t>This document has benefited from the discussions within a small
ad hoc design team the members of which are listed as document
contributors.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC4655;
</references>
<references title="Informative References">
&RFC2702;
&RFC3985;
&RFC4090;
&RFC4364;
&RFC4427;
&RFC5440;
&RFC6805;
&RFC7025;
&RFC7399;
&RFC7420;
&RFC7432;
&RFC7491;
&RFC7665;
<?rfc include="reference.I-D.ietf-pce-pceps"?>
<?rfc include="reference.I-D.ietf-pce-stateful-pce"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp"?>
<?rfc include="reference.I-D.ietf-spring-segment-routing"?>
<?rfc include="reference.I-D.zhao-teas-pcecc-use-cases"?>
<?rfc include="reference.I-D.zhao-pce-pcep-extension-for-pce-controller"?>
<?rfc include="reference.I-D.pkd-pce-pcep-yang"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:06:25 |