draft-ietf-teas-native-ip-scenarios-11.txt   draft-ietf-teas-native-ip-scenarios-12.txt 
TEAS Working Group A. Wang TEAS Working Group A. Wang
Internet-Draft China Telecom Internet-Draft China Telecom
Intended status: Informational X. Huang Intended status: Informational X. Huang
Expires: April 27, 2020 C. Kou Expires: May 1, 2020 C. Kou
BUPT BUPT
Z. Li Z. Li
China Mobile China Mobile
P. Mi P. Mi
Huawei Technologies Huawei Technologies
October 25, 2019 October 29, 2019
Scenarios and Simulation Results of PCE in Native IP Network Scenarios and Simulation Results of PCE in Native IP Network
draft-ietf-teas-native-ip-scenarios-11 draft-ietf-teas-native-ip-scenarios-12
Abstract Abstract
Requirements for providing the End to End(E2E) performance assurance Requirements for providing the End to End(E2E) performance assurance
are emerging within the service provider networks. While there are are emerging within the service provider networks. While there are
various technology solutions, there is no single solution that can various technology solutions, there is no single solution that can
fulfill these requirements for a native IP network. In particular, fulfill these requirements for a native IP network. In particular,
there is a need for a universal (E2E) solution that is simultaneously there is a need for a universal (E2E) solution that can cover both
applicable for both intra- and inter-domain scenarios. intra- and inter-domain scenarios.
One feasible E2E traffic engineering solution is the addition of One feasible E2E traffic engineering solution is the addition of
central control in a native IP network. This document describes central control in a native IP network. This document describes
various complex scenarios and simulation results when applying the various complex scenarios and simulation results when applying the
Path Computation Element (PCE) in a native IP network. This Path Computation Element (PCE) in a native IP network. This
solution, referred to as Centralized Control Dynamic Routing (CCDR), solution, referred to as Centralized Control Dynamic Routing (CCDR),
integrates the advantage of using distributed protocols and the power integrates the advantage of using distributed protocols and the power
of a centralized control technology, providing traffic engineering of a centralized control technology, providing traffic engineering
for native IP networks in a manner that applies equally to intra- and for native IP networks in a manner that applies equally to intra- and
inter-domain scenarios. inter-domain scenarios.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 27, 2020. This Internet-Draft will expire on May 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. CCDR Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 3. CCDR Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. QoS Assurance for Hybrid Cloud-based Application . . . . 4 3.1. QoS Assurance for Hybrid Cloud-based Application . . . . 4
3.2. Link Utilization Maximization . . . . . . . . . . . . . . 5 3.2. Link Utilization Maximization . . . . . . . . . . . . . . 5
3.3. Traffic Engineering for Multi-Domain . . . . . . . . . . 6 3.3. Traffic Engineering for Multi-Domain . . . . . . . . . . 6
3.4. Network Temporal Congestion Elimination . . . . . . . . . 7 3.4. Network Temporal Congestion Elimination . . . . . . . . . 7
4. CCDR Simulation . . . . . . . . . . . . . . . . . . . . . . . 7 4. CCDR Simulation . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Case Study for CCDR algorithm . . . . . . . . . . . . . . 8 4.1. Case Study for CCDR Algorithm . . . . . . . . . . . . . . 8
4.2. Topology Simulation . . . . . . . . . . . . . . . . . . . 10 4.2. Topology Simulation . . . . . . . . . . . . . . . . . . . 9
4.3. Traffic Matrix Simulation . . . . . . . . . . . . . . . . 10 4.3. Traffic Matrix Simulation . . . . . . . . . . . . . . . . 10
4.4. CCDR End-to-End Path Optimization . . . . . . . . . . . . 11 4.4. CCDR End-to-End Path Optimization . . . . . . . . . . . . 10
4.5. Network Temporal Congestion Elimination . . . . . . . . . 12 4.5. Network Temporal Congestion Elimination . . . . . . . . . 12
5. CCDR Deployment Consideration . . . . . . . . . . . . . . . . 14 5. CCDR Deployment Consideration . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
A service provider network is composed of thousands of routers that A service provider network is composed of thousands of routers that
run distributed protocols to exchange the reachability information. run distributed protocols to exchange the reachability information.
The path for the destination network is mainly calculated, and The path for the destination network is mainly calculated, and
controlled, by the distributed protocols. These distributed controlled, by the distributed protocols. These distributed
protocols are robust enough to support most applications, but have protocols are robust enough to support most applications, however,
some difficulties supporting the complexities needed for traffic they have some difficulties supporting the complexities needed for
engineering applications, e.g. E2E performance assurance, or traffic engineering applications, e.g. E2E performance assurance, or
maximizing the link utilization within an IP network. maximizing the link utilization within an IP network.
Multiprotocol Label Switching (MPLS) using Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) using Traffic Engineering (TE)
technology (MPLS-TE)[RFC3209]is one solution for traffic engineering technology (MPLS-TE)[RFC3209]is one solution for traffic engineering
networks but it introduces an MPLS network and related technology networks but it introduces an MPLS network and related technology
which would be an overlay of the IP network. MPLS-TE technology is which would be an overlay of the IP network. MPLS-TE technology is
often used for Label Switched Path (LSP) protection and complex path often used for Label Switched Path (LSP) protection and complex path
set-up within a domain. set-up within a domain. It has not been widely deployed for meeting
E2E (especially in inter-domain) dynamic performance assurance
It has not been widely deployed for meeting E2E (especially in inter- requirements for an IP network.
domain) dynamic performance assurance requirements for an IP network.
Segment Routing [RFC8402] is another solution that integrates some Segment Routing [RFC8402] is another solution that integrates some
advantages of using a distributed protocol and a centrally control advantages of using a distributed protocol and a centrally control
technology, but it requires the underlying network, especially the technology, but it requires the underlying network, especially the
provider edge router, to do a label push and pop action in-depth, and provider edge router, to do a label push and pop action in-depth, and
adds complexity when coexisting with the Non-Segment Routing network. adds complexity when coexisting with the Non-Segment Routing network.
Additionally, it can only maneuver the E2E paths for MPLS and IPv6 Additionally, it can only maneuver the E2E paths for MPLS and IPv6
traffic via different mechanisms. traffic via different mechanisms.
Deterministic Networking (DetNet)[RFC8578] is another possible Deterministic Networking (DetNet)[RFC8578] is another possible
skipping to change at page 3, line 42 skipping to change at page 3, line 41
complexity of deterministic properties and so differ from the DetNet complexity of deterministic properties and so differ from the DetNet
use cases. use cases.
This draft describes several scenarios for a native IP network where This draft describes several scenarios for a native IP network where
a Centralized Control Dynamic Routing (CCDR) framework can produce a Centralized Control Dynamic Routing (CCDR) framework can produce
qualitative improvement in efficiency without requiring a change of qualitative improvement in efficiency without requiring a change of
the data-plane behavior on the router. Using knowledge of BGP(Border the data-plane behavior on the router. Using knowledge of BGP(Border
Gateway Protocol) session-specific prefixes advertised by a router, Gateway Protocol) session-specific prefixes advertised by a router,
the network topology and the near real time link utilization the network topology and the near real time link utilization
information from network management systems, a central PCE is able to information from network management systems, a central PCE is able to
compute an optimal path and give the underly routers the destination compute an optimal path and give the underlay routers the destination
address to use to reach the BGP nexthop, such that the distributed address to use to reach the BGP nexthop, such that the distributed
routing protocol will use the computed path via traditional recursive routing protocol will use the computed path via traditional recursive
lookup procedure. Some results from simulations of path optimization lookup procedure. Some results from simulations of path optimization
are also presented, to concretely illustrate a variety of scenarios are also presented, to concretely illustrate a variety of scenarios
where CCDR shows significant improvement over traditional distributed where CCDR shows significant improvement over traditional distributed
routing protocols. routing protocols.
This draft is the base document of the following two drafts: the This draft is the base document of the following two drafts: the
universal solution draft, which is suitable for intra-domain and universal solution draft, which is suitable for intra-domain and
inter-domain TE scenario, is described in inter-domain TE scenario, is described in
skipping to change at page 6, line 41 skipping to change at page 6, line 40
+----|---+ +----|---+
| CR | | CR |
+----|---+ +----|---+
| |
--------|--------|-------| --------|--------|-------|
| | | | | | | |
+--|-+ +-|- +--|-+ +-|+ +--|-+ +-|- +--|-+ +-|+
|BRAS-----SR| |BRAS-----SR| |BRAS-----SR| |BRAS-----SR|
+----+ +--+ +----+ +--+ +----+ +--+ +----+ +--+
Figure 3: Link Utilization Maximization via CCDR Figure 3: Link Utilization Maximization via CCDR
3.3. Traffic Engineering for Multi-Domain 3.3. Traffic Engineering for Multi-Domain
Service provider networks are often comprised of different domains, Service provider networks are often comprised of different domains,
interconnected with each other,forming a very complex topology as interconnected with each other, forming a very complex topology as
illustrated in Figure 4. Due to the traffic pattern to/from the MAN illustrated in Figure 4. Due to the traffic pattern to/from the MAN
and IDC, the utilization of the links between them are often and IDC, the utilization of the links between them are often
asymmetric. It is almost impossible to balance the utilization of asymmetric. It is almost impossible to balance the utilization of
these links via a distributed protocol, but this unbalance can be these links via a distributed protocol, but this unbalance can be
overcome utilizing the CCDR framework. overcome utilizing the CCDR framework.
+---+ +---+ +---+ +---+
|MAN|-----------------IDC| |MAN|-----------------IDC|
+-|-| | +-|-+ +-|-| | +-|-+
| ---------| | | ---------| |
skipping to change at page 7, line 51 skipping to change at page 7, line 51
the workings of the CCDR algorithm with concrete paths/metrics, as the workings of the CCDR algorithm with concrete paths/metrics, as
well as a procedure for generating topology and traffic matrices and well as a procedure for generating topology and traffic matrices and
the results from simulations applying CCDR for E2E QoS (assured path the results from simulations applying CCDR for E2E QoS (assured path
and congestion elimination) over the generated topologies and traffic and congestion elimination) over the generated topologies and traffic
matrices. In all cases examined, the CCDR algorithm produces matrices. In all cases examined, the CCDR algorithm produces
qualitatively significant improvement over the reference (OSPF) qualitatively significant improvement over the reference (OSPF)
algorithm, suggesting that CCDR will have broad applicability. algorithm, suggesting that CCDR will have broad applicability.
The structure and scale of the simulated topology is similar to that The structure and scale of the simulated topology is similar to that
of the real networks. Multiple different traffic matrices were of the real networks. Multiple different traffic matrices were
generated to simulate different congestion conditions in the network, generated to simulate different congestion conditions in the network.
but only one of them is illustrated since the others produce similar
Only one of them is illustrated since the others produce similar
results. results.
4.1. Case Study for CCDR algorithm 4.1. Case Study for CCDR Algorithm
In this section we consider a specific network topology for a worked In this section we consider a specific network topology for case
case study, examining the path selected by OSPF and CCDR and study, examining the path selected by OSPF and CCDR and evaluating
evaluating how and why the paths differ. Figure 5 depicts the how and why the paths differ. Figure 5 depicts the topology of the
topology of the network in question. There are 8 forwarding devices network in this case. There are 8 forwarding devices in the network.
in the network. The original cost and utilization are marked on it, The original cost and utilization are marked on it, as shown in the
as shown in the figure. For example, the original cost and figure. For example, the original cost and utilization for the link
utilization for the link (1,2) are 3 and 50% respectively. There are (1,2) are 3 and 50% respectively. There are two flows: f1 and f2.
two flows: f1 and f2. Both of these two flows are from node 1 to Both of these two flows are from node 1 to node 8. For simplicity,
node 8. For simplicity, it is assumed that the bandwidth of the link it is assumed that the bandwidth of the link in the network is 10Mb/
in the network is 10Mb/s. The flow rate of f1 is 1Mb/s, and the flow s. The flow rate of f1 is 1Mb/s, and the flow rate of f2 is 2Mb/s.
rate of f2 is 2Mb/s. The threshold of the link in congestion is 90%. The threshold of the link in congestion is 90%.
If OSPF protocol (ISIS is similar, because it also use the Dijstra's If OSPF protocol (ISIS is similar, because it also use the Dijstra's
algorithm) is applied in the network, which adopts Dijkstra's algorithm) is applied in the network, which adopts Dijkstra's
algorithm, the two flows from node 1 to node 8 can only use the OSPF algorithm, the two flows from node 1 to node 8 can only use the OSPF
path (p1: 1->2->3->8). It is because Dijkstra's algorithm mainly path (p1: 1->2->3->8). It is because Dijkstra's algorithm mainly
considers original cost of the link. Since CCDR considers cost and considers original cost of the link. Since CCDR considers cost and
utilization simultaneously, the same path as OSPF will not be utilization simultaneously, the same path as OSPF will not be
selected due to the severe congestion of the link (2,3). In this selected due to the severe congestion of the link (2,3). In this
case, f1 will select the path (p2: 1->5->6->7->8) since the new cost case, f1 will select the path (p2: 1->5->6->7->8) since the new cost
of this path is better than that of OSPF path. Moreover, the path p2 of this path is better than that of OSPF path. Moreover, the path p2
is also better than the path (p3: 1->2->4->7->8) for for flow f1. is also better than the path (p3: 1->2->4->7->8) for for flow f1.
However, f2 will not select the same path since it will cause the new However, f2 will not select the same path since it will cause the new
congestion in the link (6,7). As a result, f2 will select the path congestion in the link (6,7). As a result, f2 will select the path
(p3: 1->2->4->7->8). (p3: 1->2->4->7->8).
+-------+ +-------+ +----+ f1 +-------> +-----+ ----> +-----+
+---------+ f1 +--------->| | ----------> | | |Edge|-----------+ |+--------| 3 |-------| 8 |
| |---------------+ | +--------| 3 |-------------| 8 | |Node|---------+ | ||+-----> +-----+ ----> +-----+
|Edge Node|-------------+ | | | +----->| | ----------> | | +----+ | | 4/95%||| 6/50% |
| | | | | | | +-------+ 6/50% +-------+ | | ||| 5/60%|
+---------+ | | 4/95% | | | | | v ||| |
| | | | | 5/60% | +----+ +-----+ -----> +-----+ +-----+ +-----+
| v | | | | |Edge|-------| 1 |--------| 2 |------| 4 |------| 7 |
+---------+ +-------+ +-------+ +-------+ +-------+ |Node|-----> +-----+ -----> +-----+7/60% +-----+5/45% +-----+
| | | |---------> | | | | | | +----+ f2 | 3/50% |
|Edge Node|-------| 1 |---------- | 2 |---------| 4 |--------| 7 | | |
| |-----> | |---------> | | 7/60% | | 5/45% | | | 3/60% +-----+ 5/55%+-----+ 3/75% |
+---------+ f2 +-------+ 3/50% +-------+ +-------+ +-------+ +-----------| 5 |------| 6 |---------+
| | +-----+ +-----+
| | (a) Dijkstra's Algorithm (OSPF/ISIS)
| +-------+ +-------+ |
| 3/60% | | 5/55% | | 3/75%|
+---------------| 5 |-----------| 6 |----------+
| | | |
+-------+ +-------+
(a) Dijkstra's Algorithm(OSPF/ISIS)
+-------+ +-------+ +----+ f1 +-----+ ----> +-----+
+---------+ f1 | | | | |Edge|-----------+ +--------| 3 |-------| 8 |
| |---------------+ +--------| 3 |-------------| 8 | |Node|---------+ | | +-----+ ----> +-----+
|Edge Node|-------------+ | | | | | | +----+ | | 4/95% | 6/50% ^|^
| | | | | +-------+ 6/50% +-------+ | | | 5/60%|||
+---------+ | | 4/95%| ^ | ^ | v | |||
| | | 5/60% | | | +----+ +-----+ -----> +-----+ ---> +-----+ ---> +-----+
| v | | | | |Edge|-------| 1 |--------| 2 |------| 4 |------| 7 |
+---------+ +-------+ +-------+ +-------+ +-------+ |Node|-----> +-----+ +-----+7/60% +-----+5/45% +-----+
| | | |---------> | |-------> | | -----> | | +----+ f2 || 3/50% |^
|Edge Node|-------| 1 |---------- | 2 |---------| 4 |--------| 7 | || ||
| |-----> | | | | 7/60% | | 5/45% | | || 3/60% +-----+5/55% +-----+ 3/75% ||
+---------+ f2 +-------+ 3/50% +-------+ +-------+ +-------+ |+-----------| 5 |------| 6 |---------+|
| | | ^ +----------> +-----+ ---> +-----+ ---------+
| | | | (b) CCDR Algorithm
| | +-------+ +-------+ | |
| | 3/60% | | 5/55% | | 3/75%| |
| +---------------| 5 |-----------| 6 |----------+ |
+--------------> | |---------> | |------------+
+-------+ +-------+
(b) CCDR Algorithm
Figure 5: Case Study for CCDR's Algorithm Figure 5: Case Study for CCDR's Algorithm
4.2. Topology Simulation 4.2. Topology Simulation
Moving on from the specific case study, we now consider a class of Moving on from the specific case study, we now consider a class of
networks more representative of real deployments, with a fully-linked networks more representative of real deployments, with a fully-linked
core network that serves to connect edge nodes, which themselves core network that serves to connect edge nodes, which themselves
connect to only a subset of the core. An example of such a topology connect to only a subset of the core. An example of such a topology
is shown in Figure 6, for the case of 4 core nodes and 5 edge nodes. is shown in Figure 6, for the case of 4 core nodes and 5 edge nodes.
The CCDR simulations presented in this work use topologies involving The CCDR simulations presented in this work use topologies involving
100 core nodes and 400 edge nodes. While the resulting graph does 100 core nodes and 400 edge nodes. While the resulting graph does
skipping to change at page 10, line 38 skipping to change at page 10, line 26
+----+ | / \ | | +----+ | / \ | |
\ | / \ | | \ | / \ | |
+----+ +----+ +----+ | +----+ +----+ +----+ |
|Edge|----|Core|-----|Core| | |Edge|----|Core|-----|Core| |
+----+ +----+ +----+ | +----+ +----+ +----+ |
| | | | | |
| +------\ +----+ | +------\ +----+
| ---|Edge| | ---|Edge|
+-----------------/ +----+ +-----------------/ +----+
Figure 6: Topology of Simulation Figure 6: Topology of Simulation
For the simulations, the number of links connecting one edge node to For the simulations, the number of links connecting one edge node to
the set of core nodes is randomly chosen between 2 to 30, and the the set of core nodes is randomly chosen between 2 to 30, and the
total number of links is more than 20000. Each link has a congestion total number of links is more than 20000. Each link has a congestion
threshold, which can be arbitrarily set to (e.g.) 90% of the nominal threshold, which can be arbitrarily set to (e.g.) 90% of the nominal
link capacity without affecting the simulation results. link capacity without affecting the simulation results.
4.3. Traffic Matrix Simulation 4.3. Traffic Matrix Simulation
For each topology, a traffic matrix is generated based on the link For each topology, a traffic matrix is generated based on the link
skipping to change at page 11, line 13 skipping to change at page 10, line 48
such as congestion, mild congestion and non-congestion. such as congestion, mild congestion and non-congestion.
In the CCDR simulation, the dimension of the traffic matrix is In the CCDR simulation, the dimension of the traffic matrix is
500*500 (100 core nodes plus 400 edge nodes). About 20% of links are 500*500 (100 core nodes plus 400 edge nodes). About 20% of links are
overloaded when the Open Shortest Path First (OSPF) protocol is used overloaded when the Open Shortest Path First (OSPF) protocol is used
in the network. in the network.
4.4. CCDR End-to-End Path Optimization 4.4. CCDR End-to-End Path Optimization
The CCDR E2E path optimization is to find the best path which is the The CCDR E2E path optimization is to find the best path which is the
lowest in metric value and for each link of the path is far below lowest in metric value and for each link of the path, the
link's congestion threshold. Based on the current state of the utilizatioin is far below link's congestion threshold. Based on the
network, the PCE within CCDR framework combines the shortest path current state of the network, the PCE within CCDR framework combines
algorithm with a penalty theory of classical optimization and graph the shortest path algorithm with a penalty theory of classical
theory. optimization and graph theory.
Given a background traffic matrix, which is unscheduled, when a set Given a background traffic matrix, which is unscheduled, when a set
of new flows comes into the network, the E2E path optimization finds of new flows comes into the network, the E2E path optimization finds
the optimal paths for them. The selected paths bring the least the optimal paths for them. The selected paths bring the least
congestion degree to the network. congestion degree to the network.
The link Utilization Increment Degree(UID), when the new flows are The link Utilization Increment Degree(UID), when the new flows are
added into the network, is shown in Figure 7. The first graph in added into the network, is shown in Figure 7. The first graph in
Figure 7 is the UID with OSPF and the second graph is the UID with Figure 7 is the UID with OSPF and the second graph is the UID with
CCDR E2E path optimization. The average UID of the first graph is CCDR E2E path optimization. The average UID of the first graph is
skipping to change at page 12, line 38 skipping to change at page 12, line 38
UID(%)| | UID(%)| |
| | | |
| | | |
20| | 20| |
| *| | *|
| * *| | * *|
| * * * * * ** * *| | * * * * * ** * *|
0+-----------------------------------------------------------+ 0+-----------------------------------------------------------+
0 100 200 300 400 500 600 700 800 900 1000 0 100 200 300 400 500 600 700 800 900 1000
Flow Number Flow Number
Figure 7: Simulation Result with Congestion Elimination
Figure 7: Simulation Result with Congestion Elimination
4.5. Network Temporal Congestion Elimination 4.5. Network Temporal Congestion Elimination
During the simulations, different degrees of network congestion were During the simulations, different degrees of network congestion were
considered. To examine the effect of CCDR on link congestion, we considered. To examine the effect of CCDR on link congestion, we
consider the Congestion Degree (CD) of a link, defined as the link consider the Congestion Degree (CD) of a link, defined as the link
utilization beyond its threshold. utilization beyond its threshold.
The CCDR congestion elimination performance is shown in Figure 8. The CCDR congestion elimination performance is shown in Figure 8.
The first graph is the CD distribution before the process of The first graph is the CD distribution before the process of
skipping to change at page 13, line 44 skipping to change at page 13, line 45
CD(%) | | CD(%) | |
10| | 10| |
| | | |
| | | |
5 | | 5 | |
| | | |
| * ** * * * ** * ** * | | * ** * * * ** * ** * |
0 +-----------------------------------------------------------+ 0 +-----------------------------------------------------------+
0 0.5 1 1.5 2 0 0.5 1 1.5 2
Link Number(*10000) Link Number(*10000)
Figure 8: Simulation Result with Congestion Elimination
Figure 8: Simulation Result with Congestion Elimination
It is clear that using an active path-computation mechanism that is It is clear that using an active path-computation mechanism that is
able to take into account observed link traffic/congestion, the able to take into account observed link traffic/congestion, the
occurrence of congestion events can be greatly reduced. Only when a occurrence of congestion events can be greatly reduced. Only when a
preponderance of links in the network are near their congestion preponderance of links in the network are near their congestion
threshold will the central controller be unable to find a clear path, threshold will the central controller be unable to find a clear path,
as opposed to when a static metric-based procedure is used, which as opposed to when a static metric-based procedure is used, which
will produce congested paths once a single bottleneck approaches its will produce congested paths once a single bottleneck approaches its
capacity. More detailed information about the algorithm can be found capacity. More detailed information about the algorithm can be found
in[PTCS] . in[PTCS] .
skipping to change at page 14, line 37 skipping to change at page 14, line 39
To deploy the CCDR solution, the PCE should collect the underlay To deploy the CCDR solution, the PCE should collect the underlay
network topology dynamically, for example via BGP-LS[RFC7752]. It network topology dynamically, for example via BGP-LS[RFC7752]. It
also needs to gather the network traffic information periodically also needs to gather the network traffic information periodically
from the network management platform. The simulation results show from the network management platform. The simulation results show
that the PCE can compute the E2E optimal path within seconds, thus it that the PCE can compute the E2E optimal path within seconds, thus it
can cope with the change of underlay network on the scale of minutes. can cope with the change of underlay network on the scale of minutes.
More agile requirements would need to increase the sample rate of More agile requirements would need to increase the sample rate of
underlay network and decrease the detection and notification interval underlay network and decrease the detection and notification interval
of the underlay network. The methods to gather and decrease the of the underlay network. The methods to gather and decrease the
latency of these information are out of the scope of this draft.. latency of these information are out of the scope of this draft.
6. Security Considerations 6. Security Considerations
This document considers mainly the integration of distributed This document considers mainly the integration of distributed
protocols and the central control capability of a PCE. While it protocols and the central control capability of a PCE. While it
certainly can ease the management of network in various traffic certainly can ease the management of network in various traffic
engineering scenarios as described in this document, the centralized engineering scenarios as described in this document, the centralized
control also bring a new point that may be easily attacked. control also bring a new point that may be easily attacked.
Solutions for CCDR scenarios need to consider protection of the PCE Solutions for CCDR scenarios need to consider protection of the PCE
and communication with the underlay devices. and communication with the underlay devices.
[RFC5440] and [RFC8253] provide additional information. [RFC5440] and [RFC8253] provide additional information.
The control priority and interaction process should also be carefully The control priority and interaction process should also be carefully
designed for the combination of distributed protocol and central designed for the combination of distributed protocol and central
control. Generally, the central control instruction should have control. Generally, the central control instruction should have
higher priority than the forwarding actions determined by the higher priority than the forwarding actions determined by the
distributed protocol. When the communication between PCE and the distributed protocol. When the communication between PCE and the
underlay devices is not in function, the distributed protocol should underlay devices is not in function, the distributed protocol should
take over the control right of the underlay network. take over the control right of the underlay network.
[I-D.ietf-teas-pce-native-ip] provide more considerations [I-D.ietf-teas-pce-native-ip] provides more considerations
corresponding to the solution. corresponding to the solution.
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
8. Contributors 8. Contributors
Lu Huang contributed to the content of this draft. Lu Huang contributed to the content of this draft.
 End of changes. 24 change blocks. 
86 lines changed or deleted 76 lines changed or added

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