PCE-Based Traffic Engineering (TE) in Native IP Networks
RFC 8821

Document Type RFC - Informational (April 2021; No errata)
Authors Aijun Wang  , Boris Khasanov  , Quintin Zhao  , Huaimo Chen 
Last updated 2021-04-05
Replaces draft-wang-teas-pce-native-ip
Stream Internet Engineering Task Force (IETF)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Lou Berger
Shepherd write-up Show (last changed 2020-12-18)
IESG IESG state RFC 8821 (Informational)
Action Holders
Consensus Boilerplate Yes
Telechat date
Responsible AD Deborah Brungard
Send notices to Lou Berger <lberger@labn.net>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions

Internet Engineering Task Force (IETF)                           A. Wang
Request for Comments: 8821                                 China Telecom
Category: Informational                                      B. Khasanov
ISSN: 2070-1721                                               Yandex LLC
                                                                 Q. Zhao
                                                        Etheric Networks
                                                                 H. Chen
                                                              April 2021

        PCE-Based Traffic Engineering (TE) in Native IP Networks


   This document defines an architecture for providing traffic
   engineering in a native IP network using multiple BGP sessions and a
   Path Computation Element (PCE)-based central control mechanism.  It
   defines the Centralized Control Dynamic Routing (CCDR) procedures and
   identifies needed extensions for the Path Computation Element
   Communication Protocol (PCEP).

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  CCDR Architecture in a Simple Topology
   4.  CCDR Architecture in a Large-Scale Topology
   5.  CCDR Multiple BGP Sessions Strategy
   6.  PCEP Extension for Critical Parameters Delivery
   7.  Deployment Considerations
     7.1.  Scalability
     7.2.  High Availability
     7.3.  Incremental Deployment
     7.4.  Loop Avoidance
     7.5.  E2E Path Performance Monitoring
   8.  Security Considerations
   9.  IANA Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Authors' Addresses

1.  Introduction

   [RFC8283], based on an extension of the PCE architecture described in
   [RFC4655], introduced a broader use applicability for a PCE as a
   central controller.  PCEP continues to be used as the protocol
   between the PCE and the Path Computation Client (PCC).  Building on
   that work, this document describes a solution of using a PCE for
   centralized control in a native IP network to provide end-to-end
   (E2E) performance assurance and QoS for traffic.  The solution
   combines the use of distributed routing protocols and a centralized
   controller, referred to as Centralized Control Dynamic Routing

   [RFC8735] describes the scenarios and simulation results for traffic
   engineering in a native IP network based on use of a CCDR
   architecture.  Per [RFC8735], the architecture for traffic
   engineering in a native IP network should meet the following

   *  Same solution for native IPv4 and IPv6 traffic.

   *  Support for intra-domain and inter-domain scenarios.

   *  Achieve E2E traffic assurance, with determined QoS behavior, for
      traffic requiring a service assurance (prioritized traffic).

   *  No changes in a router's forwarding behavior.

   *  Based on centralized control through a distributed network control

   *  Support different network requirements such as high traffic volume
      and prefix scaling.

   *  Ability to adjust the optimal path dynamically upon the changes of
      network status.  No need for reserving resources for physical
      links in advance.

   Building on the above documents, this document defines an
   architecture meeting these requirements by using a strategy of
   multiple BGP sessions and a PCE as the centralized controller.  The
   architecture depends on the central control element (PCE) to compute
   the optimal path and utilizes the dynamic routing behavior of IGP and
Show full document text