MPLS 流量工程要求

1、 简介

多协议标签交换 (Multiprotocol Label Switching，MPLS) [1,2] 将标签交换框架与网络层路由集成在一起。基本思想涉及在 MPLS 云的入口处为数据包分配固定长度的短标签（基于转发等效类的概念 [1,2]）。在 MPLS 域的整个内部，附加到数据包的标签用于做出转发决策（通常不求助于原始数据包头）。

可以从这个相对简单的范例中设计出一组强大的结构来解决新兴的差异化服务 Internet 中的许多关键问题。MPLS 最重要的初始应用之一将是流量工程。此应用程序的重要性已得到广泛认可（参见 [1,2,3]）。

这份手稿专门针对 MPLS 的流量工程应用。具体而言，本文档的目标是强调大型 Internet 骨干网中流量工程的问题和要求。期望 MPLS 规范或从其派生的实现将解决这些目标的实现。还介绍了 MPLS 实现满足要求所需的基本能力和功能。

应该注意的是，即使重点是 Internet 骨干网，本文档中描述的功能也同样适用于企业网络中的流量工程。通常，这些能力可以应用于单个技术管理下的任何标签交换网络，其中两个节点之间至少存在两条路径。

最近的一些手稿侧重于与 MPLS 下的流量工程和流量管理有关的注意事项，最著名的是 Li 和 Rekhter [3] 等人的作品。在 [3] 中，提出了一种架构，该架构采用 MPLS 和 RSVP 在 Internet 中提供可扩展的差异化服务和流量工程。本手稿补充了上述和类似的努力。它反映了作者在管理大型互联网骨干网方面的操作经验。

1.1、 术语

假定读者熟悉 [1] 中定义的 MPLS 术语。

本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是按照 RFC 2119 [11] 中的描述进行解释。

1.2、 文件组织

本文档的其余部分组织如下：第 2 节讨论 Internet 中流量工程的基本功能。第 3 节概述了 MPLS 的流量工程潜力。第 1 至 3 部分基本上是背景材料。第 4 节概述了 MPLS 流量工程的基本要求。第 5 节描述了与流量工程相关的流量骨干的理想属性和特征。第 6 节介绍了一组可以与资源相关联的属性，以通过它们来限制流量骨干和 LSP 的可路由性。第 7 节提倡在 MPLS 域中引入“基于约束的路由”框架。最后，第 8 节包含结束语。

2、 流量工程

本节介绍当代互联网自治系统中流量工程的基本功能。突出显示了当前 IGP 在流量和资源控制方面的局限性。本节作为 MPLS 要求的动机。

流量工程 (Traffic Engineering，TE) 关注运营网络的性能优化。一般而言，它包括将技术和科学原理应用于互联网流量的测量、建模、表征和控制，以及应用此类知识和技术来实现特定的性能目标。与 MPLS 相关的流量工程的方面是测量和控制。

Internet 流量工程的一个主要目标是促进高效可靠的网络操作，同时优化网络资源利用率和流量性能。由于网络资产的高成本以及互联网的商业和竞争性质，流量工程已成为许多大型自治系统中不可或缺的功能。这些因素强调了对最大运营效率的需求。

2.1、 流量工程性能目标

与流量工程相关的关键性能目标可以分类为：

1. 流量导向；

2. 资源导向。

面向流量的性能目标包括提高流量流 QoS 的方面。在单一类别的尽力而为 Internet 服务模型中，面向流量的关键性能目标包括：最小化数据包丢失、最小化延迟、最大化吞吐量和执行服务级别协议。在单类尽力而为 Internet 服务模型下，最小化数据包丢失是最重要的面向流量的性能目标之一。面向统计有界流量的性能目标（例如峰峰值数据包延迟变化、丢失率和最大数据包传输延迟）可能在即将到来的差异化服务互联网中变得有用。

面向资源的性能目标包括与资源利用优化相关的方面。网络资源的有效管理是实现面向资源的性能目标的工具。特别地，通常希望确保网络资源的子集不会变得过度利用和拥塞，而沿替代可行路径的其他子集保持未充分利用。带宽是当代网络中的重要资源。因此，流量工程的核心功能是有效地管理带宽资源。

最小化拥塞是主要的流量和面向资源的性能目标。这里的兴趣是长时间的拥塞问题，而不是由瞬时突发引起的瞬时拥塞。拥塞通常表现在两种情况下：

1. 当网络资源不足或不足以容纳提供的负载时。

2. 当流量流被低效地映射到可用资源时；导致网络资源的子集变得过度利用，而其他网络资源仍未得到充分利用。

第一类拥塞问题可以通过以下任一方式解决：(i) 容量扩展，或 (ii) 应用经典拥塞控制技术，或 (iii) 两者兼而有之。经典的拥塞控制技术试图调节需求，以便流量适合可用资源。拥塞控制的经典技术包括：速率限制、窗口流量控制、路由器队列管理、基于调度的控制等；（参见 [8] 和其中的参考资料）。

第二种拥塞问题，即资源分配效率低下的问题，通常可以通过流量工程来解决。

一般来说，可以通过采用负载均衡策略来减少资源分配效率低下导致的拥塞。这种策略的目标是通过有效的资源分配来最小化最大拥塞或者最小化最大资源利用率。当通过有效的资源分配最小化拥塞时，数据包丢失减少，传输延迟减少，总吞吐量增加。从而，终端用户对网络服务质量的感知得到显着增强。

显然，负载均衡是一项重要的网络性能优化策略。尽管如此，为流量工程提供的功能应该足够灵活，以便网络管理员可以实施其他策略，这些策略考虑到普遍的成本结构和效用或收入模型。

2.2、 流量和资源控制

运营网络的性能优化基本上是一个控制问题。在流量工程过程模型中，流量工程师或合适的自动机充当自适应反馈控制系统中的控制器。该系统包括一组互连的网元、一个网络性能监控系统和一组网络配置管理工具。流量工程师制定控制策略，通过监控系统观察网络状态，表征流量，并根据控制策略应用控制动作将网络驱动到所需状态。这可以通过响应网络的当前状态采取行动来被动地完成，或者通过使用预测技术来预测未来趋势并采取行动来避免预测的不良未来状态来主动完成。

理想情况下，控制措施应包括：

1. 流量管理参数的修改，

2. 修改与路由相关的参数，以及

3. 修改与资源相关的属性和约束。

应尽可能减少流量工程过程中涉及的人工干预水平。这可以通过以分布式和可扩展方式自动化上述控制动作的各个方面来实现。

2.3、 当前 IGP 控制机制的局限性

本小节回顾了当前 IGP 在流量工程方面的一些众所周知的局限性。

现有 Internet 内部网关协议提供的控制能力不足以用于流量工程。这使得难以实施有效的策略来解决网络性能问题。事实上，基于最短路径算法的 IGP 对互联网内自治系统中的拥塞问题有很大贡献。SPF 算法通常基于简单的附加度量进行优化。这些协议是拓扑驱动的，因此带宽可用性和流量特征不是路由决策中考虑的因素。因此，拥塞经常发生在：

1. 多个业务流的最短路径汇聚在特定链路或路由器接口上，或2. 给定的流量流通过没有足够带宽来容纳它的链路或路由器接口进行路由。

即使存在容量过剩的可行替代路径，这些情况也会出现。流量工程旨在大力消除拥塞问题的这一方面（资源分配不理想的症状）。等价路径负载共享可用于解决上面列出的第二个拥塞原因，并取得一定程度的成功，但是它通常无助于缓解由于上面列出的第一个原因导致的拥塞，尤其是在具有密集拓扑的大型网络中。

一种避免当前 IGP 不足的流行方法是通过使用overlay模型，例如 IP over ATM 或 IP over frame 中继。overlay模型通过在网络的物理拓扑之上提供任意虚拟拓扑来扩展设计空间。虚拟拓扑由虚拟电路构成，这些虚拟电路表现为 IGP 路由协议的物理链路。overlay模型提供额外的重要服务来支持流量和资源控制，包括：(1) VC 级别基于约束的路由，(2) 支持可管理配置的显式 VC 路径，(3) 路径压缩，(4) 呼叫准入控制功能，(5) 流量整形和流量监管功能，以及 (6) VC 的生存能力。这些功能可以实现各种流量工程策略。例如，可以轻松地重新路由虚拟电路，将流量从过度利用的资源转移到相对未充分利用的资源上。

对于大型密集网络中的流量工程，希望为 MPLS 配备至少与当前overlay模型相称的功能级别。幸运的是，这可以以相当直接的方式完成。

3、 MPLS 与流量工程

本节概述了 MPLS 在流量工程中的适用性。随后的部分讨论了满足流量工程要求所需的功能集。

MPLS 对流量工程具有重要的战略意义，因为它可以以集成的方式提供overlay模型中可用的大部分功能，并且成本低于当前竞争的替代方案。同样重要的是，MPLS 提供了使流量工程功能的各个方面自动化的可能性。最后一个考虑需要进一步调查，超出了本手稿的范围。

术语说明：MPLS 流量骨干的概念在本文档的其余部分被广泛使用。根据 Li 和 Rekhter [3]，流量骨干是放置在标签交换路径内的同一类流量的聚合。从本质上讲，流量骨干是流量的抽象表示，可以与特定特征相关联。将流量骨干视为可以路由的对象很有用；即可以改变业务骨干经过的路径。在这方面，流量中继类似于 ATM 和帧中继网络中的虚拟电路。然而，需要强调的是，流量骨干与路径之间存在根本区别，实际上与它所经过的 LSP 之间存在根本区别。LSP 是流量所经过的标签交换路径的规范。在实践中，术语 LSP 和流量骨干经常作为同义词使用。本手稿中使用的流量骨干的其他特征在第 5.0 节中进行了总结。

MPLS 对流量工程的吸引力可归因于以下因素：（1）不受基于目的地的转发范式约束的显式标签交换路径可以通过手动管理操作或通过底层协议的自动操作轻松创建，（2) LSP 可以潜在地有效维护，(3) 流量骨干可以实例化并映射到 LSP，(4) 一组属性可以与调节其行为特征的流量骨干相关联，(5) 一组属性可以与限制 LSP 和流量骨干放置的资源相关联，(6) MPLS 允许流量聚合和分解，而传统的仅基于目的地的 IP 转发只允许聚合，(7) 将“基于约束的路由”框架与 MPLS 集成相对容易，(8) MPLS 的良好实现可以提供比流量工程的竞争替代方案低得多的开销。

此外，通过显式标签交换路径，MPLS 允许在当前 Internet 路由模型上叠加准电路交换能力。许多现有的 MPLS 流量工程提案仅关注创建显式 LSP 的潜力。尽管此功能是流量工程的基础，但还远远不够。需要额外的增强来促进导致大型运营网络性能优化的政策的实现。本手稿中描述了一些必要的增强。

3.1、 引导 MPLS 图

本小节介绍了“引导 MPLS 图”的概念，它是 MPLS 域中流量工程的核心。引导 MPLS 图类似于overlay模型中的虚拟拓扑。通过为业务骨干选择 LSP，它在逻辑上映射到物理网络上。

引导 MPLS 图由一组包含图节点的 LSR 和一组 LSP 组成，这些 LSP 提供 LSR 之间的逻辑点到点连接，因此用作引导图的链接。有可能基于标签堆栈的概念构建分层引导 MPLS 图（参见 [1]）。

引导 MPLS 图很重要，因为 MPLS 域中带宽管理的基本问题是如何将引导 MPLS 图有效地映射到物理网络拓扑的问题。引导的 MPLS 图抽象形式化如下。

设 G = (V, E, c) 是一个描述网络物理拓扑结构的电容图。这里，V 是网络中的节点集，E 是链接集；也就是说，对于 V 中的 v 和 w，如果 v 和 w 在 G 下直接连接，则对象 (v,w) 在 E 中。参数“c”是一组与 E 和 V 相关的容量和其他约束。我们将 G 称为“基础”网络拓扑。

设 H = (U, F, d) 是引导 MPLS 图，其中 U 是 V 的子集，表示网络中的 LSR 集，或者更准确地说，是作为至少一个 LSP 端点的 LSR 集。这里，F 是 LSP 的集合，因此对于 U 中的 x 和 y，如果存在以 x 和 y 作为端点的 LSP，则对象 (x, y) 在 F 中。参数“d”是与 F 相关的一组要求和限制。显然，H 是一个有向图。可见H依赖于G的传递特性。

3.2、 MPLS流量工程的基本问题

基本上存在与 MPLS 上的流量工程相关的三个基本问题。

- 第一个问题涉及如何将数据包映射到转发等价类。

- 第二个问题涉及如何将转发等价类映射到流量骨干上。

- 第三个问题涉及如何通过标签交换路径将流量骨干映射到物理网络拓扑上。

本文档不关注列出的前两个问题。（尽管它们非常重要）。相反，本手稿的其余部分将重点介绍允许第三映射功能以导致高效和可靠网络操作的方式执行的功能。这实际上是将引导 MPLS 图 (H) 映射到“基本”网络拓扑 (G) 的问题。

4、 基于 MPLS 的流量工程增强能力

前面几节回顾了流量工程在当代互联网中的基本功能。还讨论了 MPLS 对该活动的适用性。本手稿的其余部分描述了在大型网络中完全支持 MPLS 流量工程所需的功能。

建议的能力包括：

1. 与流量骨干相关的一组属性，它们共同指定了它们的行为特征。

2. 一组与资源相关联的属性，这些属性限制了通过它们的流量骨干的放置。这些也可以看作是拓扑属性约束。

3. 一个“基于约束的路由”框架，用于为受到上述 1) 和 2) 项约束的业务骨干选择路径。基于约束的路由框架不必是 MPLS 的一部分。但是，这两者需要紧密集成在一起。

与业务骨干和资源相关的属性，以及与路由相关的参数，共同表示控制变量，这些变量可以通过管理操作或通过自动代理进行修改，以将网络驱动到所需状态。

在运营网络中，非常希望运营商可以在线动态修改这些属性，而不会不利地中断网络运营。

5、 流量骨干属性和特点

本节描述了可与流量骨干相关联以影响其行为特征的理想属性。

首先，流量骨干（如本手稿中使用的）的基本属性总结如下：

- 流量骨干是属于同一类的流量流的*聚合*。在某些情况下，可能需要放宽此定义并允许流量骨干包含多类流量聚合。

- 在单类服务模型中，例如当前的 Internet，流量骨干可以封装入口 LSR 和出口 LSR 之间的所有流量，或其子集。

- 流量骨干是可路由的对象（类似于 ATM VC）。

- 业务骨干与其所经过的 LSP 不同。在操作环境中，流量骨干可以从一条路径移动到另一条路径。

- 业务骨干是单向的。

在实践中，流量骨干可以通过其入口和出口 LSR、映射到其上的转发等效类以及一组确定其行为特征的属性来表征。

两个基本问题特别重要：（1）流量骨干的参数化和（2）流量骨干的路径放置和维护规则。

5.1、 双向流量中继

尽管流量骨干在概念上是单向的，但在许多实际情况下，同时实例化具有相同端点但以相反方向传送数据包的两个流量骨干是有用的。两个业务骨干在逻辑上耦合在一起。一个称为转发骨干的骨干将流量从始发节点传送到目的地节点。另一条中继称为反向中继，将流量从目的节点传送到始发节点。如果以下两个条件成立，我们将两个这样的业务骨干的合并称为一个双向业务骨干 (bidirectional traffic trunk，BTT)：

- 两个业务骨干都通过一个 LSR 上的原子动作（称为发起节点）或通过网络管理站的原子动作实例化。

- 没有一个复合流量骨骨干都不能存在。也就是说，两者一起被实例化和销毁。

还应考虑 BTT 的拓扑特性。BTT 可以是拓扑对称的或拓扑不对称的。如果 BTT 的组成流量骨干通过相同的物理路径路由，即使它们在相反的方向上运行，也可以说 BTT 是“拓扑对称的”。然而，如果组件流量骨干通过不同的物理路径路由，则 BTT 被称为“拓扑不对称”。

应该注意的是，双向流量骨干只是一种管理上的便利。在实践中，大多数流量工程功能可以仅使用单向流量骨干来实现。

5.2、 流量中继基本操作

下面总结了对流量工程意义重大的流量骨干的基本操作。

- 创建/ Establish：创建流量骨干的实例。

- 激活/ Activate：使流量骨干开始通过流量。业务骨干的建立和激活在逻辑上是独立的事件。但是，它们可以作为一个原子操作来实现或调用。

- 停用/ Deactivate：使流量骨干停止通过流量。

- 修改属性/ Modify Attributes：修改流量骨干的属性。

- 重新路由/ Reroute：使流量骨干改变其路由。这可以通过管理操作或由底层协议自动完成。

- 销毁/ Destroy：从网络中删除流量骨干的实例并回收分配给它的所有资源。这些资源包括标签空间和可能的可用带宽。

以上是对业务骨干的基本操作。其他操作也是可能的，例如管制和流量整形。

5.3、 计费和性能监控

计费和性能监控功能对于计费和流量表征功能非常重要。从计费和性能监控系统获得的性能统计数据可用于流量工程领域内的流量特征、性能优化和容量规划。

在流量骨干级别获取统计数据的能力非常重要，因此应将其视为 MPLS 流量工程的基本要求。

5.4、 流量骨干的基本流量工程属性

业务骨干的属性是分配给它的影响其行为特征的参数。

属性可以通过管理操作显式分配给流量骨干，也可以在分组被分类并映射到 MPLS 域入口处的等效类时由底层协议隐式分配。不管这些属性最初是如何分配的，出于流量工程的目的，应该可以在管理上修改这些属性。

下面列举了对流量工程特别重要的流量骨干的基本属性。

- 流量参数属性

- 通用路径选择和维护属性

- 优先属性

- 抢占属性

- 弹性属性

- 警务属性

流量参数和监管属性的组合类似于 ATM 网络中的使用参数控制。上面列出的大多数属性在成熟的技术中都有类似物。因此，将流量骨干属性映射到许多现有的交换和路由架构应该是相对简单的。

优先级和抢占可以看作是关系属性，因为它们表达了业务骨干之间的某些二元关系。从概念上讲，这些二元关系决定了流量骨干在路径建立和路径维护期间竞争网络资源时相互交互的方式。

5.5、 流量参数属性

流量参数可用于捕获要通过流量骨干传输的流量流的特征（或更准确地说是转发等价类）。这些特性可能包括峰值速率、平均速率、允许的突发大小等。从流量工程的角度来看，流量参数很重要，因为它们表明了流量骨干的资源需求。这对于通过预期策略分配资源和避免拥塞很有用。

出于带宽分配的目的，可以从流量骨干的流量参数计算带宽要求的单个规范值。执行这些计算的技术是众所周知的。这方面的一个例子是有效带宽理论。

5.6、 通用路径选择和管理属性

通用路径选择和管理属性定义了选择业务骨干所采用的路由的规则以及维护已经建立的路径的规则。

路径可以由底层路由协议自动计算，也可以由网络运营商以管理方式定义。如果没有与流量骨干相关的资源要求或限制，则可以使用拓扑驱动协议来选择其路径。但是，如果存在资源需求或策略限制，则应使用基于约束的路由方案进行路径选择。

在第 7 节中，描述了一个基于约束的路由框架，它可以自动计算受一组约束约束的路径。与通过管理操作实例化的显式路径有关的问题在下面的第 5.6.1 节中讨论。

路径管理涉及与维护业务骨干所经过的路径有关的所有方面。在某些操作环境中，希望 MPLS 实现能够动态地重新配置自身，以适应“系统状态”中的某些变化概念。适应性和弹性是动态路径管理的方面。

为了指导路径选择和管理过程，需要一组属性。本小节的其余部分描述了与业务骨干路径选择和管理相关的基本属性和行为特征。

5.6.1、 管理指定的显式路径

流量骨干的管理指定显式路径是通过操作员操作配置的路径。可以完全指定或部分指定管理指定的路径。如果指示了端点之间所需的所有跃点，则完全指定了路径。如果仅指示中间跳的子集，则部分指定路径。在这种情况下，需要底层协议来完成路径。由于操作员错误，管理指定的路径可能不一致或不合逻辑。底层协议应该能够检测到这种不一致并提供适当的反馈。

“路径偏好规则”属性应该与管理指定的显式路径相关联。路径偏好规则属性是一个二进制变量，它指示管理配置的显式路径是“强制”还是“非强制”。

如果选择了具有“强制属性”的管理指定的显式路径，则必须使用该路径（并且仅该路径）。如果强制路径是拓扑不可行的（例如，两个端点被拓扑分区），或者如果该路径不能被由于可用资源不足而实例化，则路径设置过程失败。换句话说，如果一条路径被指定为强制性的，那么无论当前情况如何，都不能使用备用路径。成功实例化的强制性路径也被隐式固定. 一旦路径被实例化，除非通过删除和实例化新路径，否则无法更改。

但是，如果选择了具有“非强制”偏好规则属性值的管理指定的显式路径，则应在可行的情况下使用该路径。否则，底层协议可以选择替代路径。

5.6.2、 多路径偏好规则的层次

在某些实际情况下，能够为给定的流量骨干在管理上指定一组候选显式路径并定义路径上的偏好关系层次结构可能很有用。在路径建立期间，偏好规则被应用于从候选列表中选择合适的路径。此外，在失败情况下，偏好规则被应用于从候选列表中选择替代路径。

5.6.3、 资源类亲和属性

与业务骨干相关联的资源类亲和性属性可用于指定要明确包含或排除在业务骨干路径中的资源类（参见第 6 节）。这些是策略属性，可用于对给定流量骨干所经过的路径施加额外的约束。流量的资源类亲和属性可以指定为一系列元组：

<resource-class, affinity>; <resource-class, affinity>; ..

resource-class 参数标识一个资源类，该资源类定义了与业务骨干相关的亲和关系。亲和度参数表示亲和度关系；也就是说，资源类的成员是要包含在流量骨干的路径中还是要从流量骨干的路径中排除。具体地，亲和度参数可以是采用以下值之一的二元变量：(1)显式包含，以及(2)显式排除。

如果关联属性是二进制变量，则可以使用布尔表达式来指定与给定流量骨干关联的资源类关联。

如果没有指定资源类亲和属性，则假定流量骨干和所有资源之间保持“无关”亲和关系。也就是说，不需要从流量骨干的路径中明确包含或排除任何资源。这应该是实践中的默认设置。

资源类亲和属性是非常有用和强大的构造，因为它们可用于实现各种策略。例如，它们可用于在网络的特定拓扑区域内包含某些流量骨干。

“基于约束的路由”框架（参见第 7.0 节）可用于计算受资源类亲和性约束的流量骨干的显式路径，方法如下：

1. 对于显式包含，在执行路径计算之前修剪所有不属于指定类的资源。

2. 对于显式排除，在执行路径放置计算之前修剪属于指定类的所有资源。

5.6.4、 适应性属性

网络特征和状态随时间变化。例如，新资源变得可用，失败的资源被重新激活，分配的资源被解除分配。通常，有时会出现更有效的路径。因此，从流量工程的角度来看，有必要使用管理控制参数来指定流量骨干如何响应这种动态。在某些情况下，可能需要动态更改某些流量骨干的路径以响应网络状态的变化。这个过程称为重新优化。在其他情况下，重新优化可能是非常不可取的。

适应性属性是与流量骨干相关的路径维护参数的一部分。与业务骨干关联的适应性属性指示该骨干是否需要重新优化。即，适应性属性是采用以下值之一的二进制变量：(1)允许重新优化和(2)禁用重新优化。

如果启用重新优化，那么底层协议可以通过不同的路径重新路由流量骨干，以响应网络状态的变化（主要是资源可用性的变化）。相反，如果重新优化被禁用，则流量骨干被“固定”到其已建立的路径，并且无法响应网络状态的变化而重新路由。

当允许重新优化时，稳定性是一个主要问题。为提高稳定性，MPLS 实施不应对网络的演化动态反应过度。同时，它必须足够快地适应，以便可以最佳地利用网络资产。这意味着重新优化的频率应该在管理上可配置以允许调整。

需要注意的是，重新优化不同于弹性。使用不同的属性来指定业务骨干的弹性特性（参见第 5.9 节）。在实践中，期望经过重新优化的流量骨干对沿其路径发生的故障具有隐含的弹性似乎是合理的。但是，不进行重新优化且其路径未通过“强制”属性在管理上指定的流量骨干也可能需要对沿其已建立路径的链路和节点故障具有弹性形式上，可以说通过重新优化对状态演化的适应性意味着对失败的弹性，而对失败的弹性并不意味着通过重新优化对状态变化的普遍适应性。

5.6.5、 跨并行业务骨干的负载分配

跨两个节点之间的多个并行流量骨干的负载分布是一个重要的考虑因素。在许多实际情况下，两个节点之间的聚合流量可能会导致没有单个链路（因此没有单个路径）可以承载负载。但是，总流量可能小于跨越两个节点的“最小切割”的最大允许流量。在这种情况下，唯一可行的解决方案是将聚合流量适当地划分为子流，并通过两个节点之间的多条路径路由子流。

在 MPLS 域中，这个问题可以通过在两个节点之间实例化多个流量骨干来解决，这样每个流量骨干承载一定比例的聚合流量。因此，需要一种将负载分配到在一对节点之间承载流量的多个并行流量骨干的灵活方法。

具体而言，从操作的角度来看，在需要并行流量骨干的情况下，拥有一些可用于指示每个流量骨干承载的流量的相对比例的属性将是有用的。然后底层协议将根据指定的比例将负载映射到流量骨干上。此外，通常希望在属于同一微流（相同的源地址、目标地址和端口号）的数据包之间保持数据包排序。

5.7、 优先级属性

优先级属性定义了流量骨干的相对重要性。如果基于约束的路由框架与 MPLS 一起使用，则优先级变得非常重要，因为它们可用于确定在连接建立和故障情况下为流量骨干完成路径选择的顺序。

优先级在允许抢占的实现中也很重要，因为它们可用于对流量骨干集施加偏序，根据该偏序可以实现抢占策略。

5.8、 抢占属性

抢占属性决定了一个流量骨干是否可以从给定路径抢占另一个流量骨干，以及另一个流量骨干是否可以抢占特定的流量骨干。抢占对于面向流量和面向资源的性能目标都很有用。抢占可用于确保高优先级业务骨干始终可以通过差异化服务环境中相对有利的路径进行路由。

抢占还可以用于在故障事件之后实施各种优先级恢复策略。

preemption 属性可用于指定流量骨干的四种抢占模式：(1) 抢占器启用，(2) 非抢占器，(3) 可抢占和 (4) 不可抢占。启用抢占器的流量骨干可以抢占指定为可抢占的较低优先级的流量骨干。无论相对优先级如何，指定为不可抢占的流量都不能被任何其他中继抢占。指定为可抢占的业务骨干可以被启用抢占器的更高优先级的骨干抢占。

很容易看出一些抢占模式是相互排斥的。使用上述编号方案，给定业务骨干的可行抢占模式组合如下：(1, 3)、(1, 4)、(2, 3) 和 (2, 4)。(2, 4) 组合应该是默认值。

一个流量骨干，比如“A”，可以抢占另一个流量骨干，比如“B”，前提是*所有*以下五个条件成立：（i）“A”比“B”具有相对更高的优先级，（ii ) “A”争用“B”使用的资源，(iii) 根据某些决策标准，资源不能同时容纳“A”和“B”，(iv)“A”启用抢占器，以及 (v)“ B”是可抢占的。

尽管抢占很有用，但在当前尽力而为的 Internet 服务模型下，它不被视为强制性属性。然而，在差异化服务场景中，抢占的需求变得更加迫切。此外，在新兴的光互联架构中，一些保护和恢复功能可能会从光层迁移到数据网元（如千兆和太比特标签交换路由器）以降低成本，可以采用抢占策略来减少恢复时间用于故障条件下的高优先级业务骨干。

5.9、 弹性属性

弹性属性决定了故障条件下流量骨干的行为。即当业务骨干所经过的路径发生故障时。这种情况下需要解决以下基本问题：（1）故障检测，（2）故障通知，（3）恢复和服务恢复。显然，MPLS 实施必须包含解决这些问题的机制。

对于已建立的路径受故障影响的流量骨干，可以指定多种恢复策略。以下是可行方案的示例：

1. 不要重新路由流量骨干。例如，生存性方案可能已经到位，通过备用机制提供，保证故障情况下的服务连续性，而无需重新路由流量骨干。这种替代方案的一个例子（当然还有许多其他方案）是这样一种情况，即在两个节点之间提供多条并行标签交换路径，并且以这样一种方式起作用，即一个 LSP 的故障导致放置在其上的流量骨干被映射根据一些明确定义的策略到剩余的 LSP 上。

2. 通过一条有足够资源的可行路径重新路由。如果不存在，则不要重新路由。

3. 不考虑资源限制，通过任何可用路径重新路由。

4. 许多其他方案也是可能的，包括一些可能是上述方案的组合。

“基本”弹性属性指示将应用于其路径受故障影响的业务骨干的恢复过程。具体来说，“基本”弹性属性是一个二进制变量，它确定当目标业务骨干的路径段失败时是否要重新路由。“扩展”弹性属性可用于指定在故障情况下要采取的详细操作。例如，扩展的弹性属性可能指定一组在故障条件下使用的备用路径，以及控制每个指定路径的相对优先级的规则。

弹性属性要求 MPLS 和路由之间的密切交互。

5.10、 监管属性

policing 属性确定当流量骨干变得不合规时底层协议应采取的操作。也就是说，当流量骨干超出其在流量参数中指定的合同时。通常，监管属性可以指示不符合规范的流量骨干是要进行速率限制、标记还是简单地转发而无需任何监管操作。如果使用监管，则可以使用已建立的算法（例如 ATM 论坛的 GCRA [11]）的改编来执行此功能。

在许多操作场景中，监管是必要的，但在其他一些场景中则非常不受欢迎。通常，通常需要在网络入口处进行监管（以强制遵守服务级别协议）并尽量减少核心内的监管，除非容量限制另有规定。

因此，从流量工程的角度来看，必须能够以管理方式为每个流量骨干启用或禁用流量监管。

6、 资源属性

资源属性是拓扑状态参数的一部分，用于限制流量骨干通过特定资源的路由。

6.1、 最大分配乘数

资源的最大分配乘数 (maximum allocation multiplier，MAM) 是管理上可配置的属性，它决定了可用于分配给业务骨干的资源比例。该属性主要适用于链路带宽。但是，它也可以用于缓冲 LSR 上的资源。MAM 的概念类似于帧中继和 ATM 网络中的订阅和预订因素的概念。

可以选择 MAM 的值，以便资源可以分配不足或过度分配。如果可以分配给它的所有业务骨干的总需求（如骨干业务参数所示）始终小于资源的容量，则称该资源分配不足。如果分配给它的所有业务骨干的总需求可以超过资源的容量，则称该资源被过度分配。

分配不足可用于限制资源的利用率。然而，MPLS 下的情况比电路交换方案更复杂，因为在 MPLS 下，一些流可以通过传统的逐跳协议（也通过显式路径）路由，而无需考虑资源限制。

过度分配可用于利用流量的统计特性，以实施更有效的资源分配策略。特别是在业务骨干的高峰需求不及时重合的情况下，可以使用超额分配。

6.2、 资源类属性

资源类属性是管理分配的参数，它表达了资源“类”的一些概念。资源类属性可以被视为分配给资源的“颜色”，使得具有相同“颜色”的资源集在概念上属于同一类。资源类属性可用于实现各种策略。这里感兴趣的关键资源是链接。当应用于链接时，资源类属性有效地成为“链接状态”参数的一个方面。

资源类属性的概念是一个强大的抽象。从流量工程的角度来看，它可用于实施许多与流量和面向资源的性能优化相关的策略。具体来说，资源类属性可用于：

1. 对不需要在同一拓扑区域内的一组资源应用统一策略。

2. 为流量骨干的路径放置指定资源集的相对优先级。

3. 明确地将流量骨干的放置限制为特定的资源子集。

4. 实施广义的包容/排除政策。

5. 执行流量局部控制政策。即，寻求在网络的特定拓扑区域内包含本地流量的策略。

此外，资源类属性可用于识别目的。

一般来说，一个资源可以被分配多个资源类属性。例如，给定网络中的所有 OC-48 链路都可以分配一个特殊的资源类属性。存在于网络的给定抽象域中的 OC-48 链路的子集可以被分配额外的资源类属性，以便实施特定的遏制策略，或以某种方式构建网络。

7、 基于约束的路由

本节讨论有关 MPLS 域中基于约束的路由的问题。在当代术语中，基于约束的路由通常被称为“QoS 路由”，参见 [5,6,7,10]。

然而，本文档使用术语“基于约束的路由”，因为它更好地捕捉了预想的功能，通常将 QoS 路由作为子集包含在内。

基于约束的路由使需求驱动、资源预留感知路由范式能够与当前拓扑驱动的逐跳 Internet 内部网关协议共存。

基于约束的路由框架使用以下内容作为输入：

- 与流量骨干相关的属性。

- 与资源相关的属性。

- 其他拓扑状态信息。

基于此信息，每个节点上基于约束的路由过程自动计算源自该节点的每个业务骨干的显式路由。在这种情况下，每个业务骨干的显式路由是满足在骨干属性中表达的需求要求的标签交换路径的规范，受资源可用性、管理策略和其他拓扑状态信息强加的约束。

基于约束的路由框架可以大大降低实现流量工程策略所需的手动配置和干预水平。

在实践中，流量工程师、操作员甚至自动机将指定流量骨干的端点，并为骨干分配一组属性，这些属性封装了骨干的性能期望和行为特征。然后期望基于约束的路由框架找到满足期望的可行路径。如有必要，流量工程师或流量工程支持系统可以使用管理配置的显式路由来执行细粒度优化。

7.1、 基于约束的路由的基本特征

一个基于约束的路由框架至少应该有能力自动获得流量骨干路径放置问题的基本可行解决方案。

一般而言，已知基于约束的路由问题对于大多数现实约束是难以处理的。然而，在实践中，一个非常简单的众所周知的启发式（参见例如 [9]）可用于找到可行的路径（如果存在）：

- 首先修剪不满足流量骨干属性要求的资源。

- 接下来，在残差图上运行最短路径算法。

显然，如果单个业务骨干存在可行路径，那么上面的简单过程将找到它。可以指定其他规则来打破平局并执行进一步的优化。一般来说，应该打破联系，以便将拥塞降至最低。然而，当要路由多个业务骨干时，可以证明即使存在可行的映射，上述算法也不一定总能找到映射。

7.2、 实施注意事项

许多帧中继和 ATM 交换机的商业实现已经支持一些基于约束的路由的概念。对于此类设备或由此设计的新型 MPLS 中心装置，扩展当前基于约束的路由实现以适应 MPLS 的特殊要求应该相对容易。

对于使用逐跳 IGP 拓扑驱动的路由器，可以通过以下两种方式中的至少一种方式合并基于约束的路由：

1、通过扩展OSPF、IS-IS等现有IGP协议，支持基于约束的路由。已经在努力为 OSPF 提供此类扩展（参见 [5,7]）。

2. 通过向可以与当前 IGP 共存的每个路由器添加基于约束的路由过程。这种情况如图 1 所示。

图 1. 3 层 LSR 上基于约束的路由过程

有许多与在第 3 层设备上实施基于约束的路由相关的重要细节，我们在此不讨论。这些包括以下内容：

- 在基于约束的路由进程之间交换拓扑状态信息（资源可用性信息、链路状态信息、资源属性信息）的机制。

- 维护拓扑状态信息的机制。

- 基于约束的路由过程和传统 IGP 过程之间的交互。

- 适应流量骨干适应性要求的机制。

- 适应流量骨干的弹性和生存能力要求的机制。

总之，基于约束的路由通过自动寻找满足流量骨干约束集的可行路径来帮助优化运营网络的性能。它可以大大减少实现流量工程目标所需的管理显式路径配置和手动干预的数量。

8、 结论

这份手稿提出了对 MPLS 上的流量工程的一组要求。描述了许多功能，旨在增强 MPLS 在 Internet 中的流量工程的适用性。

应该注意的是，这里描述的一些问题可以通过将最小的构建块集合并到 MPLS 中来解决，然后使用网络管理上层结构扩展功能以实现要求。此外，基于约束的路由框架不必成为核心 MPLS 规范的一部分。但是，MPLS 确实需要与基于约束的路由框架进行一些交互才能满足要求。

9、 安全注意事项

本文档不会引入 MPLS 固有的安全问题之外的新安全问题，并且可能使用针对该技术提出的相同机制。然而，由授权实体以安全方式执行管理可配置参数的操作是特别重要的。