draft-ietf-teas-pce-central-control-04.txt   draft-ietf-teas-pce-central-control-05.txt 
TEAS Working Group A. Farrel, Ed. TEAS Working Group A. Farrel, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational Q. Zhao, Ed. Intended status: Informational Q. Zhao, Ed.
Expires: February 25, 2018 R. Li Expires: March 8, 2018 R. Li
Huawei Technologies Huawei Technologies
C. Zhou C. Zhou
Cisco Systems Cisco Systems
August 24, 2017 September 4, 2017
An Architecture for Use of PCE and PCEP in a Network with Central An Architecture for Use of PCE and PCEP in a Network with Central
Control Control
draft-ietf-teas-pce-central-control-04 draft-ietf-teas-pce-central-control-05
Abstract Abstract
The Path Computation Element (PCE) has become established as a core The Path Computation Element (PCE) is a core component of Software
component of Software Defined Networking (SDN) systems. It can Defined Networking (SDN) systems. It can compute optimal paths for
compute optimal paths for traffic across a network for most traffic across a network and can also update the paths to reflect
definitions of "optimal" and can also monitor changes in resource changes in the network or traffic demands.
availability and traffic demands to update the paths.
Conventionally, the PCE has been used to derive paths for MPLS Label PCE was developed to derive paths for MPLS Label Switched Paths
Switched Paths (LSPs). These paths are supplied using the Path (LSPs) supplying them to the head end of the LSP using the Path
Computation Element Communication Protocol (PCEP) to the head end of Computation Element Communication Protocol (PCEP).
the LSP for signaling in the MPLS network.
SDN has a far broader applicability than just signaled MPLS traffic SDN has a broader applicability than signaled MPLS traffic engineered
engineered networks, and the PCE may be used to determine paths in a networks, and the PCE may be used to determine paths in a range of
wide range of use cases including static LSPs, segment routing, use cases including static LSPs, segment routing, service function
service function chaining (SFC), and indeed most forms of routed or chaining, and most forms of routed or switched network. It is,
switched network. It is, therefore, reasonable to consider PCEP as a therefore, reasonable to consider PCEP as a control protocol for use
control protocol for use in these environments to allow the PCE to be in these environments to allow the PCE to be fully enabled as a
fully enabled as a central controller. central controller.
This document briefly introduces the architecture for PCE as a This document briefly introduces the architecture for PCE as a
central controller, examines the motivations and applicability for central controller, examines the motivations and applicability for
PCEP as a control protocol in this environment, and introduces the PCEP as a control protocol in this environment, and introduces the
implications for the protocol. A PCE-based central controller can implications for the protocol. A PCE-based central controller can
simplify the processing of distributed control plane by blending it simplify the processing of distributed control plane by blending it
with elements of SDN and without necessarily completely replacing it. with elements of SDN and without necessarily completely replacing it.
This document does not describe use cases in detail and does not This document does not describe use cases in detail and does not
define protocol extensions: that work is left for other documents. define protocol extensions: that work is left for other documents.
skipping to change at page 2, line 20 skipping to change at page 2, line 15
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 25, 2018. This Internet-Draft will expire on March 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 15 skipping to change at page 3, line 9
3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16 3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16
3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16 3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16
3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17 3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17
3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17 3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17
4. Protocol Implications / Guidance for Solution Developers . . 18 4. Protocol Implications / Guidance for Solution Developers . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Manageability Considerations . . . . . . . . . . . . . . . . 19 6. Manageability Considerations . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Path Computation Element (PCE) [RFC4655] was developed to offload The Path Computation Element (PCE) [RFC4655] was developed to offload
path computation function from routers in an MPLS traffic engineered path computation function from routers in an MPLS traffic engineered
network. Since then, the role and function of the PCE has grown to network. Since then, the role and function of the PCE has grown to
cover a number of other uses (such as GMPLS [RFC7025]) and to allow cover a number of other uses (such as GMPLS [RFC7025]) and to allow
delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use
of network resources [I-D.ietf-pce-pce-initiated-lsp]. of network resources [I-D.ietf-pce-pce-initiated-lsp].
skipping to change at page 5, line 9 skipping to change at page 5, line 5
held in the Traffic Engineering Database (TED) and other databases held in the Traffic Engineering Database (TED) and other databases
available to the PCE. Then the PCE sends a request using PCEP to one 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 of the Network Elements (NEs), and that NE uses a control plane to
establish the requested connections and reserve the network establish the requested connections and reserve the network
resources. resources.
Note that other databases (such as a database of LSPs - the LSP-DB) Note that other databases (such as a database of LSPs - the LSP-DB)
might also be used, but for simplicity of illustration, just the TED might also be used, but for simplicity of illustration, just the TED
is shown. is shown.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^
| |
v v
------------ ------------
| | ----- | | -----
| PCE-based |<---| TED | | PCE-based |<---| TED |
| Controller | ----- | Controller | -----
| | | |
------------ ------------
^ ^
PCEP| PCEP|
v v
---- ---- ---- ---- ---- ---- ---- ----
| NE |<------->| NE |<--->| NE |<--->| NE | | NE |<--------->| NE |<--->| NE |<--->| NE |
---- Control ---- ---- ---- ---- Signaling ---- ---- ----
Plane Protocol
Figure 1: Architecture for Central Controller with Control Plane Figure 1: Architecture for Central Controller with Control Plane
Although the architecture shown in Figure 1 represents a form of SDN, Although the architecture shown in Figure 1 represents a form of SDN,
one objective of SDN in some environments is to remove the dependency one objective of SDN in some environments is to remove the dependency
on a control plane. A transition architecture toward this goal is on a control plane. A transition architecture toward this goal is
presented in [RFC7491] and is shown in Figure 2. In this case, presented in [RFC7491] and is shown in Figure 2. In this case,
services are still requested in the same way, and the PCE-based services are still requested in the same way, and the PCE-based
controller still requests use of the network using PCEP. The main controller still requests use of the network using PCEP. The main
difference is that the consumer of the PCEP messages is a Network difference is that the consumer of the PCEP messages is a Network
Controller that provisions the resources and instructs the data plane Controller that provisions the resources and instructs the data plane
using a Southbound Interface (SBI) that provides an interface to each using a Southbound Interface (SBI) that provides an interface to each
NE. NE.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^
| |
v v
------------ ------------
| | ----- | | -----
| PCE-based |<---| TED | | PCE-based |<---| TED |
| Controller | ----- | Controller | -----
| | | |
------------ ------------
^ ^
| PCEP | PCEP
v v
------------ ------------
| Network | | Network |
| Controller | | Controller |
/------------\ /------------\
SBI / ^ ^ \ SBI / ^ ^ \
/ | | \ / | | \
/ v v \ / v v \
----/ ---- ---- \---- ----/ ---- ---- \----
| NE | | NE | | NE | | NE | | NE | | NE | | NE | | NE |
---- ---- ---- ---- ---- ---- ---- ----
Figure 2: Architecture Including a Network Controller Figure 2: Architecture Including a Network Controller
The approach in Figure 2 delivers the SDN functionality but is overly The approach in Figure 2 delivers the SDN functionality but is overly
complicated and insufficiently flexible. complicated and insufficiently flexible.
o The complication is created by the use of two controllers in a o The complication is created by the use of two controllers in a
hierarchical organization, and the resultant use of two protocols hierarchical organization, and the resultant use of two protocols
in a southbound direction. in a southbound direction.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
There will be a trade-off in different application scenarios. In There will be a trade-off in different application scenarios. In
some cases the use of a control plane will simplify deployment (for some cases the use of a control plane will simplify deployment (for
example, by distributing recovery actions), and in other cases a example, by distributing recovery actions), and in other cases a
control plane may add operational complexity. control plane may add operational complexity.
PCEP is essentially already capable of acting as an SBI and only PCEP is essentially already capable of acting as an SBI and only
small, use case specific modifications to the protocol are needed to small, use case specific modifications to the protocol are needed to
support this architecture. The implications for the protocol are support this architecture. The implications for the protocol are
discussed further in Section 4. discussed further in Section 4.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^
| |
v v
------------ ------------
| | ----- | | -----
| PCE-based |<---| TED | | PCE-based |<---| TED |
| Controller | ----- | Controller | -----
| | | |
/------------\ /------------\
PCEP / ^ ^ \ PCEP / ^ ^ \
/ | | \ / | | \
/ v v \ / v v \
/ ---- ---- \ / ---- ---- \
/ | NE | | NE | \ / | NE | | NE | \
----/ ---- ---- \---- ----/ ---- ---- \----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
^ ---- ---- ^ ^ ---- ---- ^
:......>| NE |...| NE |<....: :......>| NE |...| NE |<....:
Control Plane ---- ---- Signaling Protocol ---- ----
Figure 3: Architecture for Node-by-Node Central Control Figure 3: Architecture for Node-by-Node Central Control
2.1. Resilience and Scaling 2.1. Resilience and Scaling
Systems with central controllers are vulnerable to two problems: Systems with central controllers are vulnerable to two problems:
failure of the controller or overload of the controller. These failure of the controller or overload of the controller. These
concerns are not unique to the use of a PCE-based controller, but 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 need to be addressed in this document before the PCE-based controller
architecture can be considered for use in all but the smallest architecture can be considered for use in all but the smallest
skipping to change at page 8, line 20 skipping to change at page 8, line 20
For simplicity of illustration, these three approaches are shown in For simplicity of illustration, these three approaches are shown in
the sections that follow without a control plane. However, the the sections that follow without a control plane. However, the
general, hybrid approach of Figure 3 is applicable in each case. general, hybrid approach of Figure 3 is applicable in each case.
2.1.1. Partitioned Network 2.1.1. Partitioned Network
The first and simplest approach to handling controller overload or The first and simplest approach to handling controller overload or
scalability is to use multiple controllers, each responsible for a scalability is to use multiple controllers, each responsible for a
part of the network. We can call the resultant areas of control part of the network. We can call the resultant areas of control
"domains." "domains" [RFC4655].
This approach is shown in Figure 4. It can clearly address some of This approach is shown in Figure 4. It can clearly address some of
the scaling and overload concerns since each controller now only has the scaling and overload concerns since each controller now only has
responsibility for a subset of the network elements. But this comes responsibility for a subset of the network elements. But this comes
at a cost because end-to-end connections require coordination between at a cost because end-to-end connections require coordination between
the controllers. Furthermore, this technique does not remove the the controllers. Furthermore, this technique does not remove the
single-point-of-failure concern even if it does reduce the impact on single-point-of-failure concern even if it does reduce the impact on
the network of the failure of a single controller. the network of the failure of a single controller.
Note that PCEP is designed to work as a PCE-to-PCE protocol as well Note that PCEP is designed to work as a PCE-to-PCE protocol as well
skipping to change at page 11, line 48 skipping to change at page 11, line 48
state changes in the network are not to be lost. Furthermore, if state changes in the network are not to be lost. Furthermore, if
there are more than two controllers, the synchronization between there are more than two controllers, the synchronization between
controllers can become a hard problem. controllers can become a hard problem.
Synchronization issues are often off-loaded as "database Synchronization issues are often off-loaded as "database
synchronization" problems because distributed database packages have synchronization" problems because distributed database packages have
already had to address these challenges, or by using a shared already had to address these challenges, or by using a shared
database. In networking the problem may also be addressed by database. In networking the problem may also be addressed by
collecting the state from the network (effectively using the network collecting the state from the network (effectively using the network
as a database) using normal routing protocols such as OSPF, IS-IS, as a database) using normal routing protocols such as OSPF, IS-IS,
and BGP. and BGP. It should be noted that addressing the synchronization
problem through a shared database may be hiding the issues of
congestion and of a single point of failure: whole the controllers
may have been made resilient by allowing redundancy, the shared
database is still a problem and so the whole system is still
vulnerable.
2.1.3. Hierarchical Controllers 2.1.3. Hierarchical Controllers
Figure 7 shows an approach with hierarchical controllers. This Figure 7 shows an approach with hierarchical controllers. This
approach was developed for PCEs in [RFC6805] and appears in various approach was developed for PCEs in [RFC6805] and appears in various
SDN architectures where a "parent PCE", an "orchestrator", or "super SDN architectures where a "parent PCE", an "orchestrator", or "super
controller" takes responsibility for a high-level view of the network controller" takes responsibility for a high-level view of the network
before distributing tasks to lower level PCEs or controllers. before distributing tasks to lower level PCEs or controllers.
On its own, this approach does little to protect against the failure On its own, this approach does little to protect against the failure
skipping to change at page 14, line 31 skipping to change at page 14, line 31
3.1.1. Applicability to Control Plane Operated Networks 3.1.1. Applicability to Control Plane Operated Networks
This mode of operation is the common approach for an active, stateful This mode of operation is the common approach for an active, stateful
PCE to control a traffic engineered MPLS or GMPLS network PCE to control a traffic engineered MPLS or GMPLS network
[I-D.ietf-pce-stateful-pce]. Note that the PCE-based controller [I-D.ietf-pce-stateful-pce]. Note that the PCE-based controller
determines what LSPs are needed and where to place them. PCEP is 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 used to instruct the head end of each LSP, and the head end signals
in the control plane to set up the LSP. in the control plane to set up the LSP.
In this mode of operation, the PCE may construct its TED in a number
of ways as described in [RFC4655] including (but not limited to)
participating in the IGP or receiving information from a network
element via BGP-LS [RFC7752].
3.1.2. Static LSPs in MPLS 3.1.2. Static LSPs in MPLS
Static LSPs are provisioned without the use of a control plane. This Static LSPs are provisioned without the use of a control plane. This
means that they are established using management plane or "manual" means that they are established using management plane or "manual"
configuration. configuration.
Static LSPs can be provisioned as explicit label instructions at each Static LSPs can be provisioned as explicit label instructions at each
hop on the end-to-end path LSP. Each router along the path must be hop on the end-to-end path LSP. Each router along the path must be
told what label forwarding instructions to program and what resources told what label forwarding instructions to program and what resources
to reserve. The PCE-based controller keeps a view of the network and to reserve. The PCE-based controller keeps a view of the network and
skipping to change at page 19, line 51 skipping to change at page 19, line 51
The architecture described in this document is a management The architecture described in this document is a management
architecture: the PCE-based controller is a management component that architecture: the PCE-based controller is a management component that
controls the network through a southbound management protocol (PCEP). controls the network through a southbound management protocol (PCEP).
An implementation of a PCE-based controller will require access to An implementation of a PCE-based controller will require access to
information about the state of the network, its nodes, and its links. information about the state of the network, its nodes, and its links.
Some of this will be the TED as is normal for a PCE and can be Some of this will be the TED as is normal for a PCE and can be
collected using the mechanisms already in place (such as listening to collected using the mechanisms already in place (such as listening to
the IGPs, using BGP-LS [RFC7752], or northbound export of YANG- the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-
encoded data [I-D.ietf-teas-yang-te-topo]). More information may be encoded data [I-D.ietf-teas-yang-te-topo] from the network elements
collected in the LSP database as described for stateful PCEs as to the controller). More information may be collected in the LSP
described in [RFC7399] and [I-D.ietf-pce-stateful-pce]. Additional database as described for stateful PCEs as described in [RFC7399] and
information may be needed for other specific use cases and will need [I-D.ietf-pce-stateful-pce]. Additional information may be needed
to be collected and passed to the controller. for other specific use cases and will need to be collected and passed
to the controller. This may require protocol extensions for the
mechanisms listed in this paragraph.
The use of different PCEP options and protocol extensions may have an The use of different PCEP options and protocol extensions may have an
impact on interoperability, which is a management issue. As noted in impact on interoperability, which is a management issue. As noted in
Section 4, protocol extensions should be done in a way that makes it Section 4, protocol extensions should be done in a way that makes it
possible to identify profiles of PCEP to aid interoperability and possible to identify profiles of PCEP to aid interoperability and
this will aid deployment and manageability. this will aid deployment and manageability.
RFC 5440 [RFC5440] contains a substantive manageability RFC 5440 [RFC5440] contains a substantive manageability
considerations section that examines how a PCE-based system and a considerations section that examines how a PCE-based system and a
PCE-enabled system may be managed. A MIB module for PCEP was PCE-enabled system may be managed. A MIB module for PCEP was
skipping to change at page 21, line 24 skipping to change at page 21, line 45
This document has benefited from the discussions within a small ad This document has benefited from the discussions within a small ad
hoc design team the members of which are listed as document hoc design team the members of which are listed as document
contributors. contributors.
Thanks to Michael Scharf and Andy Malis for a lively discussion of Thanks to Michael Scharf and Andy Malis for a lively discussion of
this document. this document.
Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call
comments on this document. comments on this document.
Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful
comments during IESG review.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-10 (work in Model", draft-ietf-pce-pce-initiated-lsp-10 (work in
progress), June 2017. progress), June 2017.
 End of changes. 16 change blocks. 
97 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/