An Architecture for Use of PCE and PCEP in a Network with Central Control
draft-zhao-teas-pce-control-function-01

Document Type Replaced Internet-Draft (teas WG)
Last updated 2016-06-28 (latest revision 2016-05-24)
Replaced by draft-ietf-teas-pce-central-control
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Candidate for WG Adoption
Document shepherd No shepherd assigned
IESG IESG state Replaced by draft-ietf-teas-pce-central-control
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-zhao-teas-pce-control-function-01.txt

Abstract

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.

Authors

Adrian Farrel (adrian@olddog.co.uk)
Quintin Zhao (quintin.zhao@huawei.com)
Zhenbin Li (lizhenbin@huawei.com)
Chao Zhou (chao.zhou@cisco.com)

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