Scenarios and Simulation Results of PCE in a Native IP Network
RFC 8735
Internet Engineering Task Force (IETF) A. Wang
Request for Comments: 8735 China Telecom
Category: Informational X. Huang
ISSN: 2070-1721 C. Kou
BUPT
Z. Li
China Mobile
P. Mi
Huawei Technologies
February 2020
Scenarios and Simulation Results of PCE in a Native IP Network
Abstract
Requirements for providing the End-to-End (E2E) performance assurance
are emerging within the service provider networks. While there are
various technology solutions, there is no single solution that can
fulfill these requirements for a native IP network. In particular,
there is a need for a universal E2E solution that can cover both
intra- and inter-domain scenarios.
One feasible E2E traffic-engineering solution is the addition of
central control in a native IP network. This document describes
various complex scenarios and simulation results when applying the
Path Computation Element (PCE) in a native IP network. This
solution, referred to as Centralized Control Dynamic Routing (CCDR),
integrates the advantage of using distributed protocols and the power
of a centralized control technology, providing traffic engineering
for native IP networks in a manner that applies equally to intra- and
inter-domain scenarios.
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
https://www.rfc-editor.org/info/rfc8735.
Copyright Notice
Copyright (c) 2020 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 Scenarios
3.1. QoS Assurance for Hybrid Cloud-Based Application
3.2. Link Utilization Maximization
3.3. Traffic Engineering for Multi-domain
3.4. Network Temporal Congestion Elimination
4. CCDR Simulation
4.1. Case Study for CCDR Algorithm
4.2. Topology Simulation
4.3. Traffic Matrix Simulation
4.4. CCDR End-to-End Path Optimization
4.5. Network Temporal Congestion Elimination
5. CCDR Deployment Consideration
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
1. Introduction
A service provider network is composed of thousands of routers that
run distributed protocols to exchange reachability information. The
path for the destination network is mainly calculated, and
controlled, by the distributed protocols. These distributed
protocols are robust enough to support most applications; however,
they have some difficulties supporting the complexities needed for
traffic-engineering applications, e.g., E2E performance assurance, or
maximizing the link utilization within an IP network.
Multiprotocol Label Switching (MPLS) using Traffic-Engineering (TE)
technology (MPLS-TE) [RFC3209] is one solution for TE networks, but
it introduces an MPLS network along with related technology, which
would be an overlay of the IP network. MPLS-TE technology is often
used for Label Switched Path (LSP) protection and setting up complex
paths within a domain. It has not been widely deployed for meeting
E2E (especially in inter-domain) dynamic performance assurance
requirements for an IP network.
Show full document text