rfc8735xml2.original.xml   rfc8735.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) <rfc category="info" consensus="true"
by Daniel M Kohn (private) --> docName="draft-ietf-teas-native-ip-scenarios-12" ipr="trust200902"
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ number="8735" obsoletes="" sortRefs="true" submissionType="IETF"
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. symRefs="true" tocDepth="3" tocInclude="true" updates="" version="3"
RFC.2119.xml"> xml:lang="en">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-teas-native-ip-scenarios-12"
ipr="trust200902">
<front> <front>
<title abbrev="CCDR Scenario and Simulation Results">Scenarios and <title abbrev="CCDR Scenario and Simulation Results">Scenarios and
Simulation Results of PCE in Native IP Network</title> Simulation Results of PCE in a Native IP Network</title>
<seriesInfo name="RFC" value="8735"/>
<author fullname="Aijun Wang" initials="A" surname="Wang"> <author fullname="Aijun Wang" initials="A" surname="Wang">
<organization>China Telecom</organization> <organization>China Telecom</organization>
<address> <address>
<postal> <postal>
<street>Beiqijia Town, Changping District</street> <street>Beiqijia Town, Changping District</street>
<city>Beijing</city> <city>Beijing</city>
skipping to change at line 85 skipping to change at line 75
<region/> <region/>
<code/> <code/>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>koucx@lsec.cc.ac.cn</email> <email>koucx@lsec.cc.ac.cn</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Zhenqiang Li" initials="Z" surname="Li"> <author fullname="Zhenqiang Li" initials="Z" surname="Li">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
skipping to change at line 111 skipping to change at line 99
<region/> <region/>
<code>100053</code> <code>100053</code>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>li_zhenqiang@hotmail.com</email> <email>li_zhenqiang@hotmail.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Penghui Mi" initials="P" surname="Mi"> <author fullname="Penghui Mi" initials="P" surname="Mi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
skipping to change at line 138 skipping to change at line 124
<region>Bantian,Longgang District</region> <region>Bantian,Longgang District</region>
<code>518129</code> <code>518129</code>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>mipenghui@huawei.com</email> <email>mipenghui@huawei.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<date day="29" month="October" year="2019"/> <date month="February" year="2020"/>
<area>RTG Area</area> <area>RTG Area</area>
<workgroup>TEAS Working Group</workgroup> <workgroup>TEAS Working Group</workgroup>
<keyword>RFC</keyword> <keyword>CCDR, Traffic Engineering,</keyword>
<abstract> <abstract>
<t>Requirements for providing the End to End(E2E) performance assurance <t>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, there 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 is a need for a universal E2E solution that can cover both intra- and
inter-domain scenarios.</t> inter-domain scenarios.</t>
<t>One feasible E2E traffic engineering solution is the addition of <t>One feasible E2E traffic-engineering solution is the addition of
central control in a native IP network. This document describes various central control in a native IP network. This document describes various
complex scenarios and simulation results when applying the Path complex scenarios and simulation results when applying the Path
Computation Element (PCE) in a native IP network. This solution, Computation Element (PCE) in a native IP network. This solution,
referred to as Centralized Control Dynamic Routing (CCDR), integrates referred to as Centralized Control Dynamic Routing (CCDR), integrates
the advantage of using distributed protocols and the power of a the advantage of using distributed protocols and the power of a
centralized control technology, providing traffic engineering for native centralized control technology, providing traffic engineering for native
IP networks in a manner that applies equally to intra- and inter-domain IP networks in a manner that applies equally to intra- and inter-domain
scenarios.</t> scenarios.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>A service provider network is composed of thousands of routers that <t>A service provider network is composed of thousands of routers that
run distributed protocols to exchange the reachability information. The run distributed protocols to exchange reachability information. The path
path for the destination network is mainly calculated, and controlled, for the destination network is mainly calculated, and controlled, by the
by the distributed protocols. These distributed protocols are robust distributed protocols. These distributed protocols are robust enough to
enough to support most applications, however, they have some support most applications; however, they have some difficulties
difficulties supporting the complexities needed for traffic engineering supporting the complexities needed for traffic-engineering applications,
applications, e.g. E2E performance assurance, or maximizing the link e.g., E2E performance assurance, or maximizing the link utilization
utilization within an IP network.</t> within an IP network.</t>
<t>Multiprotocol Label Switching (MPLS) using Traffic Engineering (TE) <t>Multiprotocol Label Switching (MPLS) using Traffic-Engineering (TE)
technology (MPLS-TE)<xref target="RFC3209"/>is one solution for traffic technology (MPLS-TE) <xref format="default" target="RFC3209"/> is one
engineering networks but it introduces an MPLS network and related solution for TE networks, but it introduces an MPLS network along with
technology which would be an overlay of the IP network. MPLS-TE related technology, which would be an overlay of the IP network. MPLS-TE
technology is often used for Label Switched Path (LSP) protection and technology is often used for Label Switched Path (LSP) protection and
complex path set-up within a domain. It has not been widely deployed for setting up complex paths within a domain. It has not been widely
meeting E2E (especially in inter-domain) dynamic performance assurance deployed for meeting E2E (especially in inter-domain) dynamic
requirements for an IP network.</t> performance assurance requirements for an IP network.</t>
<t>Segment Routing <xref target="RFC8402"/> is another solution that <t>Segment Routing <xref format="default" target="RFC8402"/> is another
integrates some advantages of using a distributed protocol and a solution that integrates some advantages of using a distributed protocol
centrally control technology, but it requires the underlying network, and central control technology, but it requires the underlying network,
especially the provider edge router, to do a label push and pop action especially the provider edge router, to do an in-depth label push and
in-depth, and adds complexity when coexisting with the Non-Segment pop action while adding complexity when coexisting with the non-segment
Routing network. Additionally, it can only maneuver the E2E paths for routing network. Additionally, it can only maneuver the E2E paths for
MPLS and IPv6 traffic via different mechanisms.</t> MPLS and IPv6 traffic via different mechanisms.</t>
<t>Deterministic Networking (DetNet)<xref target="RFC8578"/> is another <t>Deterministic Networking (DetNet) <xref format="default"
possible solution. It is primarily focused on providing bounded latency target="RFC8578"/> is another possible solution. It is primarily focused
for a flow and introduces additional requirements on the domain edge on providing bounded latency for a flow and introduces additional
router. The current DetNet scope is within one domain. The use cases requirements on the domain edge router. The current DetNet scope is
defined in this document do not require the additional complexity of within one domain. The use cases defined in this document do not require
deterministic properties and so differ from the DetNet use cases.</t> the additional complexity of deterministic properties and so differ from
the DetNet use cases.</t>
<t>This draft describes several scenarios for a native IP network where <t>This document describes several scenarios for a native IP network
a Centralized Control Dynamic Routing (CCDR) framework can produce where a Centralized Control Dynamic Routing (CCDR) framework can produce
qualitative improvement in efficiency without requiring a change of the qualitative improvement in efficiency without requiring a change to the
data-plane behavior on the router. Using knowledge of BGP(Border Gateway data-plane behavior on the router. Using knowledge of the Border Gateway
Protocol) session-specific prefixes advertised by a router, the network Protocol (BGP) session-specific prefixes advertised by a router, the
topology and the near real time link utilization information from network topology and the near-real-time link-utilization information
network management systems, a central PCE is able to compute an optimal from network management systems, a central PCE is able to compute an
path and give the underlay routers the destination address to use to optimal path and give the underlying routers the destination address to
reach the BGP nexthop, such that the distributed routing protocol will use to reach the BGP nexthop, such that the distributed routing protocol
use the computed path via traditional recursive lookup procedure. Some will use the computed path via traditional recursive lookup procedure.
results from simulations of path optimization are also presented, to Some results from simulations of path optimization are also presented to
concretely illustrate a variety of scenarios where CCDR shows concretely illustrate a variety of scenarios where CCDR shows
significant improvement over traditional distributed routing significant improvement over traditional distributed routing
protocols.</t> protocols.</t>
<t>This draft is the base document of the following two drafts: the <t>This document is the base document of the following two documents:
universal solution draft, which is suitable for intra-domain and the universal solution document, which is suitable for intra-domain and
inter-domain TE scenario, is described in <xref inter-domain TE scenario, is described in <xref format="default"
target="I-D.ietf-teas-pce-native-ip"/>; the related protocol extension target="I-D.ietf-teas-pce-native-ip"/>; and the related protocol
contents is described in <xref extension contents is described in <xref format="default"
target="I-D.ietf-pce-pcep-extension-native-ip"/></t> target="I-D.ietf-pce-pcep-extension-native-ip"/>.</t>
</section> </section>
<section title="Terminology"> <section numbered="true" toc="default">
<t>This document uses the following terms defined in <xref <name>Terminology</name>
target="RFC5440"/>: PCE.</t>
<t>The following terms are defined in this document:</t> <t>In this document, PCE is used as defined in <xref format="default"
target="RFC5440"/>. The following terms are used as described here:</t>
<t><list style="symbols"> <dl indent="8" spacing="normal">
<t>BRAS: Broadband Remote Access Server</t> <dt>BRAS:</dt>
<t>CD: Congestion Degree</t> <dd>Broadband Remote Access Server</dd>
<t>CR: Core Router</t> <dt>CD:</dt>
<t>CCDR: Centralized Control Dynamic Routing</t> <dd>Congestion Degree</dd>
<t>E2E: End to End</t> <dt>CR:</dt>
<t>IDC: Internet Data Center</t> <dd>Core Router</dd>
<t>MAN: Metro Area Network</t> <dt>CCDR:</dt>
<t>QoS: Quality of Service</t> <dd>Centralized Control Dynamic Routing</dd>
<t>SR: Service Router</t> <dt>E2E:</dt>
<t>TE: Traffic Engineering</t> <dd>End to End</dd>
<t>UID: Utilization Increment Degree</t> <dt>IDC:</dt>
<t>WAN: Wide Area Network</t> <dd>Internet Data Center</dd>
</list></t>
<dt>MAN:</dt>
<dd>Metro Area Network</dd>
<dt>QoS:</dt>
<dd>Quality of Service</dd>
<dt>SR:</dt>
<dd>Service Router</dd>
<dt>TE:</dt>
<dd>Traffic Engineering</dd>
<dt>UID:</dt>
<dd>Utilization Increment Degree</dd>
<dt>WAN:</dt>
<dd>Wide Area Network</dd>
</dl>
</section> </section>
<section title="CCDR Scenarios"> <section numbered="true" toc="default">
<name>CCDR Scenarios</name>
<t>The following sections describe various deployment scenarios where <t>The following sections describe various deployment scenarios where
applying the CCDR framework is intuitively expected to produce applying the CCDR framework is intuitively expected to produce
improvements, based on the macro-scale properties of the framework and improvements based on the macro-scale properties of the framework and
the scenario.</t> the scenario.</t>
<section title="QoS Assurance for Hybrid Cloud-based Application"> <section numbered="true" toc="default">
<name>QoS Assurance for Hybrid Cloud-Based Application</name>
<t>With the emergence of cloud computing technologies, enterprises are <t>With the emergence of cloud computing technologies, enterprises are
putting more and more services on a public oriented cloud environment, putting more and more services on a public-oriented cloud environment
but keeping core business within their private cloud. The while keeping core business within their private cloud. The
communication between the private and public cloud sites will span the communication between the private and public cloud sites spans the
Wide Area Network (WAN) network. The bandwidth requirements between WAN. The bandwidth requirements between them are variable, and the
them are variable and the background traffic between these two sites background traffic between these two sites varies over time.
varies over time. Enterprise applications require assurance of the E2E Enterprise applications require assurance of the E2E QoS performance
Quality of Service(QoS) performance on demand for variable bandwidth on demand for variable bandwidth services.</t>
services.</t>
<t>CCDR, which integrates the merits of distributed protocols and the <t>CCDR, which integrates the merits of distributed protocols and the
power of centralized control, is suitable for this scenario. The power of centralized control, is suitable for this scenario. The
possible solution framework is illustrated below:</t> possible solution framework is illustrated below:</t>
<figure> <figure anchor="hybrid-cloud-comm"
<artwork><![CDATA[ +------------------------ title="Hybrid Cloud Communication Scenario">
+ <artwork align="left" alt="" name="" type=""><![CDATA[
| Cloud Based Application| +------------------------+
+------------------------+ | Cloud-Based Application|
| +------------------------+
+-----------+ |
| PCE | +-----------+
+-----------+ | PCE |
| +-----------+
| |
//--------------\\ |
///// \\\\\ //--------------\\
Private Cloud Site || Distributed |Public Cloud Site ///// \\\\\
| Control Network | Private Cloud Site || Distributed |Public Cloud Site
\\\\\ ///// | Control Network |
\\--------------// \\\\\ /////
\\--------------//
Figure 1: Hybrid Cloud Communication Scenario
]]></artwork> ]]></artwork>
</figure> </figure>
<t>As illustrated in Figure 1, the source and destination of the <t>As illustrated in <xref target="hybrid-cloud-comm"/>, the source
"Cloud Based Application" traffic are located at "Private Cloud Site" and destination of the "Cloud-Based Application" traffic are located
and "Public Cloud Site" respectively.</t> at "Private Cloud Site" and "Public Cloud Site", respectively.</t>
<t hangText="Section 4">By default, the traffic path between the <t>By default, the traffic path between the private and public cloud
private and public cloud site is determined by the distributed control site is determined by the distributed control network. When an
network. When application requires the E2E QoS assurance, it can send application requires E2E QoS assurance, it can send these requirements
these requirements to the PCE, and let the PCE compute one E2E path to the PCE and let the PCE compute one E2E path, which is based on the
which is based on the underlying network topology and the real traffic underlying network topology and real traffic information, in order to
information, to accommodate the application's QoS requirements. <xref accommodate the application's QoS requirements. <xref format="default"
target="Section-4.4"/> of this document describes the simulation target="Section-4.4"/> of this document describes the simulation
results for this use case.</t> results for this use case.</t>
</section> </section>
<section title="Link Utilization Maximization"> <section numbered="true" toc="default">
<t>Network topology within a Metro Area Network (MAN) is generally in <name>Link Utilization Maximization</name>
a star mode as illustrated in Figure 2, with different devices
connected to different customer types. The traffic from these
customers is often in a tidal pattern, with the links between the Core
Router(CR)/Broadband Remote Access Server(BRAS) and CR/Service
Router(SR) experiencing congestion in different periods, because the
subscribers under BRAS often use the network at night, and the leased
line users under SR often use the network during the daytime. The link
between BRAS/SR and CR must satisfy the maximum traffic volume between
them, respectively, and this causes these links often to be
under-utilized.</t>
<figure> <t>Network topology within a Metro Area Network (MAN) is generally in
<artwork><![CDATA[ +--------+ a star mode as illustrated in <xref target="star-mode-man"/>, with
| CR | different devices connected to different customer types. The traffic
+----|---+ from these customers is often in a tidal pattern with the links
| between the Core Router (CR) / roadband Remote Access Server (BRAS)
--------|--------|-------| and CR/Service Router (SR) experiencing congestion in different
| | | | periods due to subscribers under BRAS often using the network at night
+--|-+ +-|- +--|-+ +-|+ and the leased line users under SR often using the network during the
|BRAS| |SR| |BRAS| |SR| daytime. The link between BRAS/SR and CR must satisfy the maximum
+----+ +--+ +----+ +--+ traffic volume between them, respectively, which causes these links to
often be underutilized.</t>
Figure 2: Star-mode Network Topology within MAN]]></artwork> <figure anchor="star-mode-man"
title="Star-Mode Network Topology within MAN">
<artwork align="left" alt="" name="" type=""><![CDATA[
+--------+
| CR |
+----|---+
|
|-------|--------|-------|
| | | |
+--|-+ +-|+ +--|-+ +-|+
|BRAS| |SR| |BRAS| |SR|
+----+ +--+ +----+ +--+
]]></artwork>
</figure> </figure>
<t>If we consider connecting the BRAS/SR with a local link loop (which <t>If we consider connecting the BRAS/SR with a local link loop (which
is usually lower cost), and control the overall MAN topology with the is usually lower cost) and control the overall MAN topology with the
CCDR framework, we can exploit the tidal phenomena between the BRAS/CR CCDR framework, we can exploit the tidal phenomena between the BRAS/CR
and SR/CR links, maximizing the utilization of these central trunk and SR/CR links, maximizing the utilization of these central trunk
links (which are usually higher cost than the local loops).</t> links (which are usually higher cost than the local loops).</t>
<t><figure> <figure anchor="link-max-ccdr"
<artwork><![CDATA[ +-------+ title="Link Utilization Maximization via CCDR">
----- PCE | <artwork align="left" alt="" name="" type=""><![CDATA[
| +-------+ +-------+
+----|---+ ----- PCE |
| CR | | +-------+
+----|---+ +----|---+
| | CR |
--------|--------|-------| +----|---+
| | | | |
+--|-+ +-|- +--|-+ +-|+ |-------|--------|-------|
|BRAS-----SR| |BRAS-----SR| | | | |
+----+ +--+ +----+ +--+ +--|-+ +-|+ +--|-+ +-|+
|BRAS-----SR| |BRAS-----SR|
Figure 3: Link Utilization Maximization via CCDR]]></artwork> +----+ +--+ +----+ +--+
</figure></t> ]]></artwork>
</figure>
</section> </section>
<section title="Traffic Engineering for Multi-Domain"> <section numbered="true" toc="default">
<name>Traffic Engineering for Multi-domain</name>
<t>Service provider networks are often comprised of different domains, <t>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 <xref target="te-topology"/>. Due to the traffic
and IDC, the utilization of the links between them are often pattern to/from the MAN and IDC, the utilization of the links between
asymmetric. It is almost impossible to balance the utilization of them are often asymmetric. It is almost impossible to balance the
these links via a distributed protocol, but this unbalance can be utilization of these links via a distributed protocol, but this
overcome utilizing the CCDR framework.</t> unbalance can be overcome utilizing the CCDR framework.</t>
<t><figure>
<artwork><![CDATA[ +---+ +---+
|MAN|-----------------IDC|
+-|-| | +-|-+
| ---------| |
------|BackBone|------
| ----|----| |
| | |
+-|-- | ----+
|IDC|----------------|MAN|
+---| |---+
Figure 4: Traffic Engineering for Complex Multi-Domain Topology]]></artwork <figure anchor="te-topology"
> title="Traffic Engineering for Complex Multi-domain Topology">
</figure></t> <artwork align="left" alt="" name="" type=""><![CDATA[
+---+ +---+
|MAN|----------------|IDC|
+---+ | +---+
| ---------- |
|-----|Backbone|-----|
| ----|----- |
| | |
+---+ | +---+
|IDC|----------------|MAN|
+---+ +---+
]]></artwork>
</figure>
<t>A solution for this scenario requires the gathering of NetFlow <t>A solution for this scenario requires the gathering of NetFlow
information, analysis of the source/destination AS, and determining information, analysis of the source/destination autonomous system
what is the main cause of the congested link(s). After this, the (AS), and determining what the main cause of the congested link(s) is.
operator can use the external Border Gateway Protocol(eBGP) sessions After this, the operator can use the external Border Gateway Protocol
to schedule the traffic among the different domains according to the (eBGP) sessions to schedule the traffic among the different domains
solution described in CCDR framework.</t> according to the solution described in the CCDR framework.</t>
</section> </section>
<section title="Network Temporal Congestion Elimination"> <section numbered="true" toc="default">
<t>In more general situations, there are often temporal congestion <name>Network Temporal Congestion Elimination</name>
within the service provider&rsquo;s network, for example due to daily
or weekly periodic bursts, or large events that are scheduled well in <t>In more general situations, there is often temporal congestion
within the service provider's network, for example, due to daily or
weekly periodic bursts or large events that are scheduled well in
advance. Such congestion phenomena often appear regularly, and if the advance. Such congestion phenomena often appear regularly, and if the
service provider has methods to mitigate it, it will certainly improve service provider has methods to mitigate it, it will certainly improve
their network operations capabilities and increase satisfaction for their network operation capabilities and increase satisfaction for
their customers. CCDR is also suitable for such scenarios, as the customers. CCDR is also suitable for such scenarios, as the controller
controller can schedule traffic out of the congested links, lowering can schedule traffic out of the congested links, lowering their
the utilization of them during these times. <xref utilization during these times. <xref format="default"
target="Section-4.5"/> describes the simulation results of this target="Section-4.5"/> describes the simulation results of this
scenario.</t> scenario.</t>
</section> </section>
</section> </section>
<section anchor="Section-4" title="CCDR Simulation"> <section anchor="Section-4" numbered="true" toc="default">
<name>CCDR Simulation</name>
<t>The following sections describe a specific case study to illustrate <t>The following sections describe a specific case study to illustrate
the workings of the CCDR algorithm with concrete paths/metrics, as well the workings of the CCDR algorithm with concrete paths/metrics, as well
as a procedure for generating topology and traffic matrices and the as a procedure for generating topology and traffic matrices and the
results from simulations applying CCDR for E2E QoS (assured path and results from simulations applying CCDR for E2E QoS (assured path and
congestion elimination) over the generated topologies and traffic 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.</t> algorithm, suggesting that CCDR will have broad applicability.</t>
<t>The structure and scale of the simulated topology is similar to that <t>The structure and scale of the simulated topology is similar to that
of the real networks. Multiple different traffic matrices were generated of the real networks. Multiple different traffic matrices were generated
to simulate different congestion conditions in the network. Only one of to simulate different congestion conditions in the network. Only one of
them is illustrated since the others produce similar results.</t> them is illustrated since the others produce similar results.</t>
<section title="Case Study for CCDR Algorithm"> <section numbered="true" toc="default">
<t>In this section we consider a specific network topology for case <name>Case Study for CCDR Algorithm</name>
study, examining the path selected by OSPF and CCDR and evaluating how
and why the paths differ. Figure 5 depicts the topology of the network
in this case. There are 8 forwarding devices in the network. The
original cost and utilization are marked on it, as shown in the
figure. For example, the original cost and utilization for the link
(1,2) are 3 and 50% respectively. There are two flows: f1 and f2. Both
of these two flows are from node 1 to node 8. For simplicity, it is
assumed that the bandwidth of the link in the network is 10Mb/s. The
flow rate of f1 is 1Mb/s, and the flow rate of f2 is 2Mb/s. The
threshold of the link in congestion is 90%.</t>
<t>If OSPF protocol (ISIS is similar, because it also use the <t>In this section, we consider a specific network topology for case
Dijstra's algorithm) is applied in the network, which adopts study: examining the path selected by OSPF and CCDR and evaluating how
Dijkstra's algorithm, the two flows from node 1 to node 8 can only use and why the paths differ. <xref target="ccdr-algo"/> depicts the
the OSPF path (p1: 1-&gt;2-&gt;3-&gt;8). It is because Dijkstra's topology of the network in this case. There are eight forwarding
algorithm mainly considers original cost of the link. Since CCDR devices in the network. The original cost and utilization are marked
considers cost and utilization simultaneously, the same path as OSPF on it as shown in the figure. For example, the original cost and
will not be selected due to the severe congestion of the link (2,3). utilization for the link (1, 2) are 3 and 50%, respectively. There are
In this case, f1 will select the path (p2: 1-&gt;5-&gt;6-&gt;7-&gt;8) two flows: f1 and f2. Both of these two flows are from node 1 to node
since the new cost of this path is better than that of OSPF path. 8. For simplicity, it is assumed that the bandwidth of the link in the
network is 10 Mb/s. The flow rate of f1 is 1 Mb/s and the flow rate of
f2 is 2 Mb/s. The threshold of the link in congestion is 90%.</t>
<t>If the OSPF protocol, which adopts Dijkstra's algorithm (IS-IS is
similar because it also uses Dijkstra's algorithm), is applied in the
network, the two flows from node 1 to node 8 can only use the OSPF
path (p1: 1-&gt;2-&gt;3-&gt;8). This is because Dijkstra's algorithm
mainly considers the original cost of the link. Since CCDR considers
cost and utilization simultaneously, the same path as OSPF will not be
selected due to the severe congestion of the link (2, 3). In this
case, f1 will select the path (p2: 1-&gt;5-&gt;6-&gt;7-&gt;8) since
the new cost of this path is better than that of the OSPF path.
Moreover, the path p2 is also better than the path (p3: Moreover, the path p2 is also better than the path (p3:
1-&gt;2-&gt;4-&gt;7-&gt;8) for for flow f1. However, f2 will not 1-&gt;2-&gt;4-&gt;7-&gt;8) for flow f1. However, f2 will not select
select the same path since it will cause the new congestion in the the same path since it will cause new congestion in the link (6, 7).
link (6,7). As a result, f2 will select the path (p3: As a result, f2 will select the path (p3:
1-&gt;2-&gt;4-&gt;7-&gt;8).</t> 1-&gt;2-&gt;4-&gt;7-&gt;8).</t>
<t><figure> <figure anchor="ccdr-algo" title="Case Study for CCDR's Algorithm">
<artwork><![CDATA[ <artwork align="left" alt="" name="" type=""><![CDATA[
+----+ f1 +-------> +-----+ ----> +-----+ +----+ f1 +-------> +-----+ ----> +-----+
|Edge|-----------+ |+--------| 3 |-------| 8 | |Edge|-----------+ |+--------| 3 |-------| 8 |
|Node|---------+ | ||+-----> +-----+ ----> +-----+ |Node|---------+ | ||+-----> +-----+ ----> +-----+
+----+ | | 4/95%||| 6/50% | +----+ | | 4/95%||| 6/50% |
| | ||| 5/60%| | | ||| 5/60%|
| v ||| | | v ||| |
+----+ +-----+ -----> +-----+ +-----+ +-----+ +----+ +-----+ -----> +-----+ +-----+ +-----+
|Edge|-------| 1 |--------| 2 |------| 4 |------| 7 | |Edge|-------| 1 |--------| 2 |------| 4 |------| 7 |
|Node|-----> +-----+ -----> +-----+7/60% +-----+5/45% +-----+ |Node|-----> +-----+ -----> +-----+7/60% +-----+5/45% +-----+
+----+ f2 | 3/50% | +----+ f2 | 3/50% |
| | | |
| 3/60% +-----+ 5/55%+-----+ 3/75% | | 3/60% +-----+ 5/55%+-----+ 3/75% |
+-----------| 5 |------| 6 |---------+ +-----------| 5 |------| 6 |---------+
+-----+ +-----+ +-----+ +-----+
(a) Dijkstra's Algorithm (OSPF/ISIS) (a) Dijkstra's Algorithm (OSPF/IS-IS)
+----+ f1 +-----+ ----> +-----+
|Edge|-----------+ +--------| 3 |-------| 8 |
|Node|---------+ | | +-----+ ----> +-----+
+----+ | | 4/95% | 6/50% ^|^
| | | 5/60%|||
| v | |||
+----+ +-----+ -----> +-----+ ---> +-----+ ---> +-----+
|Edge|-------| 1 |--------| 2 |------| 4 |------| 7 |
|Node|-----> +-----+ +-----+7/60% +-----+5/45% +-----+
+----+ f2 || 3/50% |^
|| ||
|| 3/60% +-----+5/55% +-----+ 3/75% ||
|+-----------| 5 |------| 6 |---------+|
+----------> +-----+ ---> +-----+ ---------+
(b) CCDR Algorithm
Figure 5: Case Study for CCDR's Algorithm +----+ f1 +-----+ ----> +-----+
|Edge|-----------+ +--------| 3 |-------| 8 |
|Node|---------+ | | +-----+ ----> +-----+
+----+ | | 4/95% | 6/50% ^|^
| | | 5/60%|||
| v | |||
+----+ +-----+ -----> +-----+ ---> +-----+ ---> +-----+
|Edge|-------| 1 |--------| 2 |------| 4 |------| 7 |
|Node|-----> +-----+ +-----+7/60% +-----+5/45% +-----+
+----+ f2 || 3/50% |^
|| ||
|| 3/60% +-----+5/55% +-----+ 3/75% ||
|+-----------| 5 |------| 6 |---------+|
+----------> +-----+ ---> +-----+ ---------+
(b) CCDR Algorithm
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section title="Topology Simulation"> <section numbered="true" toc="default">
<name>Topology Simulation</name>
<t>Moving on from the specific case study, we now consider a class of <t>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 is 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. The shown in <xref target="top-sim"/> for the case of 4 core nodes and 5
CCDR simulations presented in this work use topologies involving 100 edge nodes. The CCDR simulations presented in this work use topologies
core nodes and 400 edge nodes. While the resulting graph does not fit involving 100 core nodes and 400 edge nodes. While the resulting graph
on this page, this scale of network is similar to what is deployed in does not fit on this page, this scale of network is similar to what is
production environments.</t> deployed in production environments.</t>
<t><figure>
<artwork><![CDATA[ +----+
/|Edge|\
| +----+ |
| |
| |
+----+ +----+ +----+
|Edge|----|Core|-----|Core|---------+
+----+ +----+ +----+ |
/ | \ / | |
+----+ | \ / | |
|Edge| | X | |
+----+ | / \ | |
\ | / \ | |
+----+ +----+ +----+ |
|Edge|----|Core|-----|Core| |
+----+ +----+ +----+ |
| | |
| +------\ +----+
| ---|Edge|
+-----------------/ +----+
Figure 6: Topology of Simulation <figure anchor="top-sim" title="Topology of Simulation">
<artwork align="left" alt="" name="" type=""><![CDATA[
+----+
/|Edge|\
| +----+ |
| |
| |
+----+ +----+ +----+
|Edge|----|Core|-----|Core|---------+
+----+ +----+ +----+ |
/ | \ / | |
+----+ | \ / | |
|Edge| | X | |
+----+ | / \ | |
\ | / \ | |
+----+ +----+ +----+ |
|Edge|----|Core|-----|Core| |
+----+ +----+ +----+ |
| | |
| +------\ +----+
| ---|Edge|
+-----------------/ +----+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>For the simulations, the number of links connecting one edge node <t>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 to the set of core nodes is randomly chosen between two and thirty,
total number of links is more than 20000. Each link has a congestion and the total number of links is more than 20,000. Each link has a
threshold, which can be arbitrarily set to (e.g.) 90% of the nominal congestion threshold, which can be arbitrarily set, for example, to
link capacity without affecting the simulation results.</t> 90% of the nominal link capacity without affecting the simulation
results.</t>
</section> </section>
<section title="Traffic Matrix Simulation"> <section numbered="true" toc="default">
<name>Traffic Matrix Simulation</name>
<t>For each topology, a traffic matrix is generated based on the link <t>For each topology, a traffic matrix is generated based on the link
capacity of topology. It can result in many kinds of situations, such capacity of the topology. It can result in many kinds of situations
as congestion, mild congestion and non-congestion.</t> such as congestion, mild congestion, and non-congestion.</t>
<t>In the CCDR simulation, the dimension of the traffic matrix is <t>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.</t> in the network.</t>
</section> </section>
<section anchor="Section-4.4" title="CCDR End-to-End Path Optimization"> <section anchor="Section-4.4" numbered="true" toc="default">
<t>The CCDR E2E path optimization is to find the best path which is <name>CCDR End-to-End Path Optimization</name>
the lowest in metric value and for each link of the path, the
utilizatioin is far below link&rsquo;s congestion threshold. Based on <t>The CCDR E2E path optimization entails finding the best path, which
the current state of the network, the PCE within CCDR framework is the lowest in metric value, as well as having utilization far below
combines the shortest path algorithm with a penalty theory of the congestion threshold for each link of the path. Based on the
classical optimization and graph theory.</t> current state of the network, the PCE within CCDR framework combines
the shortest path algorithm with a penalty theory of classical
optimization and graph theory.</t>
<t>Given a background traffic matrix, which is unscheduled, when a set <t>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.</t> congestion degree to the network.</t>
<t>The link Utilization Increment Degree(UID), when the new flows are <t>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 <xref
Figure 7 is the UID with OSPF and the second graph is the UID with target="sim-congestion-elimination"/>. The first graph in <xref
CCDR E2E path optimization. The average UID of the first graph is more target="sim-congestion-elimination"/> is the UID with OSPF, and the
than 30%. After path optimization, the average UID is less than 5%. second graph is the UID with CCDR E2E path optimization. The average
The results show that the CCDR E2E path optimization has an UID of the first graph is more than 30%. After path optimization, the
eye-catching decrease in UID relative to the path chosen based on average UID is less than 5%. The results show that the CCDR E2E path
OSPF.</t> optimization has an eye-catching decrease in UID relative to the path
chosen based on OSPF.</t>
<t>While real-world results invariably differ from simulations (for <t>While real-world results invariably differ from simulations (for
example, real-world topologies are likely to exhibit correlation in example, real-world topologies are likely to exhibit correlation in
the attachment patterns for edge nodes to the core, which are not the attachment patterns for edge nodes to the core, which are not
reflected in these results), the dramatic nature of the improvement in reflected in these results), the dramatic nature of the improvement in
UID and the choice of simulated topology to resemble real-world UID and the choice of simulated topology to resemble real-world
conditions suggests that real-world deployments will also experience conditions suggest that real-world deployments will also experience
significant improvement in UID results.</t> significant improvement in UID results.</t>
<t><figure> <figure anchor="sim-congestion-elimination"
<artwork><![CDATA[ +---------------------------------------- title="Simulation Results with Congestion Elimination">
-------------------+ <artwork align="left" alt="" name="" type=""><![CDATA[
| * * * *| +-----------------------------------------------------------+
60| * * * * * *| | * * * *|
|* * ** * * * * * ** * * * * **| 60| * * * * * *|
|* * ** * * ** *** ** * * ** * * * ** * * *** **| |* * ** * * * * * ** * * * * **|
|* * * ** * ** ** *** *** ** **** ** *** **** ** *** **| |* * ** * * ** *** ** * * ** * * * ** * * *** **|
40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **| |* * * ** * ** ** *** *** ** **** ** *** **** ** *** **|
UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********| 40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **|
|*** ******* ** **** *********** *********** ***************| UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********|
|******************* *********** *********** ***************| |*** ******* ** **** *********** *********** ***************|
20|******************* ***************************************| |******************* *********** *********** ***************|
|******************* ***************************************| 20|******************* ***************************************|
|***********************************************************| |******************* ***************************************|
|***********************************************************| |***********************************************************|
0+-----------------------------------------------------------+ |***********************************************************|
0 100 200 300 400 500 600 700 800 900 1000 0+-----------------------------------------------------------+
+-----------------------------------------------------------+ 0 100 200 300 400 500 600 700 800 900 1000
| | +-----------------------------------------------------------+
60| | | |
| | 60| |
| | | |
| | | |
40| | | |
UID(%)| | 40| |
| | UID(%)| |
| | | |
20| | | |
| *| 20| |
| * *| | *|
| * * * * * ** * *| | * *|
0+-----------------------------------------------------------+ | * * * * * ** * *|
0 100 200 300 400 500 600 700 800 900 1000 0+-----------------------------------------------------------+
Flow Number 0 100 200 300 400 500 600 700 800 900 1000
Flow Number
Figure 7: Simulation Result with Congestion Elimination
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section anchor="Section-4.5" <section anchor="Section-4.5" numbered="true" toc="default">
title="Network Temporal Congestion Elimination"> <name>Network Temporal Congestion Elimination</name>
<t>During the simulations, different degrees of network congestion <t>During the simulations, different degrees of network congestion
were considered. To examine the effect of CCDR on link congestion, we were 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.</t> utilization beyond its threshold.</t>
<t>The CCDR congestion elimination performance is shown in Figure 8. <t>The CCDR congestion elimination performance is shown in <xref
The first graph is the CD distribution before the process of target="sim-congestion-elimination-2"/>. The first graph is the CD
congestion elimination. The average CD of all congested links is about distribution before the process of congestion elimination. The average
20%. The second graph shown in Figure 8 is the CD distribution after CD of all congested links is about 20%. The second graph shown in
using the congestion elimination process. It shows that only 12 links <xref target="sim-congestion-elimination-2"/> is the CD distribution
among the total of 20000 links exceed the threshold, and all the CD after using the congestion elimination process. It shows that only
values are less than 3%. Thus, after scheduling of the traffic away twelve links among the total 20,000 exceed the threshold, and all the
CD values are less than 3%. Thus, after scheduling the traffic away
from the congested paths, the degree of network congestion is greatly from the congested paths, the degree of network congestion is greatly
eliminated and the network utilization is in balance.</t> eliminated and the network utilization is in balance.</t>
<t><figure> <figure anchor="sim-congestion-elimination-2"
<artwork><![CDATA[ Before congestion elimina title="Simulation Results with Congestion Elimination">
tion <artwork align="left" alt="" name="" type=""><![CDATA[
+-----------------------------------------------------------+ Before congestion elimination
| * ** * ** ** *| +-----------------------------------------------------------+
20| * * **** * ** ** *| | * ** * ** ** *|
|* * ** * ** ** **** * ***** *********| 20| * * **** * ** ** *|
|* * * * * **** ****** * ** *** **********************| |* * ** * ** ** **** * ***** *********|
15|* * * ** * ** **** ********* *****************************| |* * * * * **** ****** * ** *** **********************|
|* * ****** ******* ********* *****************************| 15|* * * ** * ** **** ********* *****************************|
CD(%) |* ********* ******* ***************************************| |* * ****** ******* ********* *****************************|
10|* ********* ***********************************************| CD(%) |* ********* ******* ***************************************|
|*********** ***********************************************| 10|* ********* ***********************************************|
|***********************************************************| |*********** ***********************************************|
5|***********************************************************| |***********************************************************|
|***********************************************************| 5|***********************************************************|
|***********************************************************| |***********************************************************|
0+-----------------------------------------------------------+ |***********************************************************|
0 0.5 1 1.5 2 0+-----------------------------------------------------------+
0 0.5 1 1.5 2
After congestion elimination
+-----------------------------------------------------------+
| |
20| |
| |
| |
15| |
| |
CD(%) | |
10| |
| |
| |
5 | |
| |
| * ** * * * ** * ** * |
0 +-----------------------------------------------------------+
0 0.5 1 1.5 2
Link Number(*10000)
Figure 8: Simulation Result with Congestion Elimination After congestion elimination
+-----------------------------------------------------------+
| |
20| |
| |
| |
15| |
| |
CD(%) | |
10| |
| |
| |
5 | |
| |
| * ** * * * ** * ** * |
0 +-----------------------------------------------------------+
0 0.5 1 1.5 2
Link Number(*10000)
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>It is clear that using an active path-computation mechanism that is <t>It is clear that by using an active path-computation mechanism that
able to take into account observed link traffic/congestion, the is 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 will as opposed to when a static metric-based procedure is used, which will
produce congested paths once a single bottleneck approaches its 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<xref target="PTCS"/> .</t> in <xref format="default" target="PTCS"/>.</t>
</section> </section>
</section> </section>
<section title="CCDR Deployment Consideration"> <section numbered="true" toc="default">
<name>CCDR Deployment Consideration</name>
<t>The above CCDR scenarios and simulation results demonstrate that a <t>The above CCDR scenarios and simulation results demonstrate that a
single general solution can be found that copes with multiple complex single general solution can be found that copes with multiple complex
situations. The specific situations considered are not known to have any situations. The specific situations considered are not known to have any
special properties, so it is expected that the benefits demonstrated special properties, so it is expected that the benefits demonstrated
will have general applicability. Accordingly, the integrated use of a will have general applicability. Accordingly, the integrated use of a
centralized controller for the more complex optimal path computations in centralized controller for the more complex optimal path computations in
a native IP network should result in significant improvements without a native IP network should result in significant improvements without
impacting the underlay network infrastructure.</t> impacting the underlying network infrastructure.</t>
<t>For intra-domain or inter-domain native IP TE scenarios, the <t>For intra-domain or inter-domain native IP TE scenarios, the
deployment of a CCDR solution is similar, with the centralized deployment of a CCDR solution is similar with the centralized controller
controller being able to compute paths and no changes required to the being able to compute paths along with no changes being required to the
underlying network infrastructure. This universal deployment underlying network infrastructure. This universal deployment
characteristic can facilitate a generic traffic engineering solution, characteristic can facilitate a generic traffic-engineering solution
where operators do not need to differentiate between intra-domain and where operators do not need to differentiate between intra-domain and
inter-domain TE cases.</t> inter-domain TE cases.</t>
<t>To deploy the CCDR solution, the PCE should collect the underlay <t>To deploy the CCDR solution, the PCE should collect the underlying
network topology dynamically, for example via BGP-LS<xref network topology dynamically, for example, via Border Gateway Protocol -
target="RFC7752"/>. It also needs to gather the network traffic Link State (BGP-LS) <xref format="default" target="RFC7752"/>. It also
information periodically from the network management platform. The needs to gather the network traffic information periodically from the
simulation results show that the PCE can compute the E2E optimal path network management platform. The simulation results show that the PCE
within seconds, thus it can cope with the change of underlay network on can compute the E2E optimal path within seconds; thus, it can cope with
the scale of minutes. More agile requirements would need to increase the a change to the underlying network in a matter of minutes. More agile
sample rate of underlay network and decrease the detection and requirements would need to increase the sample rate of the underlying
notification interval of the underlay network. The methods to gather and network and decrease the detection and notification interval of the
decrease the latency of these information are out of the scope of this underlying network. The methods of gathering this information as well as
draft.</t> decreasing its latency are out of the scope of this document.</t>
</section> </section>
<section title="Security Considerations"> <section numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document considers mainly the integration of distributed <t>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 can
certainly can ease the management of network in various traffic certainly simplify the management of a network in various
engineering scenarios as described in this document, the centralized traffic-engineering scenarios as described in this document, the
control also bring a new point that may be easily attacked. Solutions centralized control also brings a new point that may be easily attacked.
for CCDR scenarios need to consider protection of the PCE and Solutions for CCDR scenarios need to consider protection of the PCE and
communication with the underlay devices.</t> communication with the underlying devices.</t>
<t><xref target="RFC5440"/> and <xref target="RFC8253"/> provide <t><xref format="default" target="RFC5440"/> and <xref format="default"
additional information.</t> target="RFC8253"/> provide additional information.</t>
<t>The control priority and interaction process should also be carefully <t>The control priority and interaction process should also be carefully
designed for the combination of distributed protocol and central designed for the combination of the distributed protocol and central
control. Generally, the central control instruction should have higher control. Generally, the central control instructions should have higher
priority than the forwarding actions determined by the distributed priority than the forwarding actions determined by the distributed
protocol. When the communication between PCE and the underlay devices is protocol. When communication between PCE and the underlying devices is
not in function, the distributed protocol should take over the control disrupted, the distributed protocol should take control of the
right of the underlay network. <xref underlying network. <xref format="default"
target="I-D.ietf-teas-pce-native-ip"/> provides more considerations target="I-D.ietf-teas-pce-native-ip"/> provides more considerations
corresponding to the solution.</t> corresponding to the solution.</t>
</section> </section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<t>This document does not require any IANA actions.</t> <name>IANA Considerations</name>
</section>
<section title="Contributors">
<t>Lu Huang contributed to the content of this draft.</t>
</section>
<section title="Acknowledgement">
<t>The author would like to thank Deborah Brungard, Adrian Farrel,
Huaimo Chen, Vishnu Beeram and Lou Berger for their support and comments
on this draft.</t>
<t>Thanks Benjamin Kaduk for his careful review and valuable suggestions <t>This document has no IANA actions.</t>
to this draft. Also thanks Roman Danyliw, Alvaro Retana and &Eacute;ric
Vyncke for their views and comments.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-teas-pce-native-ip"
<?rfc include="reference.RFC.5440"?> to="PCE-NATIVE-IP"/>
<?rfc include="reference.RFC.7752"?> <displayreference target="I-D.ietf-pce-pcep-extension-native-ip"
to="PCEP-NATIVE-IP-EXT"/>
<?rfc include="reference.RFC.8253"?> <references>
</references> <name>References</name>
<references title="Informative References"> <references>
<?rfc include="reference.RFC.3209"?> <name>Normative References</name>
<?rfc include="reference.RFC.8402"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.x
ml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<?rfc include="reference.RFC.8578"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.x
ml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<?rfc include="reference.I-D.ietf-teas-pce-native-ip"?> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.x
ml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
</references>
<?rfc include="reference.I-D.ietf-pce-pcep-extension-native-ip"?> <references>
<name>Informative References</name>
<reference anchor="PTCS" <xi:include
target="http://ieeexplore.ieee.org/document/8657733"> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.x
<front> ml"
<title>A Practical Traffic Control Scheme With Load Balancing Based xmlns:xi="http://www.w3.org/2001/XInclude"/>
on PCE Architecture</title>
<author fullname="Pei Zhang" initials="P." surname="Zhang"> <xi:include
<organization/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.x
</author> ml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<author fullname="Kun Xie" initials="K." surname="Xie"> <xi:include
<organization/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8578.x
</author> ml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<author fullname="Caixia Kou" initials="C." surname="Kou"> <xi:include
<organization/> href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-
</author> teas-pce-native-ip.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<author fullname="Xiaohong Huang" initials="X." surname="Huang"> <xi:include
<organization/> href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-
</author> pce-pcep-extension-native-ip.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<author fullname="Aijun Wang" initials="A." surname="Wang"> <reference anchor="PTCS"
<organization/> target="https://ieeexplore.ieee.org/document/8657733">
</author> <front>
<title>A Practical Traffic Control Scheme With Load Balancing
Based on PCE Architecture</title>
<author fullname="Qiong Sun" initials="Q." surname="Sun"> <seriesInfo name="DOI" value="10.1109/ACCESS.2019.2902610"/>
<organization/>
</author>
<date day="4" month="March" year="2019"/> <seriesInfo name="IEEE Access" value="18526773"/>
<abstract> <author fullname="Pei Zhang" initials="P." surname="Zhang">
<t>This document describes a framework by which Integrated <organization/>
Services may be supported over Diffserv networks. This memo </author>
provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="IEEE Access" value="18526773"/> <author fullname="Kun Xie" initials="K." surname="Xie">
<organization/>
</author>
<seriesInfo name="DOI" value="10.1109/ACCESS.2019.2902610"/> <author fullname="Caixia Kou" initials="C." surname="Kou">
</reference> <organization/>
</author>
<?rfc ?> <author fullname="Xiaohong Huang" initials="X." surname="Huang">
<organization/>
</author>
<author fullname="Aijun Wang" initials="A." surname="Wang">
<organization/>
</author>
<author fullname="Qiong Sun" initials="Q." surname="Sun">
<organization/>
</author>
<date month="March" year="2019"/>
</front>
</reference>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact
fullname="Deborah Brungard"/>, <contact
fullname="Adrian Farrel"/>, <contact fullname="Huaimo Chen"/>, <contact
fullname="Vishnu Beeram"/>, and <contact fullname="Lou Berger"/> for
their support and comments on this document.</t>
<t>Thanks to <contact fullname="Benjamin Kaduk"/> for his careful review
and valuable suggestions on this document. Also, thanks to <contact
fullname="Roman Danyliw"/>, <contact fullname="Alvaro Retana"/>, and
<contact fullname="Eric Vyncke"/> for their reviews and comments.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t><contact fullname="Lu Huang"/> contributed to the content of this
document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 111 change blocks. 
500 lines changed or deleted 573 lines changed or added

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