| RFC 8735 | CCDR Scenario and Simulation Results | February 2020 |
| Wang, et al. | Informational | [Page] |
服务提供商网络中不断出现提供端到端 (E2E) 性能保证的要求。 尽管有多种技术解决方案，但没有单一的解决方案可以满足本地 IP 网络的这些要求。 尤其需要一种能够覆盖域内和域间场景的通用端到端解决方案。¶
一种可行的端到端流量工程解决方案是在本地 IP 网络中添加中央控制。 本文档描述了在本机 IP 网络中应用路径计算元素 (PCE) 时的各种复杂场景和模拟结果。 该解决方案称为集中控制动态路由 (CCDR)，集成了使用分布式协议的优势和集中控制技术的强大功能，以同样适用于域内和域间的方式为本机 IP 网络提供流量工程。场景。¶
本文档不是互联网标准跟踪规范；发布仅供参考。¶
本文档是互联网工程任务组 (IETF) 的产品。 它代表了IETF社区的共识。 它已接受公众审查，并已被互联网工程指导小组 (IESG) 批准发布。 并非 IESG 批准的所有文件都是任何级别互联网标准的候选文件；请参阅 RFC 7841 第 2 节。¶
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8735。¶
版权所有 (c) 2020 IETF Trust 和文档作者。 保留所有权利。¶
本文档受本文档发布之日生效的 BCP 78 和 IETF Trust 与 IETF 文件相关的法律规定 (https://trustee.ietf.org/license-info) 的约束。 请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。 从本文档中提取的代码组件必须包括信托法律条款第 4.e 节中所述的简化 BSD 许可文本，并且在提供时不提供简化 BSD 许可中所述的保证。¶
服务提供商网络由数千个运行分布式协议来交换可达性信息的路由器组成。 目的网络的路径主要由分布式协议计算和控制。 这些分布式协议足够强大，可以支持大多数应用程序；然而，它们在支持流量工程应用所需的复杂性方面存在一些困难，例如端到端性能保证或最大化 IP 网络内的链路利用率。¶
使用流量工程 (TE) 技术的多协议标签交换 (MPLS) (MPLS-TE)[RFC3209] 是 TE 网络的一种解决方案，但它引入了 MPLS 网络与相关技术，这将是IP网络的覆盖。 MPLS-TE 技术通常用于标签交换路径 (LSP) 保护以及在域内建立复杂路径。 尚未广泛部署以满足IP网络端到端（尤其是域间）动态性能保障需求。¶
分段路由[RFC8402]是另一种解决方案，它集成了使用分布式协议和中央控制技术的一些优点，但它需要底层网络，特别是提供商边缘路由器来执行深入的标签推送和弹出操作，同时在与非分段路由网络共存时增加复杂性。 此外，它只能通过不同的机制操纵 MPLS 和 IPv6 流量的 E2E 路径。¶
确定性网络 (DetNet) [RFC8578] 是另一种可能的解决方案。 它主要专注于为流提供有限的延迟，并对域边缘路由器提出了额外的要求。 目前的 DetNet 范围仅限于一个域内。 本文档中定义的用例不需要确定性属性的额外复杂性，因此与 DetNet 用例不同。¶
本文档描述了本机 IP 网络的几种场景，其中集中控制动态路由 (CCDR) 框架可以在效率上产生质的改进，而无需更改路由器上的数据平面行为。 利用路由器通告的边界网关协议 (BGP) 会话特定前缀、网络拓扑和来自网络管理系统的近实时链路利用率信息，中央 PCE 能够计算最佳路径并给出底层路由器用于到达 BGP 下一跳的目标地址，以便分布式路由协议将通过传统的递归查找过程使用计算出的路径。 还给出了一些路径优化模拟结果，具体说明了 CCDR 相对于传统分布式路由协议的显着改进的各种场景。¶
本文档是以下两个文档的基础文档：通用解决方案文档，适用于域内和域间TE场景，参见[PCE-NATIVE-IP ]；相关协议扩展内容参见[PCEP-NATIVE-IP-EXT]。¶
在本文档中，PCE 按照 [RFC5440] 中的定义使用。 此处使用了以下术语：¶
以下部分描述了各种部署场景，在这些场景中，应用 CCDR 框架直观地预计会根据框架和场景的宏观属性产生改进。¶
随着云计算技术的出现，企业将越来越多的服务放在面向公有的云环境上，同时将核心业务保留在私有云中。 私有云站点和公共云站点之间的通信跨越 WAN。 它们之间的带宽要求是可变的，并且这两个站点之间的后台流量随着时间的推移而变化。 企业应用需要按需保证可变带宽业务的端到端QoS性能。¶
CCDR融合了分布式协议的优点和集中控制的力量，非常适合这种场景。 可能的解决方案框架如下图所示：¶
+------------------------+
| Cloud-Based Application|
+------------------------+
|
+-----------+
| PCE |
+-----------+
|
|
//--------------\\
///// \\\\\
Private Cloud Site || Distributed |Public Cloud Site
| Control Network |
\\\\\ /////
\\--------------//
如图图1所示，“云应用”流量的来源和目的地分别位于“私有云站点”和“公有云站点”。¶
默认情况下，私有云站点和公共云站点之间的流量路径由分布式控制网络决定。 当应用需要端到端的QoS保证时，可以将这些需求发送给PCE，让PCE根据底层网络拓扑和真实流量信息计算出一条端到端的路径，以满足应用的QoS需求。 本文档的第 4.4 节描述了该用例的模拟结果。¶
城域网 (MAN) 内的网络拓扑一般采用星形模式，如 图 2 所示，不同的设备连接到不同的客户类型。 这些客户的流量往往呈潮汐式，核心路由器（CR）/宽带远程接入服务器（BRAS）和CR/业务路由器（SR）之间的链路由于BRAS下的用户经常使用宽带网络而在不同时期出现拥塞。夜间网络和SR下的专线用户经常在白天使用网络。 BRAS/SR和CR之间的链路必须分别满足它们之间的最大流量，这导致这些链路经常得不到充分利用。¶
+--------+
| CR |
+----|---+
|
|-------|--------|-------|
| | | |
+--|-+ +-|+ +--|-+ +-|+
|BRAS| |SR| |BRAS| |SR|
+----+ +--+ +----+ +--+
如果我们考虑将BRAS/SR与本地链路环路连接（通常成本较低）并使用CCDR框架控制整个城域网拓扑，我们可以利用BRAS/CR和SR/CR链路之间的潮汐现象，最大化利用这些中央干线链路（通常比本地环路的成本更高）。¶
+-------+
----- PCE |
| +-------+
+----|---+
| CR |
+----|---+
|
|-------|--------|-------|
| | | |
+--|-+ +-|+ +--|-+ +-|+
|BRAS-----SR| |BRAS-----SR|
+----+ +--+ +----+ +--+
如 图 4 所示，服务提供商网络通常由不同的域组成，这些域相互连接，形成非常复杂的拓扑结构。 由于进出 MAN 和 IDC 的流量模式，它们之间的链路利用率通常是不对称的。 通过分布式协议来平衡这些链路的使用几乎是不可能的，但是可以利用 CCDR 框架来克服这种不平衡。¶
+---+ +---+
|MAN|----------------|IDC|
+---+ | +---+
| ---------- |
|-----|Backbone|-----|
| ----|----- |
| | |
+---+ | +---+
|IDC|----------------|MAN|
+---+ +---+
此场景的解决方案需要收集 NetFlow 信息、分析源/目标自治系统 (AS)，并确定拥塞链路的主要原因是什么。 此后，运营商可以根据 CCDR 框架中描述的解决方案，使用外部边界网关协议 (eBGP) 会话来调度不同域之间的流量。¶
在更一般的情况下，服务提供商的网络内经常存在临时拥塞，例如，由于每日或每周的周期性突发或提前安排好的大型事件。 这种拥塞现象经常出现，如果服务提供商有办法缓解这种拥塞现象，必将提高其网络运营能力并提高客户的满意度。 CCDR 也适用于此类场景，因为控制器可以调度拥塞链路中的流量，从而降低这些时间段的利用率。 第4.5节描述了该场景的模拟结果。¶
以下部分描述了一个具体的案例研究，以说明 CCDR 算法与具体路径/度量的工作原理，以及生成拓扑和流量矩阵的过程以及应用 CCDR 实现 E2E QoS（保证路径和拥塞消除）的模拟结果在生成的拓扑和流量矩阵上。 在所有检查的案例中，CCDR 算法在质量上比参考 (OSPF) 算法有了显着的改进，这表明 CCDR 将具有广泛的适用性。¶
模拟拓扑的结构和规模与真实网络相似。 生成多个不同的流量矩阵来模拟网络中不同的拥塞状况。 由于其他结果相似，因此仅说明其中之一。¶
在本节中，我们考虑一个特定的网络拓扑进行案例研究：检查 OSPF 和 CCDR 选择的路径并评估路径的不同方式和原因。 图 5 描述了本例中的网络拓扑。 网络中有八台转发设备。 原来的成本和利用率都标注在上面了，如图所示。 例如，链路(1, 2)的原始成本和利用率分别为3%和50%。 有两个流：f1 和 f2。 这两个流都是从节点1到节点8。 为了简单起见，假设网络中链路的带宽为10 Mb/s。 f1的流量为1Mb/s，f2的流量为2Mb/s。 链路拥塞阈值为90%。¶
如果网络中应用采用Dijkstra算法的OSPF协议（IS-IS也类似，因为也采用Dijkstra算法），则从节点1到节点8的两条流只能使用OSPF路径（p1:1-> 2->3->8)。 这是因为Dijkstra算法主要考虑的是链路的原始成本。 由于CCDR同时考虑成本和利用率，因此由于链路拥塞严重，不会选择与OSPF相同的路径（2、3）。 在这种情况下，f1 将选择路径 (p2: 1->5->6->7->8)，因为该路径的新成本优于 OSPF 路径的新成本。 此外，对于流f1，路径p2也优于路径(p3：1->2->4->7->8)。 然而，f2 不会选择相同的路径，因为这会导致链路 (6, 7) 中出现新的拥塞。 结果，f2 将选择路径 (p3: 1->2->4->7->8)。¶
+----+ 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 |---------+
+-----+ +-----+
(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
从具体的案例研究开始，我们现在考虑一类更能代表实际部署的网络，其具有完全链接的核心网络，用于连接边缘节点，而边缘节点本身仅连接到核心的一个子集。 图 6 显示了此类拓扑的示例，其中包含 4 个核心节点和 5 个边缘节点。 本工作中提出的 CCDR 模拟使用涉及 100 个核心节点和 400 个边缘节点的拓扑。 虽然生成的图表不适合此页面，但这种网络规模与生产环境中部署的网络规模类似。¶
+----+
/|Edge|\
| +----+ |
| |
| |
+----+ +----+ +----+
|Edge|----|Core|-----|Core|---------+
+----+ +----+ +----+ |
/ | \ / | |
+----+ | \ / | |
|Edge| | X | |
+----+ | / \ | |
\ | / \ | |
+----+ +----+ +----+ |
|Edge|----|Core|-----|Core| |
+----+ +----+ +----+ |
| | |
| +------\ +----+
| ---|Edge|
+-----------------/ +----+
为了进行模拟，将一个边缘节点连接到一组核心节点的链路数量在 2 到 30 之间随机选择，并且链路总数超过 20,000。 每条链路都有一个拥塞阈值，可以任意设置，例如设置为链路标称容量的90%，不会影响仿真结果。¶
对于每个拓扑，根据该拓扑的链路容量生成流量矩阵。 可能会导致拥塞、轻度拥塞、不拥塞等多种情况。¶
CCDR模拟中，流量矩阵的维度为500*500（100个核心节点+400个边缘节点）。 网络中使用开放最短路径优先（OSPF）协议时，大约有20%的链路出现过载。¶
CCDR E2E路径优化需要找到度量值最低的最佳路径，并且路径中每条链路的利用率远低于拥塞阈值。 CCDR框架内的PCE基于网络的当前状态，将最短路径算法与经典优化和图论的惩罚理论相结合。¶
给定一个未调度的背景流量矩阵，当一组新流进入网络时，端到端路径优化会找到它们的最佳路径。 所选路径给网络带来的拥塞程度最小。¶
新流量加入网络后的链路利用率增量度 (UID) 如 图 7 所示。 图7中第一张图是使用OSPF的UID，第二张图是使用CCDR E2E路径优化的UID。 第一张图的平均UID超过30%。 路径优化后，平均UID小于5%。 结果表明，CCDR E2E路径优化相对于基于OSPF选择的路径，UID明显下降。¶
虽然现实世界的结果总是与模拟不同（例如，现实世界的拓扑可能会表现出边缘节点到核心的附着模式的相关性，但这些结果并未反映在这些结果中），UID 改进的巨大本质选择模拟拓扑来模拟现实世界的条件表明，现实世界的部署也将在 UID 结果方面得到显着改善。¶
+-----------------------------------------------------------+
| * * * *|
60| * * * * * *|
|* * ** * * * * * ** * * * * **|
|* * ** * * ** *** ** * * ** * * * ** * * *** **|
|* * * ** * ** ** *** *** ** **** ** *** **** ** *** **|
40|* * * ***** ** *** *** *** ** **** ** *** ***** ****** **|
UID(%)|* * ******* ** *** *** ******* **** ** *** ***** *********|
|*** ******* ** **** *********** *********** ***************|
|******************* *********** *********** ***************|
20|******************* ***************************************|
|******************* ***************************************|
|***********************************************************|
|***********************************************************|
0+-----------------------------------------------------------+
0 100 200 300 400 500 600 700 800 900 1000
+-----------------------------------------------------------+
| |
60| |
| |
| |
| |
40| |
UID(%)| |
| |
| |
20| |
| *|
| * *|
| * * * * * ** * *|
0+-----------------------------------------------------------+
0 100 200 300 400 500 600 700 800 900 1000
Flow Number
在模拟过程中，考虑了不同程度的网络拥塞。 为了检查 CCDR 对链路拥塞的影响，我们考虑链路的拥塞度 (CD)，定义为超出其阈值的链路利用率。¶
CCDR 的拥塞消除性能如 图 8 所示。 第一张图是拥塞消除过程之前的CD分布。 所有拥塞链路的平均CD约为20%。 图8所示的第二张图是使用拥塞消除过程后的CD分布。 结果显示，2万个环节中只有12个环节超过了阈值，所有CD值均小于3%。 这样，将流量调度远离拥塞路径后，网络拥塞程度大大消除，网络利用率达到平衡。¶
Before congestion elimination
+-----------------------------------------------------------+
| * ** * ** ** *|
20| * * **** * ** ** *|
|* * ** * ** ** **** * ***** *********|
|* * * * * **** ****** * ** *** **********************|
15|* * * ** * ** **** ********* *****************************|
|* * ****** ******* ********* *****************************|
CD(%) |* ********* ******* ***************************************|
10|* ********* ***********************************************|
|*********** ***********************************************|
|***********************************************************|
5|***********************************************************|
|***********************************************************|
|***********************************************************|
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)
显然，通过使用能够考虑观察到的链路流量/拥塞的主动路径计算机制，可以大大减少拥塞事件的发生。 只有当网络中的优势链路接近其拥塞阈值时，中央控制器才无法找到一条畅通的路径，这与使用基于静态度量的过程不同，一旦单个瓶颈接近其容量，就会产生拥塞路径。 有关该算法的更多详细信息可以在[PTCS]中找到。¶
上述 CCDR 场景和仿真结果表明，可以找到应对多种复杂情况的单一通用解决方案。 所考虑的具体情况尚不清楚是否具有任何特殊属性，因此预计所展示的好处将具有普遍适用性。 因此，在本机 IP 网络中集成使用集中式控制器来进行更复杂的最佳路径计算应该会带来显着的改进，而不会影响底层网络基础设施。¶
对于域内或域间的原生IP TE场景，CCDR解决方案的部署类似于集中控制器能够计算路径，并且不需要改变底层网络基础设施。 这种通用部署特性可以促进通用流量工程解决方案，运营商无需区分域内和域间 TE 情况。¶
要部署 CCDR 解决方案，PCE 应动态收集底层网络拓扑，例如通过边界网关协议 - 链路状态 (BGP-LS)[RFC7752]。 它还需要定期从网络管理平台收集网络流量信息。 仿真结果表明PCE可以在数秒内计算出端到端最优路径；因此，它可以在几分钟内应对底层网络的变化。 更敏捷的需求需要提高底层网络的采样率，减少底层网络的检测和通知间隔。 收集此信息以及减少其延迟的方法超出了本文档的范围。¶
本文档主要考虑分布式协议的集成和PCE的集中控制能力。 虽然它确实可以简化本文所述的各种流量工程场景中的网络管理，但集中控制也带来了一个容易受到攻击的新点。 CCDR场景的解决方案需要考虑PCE的保护以及与底层设备的通信。¶
[RFC5440] 和 [RFC8253] 提供更多信息。¶
针对分布式协议与集中控制的结合，还应精心设计控制优先级和交互过程。 一般来说，中央控制指令应具有比分布式协议确定的转发动作更高的优先级。 当PCE和底层设备之间的通信中断时，分布式协议应该控制底层网络。 [PCE-NATIVE-IP]提供了与解决方案相对应的更多注意事项。¶
本文档没有 IANA 操作。¶
作者谨此感谢 Deborah Brungard、Adrian Farrel、Huaimo Chen、Vishnu Beeram 和 感谢 Lou Berger 对本文档的支持和评论。¶
感谢 Benjamin Kaduk 对本文档的仔细审阅和宝贵建议。 另外，感谢 Roman Danyliw、Alvaro Retana 和 Éric Vyncke 的审阅和评论。¶
Lu Huang为本文档的内容做出了贡献。¶