Optimizability
前几章介绍了引入分段路由的各种用例。本章特别介绍 SR 的流量工程（TE）方面。具体说明如下：
TE 进程模型
显式路径定义的角色
路由约束和 SR SID 类型的几个显著属性
分布式和集中式路径计算
最后是利用集中式控制器的示例网络的端到端 SR-IOV 解决方案。
TE 进程模型
在中Figure 1提供的 TE 进程模型中（操作员或合适的 automaton）用作自适应反馈“控制”系统中的控制器。此系统包括：
一组互连的网络元素（IP/MPLS 网络）
网络状态/拓扑监控元素
网络性能监控元素
网络配置管理元素
操作员/automaton formulates 控制策略，通过监控系统观察网络状态，为信息流提供表现，并应用控制操作以将网络驱动到最佳状态。这可以基于网络的当前状态 reactively，也可根据预测的未来状态主动进行。
自适应反馈环可在网络中的每个节点（即分布式 TE）或以集中式方式实施，即使用路径计算元素（PCE）。此外，可以采用各种混合模式。
显式路由：TE 工具
显式路由可能需要优化网络资源或提供非常严格的服务保证，但它本身不是一个 TE 解决方案。TE 进程模型（信息流工程解决方案的重要部分）的结果可能需要显式路由的编程才能对结果计算进行计划。因此，希望能够为一个或多个 Lsp 定义跨网络的严格路径。RSVP 和 SR 都提供了一种在网络上显式定义严格路径（严格跳跃、松散跳和/或抽象/多广播跳跃）的方法。
Explicit Routing with RSVP
网络运营商请求通常通过配置、Lsp 来满足特定约束。例如，网络运营商可以请求来自节点 R1 的 LSP，在节点 R6 处终止，每秒保留100兆位，并仅遍历蓝色接口。一个路径计算模块位于一个––或入口路由器等中央控制器上，可计算满足所有约束的路径。Figure 3说明了生成的 RSVP 路径设置和保留消息，以设置 LSP 和产生 MPLS 转发表标签操作。
以下配置示例说明了所需配置。’值得注意的是，没有为 LSP 定义路由约束。换句话说，唯一显示的配置就是显式路径的定义。在许多（或大多数） RSVP-TE 部署中，路径未明确定义，而是定义路由约束（如带宽或链路关联），因此入口节点或外部 CSPF 会动态计算显式路径以满足路由constraint.
R1 configuration
Explicit Path Definition with SR
与 RSVP-TE 显式 Lsp 非常类似，网络运营商通常通过配置、可满足特定约束的 Lsp 来请求。二者的主要差异不仅是特定的配置语法，而且与使用相同 CLI 结构描述‘路由约束’的概念十分相似。要提供复杂的 TE 约束，入口 SR 节点可能需要依赖外部控制器或 PCE。
使用与 RSVP-TE 相同的示例，网络运营商可以请求来自节点 R1 的 LSP，在节点 R6 处终止，每秒保留100兆位，并仅遍历蓝色接口，但需要外部控制器/PCE 来计算路径。仅当指定带宽约束为 SR’时，才需要外部 PCE 来发出其保留。如果不需要带宽，则由 R1 完成的分布式路径计算足以满足 SR 路径计算的需求。Figure 4显示了生成的 SR 路径和 MPLS 转发表标签操作。请注意，与 SPF SR LSP 和前 RSVP-TE Lsp 相比，SR-TE LSP 的标签转发操作有相当大的差异。
默认情况下，会动态分配 SR 邻接 Sid。由于下一个配置示例说明了如何使用传统 CLI 技术来描述显式路径，因此路径中的每个跳跃都由其标签/SID 指定，因此建议将标签预规划且静态分配，以便每个链路都具有唯一的标签/SID，这与 IP 寻址的处理方式很相似。’值得注意的是，通过 CLI 使用传统 IP 地址作为路径中的指定跃点，并允许入口路由器解析 SID 和标签堆栈，从而提供 sr-iov 路径。
R1: defining static adjacency SIDs
R1: defining explicit SR tunnels
如上所述，您可以使用自动转换选项并将路径描述为一系列 IP 跳跃，如 RSVP-TE 路径，Junos 将转换 Sid。这种方法有充分的优势，那就是消除了静态配置邻接 Sid 的需要，确保了可能会计算路径的控制器，而不需要在转出的链路发生变化时更改路径。
松散跳跃、前缀 Sid 和任意播-Sid
Segment Routing SIDs
段标识符（SID）标识每个分段。网络运营商使用与分配专用 IP （即 RFC 1918）地址类似的过程分配 Sid。每个 SID 都映射到具有 SR MPLS 的 MPLS 标签。支持 SR 的路由器通过 IGP 通告 Sid。除了上面介绍的所有 IGP 域中的前面提到的 TE link 属性外，IGP 还将此数据泛滥。因此，IGP 域中的每个节点都维护着一个相同的链路状态数据库（LSDB）副本和一个信息流工程数据库（李小明）。以下分段类型最常用，将在本章中用于描述几个相关用例。
邻接：邻接段表示两个路由器之间的 IGP 邻接关系。Junos 动态分配邻接 Sid，但也可静态配置。如前所述，这可能在某些情况下有用：
前缀：前缀段表示任何路由器与指定前缀之间的最小成本路径 IGP。前缀段包含一个或多个路由器跳跃。节点 SID 也是一种前缀 SID：
任意广播：任意广播段类似于前缀段，因为它们表示任何路由器与指定前缀之间的最小成本路径 IGP。但是，可以从网络中的多个点公布指定的前缀。请注意，在本例中，CLI 仅显示公告任意点入 SID 的单个节点。在实际部署中，属于任意广播组一部分的所有节点将通告相同的任意广播 SID。
绑定：绑定前缀表示 SR 域中的隧道。该隧道可以是另一个 SR 路径、一个 LDP 信号 LSP、一个 RSVP-TE 信号 LSP 或任何其他封装：
The Critical Role of Maximum SID Depth
最大 SID 深度（MSD）是一种通用概念，用于定义’可在给定节点上施加的 SID 的 LSR 硬件和软件数量。它在各种 IETF OSPF/ISIS/BGP-LS/PCEP 草稿中定义。计算 SR 路径时，计算实体必须了解可在给定 SR 路径的每个节点或链路上施加的 MSD，这一点至关重要。这可确保计算路径的 SID 堆栈深度不会超过节点能够施加的 Sid 数。
Setting, Reporting, and Advertising MSD
使用 PCEP 与 LSP 进行通信时，如果要以 MSD 状态报告、控制和调配以下 CLI 可用于增加报告的 MSD 值5：
虽然这种报告通过控制平面协议向控制器 MSD，但 Junos 还要求要强加标签的入口接口的标签拼版也从默认值3增加：
SID Depth Reduction
由于 MSD 在许多 SR 场景中至关重要，因此不需要完全指定端到端路径是一种非常流行的想法。在前面的示例中，CLI 指定了 SR-IOV 的单个跳跃（以及 RSVP-TE LSP），可称为严格。严格的跳跃表示指定的 LSR 必须直接连接到前一跳跃。另一方面，松散跳跃意味着路径必须通过指定的 LSR，但 LSR 无需直接连接到最后一个跳跃; 否则，可使用两者之间的任何有效路由。让’我们来看一个使用中Figure 5所示拓扑的示例。
让’我们假设您希望从 R1、R 4 和 R5 的较低路由中，LSP 从1个扩展至 R6。要实现此目标，您只需将 R3 指定为路径中的第一条跳跃，然后让正常路由从该路径开始，因为从 R3 到 IGP R6 的途径的度量值为30，而通过 R1 的路径的 IGP 指标为40。SR-TE LSP 的结果标签堆栈仅为两个标签深度（用于 R6 的 R3 和 node SID 的节点 SID），而不是在前面看到的4个：
您可以将此和前面的示例等同于静态路由的 MPLS 版本。与静态路由一样，当您需要显式控制（也就像静态路由）时，手动配置路径很有用，当您想要建立许多路径和/或希望网络动态响应新事件（如链路即将出现或下降）时，可带来管理问题。
明确配置路径、RSVP 或 SR 的松散跳跃时，必须特别小心。链路故障可能会导致意外转发行为。例如，’假设 R1 和 R3 之间的链路发生故障，如中Figure 6所示。由于 SR-IOV LSP 是静态指令集，并且路径中指定的节点 SID 仍可在网络上访问，因此生成的 LSP’s 路径将是最优的，但有效。
绑定 Sid 表示另一个选项，用于在配置显式路径时降低标签堆栈深度，如Figure 7中所示。使用相同的简单示例拓扑，SR-IOV LSP 可以从 R3 创建到 R5，并以绑定 SID 的方式通告，以便从 R1 到 R6 的入口 LSP 引用其路径中的绑定 SID，而最终的标签堆栈仅为两深度。
R3 to R5 SR-TE LSP with binding-SID = 2000
And then the SR-TE LSP from R1 to R6 would look like:
任意播 Sid 代表另一种 SID 类型，用于在 SR 网络中创建一些有趣的转发行为。由于由多个节点组成 "任意广播" 组，因此通告相同的前缀 SID，入口或中转节点将从通告前缀 SID 的节点上向前转发，从 IGP 度量的角度来看。这使得运营商能够引入负载平衡和高可用性方案，这一点对 SR 网络来说有些独特。再次使用中显示的Figure 8简单网络拓扑，让我们’假定 r 4 和 R5 宣布了相同的任意广播 SID 405。现在，您可以从 R1 到 R6 创建一个入口 LSP，从而在 R1、r、R5、R6 path 和 R1、R3、R 4、R5 和 R6 路径之间产生相同的成本负载平衡，如图所示。
同样，尽管不是使用任意广播 Sid 的主要目标，但通过将任意广播 SID 指定为我们的 SR-1 Lsp 路径中的跳跃，可以减少标签堆栈：
入口 LSR 用于确定路径的另一种方式是动态计算。正如 OSPF 和 IS-IS 使用最短路径优先（SPF）算法来计算路由，入口 LSR 可以使用称为受限最短路径优先（CSPF）的 SPF 算法的修改来计算路径。接’下来让我们探讨动态路径计算。
动态路径计算和路由限制
至此，我们已讨论了各种定义非最短路径或显式路径的方法，使用 SR 提供的各种 Sid 以及几个特殊注意事项。但是，定义和管理数十个、数百个、数千个或数十个静态 SR 路径是 unscalable 的。因此，我们必须回到 TE 进程模型，并探索如何定义‘简单’路由约束，描述如何计算 sr-iov lsp 路径。换句话说，显式路径不是 TE，而是一种支持 TE 的方法。首先，让’我们来了解信息分配或状态/拓扑监控。
Link and Node Attributes and Routing Constraints
TE 的最重要的要求是链路和节点特性的传播。就像 Sid 在整个路由域中可靠地淹没一样，链路和节点特征以及面向 TE 的资源可用性也在整个通过 Igp 扩展的 TE 域内。通过增加链路状态路由协议的扩展，支持使用链路状态路由协议在其路由更新中高效传播与资源可用性相关的信息。链路状态路由协议不仅在链路状态或规格变化的情况下管理网络中的更新泛滥，而且还可以从 TE 角度进行带宽可用性。这些资源属性由网络中的路由器集淹没，以使其可用于在 TE 网络 LSP 路径计算（动态隧道）中使用的头端路由器。
链路状态公告附带的信息列表介绍了给定路由器’的邻接方连接网络、网络资源信息以及与实际资源可用性相关的其他相关信息，这些均可在以后执行基于约束的 SPF 计算。提供 OSPF 和 IS-IS 的扩展可在 MPLS TE 环境中将其用于传播与资源可用性和动态 LSP 路径选择相关的信息。这些链路和节点属性采用链接颜色、共享风险链接组关联、可用带宽以及指标类型（TE 或 IGP）的形式来命名。这些属性在由计算实体使用的李小明中可用。同样，使用中显示的Figure 9简单示例拓扑，以下内容已添加到 R5：
这会产生一个与 R5 至 r R2 Figure 9链路的着色方式类似的 TE 拓扑 blue并添加到名为的 SRLG common-254从 R5 到 R 4 的链路已着色 red，在给定 te-metricof 100同时又添加到相同的 SRLG 中。
让’我们来观察李小明的内容，以了解’r 4，并了解链路 TE 信息如何在 R1 上充斥，使用 ISIS TE 扩展，因此可用于路径计算，特别是约束包含或排除：
user@R1> show ted database R5.00 extensive To: R4.00(1.1.1.4), Local: 10.1.45.2, Remote: 10.1.45.1 Local interface index: 335, Remoteinterface index: 334 Color: 0x800000 red Metric: 100 IGP metric: 10 Static BW: 1000Mbps Reservable BW: 1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps SRLGs: common-254 P2P Adjacency-SID: IPV4, SID: 299840, Flags: 0x30, Weight: 0 <output truncated>
Distributed SR Constraint-based SPF
在正常的 SPF 计算过程中，路由器将自身置于树的开头，并将最短路径计算为每个目标，仅对目标考虑最小指标或成本路由。在此计算中，要注意的一个关键概念是，不会考虑到动态路径计算和路由约束的带宽与其他路径上的链路相关。如果给定路径所需的属性不只包括 IGP 成本或指标（如链路颜色），则拓扑可被约束为消除不允许提及的要求的链路，因此，SPF 算法将返回具有链路成本和链路包含/排除要求的路径。
借助 CSPF，您不仅可以使用链路开销来识别可用于 TE LSP 路径的可能路径。选择用于设置 TE LSP 路径的路径是在计算实体上执行的，在排除所有不符合特定条件的链路（如链路颜色）之后，除了 te-cost的链接。CSPF 计算结果是一组有序的 Sid，映射到构成 TE LSP 的路由器的下一跳跃地址。因此，通过使用 CSPF 来识别网络中满足标准的可能链路，可以实例化多个 TE Lsp。
基于约束的 SPF 可在基于约束的计算期间使用管理重量或 TE 指标。如果发生并列，最小带宽的路径优先，后面是路径上数量最少的跃点。如果其他所有参数相等，CSPF 将随机选取一个路径，并选择与 TE LSP 的首选路径相同。
如前所述，SR 路径包含几个突出特性，主要是 MSD 和 ECMP 属性，因此需要比传统的 RSVP-TE 路径略有不同的 CSPF 结果。因此，Junos 作为一种分布式 CSPF （我们’将讨论外部、集中式、CSPFs 的时刻），它得到了增强，不仅为路径提供了一组有序的邻接 sid，还可以最小化或满足给定入口路由器’MSD 的 MSD，以及通过在分段列表中提供节点 sid 来利用任何可用的 ECMPs。
SR-IOV 候选路径将在本地计算，以便满足配置的路由约束。禁用标签堆栈压缩时，多路径 CSPF 计算结果将是一组有序的邻接 Sid。启用标签堆栈压缩时，结果将是一组经过压缩的标签堆栈（包含调整和 Sid 和节点 Sid），尽可能提供类似IP 的 ECMP 转发行为。
对于所有计算结果，我们都使用事件驱动的方法提供与网络的当前状态一致的最新结果。但是，我们需要小心确保在包含大量网络事件的时段内，我们的计算不会被淹没。因此，该算法具有以下属性：
针对单个事件的快速反应（例如链路故障）
Temporally close 的多个 IGP 事件的快速进度反应，而计算和使用结果的能力被视为可接受
计算和消耗结果能力时延迟的反应存在问题
此外，根据标签堆栈压缩是否启用，对某些网络事件的反应也会有所不同。对于以下事件，当压缩关闭时，不会立即 recomputation 候选路径的 SID 列表：
链路的 TE 变化
链接未按候选路径遍历链接的事件
链接启动事件
当标签堆栈压缩打开时，会对上述事件进行处理，以查看计算结果是否会受到影响。
R1: CSPF
此配置会导致创建 SR-IOV Lsp，如中Figure 11所示。
Verifying the SR-TE LSPs computed by the Distributed SR CSPF
user@R1# run show spring-traffic-engineering lsp detail Name: sr-te-lsp-to-r6 Tunnel-source: Static configuration To: 1.1.1.6 State: Up Path: 1st-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:red-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 2 computed segment : 1 (computed-node-segment): node segment label: 104 router-id: 1.1.1.4 computed segment : 2 (computed-node-segment): node segment label: 100 router-id: 1.1.1.6 Path: 2nd-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:blue-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 1 computed segment : 1 (computed-node-segment): node segment label: 100 router-id: 1.1.1.6
您可以在输出中看到，Junos 计算仅包含 R 4 的节点 SID 的路径，以满足红色路径的约束，同时还确定蓝色路径只是最短路径，因此仅使用 R6 的节点 SID，而不是计算邻接 Sid 的完全限定路径。相反，如果您将 no-label-stack-compression关键字您可以看到如何计算完全合格的 SID 列表，包括邻接 Sid。
Configuration example for R1
Verifying the SR-TE LSPs computed by the Distributed SR CSPF
user@R1# run show spring-traffic-engineering lsp detail Name: sr-te-lsp-to-r6 Tunnel-source: Static configuration To: 1.1.1.6 State: Up Path: 1st-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:red-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 4 computed segment : 1 (computed-adjacency-segment): label: 16 source router-id: 1.1.1.1, destination router-id: 1.1.1.3 source interface-address: 10.1.13.1, destination interface-address: 10.1.13.2 computed segment : 2 (computed-adjacency-segment): label: 18 source router-id: 1.1.1.3, destination router-id: 1.1.1.4 source interface-address: 10.1.34.1, destination interface-address: 10.1.34.2 computed segment : 3 (computed-adjacency-segment): label: 20 source router-id: 1.1.1.4, destination router-id: 1.1.1.5 source interface-address: 10.1.45.1, destination interface-address: 10.1.45.2 computed segment : 4 (computed-adjacency-segment): label: 24 source router-id: 1.1.1.5, destination router-id: 1.1.1.6 source interface-address: 10.1.56.1, destination interface-address: 10.1.56.2 Path: 2nd-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:blue-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 3 computed segment : 1 (computed-adjacency-segment): label: 19 source router-id: 1.1.1.1, destination router-id: 1.1.1.2 source interface-address: 10.1.12.1, destination interface-address: 10.1.12.2 computed segment : 2 (computed-adjacency-segment): label: 21 source router-id: 1.1.1.2, destination router-id: 1.1.1.5 source interface-address: 10.1.25.1, destination interface-address: 10.1.25.2 computed segment : 3 (computed-adjacency-segment): label: 24 source router-id: 1.1.1.5, destination router-id: 1.1.1.6 source interface-address: 10.1.56.1, destination interface-address: 10.1.56.2
最后，如上文所述，在动态 CSPF 期间，最大 SID 深度继续发挥重要作用。与上一个 PCEP 示例一样，可以为每个特定计算配置文件设置最大 SID 深度，方法是使用 maximum-segment-list-depth<value>关键字。
Configuration example for R1
用于外部 CSPF 的集中式控制器或 PCE
在讨论 SR 时，经常会假设存在控制器或集中的 PCE，因此让我们来’简要了解如何将 Northstar TE 控制器用作 SR 路径的外部路径计算源。
BGP Link-state for Topology Discovery
为了让控制器（PCE）执行任何类型的路径计算，它必须与网络“拓扑同步。”网络拓扑可以采用流量工程数据库（李小明）的形式，与 RSVP 用于路径计算、链路状态数据库（LSDB）或更多物理形式的方式非常类似。下面的示例演示如何使用 BGP-LS 将李小明传达给 Juniper’s Northstar 控制器。
有关 BGP-LS 配置示例，请参阅可观察性章中的Observability部分。
PCEP for SR-TE LSP Creation and Control
控制器所需的下一条相关信息就是能够学习或创建 SR-1A LSP 状态。在下一个配置示例中，显示了路径计算客户端（PCC）或入口路由器与控制器之间的路径计算元素协议（PCEP）会话。Figure 13显示了 PCEP 会话参数。
现在，’让我们来回顾一些 SR 特定的 SID 类型，了解它们‘在控制器’上的外观以及如何宣布它们。
在 LSDB 过程中，任意广播 Sid 由 IGP SR 扩展进行通告，通过扩散，创建第二组 lo 0.0 地址并为其公告前缀 SID。下一示例宣布节点 p1. nyc 和 p2 中的任意广播 SID 123。
Announcing anycast SIDs from p1.nyc and p2.nyc
Verifying on pe1.nyc
user@pe1.nyc> show isis database p2.nyc.00-00 extensive | match “1.1.2.3|123” IP prefix: 1.1.2.3/32 Metric: 0 Internal Up IP prefix: 1.1.2.3/32, Internal, Metric: default 0, Up IP extended prefix: 1.1.2.3/32 metric 0 up Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 123 IP address: 1.1.2.3 user@pe1.nyc> show isis database p1.nyc.00-00 extensive | match “1.1.2.3|123” IP prefix: 1.1.2.3/32 Metric: 0 Internal Up IP prefix: 1.1.2.3/32, Internal, Metric: default 0, Up IP extended prefix: 1.1.2.3/32 metric 0 up Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 123 IP address: 1.1.2.3
可将任意广播 SID 视为 Northstar GUI 上的 node 属性，后来在创建 SR-IOV LSP’时，它选择为严格或松散跳跃（更可能是松散跳跃）。将绑定 Sid 添加到 SR-TE LSP 中，如中Figure 14所示，然后通过 PCE 协议通告至 Northstar。
Creating a Core SR-TE LSP with a binding SID
Verifying the core LSP on P1.NYC
user@p1.nyc# run show spring-traffic-engineering lsp detail Name: P1NYC-2-P1IAD Tunnel-source: Static configuration To: 128.49.106.9 State: Up Telemetry statistics: Sensor-name: ingress-P1NYC-2-P1IAD, Id: 3758096386 Sensor-name: transit-P1NYC-2-P1IAD, Id: 3758096387 Path: P1NYC-2-P1IAD Outgoing interface: ge-0/0/4.0 Auto-translate status: Enabled Auto-translate result: Success BFD status: N/A BFD name: N/A SR-ERO hop count: 2 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 0.0.0.0 -> 192.0.2.15 SID type: 20-bit label, Value: 94 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 0.0.0.0 -> 192.0.2.26 SID type: 20-bit label, Value: 51 Total displayed LSPs: 1 (Up: 1, Down: 0)
Verifying the routing table on p1.nyc
user@p1.nyc# run show route protocol spring-te inet.0: 49 destinations, 60 routes (46 active, 0 holddown, 3 hidden) inet.3: 11 destinations, 15 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.9/32 *[SPRING-TE/8] 00:02:45, metric 1, metric2 20 > to 192.0.2.21 via ge-0/0/5.0, Push 1009 to 192.0.2.13 via ge-0/0/1.0, Push 1009, Push 1008(top) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 62 destinations, 62 routes (62 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1000001 *[SPRING-TE/8] 00:02:45, metric 1, metric2 20 > to 192.0.2.21 via ge-0/0/5.0, Swap 1009 to 192.0.2.13 via ge-0/0/1.0, Swap 1009, Push 1008(top)
Verifying binding SIDs on the Northstar TE Controller
可使用 LSP 属性或通过将绑定 SID 列添加到 [隧道] 选项卡来验证绑定 Sid。
现在，您已经了解了 TE 的各个方面、一些 SR 特定的 SID 类型以及如何将基本信息与控制器同步，让我们’从前面的章节回顾示例网络，并将整个解决方案结合在一起！
端到端 TE 解决方案
将示例网络转换为分段路由的一个关键目标是将一种“带宽优化” （TE）复制到核心、2级 ISIS 域中，其中当前自动带宽为 RSVP-TE lsp 提供相对于路径带宽优化的粒度。由于 SR 不保留每个 LSP 状态，因此基于 LSP 的统计数据，因此 SR 网络的带宽优化解决方案要求控制器从另一个来源（如Observability章中所述）中获取数据，以便在另一窗体（RSVP-TE）中结束解决方案。
’首先，先从在 PE1 和 IAD PoP 中的所有 pe 之间创建Table 1一个 sr-iov lsp 的网格（请参阅）。这些 Lsp 将使用 PCE 协议创建，ephemerally，使 Northstar 控制器可以显式控制其每条路径。
Table 1: SR-IOV LSP 网格
LSP 名称 | 入口路由器 | 出口路由器 |
|---|---|---|
pe1.nyc-pe1.iad | pe1.nyc | pe1.iad |
pe1.nyc-pe2.iad | pe1.nyc | pe2.iad |
pe1.nyc-pe3.iad | pe1.nyc | pe3.iad |
pe1.iad-pe1.nyc | pe1.iad | pe1.nyc |
pe2.iad-pe1.nyc | pe2.iad | pe1.nyc |
pe3.iad-pe1.nyc | pe3.iad | pe1.nyc |
要在 Northstar 控制器上创建 SR-IOV LSP，请使用应用程序 > 调配 LSP 下拉选项或 "隧道" 选项卡上的 Add 按钮。将显示一个弹出窗口，其中添加了 LSP 的属性，如中Figure 16所示。创建 SR-IOV Lsp 时的一个关键属性是为其提供一些额定标准‘计划带宽’值。这是为了确保在定期 reoptimization 期间或触发的 reoptimization 中，链路拥塞感知可通过 Northstar’s CSPF 来解决，正如您稍后将看到的那样。
在此编写时，每个 SR 策略入口统计数据不可用于 Northstar 控制器。未来，分配给每个 SR-IOV LSP 的静态10k 带宽可以更换为动态实时数据平面统计信息，以便 realizable 更细粒度的带宽优化。
生成的 SR-IOV LSP 网格显示在中Figure 17。在这里，您可以看到网格将遍历哪些链路。
从入口 PCC 的角度来看，您可以看到三个 SR-IOV Lsp 已通过控制器（PCE）发出了信号：
user@pe1.nyc> show path-computation-client lsp Name Status PLSP-Id LSP-Type Controller Path-Setup-Type pe1.nyc-pe1.iad Primary(Act) 10 ext-provised NS1 spring-te pe1.nyc-pe2.iad Primary(Act) 11 ext-provised NS1 spring-te pe1.nyc-pe3.iad Primary(Act) 12 ext-provised NS1 spring-te
并且每个都已安装在 inet 中。 pe1 的3个筋。 nyc：
user@pe1.nyc# run show route protocol spring-te table inet.3 inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:06:23, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 18, Push 22(top) 128.49.106.11/32 [SPRING-TE/8] 1d 00:38:38, metric 1, metric2 0 > to 192.0.2.7 via ge-0/0/2.0, Push 28, Push 20, Push 18(top) 128.49.106.13/32 *[SPRING-TE/8] 00:05:30, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 20, Push 26(top)
您可以通过 Northstar 控制器 GUI 验证每个 SR-IOV LSP 的标签堆栈，如中Figure 18所示，如记录路由和 ERO 列中所示，以及显示拓扑的邻接 sid。
您可以从 Junos 入口路由器’到 sr-iov LSP 详细输出中看到，标签堆栈匹配。’值得注意的是，由于 PCEP NAI （node 或邻接方标识符）字段中的 IP 地址用于输出接口选择，因此第一个标签（如果在 sr-iov 中 pe1，nyc-pe1 iad）实际上并未强加于数据包。下一输出将对此进行说明。
Detailed SR-TE LSP output:
user@pe1.nyc> show spring-traffic-engineering lsp detail Name: pe1.nyc-pe1.iad Tunnel-source: Path computation element protocol(PCEP) To: 128.49.106.11 State: Up Telemetry statistics: Sensor-name: ingress-pe1.nyc-pe1.iad, Id: 3758096391 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A BFD status: N/A BFD name: N/A SR-ERO hop count: 4 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.6 -> 192.0.2.7 SID type: 20-bit label, Value: 17 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.22 -> 192.0.2.23 SID type: 20-bit label, Value: 18 Hop 3 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.33 -> 192.0.2.32 SID type: 20-bit label, Value: 20 Hop 4 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.39 -> 192.0.2.38 SID type: 20-bit label, Value: 28
JUNOS inet.3 RIB entry for the SR-TE LSPs:
user@pe1.nyc# run show route protocol spring-te table inet.3 inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:06:23, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 18, Push 22(top) 128.49.106.11/32 [SPRING-TE/8] 1d 00:38:38, metric 1, metric2 0 > to 192.0.2.7 via ge-0/0/2.0, Push 28, Push 20, Push 18(top) 128.49.106.13/32 *[SPRING-TE/8] 00:05:30, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 20, Push 26(top)
我们的示例网络为连接的 CE 路由器提供多项服务。从 ce1. nyc 您可以在 pe1 和 pe2 之间看到传输 SR-IOV Lsp 的结果标签堆栈。 iad：
user@ce1.nyc> traceroute 198.51.100.60 traceroute to 198.51.100.60 (198.51.100.60), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 3.008 ms 1.918 ms 1.972 ms 2 p1.nyc-ge-0-0-2.0 (192.0.2.5) 12.785 ms 9.685 ms 24.882 ms MPLS Label=22 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=1 S=1 3 p1.ewr-ge-0-0-2.0 (192.0.2.15) 8.927 ms 14.411 ms 8.648 ms MPLS Label=18 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=2 S=1 4 p1.iad-ge-0-0-6.0 (192.0.2.26) 9.039 ms 8.564 ms 10.233 ms MPLS Label=18 CoS=0 TTL=1 S=1 5 pe2.iad-ge-0-0-1.0 (192.0.2.40) 7.857 ms 7.481 ms 17.570 ms 6 ce1.iad-ge-0-0-7.0 (198.51.100.60) 8.767 ms 13.242 ms 15.533 ms user@ce1.nyc> ping 198.51.100.54 rapid count 100000000 size 500 PING 198.51.100.54 (198.51.100.54): 500 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
现在，’让我们来回头看看如何使用 Northstar 控制器为 IS-IS 2 级域提供带宽优化服务。原始核心网络基于 RSVP-TE 自动带宽 Lsp 构建。它们可动态适应提高和降低流量率。分段路由当前没有同等功能，主要是由于缺乏传输 LSP 状态。我们将在 Northstar 控制器上启用一个属性，以响应接口拥塞，从而根据入口统计信息收集触发 SR-IOV LSP 重新优化。要启用 Northstar 控制器的此功能，请转至管理 > 分析并切换重新路由功能，如中Figure 20所示。
要确保拓扑结构还显示实时接口统计信息，请使用 GUI 左侧的下拉框。选择性能并启用接口利用率，如中Figure 21所示。
要模拟网络上的信息流，为了说明控制器’如何将 sr-iov lsp 从拥塞链路中重新路由，让我们’在 pe1 和 p1 之间使用大数据包大小启动一些扩展 ping。 iad：
user@pe1.nyc> traceroute 192.0.2.26 traceroute to 192.0.2.26 (192.0.2.26), 30 hops max, 40 byte packets 1 p1.nyc-ge-0-0-2.0 (192.0.2.5) 3.569 ms 2.412 ms 3.261 ms 2 p1.ewr-ge-0-0-2.0 (192.0.2.15) 6.769 ms 3.793 ms 3.152 ms 3 p1.iad-ge-0-0-6.0 (192.0.2.26) 6.040 ms 5.814 ms 5.074 ms user@pe1.nyc> ping rapid 192.0.2.26 count 100000000 size 500 PING 192.0.2.26 (192.0.2.26): 500 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
另一方向上同样…
user@p1.iad> traceroute 128.49.106.1 traceroute to 128.49.106.1 (128.49.106.1), 30 hops max, 40 byte packets 1 p1.phl-ge-0-0-3.0 (192.0.2.31) 2.637 ms 2.077 ms 2.322 ms 2 p1.nyc-ge-0-0-5.0 (192.0.2.20) 3.493 ms 5.646 ms 3.116 ms 3 pe1.nyc-lo0.0 (128.49.106.1) 7.056 ms 5.973 ms 7.435 ms user@p1.iad> ping 128.49.106.1 rapid count 10000000 size 1000 PING 128.49.106.1 (128.49.106.1): 1000 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
如中Figure 22所示，Northstar 检测到链路拥塞，这将触发一个路径 reoptimization 并将 sr-iov lsp 从拥塞链路上重新路由。
通过在左面板中选择时间线，您可以看到Figure 23基于接口拥塞阈值的链路拥塞已被检测到，正在遍历拥塞链路的 lsp 已计划进行重新路由。
回到 Northstar’s 拓扑结构 > 通道视图，您可以在 pe1 和 pe2 之间看到 sr-iov LSP。iad 英寸Figure 24您可以看到 LSP 现在处于新路径，以避免拥塞链路。
入口路由器’的 sr-iov LSP 也已更新：
user@pe1.nyc> show route table inet.3 protocol spring-te inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 20, Push 26(top) 128.49.106.11/32 [SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 28, Push 18, Push 22(top) 128.49.106.13/32 *[SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 18, Push 22(top)
在大多数主干广域网中，信息流工程是不可或缺的功能。现代 TE 的一个重要目标是优化资源利用率。RSVP 具有较长的历史和大的工具供您利用，而 SR 则需要利用较新的工具（例如流遥测和控制器）来实现更好的资源利用。本章提供许多用于创建显式路径的 SR 特定选项、各种形式的分布式和集中式路径计算，最后是如何将我们的示例网络转换为 SR TE。虽然带宽优化解决方案与传统的 RSVP-TE 截然不同，但它可以提供一种方法来对接口拥塞进行反应，以实现资源优化。