Skip to main content

An Architecture for Use of PCE and PCEP in a Network with Central Control

Document Type Replaced Internet-Draft (teas WG)
Expired & archived
Authors Adrian Farrel , Quintin Zhao , Zhenbin Li , Chao Zhou
Last updated 2016-06-28 (Latest revision 2016-05-24)
Replaced by draft-ietf-teas-pce-central-control
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Additional resources Mailing list discussion
Stream WG state Candidate for WG Adoption
Document shepherd (None)
IESG IESG state Replaced by draft-ietf-teas-pce-central-control
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


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. 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. 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. 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.


Adrian Farrel
Quintin Zhao
Zhenbin Li
Chao Zhou

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)