Segment Routing Architecture

段路由架构

梗概

段路由 (Segment Routing，SR) 利用源路由范例，节点通过称为“段”的有序指令列表来引导数据包。一个段可以代表任何指令，拓扑或基于服务。段可以具有 SR 节点的局部语义或 SR 域内的全局语义。 SR 提供​了一种机制，允许将流限制到特定的拓扑路径，同时仅在到 SR 域的入口节点处保持每个流的状态。

SR 可以直接应用于 MPLS 架构，无需改变转发平面，段被编码为 MPLS 标签，段的有序列表被编码为标签堆栈，要处理的段位于堆栈的顶部。段完成后，相关标签从堆栈中弹出。

SR 可以应用于 IPv6 架构，具有一种新型的路由头。段被编码为 IPv6 地址。段的有序列表在路由包头中编码为 IPv6 地址的有序列表。活动段由数据包的目的地址 (Destination Address，DA) 指示。下一个活动段由新路由报头中的指针指示。

本备忘录的状态

这是一个 Internet 标准跟踪文档。

本文档是互联网工程任务组 (Internet Engineering Task Force，IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导组 (Internet Engineering Steering Group ，IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。

有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问 。

版权声明

版权所有 (c) 2018 IETF Trust 和确定为文档作者的人员。版权所有。

本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 () 约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。

1、 简介

段路由 (Segment Routing，SR) 利用源路由范例。节点通过 SR 策略引导数据包，该策略被实例化为称为“段”的有序指令列表。一个段可以代表任何指令，拓扑或基于服务。段可以具有 SR 节点的局部语义或 SR 域内的全局语义。 SR 支持按流显式路由，同时仅在到 SR 域的入口节点处保持按流状态。

段通常由其段标识符 (Segment Identifier，SID) 表示。

段可以与拓扑指令相关联。拓扑本地段可以指示节点通过特定的传出接口转发数据包。拓扑全局段可以指示 SR 域通过特定路径将数据包转发到目的地。同一目的地可能存在不同的段，每个段都有不同的路径目标（例如，最小化哪个度量，指定了哪些约束）。

段可以与服务指令相关联（例如，数据包应该由与段相关联的容器或虚拟机（Virtual Machine，VM）处理）。一个段可能与 QoS 处理相关联（例如，整形与此段一起接收的数据包以 x Mbps 的速度）。

SR 架构支持与段相关联的任何类型的指令。

SR 架构支持任何类型的控制平面：分布式、集中式或混合式。

在分布式场景中，段由 IS-IS 或 OSPF 或 BGP 分配和发送信号。一个节点单独决定在 SR 策略上引导数据包（例如，预先计算的本地保护 [RFC8355]）。一个节点单独计算 SR 策略。

在集中式场景中，段由 SR 控制器分配和实例化。 SR 控制器决定哪些节点需要在哪些源路由策略上引导哪些数据包。 SR 控制器计算源路由策略。 SR 架构不限制控制器如何对网络进行编程。可能的选项是网络配置协议 (Network Configuration Protocol，NETCONF)、路径计算元素通信协议 (Path Computation Element Communication Protocol，PCEP) 和 BGP。 SR 架构不限制 SR 控制器的数量。具体来说，多个SR控制器可以对同一个SR域进行编程。 SR 架构允许这些 SR 控制器发现哪些 SID 在哪些节点被实例化，哪些本地 (SRLB) 和全局 (SRGB) 标签集在哪些节点可用。

混合方案用集中控制器补充基本分布式控制平面。例如，当目的地在 IGP 域之外时，SR 控制器可以代表 IGP 节点计算 SR 策略。 SR 架构不限制作为分布式控制平面一部分的节点如何与 SR 控制器交互。可能的选项是 PCEP 和 BGP。

主机可以是 SR 域的一部分。集中式控制器可以通过将这些策略推送到主机或响应来自主机的请求来通知主机有关策略。

SR 架构可以在各种数据平面上实例化。本文档介绍了 SR 的两个数据平面实例：SR over MPLS (SR-MPLS) 和 SR over IPv6 (SRv6)。

SR 可以直接应用于 MPLS 架构，而无需更改转发平面 [SR-MPLS]。段被编码为 MPLS 标签。 SR 策略被实例化为标签堆栈。要处理的段（活动段）位于堆栈的顶部。段完成后，相关标签从堆栈中弹出。

SR 可以通过一种称为 SR 包头 (SR Header，SRH) [IPv6-SRH] 的新型路由包头应用于 IPv6 架构。指令与段相关联并编码为 IPv6 地址。 SRv6 段也称为 SRv6 SID。 SR 策略被实例化为路由包头中 SRv6 SID 的有序列表。活动段由数据包的目的地址 (DA) 指示。下一个活动段由 SRH 中的 SegmentsLeft (SL) 指针指示。当一个 SRv6 SID 完成时，SL 递减，下一个段被复制到 DA。当数据包在 SR 策略上被引导时，相关的 SRH 被添加到数据包中。

在基于 IGP 的分布式控制平面的场景中，定义了两个拓扑段：IGP-Adjacency 段和 IGP-Prefix 段。

在基于 BGP 的分布式控制平面的场景中，定义了两个拓扑段：BGP 对等段和 BGP-Prefix 段。

SR 策略的头端将 SID（称为绑定段或 BSID）绑定到其策略。当头端收到一个活动段与本地 SR 策略的 BSID 匹配的数据包时，头端将数据包引导到关联的 SR 策略中。

本文档定义了 SR-MPLS 和 SRv6 数据平面的 IGP、BGP 和绑定段。

注：本文档定义了 Segment Routing 的架构，包括基本对象和功能的定义以及总体设计的描述。它没有定义实现架构的方法——包含在许多参考文档中，为了方便读者，本文档中提到了其中的一些。

2、 术语

关键词“必须”、“不得”、“要求”、“应该”、“不应该”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选” “当且仅当它们以所有大写字母出现时，本文档中的内容将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。

SR-MPLS：SR 在 MPLS 数据平面上的实例化。

SRv6：SR在IPv6数据平面上的实例化。

Segment：段，节点对传入数据包执行的指令（例如，根据到达目的地的最短路径转发数据包，或通过特定接口转发数据包，或将数据包传送到给定的应用程序/服务实例）。

SID：segment identifier，段标识符。请注意，术语 SID 通常用于代替术语“段”，尽管这在技术上是不精确的，因为它忽略了任何必要的翻译。

SR-MPLS SID：MPLS 标签，或与段显式关联的 MPLS 标签空间的索引值。

SRv6 SID：与段显式关联的 IPv6 地址。

Segment Routing domain（SR domain）：段路由域，SR域，参与基于源的路由模型的节点集。这些节点可以连接到相同的物理基础设施（例如，服务提供商的网络）。它们也可以相互远程连接（例如，企业 VPN 或overlay网络）。如果部署了多个协议实例，SR 域通常包括网络中的所有协议实例。然而，一些部署可能希望将网络细分为多个 SR 域，每个域包含一个或多个协议实例。期望 SR 域中的所有节点都由同一个管理实体管理。

Active Segment：活动段，接收路由器用于处理数据包的段。在 MPLS 数据平面中，它是顶部标签。在IPv6数据平面中，它是目的地址[IPv6-SRH]。

PUSH：在段列表顶部插入段的操作。在 SR-MPLS 中，段列表的顶部是标签堆栈的最顶部（外部）标签。在 SRv6 中，段列表的顶部由 [IPv6-SRH] 中定义的段路由头中的第一个段表示。

NEXT：当活动段完成时，NEXT是由检查下一段组成的操作。下一段变为活动状态。在 SR-MPLS 中，NEXT 被实现为顶部标签的 POP。在 SRv6 中，NEXT 被实现为从 SRH 到 IPv6 包头的目的地址的下一段的副本。

CONTINUE：活动段未完成；因此，它保持活跃。在 SR-MPLS 中，CONTINUE 操作被实现为顶部标签的交换 [RFC3031]。在 SRv6 中，这是常规 IPv6 数据包根据其目的地址的普通 IPv6 转发动作。

SR Global Block(SRGB)：SR 全局块，SR 域中的全局段集。如果一个节点参与多个SR域，则每个SR域对应一个SRGB。在 SR-MPLS 中，SRGB 是节点的本地属性，标识为全局段保留的本地标签集。在 SR-MPLS 中，强烈建议在 SR 域内的所有节点上使用相同的 SRGB。这样做可以简化操作和故障排除，因为相同的标签在每个节点代表相同的全局段。在 SRv6 中，SRGB 是 SR 域中全局 SRv6 SID 的集合。

SR Local Block (SRLB)：SR 节点的本地属性。如果一个节点加入多个SR域，则每个SR域对应一个SRLB。在 SR-MPLS 中，SRLB 是一组为本地段保留的本地标签。在 SRv6 中，SRLB 是一组为本地 SRv6 SID 保留的本地 IPv6 地址。在控制器驱动的网络中，一些控制器或应用程序可能会使用控制平面来发现可用的本地段集。

Global Segment：全局段，作为域的 SRGB 一部分的段。与段相关的指令是在 SR 域级别定义的。到 SR 域内给定目的地的拓扑最短路径段是全局段的典型示例。

Local Segment：在 SR-MPLS 中，这是 SRGB 之外的本地标签。它可能是显式通告的 SRLB 的一部分。在 SRv6 中，这可以是任何 IPv6 地址，即该地址可能是 SRGB 的一部分，但使用它具有本地意义。与段相关的指令是在节点级别定义的。

IGP Segment：附加到由链路状态 IGP 通告的一条信息的段的通用名称，例如，IGP 前缀或 IGP 邻接。

IGP-Prefix Segment：IGP-Prefix Segment是代表IGP前缀的IGP段。当 IGP-Prefix 段在 SR IGP 实例/拓扑中是全局的时，它会标识一条指令，以沿着使用算法字段、拓扑和 IGP 实例中指定的路由算法计算的路径转发数据包通告。也称为“前缀段”。

Prefix-SID：IGP-Prefix 段的SID。

IGP-Anycast Segment：IGP-Anycast 段是一个 IGP-Prefix 段，用于标识一组路由器通告的任播前缀。

Anycast-SID：IGP-Anycast 段的SID。

IGP-Adjacency Segment：IGP-Adjacency Segment 是附加在一个单向邻接或一组单向邻接上的IGP 段。默认情况下，IGP-Adjacency 段对于通告它的节点是本地的（除非另外明确通告）。也称为“Adj-SID”。

Adj-SID：IGP-Adjacency 段的 SID。

IGP-Node Segment：IGP-Node 段是一个 IGP-Prefix 段，用于标识特定路由器（例如，环回）。也称为“节点段”。

Node-SID：IGP-Node段的SID。

SR Policy：SR 策略，段的有序列表。 SR 策略的头端将数据包引导到 SR 策略上。段列表可以在 SR-MPLS 中明确指定为标签堆栈，在 SRv6 中指定为 SRv6 SID 的有序列表。或者，基于目的地和一组优化目标和约束（例如，延迟、亲和性、SRLG 等）计算段列表。计算可以是本地的，也可以委托给 PCE 服务器。 SR 策略可由运营商配置，通过 NETCONF [RFC6241] 提供或通过 PCEP [RFC5440] 提供。 SR 策略可用于流量工程 (Traffic Engineering，TE)、运营、管理和维护 (Operations, Administration, and Maintenance，OAM) 或快速重路由 (Fast Reroute，FRR) 原因。

Segment List Depth：SR Policy 的段数。在节点N实例化SR策略的实体应该能够发现节点N的深度插入能力。例如，[PCEP-SR-EXT]中描述的PCEP SR能力通告就是发现这种能力的一种手段。

转发信息库（Forwarding Information Base，FIB）：节点的转发表

3、 链路状态 IGP 段

在 SR 域内，具有 SR 功能的 IGP 节点为其附加的前缀和邻接通告分段。这些段称为“IGP 段”或“IGP SID”。它们在 Segment Routing 和用例中发挥着关键作用，因为它们能够表达整个 SR 域中的任何路径。这样的路径要么表示为单个 IGP 段，要么表示为多个 IGP 段的列表。

IGP 段的通告需要在链路状态 IGP 协议中进行扩展。这些扩展在[ISIS-SR-EXT]、[OSPF-SR-EXT]和[OSPFv3-SR-EXT]中定义。

3.1、 IGP-前缀段（Prefix-SID）

IGP-Prefix 段是附加在 IGP 前缀上的 IGP 段。 IGP-Prefix 段在 SR 域内是全局的（除非另有明确通告）。 IGP-Prefix 段的场景包括前缀、拓扑和算法。只要元组 <prefix, topology, algorithm> 是唯一的，多个 SID 可以分配给相同的前缀。

在 IS-IS 和 OSPF 中定义了多个实例和拓扑：[RFC5120]、[RFC8202]、[RFC6549] 和 [RFC4915]。

3.1.1、 前缀 SID 算法

Segment Routing 支持使用多种路由算法，即可以支持不同的基于约束的最短路径计算。算法标识符作为 Prefix-SID 通告的一部分包含在内。定义算法的文档中需要指定如何完成特定于算法的路径计算。

本文档定义了两种算法：

* 最短路径优先：此算法是默认行为。数据包按照 IGP 采用的众所周知的 ECMP 感知最短路径优先 (Shortest Path First，SPF) 算法进行转发。但是，明确允许中点基于本地策略实现另一个转发。事实上，最短路径优先算法是大多数网络的默认和当前行为，其中本地策略可能会覆盖SPF 决定。

* 严格最短路径优先（Strict-SPF）：该算法要求数据包根据 ECMP 感知 SPF 算法进行转发，并指示路径中的任何路由器忽略任何可能覆盖SPF 决定的本地策略。使用 Strict-SPF 算法通告的 SID 可确保数据包将采用的路径是预期的且未更改的 SPF 路径。请注意，快速重路由 (FRR) [RFC5714] 机制仍然符合严格最短路径优先算法。换言之，接收到的带有 Strict-SPF SID 的数据包可以通过 FRR 机制重新路由。 Strict-SPF 使用与最短路径优先算法相同的拓扑。显然，不支持 Strict-SPF 的节点不会为该算法安装转发表项。将拓扑仅限于支持该算法的那些节点将不会产生所需的转发路径，因为所需的行为是遵循最短路径优先算法计算出的路径。因此，如果路径穿过不支持 Strict-SPF 算法的节点，则源 SR 节点不得使用包含严格 SPF 段的 SR 策略。

IGP-Prefix 段标识到相关前缀的路径，根据相关算法计算。注入 SR 域内任何位置的具有活动 Prefix-SID 的数据包预计将沿使用指定算法计算的路径转发。为此，需要支持指定算法的路由器的全连接拓扑。

3.1.2、 SR-MPLS

当 SR 在 MPLS 数据平面上使用时，SID 是 MPLS 标签或 MPLS 标签空间（SRGB 或 SRLB）的索引。

在可能的情况下，建议在 SR 域中的所有节点上配置相同的 SRGB。这简化了故障排除，因为相同的标签将与所有节点上的相同前缀相关联。此外，它简化了对任播的支持，详见第 3.3 节。

以下行为与在 MPLS 数据平面上运行的 SR 相关联：

* IGP-Prefix 段的IGP 信令扩展包含一个标志，用于指示附加前缀的节点的直接连接的邻居在处理SID 时应该执行NEXT 操作还是CONTINUE 操作。此行为等效于 MPLS 中的倒数第二跳弹出 (NEXT) 或终极跳弹出 (CONTINUE)。

* Prefix-SID按照类似于IP地址分配的过程，以MPLS标签（或SRGB中的索引）的形式分配。通常，Prefix-SID 由运营商（或网络管理系统 (Network Management System，NMS)）通过策略分配，并且 SID 很少更改。

* 虽然 SR 允许将本地段附加到 IGP 前缀，其中使用术语“IGP-Prefix 段”或“Prefix-SID”，但假定该段是全局的（即，SID 是从通告中定义的） SRGB）。这与所有描述的需要附加到 IGP 前缀的全局段的用例一致。

* 分配过程不得为不同的前缀分配相同的 Prefix-SID。

* 如果节点获知具有超出本地配置的 SRGB 范围的值的 Prefix-SID，则节点不得使用 Prefix-SID 并且应该发布报告错误配置的错误日志。

* 如果节点 N 为附加到 N 的前缀 R 通告 Prefix-SID SID-R 并指定 CONTINUE 作为由直接连接的邻居执行的操作，则 N 必须维护以下 FIB 条目：

传入活动段：SID-R

入口操作：NEXT

出接口：NULL

* 远程节点必须为附加到前缀 R 的任何学习的 Prefix-SID SID-R 维护以下 FIB 条目：

传入活动段：SID-R

入口操作：

如果 R 的下一跳是 R 的发起者，并且 M 已被指示删除活动段： NEXT Else: CONTINUE

出接口：沿路径到达下一跳的接口，使用算法计算出的 SID 向前缀 R 通告。

由于 Prefix-SID 特定于给定算法，如果与算法关联的流量到达不支持该算法的节点，则流量将被丢弃，因为将没有与传入标签匹配的转发条目。

3.1.3、 SRv6

在 IPv6 数据平面上使用 SR 时：

* Prefix-SID 是 IPv6 地址。

* 操作人员必须显式实例化一个 SRv6 SID。默认情况下，IPv6 节点地址不是 SRv6 SID。

节点 N 通告可用作段标识符的 IPv6 地址 R 必须维护以下 FIB 条目：

传入活动段：R

入口操作：NEXT

出接口：NULL

请注意，转发到 R 不需要在所有其他路由器的 FIB 中为 R 提供条目。转发可以并且通常是通过覆盖 R 的较短掩码前缀来实现的。

独立于 SR 支持，任何远程 IPv6 节点都将为任何前缀维护一个普通的 IPv6 FIB 条目，无论前缀是否代表一个段。这允许即使不支持 SR 的节点也可以将数据包转发到拥有 SID 的节点。

SRv6 支持多种算法。由于特定于算法的 SID 只是 IPv6 地址，因此可以通过将特定于算法的子网分配给节点分配的（组）算法特定 SID 来实现特定于算法的转发条目。

不支持给定算法的节点可能仍然具有覆盖算法特定地址的 FIB 条目，即使该节点尚未计算算法特定路径。由于不支持给定算法的节点将不会包含在与该算法特定的 SPF 关联的拓扑中，因此可以缓解这种情况；因此，使用特定于算法的目的地的流量通常不会流经被排除的节点。如果这样的流量到达并由这样的节点转发，它仍然会向目的地节点前进。下一跳将是支持算法的节点——在这种情况下，数据包将沿着特定于算法的路径转发（如果没有可用的路径，则丢弃）——或者是不支持算法的节点——在这种情况下，数据包将继续沿算法 0 路径向目标节点转发。

3.2、 IGP-节点段（Node-SID）

IGP Node-SID 不得与同一路由域内由多个路由器拥有的前缀相关联。

3.3、 IGP-任播段（Anycast-SID）

Anycast 段或 Anycast-SID 强制执行 ECMP 感知的最短路径转发到任播集的最近节点。 这对于表达宏观工程政策或保护机制很有用。

IGP-Anycast 段不得引用特定节点。

在任播组内，SR 域中的所有路由器必须以相同的 SID 值通告相同的前缀。

3.3.1、 SR-MPLS 中的任播 SID

图 1：传输设备组

图 1 说明了具有两组传输设备的网络示例。 A组由设备{A1、A2、A3和A4}组成。 它们都配备了任播地址 192.0.2.10/32 和任播 SID 100。

类似地，B 组由设备{B1、B2、B3 和 B4} 组成，它们都配备了任播地址 192.0.2.1/32 和任播-SID 200。在上述网络拓扑中，每个提供边缘（PE ) 设备具有到每个组的路径：A 和 B。

PE1 可以在向 PE3 或 PE4 发送流量时选择特定的传输设备组。 这将通过将组的 Anycast-SID 推送到堆栈中来完成。

处理任播和后续段需要特别小心。

图 2：通过任播组 A 的传输路径

考虑MPLS部署，在上述拓扑中，如果设备PE1（或PE2）需要向设备PE3（或PE4）发送数据包，则需要将数据包封装在具有以下标签栈的MPLS负载中。

* R1 为 Anycast-SID 100 分配的标签（外标签）。

* 由组 A 中最近的路由器为 SID 30（用于目的地 PE3）分配的标签。

在这种情况下，第一个标签很容易计算。但是，由于拓扑上最近的设备（A1 和 A2）不止一个，因此除非 A1 和 A2 将相同的标签值分配给相同的前缀，否则无法确定第二个标签。设备 A1 和 A2 可能是来自不同硬件供应商的设备。如果两者都没有为 SID 30 分配相同的标签值，则不可能使用任播组 A 作为到 PE3 的中转任播组。因此，PE1（或PE2）无法计算适当的标签堆栈来专门引导数据包通过A 组设备。尝试向 PE1 或 PE2 发送数据包时，设备 PE3 和 PE4 也是如此。

为了简化任播段的使用，建议在特定任播组的所有节点上配置相同的 SRGB。如上所述，使用这种方法，计算任播段之后的标签很简单。

使用任播段而不在属于同一任播组的所有节点上配置相同的 SRGB 可能会导致错误路由（在 MPLS VPN 部署中，某些流量可能会在 VPN 之间泄漏）。

3.4. IGP-邻接段（Adj-SID）

邻接由本地节点（即在 IGP 中通告邻接的节点）和远程节点（即邻接的另一端）形成。本地节点必须是 IGP 节点。远程节点可以是相邻的 IGP 邻居或非相邻的邻居（例如，转发邻接，[RFC4206]）。

一个在SR域内任何地方注入的具有段列表{SN，SNL}的数据包，其中SN是节点N的Node-SID，SNL是节点N附加到其在链路L上的邻接的Adj-SID，将沿最短路径转发路径到 N，然后由 N 切换，不考虑任何 IP 最短路径，朝向链路 L。如果 Adj-SID 标识一组邻接，则节点 N 在该组的各个成员之间对流量进行负载均衡。

类似地，当使用全局 Adj-SID 时，带有段列表 {SNL} 的 SR 域内任何位置注入的数据包，其中 SNL 是节点 N 附加到其在链路 L 上的邻接的全局 Adj-SID，将沿着到 N 的最短路径，然后在不考虑 IP 最短路径的情况下由 N 切换到链路 L。如果 Adj-SID 标识一组邻接，则节点 N 会在该网络的各个成员之间进行流量负载均衡放。使用全局 Adj-SID 允许在以附加状态为代价表示路径时减少段列表的大小（即，全局 Adj-SID 将被该区域内的所有路由器插入其转发表中）。

“IGP-Adjacency segment”或“Adj-SID”强制将数据包从节点切换到定义的接口或接口集。这是理论上证明任何路径都可以表示为段列表的关键。

Adj-SID 的编码包括一组支持以下功能的标志：

* 有资格获得保护（例如，使用 IPFRR 或 MPLS-FRR）。保护允许在与 Adj-SID 关联的接口关闭的情况下，仍然可以通过备用路径转发数据包。使用保护显然是基于政策的决定；也就是说，对于给定的政策，保护可能是可取的，也可能不是。

* 指示 Adj-SID 是否具有局部或全局作用域。默认范围应该是本地的。

* 指示 Adj-SID 是否在控制平面重启时保持不变。持久性是确保 SR 策略不会由于 Adj-SID 的重新分配而暂时导致误转发的关键属性。

权重（如下所述）也与 Adj-SID 通告相关联。

节点应该为其每个邻接分配一个 Adj-SID。

一个节点可以为同一个邻接分配多个 Adj-SID。一个例子是支持一个符合保护条件的 Adj-SID 和一个不符合保护条件的 Adj-SID。

一个节点可以将相同的 Adj-SID 关联到多个邻接。

为了能够在 IGP 中通告表示两个节点之间 IGP 邻接的所有 Adj-SID，IGP 不得执行并行邻接抑制。

当节点将 Adj-SID V 绑定到本地数据链路 L 时，节点必须安装以下 FIB 条目：

传入活动段：V

入口操作：NEXT

出接口：L

Adj-SID 意味着，从路由器通告它，通过 Adj-SID 标识的一个或多个邻接转发数据包，而不管其 IGP/SPF 成本如何。换句话说，邻接段的使用会overlay网络由 SPF 算法做出的路由决定。

3.4.1、 平行邻接

Adj-SID 可用于表示两个相邻路由器之间的一组并行接口。

一个节点必须为任何本地产生的值 W 的 Adj-SID 安装一个 FIB 条目，该 Adj-SID 附加到一组链路 B，具有：

传入活动段：W

入口操作：NEXT

出接口：B 组内任何数据链路之间的负载均衡

当并行邻接被使用并与相同的 Adj-SID 相关联时，为了优化负载均衡功能，“权重”因子可以与每个邻接通告的 Adj-SID 相关联。 权重告诉入口（或 SDN/编排系统）关于并行邻接上的负载均衡因子。 如图 3 所示，A 和 B 通过两个并行邻接点连接

图 3：并行链接和 Adj-SID

节点 A 通告以下 Adj-SID 和权重：

* Link-1：Adj-SID 1000，权重：1

* Link-2：Adj-SID 1000，权重：2

节点 S 接收并行邻接的通告，并了解到通过使用 Adj-SID 1000，节点 A 将根据 1:2 的比率对并行链路（Link-1 和 Link-2）上的流量进行负载均衡，即两倍于与 Link-1 相比，许多数据包将流经 Link-2。

3.4.2、 LAN 邻接段

在 LAN 子网中，链路状态协议定义了指定路由器（Designated Router，DR，在 OSPF 中）或指定中间系统（Designated Intermediate System，DIS，在 IS-IS 中）的概念，它们在广播子网中进行泛洪，并在特殊路由更新中描述 LAN 拓扑（ OSPF Type2 LSA 或 IS-IS 伪节点 LSP）。

LAN 的难点在于每个路由器只向 DR/DIS 通告其连接性，而不向 LAN 中的每个单独节点通告。因此，为了让 LAN 中的每个路由器通告与 LAN 中的每个邻居关联的 Adj-SID，需要额外的协议机制（IS-IS 和 OSPF）。

3.5、 区域间注意事项

在下面的示例图中，假设所有区域都是单个 SR 域的一部分。

图 4 假设 IPv6 控制平面与 MPLS 数据平面。

图 4：区域间拓扑示例

在区域 2 中，节点 Z 将 Node-SID 150 分配给其本地 IPv6 前缀 2001:DB8::2:1/128。

区域边界路由器 (Area Border Routers，ABR) G 和 J 将根据正常的区域间/级别 IGP 传播规则创建前缀的新实例，将前缀及其 SID 传播到骨干区域。

当从骨干区域向下泄漏前缀到区域 1 时，节点 C 和 I 将应用相同的行为。因此，节点 S 将看到前缀 2001:DB8::2:1/128 和 Prefix-SID 150 并由节点 C 和 I 通告。

因此，结果是 Prefix-SID 通过区域间过程保持附加到其相关的 IGP 前缀，这是单个 SR 域中的预期行为。

当节点 S 向 2001:DB8::2:1/128 发送流量时，将 Node-SID(150) 作为活动段推送给 A。

当数据包到达 ABR I（或 C）时，ABR 根据活动段（Node-SID(150)）转发数据包。转发继续跨越区域边界，使用相同的 Node-SID(150)，直到数据包到达其目的地。

4、 BGP 段

BGP 段可以由 BGP 分配和分发。

4.1、 BGP-前缀段

BGP-Prefix 段是附加到 BGP 前缀的 BGP 段。

一个 BGP-Prefix 段在 SR 域内是全局的（除非明确声明）。

BGP-Prefix 段是等效于 IGP-Prefix 段的 BGP。

BGP-Prefix 段的一个可能用例是无 IGP 的超大规模spine-leaf拓扑，其中仅通过 BGP 学习连接 [RFC7938]

4.2、 BGP 对等网段

在 BGP 出口对等工程（Egress Peer Engineering，EPE）的场景中，如 [SR-CENTRAL-EPE] 中所述，启用 EPE 的出口节点可以通告与其连接的对等体对应的段。这些段称为 BGP 对等段或 BGP 对等 SID。它们支持源路由域间路径的表达。

自治系统(Autonomous System，AS)的入口边界路由器可以组成一个段列表，以引导流沿着AS内的选定路径朝向AS的选定出口边界路由器C并通过特定对等体。在入口节点应用的 BGP 对等工程策略至少涉及两个段：所选出口节点的 Node-SID 和所选出口节点对等体或对等接口的 BGP 对等段。

定义了三种类型的 BGP 对等互连段/SID：PeerNode SID、PeerAdj SID 和 PeerSet SID。

*> PeerNode SID：BGP PeerNode 段/SID 是本地段。在广播它的 BGP 节点处，其语义是：

* SR 操作：NEXT。

* Next-Hop：与段相关的连接的对等节点。

*> PeerAdj SID：BGP PeerAdj 段/SID 是本地段。在广播它的 BGP 节点上，语义是：

* SR 操作：NEXT。

* Next-Hop：通过与段相关的接口连接的对等体。

*> PeerSet SID：BGP PeerSet 段/SID 是本地段。在广播它的 BGP 节点上，语义是：

* SR 操作：NEXT。

* 下一跳：通过任何连接的接口将负载均衡到相关组中的任何对等点。

对等体集可以是来自同一 AS 的所有连接对等体，也可以是这些对等体的子集。一个组也可以跨越 AS。组定义是操作人员设置的策略。

在[BGPLS-SR-EPE]中定义了发送这些BGP对等段所需的BGP扩展。

5. 绑定段

为了提供更大的可扩展性、网络不透明性和服务独立性，SR 使用绑定 SID (BSID)。 BSID 绑定到 SR Policy，其实例化可能涉及 SID 列表。任何接收到的活动段等于 BSID 的数据包都被引导到绑定的 SR 策略上。

BSID 可以是本地或全局 SID。如果是本地的，应该从 SRLB 分配一个 BSID。如果是全局的，必须从 SRGB 分配一个 BSID。

BSID 的使用允许策略的实例化（SID 列表）仅存储在需要实施策略的一个或多个节点上。到支持该策略的节点的流量方向则只需要强加 BSID。如果策略发生变化，这也意味着只有实施策略的节点需要更新。该策略的用户不受影响。

5.1、 IGP 镜像场景段

绑定段的一个用例是为 IGP 节点提供支持，以通告其处理最初发往另一个 IGP 节点（称为“镜像节点”并由 IP 地址或节点 SID 标识）的流量的能力，前提是镜像场景段在任何本地于镜像节点的服务段之前插入段列表中。

当给定节点 B 想要提供出口节点 A 保护时，它会通告标识节点 A 场景的段。这样的段称为“镜像场景段”，由镜像 SID 标识。

使用 SR IGP 协议扩展 [ISIS-SR-EXT] 中定义的绑定段来通告镜像 SID。

发生故障时，本地修复点 (PLR) 将流量从 A 转移到 B 对受保护的流量执行镜像 SID 的 PUSH。当接收以镜像 SID 作为活动段的流量时，B 使用该段并在 A 的场景中处理底层段。

6、 组播

段路由是为单播定义的。源路由概念在组播中的应用不在本文档的范围内。

7、 IANA 考虑

本文档没有 IANA 行动。

8、 安全考虑

分段路由适用于 MPLS 和 IPv6 数据平面。

SR 向数据包添加一些元数据（指令），以及数据包必须遍历的转发路径元素（例如，节点、链接、服务等）的列表。必须注意，完整的源路由路径可以由单个段表示。这是绑定 SID 的情况。

默认情况下，SR 在受信任的域中运行。流量必须在域边界进行过滤。

使用最佳实践来降低受信任域内的篡改风险非常重要。此类实践在 [RFC4381] 中进行了讨论，并且适用于 SR-MPLS 和 SRv6。

8.1、 SR-MPLS

当应用于 MPLS 数据平面时，SR 不会引入任何新行为或 MPLS 数据平面工作方式的任何变化。因此，从安全的角度来看，本文档没有在 MPLS 数据平面中定义任何附加机制。

SR 允许使用单个段（绑定 SID）来表达源路由路径。与同样提供显式路由功能的 RSVP-TE 相比，在提供的信息方面没有根本区别。 RSVP-TE 和段路由都可以使用单个段来表示源路由路径。

当使用单个标签表示路径时，元数据的语法在 RSVP-TE [RFC3209] 和 SR 之间是等效的。

当源路由路径用段列表表示时，额外的元数据被添加到由包必须遵循的源路由路径组成的包中，并表示为段列表。

当使用标签堆栈表示路径时，如果可以访问标签的含义（即转发等效类），则可以了解显式路径。对于 MPLS 数据平面，由于不需要修改数据平面，因此没有根本的能力变化。然而，标签堆叠的发生会增加。

SR 域边界路由器必须过滤任何发往与受信任域内的段相关联的标签的外部流量。这包括受信任域的 SRGB 内的标签、特定边界路由器的 SRLB 内的标签以及这些块之外的标签。外部流量是从连接到信任域外节点的接口接收的任何流量。

从网络保护的角度来看，有一个假定的信任模型，这样任何在数据包上施加标签堆栈的节点都被假定允许这样做。与提供最短路径路由的普通 IP 相比，这是一个重大变化，但与提供显式路由功能（如 RSVP-TE）的现有技术相比，它没有根本的不同。默认情况下，显式路由信息不得通过管理域的边界泄漏。已在各种协议中定义的段路由扩展利用了这些协议的安全机制，例如加密、身份验证、过滤等。

在一般情况下，具有分段路由功能的路由器仅在标签先前已由受信任的来源通告时才接受并安装标签。使用提供身份验证和安全机制的现有控制平面协议来验证接收到的信息。 Segment Routing 没有在现有的控制平面协议中定义任何额外的安全机制。

SR 不会在源路由路径的源和中点之间引入信令。使用 SR，源路由路径是使用先前在 IP 控制平面中通告的 SID 计算的。因此，除了在SR域的边界过滤和控制SID的通告外，还需要在数据平面进行过滤。过滤必须在 SR 域边界的转发平面上执行，并且可能需要查看多个标签/指令。

对于 MPLS 数据平面，没有新的要求，因为现有的 MPLS 架构已经允许通过堆叠多个标签来进行这种源路由。并且，为了安全保护，[RFC4381] 和 [RFC5920] 已经要求在信任边界上过滤 MPLS 数据包。

8.2、 SRv6

当应用于 IPv6 数据平面时，分段路由确实引入了分段路由包头（SRH，[IPv6-SRH]），它是 [RFC8200] 中定义的一种路由扩展包头。

SRH 将一些元数据添加到 IPv6 数据包中，其中包含数据包必须经过并由 IPv6 地址表示的转发路径元素（例如，节点、链接、服务等）的列表。可以使用单个段（单个 IPv6 地址）在数据包中编码完整的源路由路径。

SR 域边界路由器必须过滤任何发往受信任域的 SRGB 或特定边界路由器的 SRLB 内的地址的外部流量。外部流量是从连接到信任域外节点的接口接收的任何流量。

从网络保护的角度来看，有一个假定的信任模型，这样任何向数据包添加 SRH 的节点都被假定允许这样做。因此，默认情况下，显式路由信息绝不能通过管理域的边界泄漏。已在各种协议中定义的段路由扩展利用了这些协议的安全机制，例如加密、身份验证、过滤等。

在一般情况下，SRv6 路由器接受并安装段标识符（以 IPv6 地址的形式），仅当这些 SID 由受信任的源通告时。使用提供身份验证和安全机制的现有控制平面协议来验证接收到的信息。 Segment Routing 没有在现有的控制平面协议中定义任何额外的安全机制。

当未实施上述行为或违反假定的信任模型时（例如，通过安全漏洞）可能出现的问题包括：

* 恶意循环

* 规避访问控制

* 隐藏 DoS 攻击的来源

在 [RFC5095] 中更完整地讨论了 IPv6 数据平面上 SR 的安全问题。新的基于 IPv6 的分段路由头在 [IPv6-SRH] 中定义。本文档还讨论了上述安全问题。

8.3、 拥塞控制

SR 没有引入新的拥塞控制要求。默认情况下，流量交付被假定为尽力而为。拥塞控制可以在端点实现。在使用 SR 策略的情况下，可以通过监控与标识 SR 策略的绑定 SID 相关联的传入流量来管理带宽分配。 [RFC8084] 中提出的其他解决方案也可能适用。

9、 可管理性考虑

在启用 SR 的网络中，数据包采用的路径在包头中进行编码。由于路径不是通过协议发送的，因此 OAM 机制是必要的，以便网络运营商验证路径的有效性以及检查和监控其活动性和性能。然而，必须注意的是，SR 允许大幅减少传输节点中的状态数量；因此，中转节点必须管理的元素数量较少。

MPLS 数据平面的 SR OAM 用例在 [RFC8403] 中定义。

MPLS 数据平面的 SR OAM 程序在 [RFC8287] 中定义。

SR 路由器从为 SR 扩展的不同路由协议接收 SID（索引、标签或 IPv6 地址）的通告。这些协议中的每一个都有监控和故障排除机制，为必须扩展的 IP 地址提供操作和管理功能，以便包括 S​​ID 的故障排除和监控功能。

SR 架构引入了全局段的使用。每个全局段必须绑定到 SR 域内的唯一索引或地址。运营商对此类索引或地址分配的管理对于网络行为避免误路由等情况至关重要。除了运营商将拥有的分配策略/工具之外，实施应该通过提供确定性解决方法来在冲突检测的情况下保护网络。

当使用标签堆栈表示路径时，标签堆栈的发生会增加。一个节点可能想在控制平面中用信号通知它可以支持的标签堆栈大小的能力。

[SR-YANG] 中定义了用于 SR 配置和操作的 YANG 数据模型 [RFC6020]。

SR应用于IPv6数据平面时，通过IPv6地址来标识段。段标识符的分配、管理和故障排除与应用于 IPv6 地址分配和管理的现有机制没有什么不同。

数据包的 DA 给出了活动段地址。 SRH 中的段列表给出了数据包的整个路径。源路由路径的验证是通过检查与等效路由表条目匹配的数据包头中存在的 DA 和 SRH 来完成的。

在 SRv6 数据平面的场景中，源路由路径在 SRH 中编码，如 [IPv6-SRH] 中所述。 SRv6 源路由路径作为 IPv6 地址列表实例化到 SRH 中，其中活动段位于 IPv6 数据包头的 DA 字段中。通常，通过检查任何节点中的数据包头，可以推导出它所属的源路由路径。类似于 SR-MPLS 数据平面的场景，一个实现可以发起路径控制和监视数据包，其中源路由路径插入到 SRH 中，并且路径的每个段在数据包中插入相关数据以便测量端到端的路径和性能。

10、 参考文献10.1、 规范参考

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <;.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <;.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <;.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <;.

10.2、 参考资料

[BGPLS-SR-EPE]Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", Work in Progress, draft-ietf-idr-bgpls-segment-routing-epe-15, March 2018.

[IPv6-SRH] Filsfils, C., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, Ed., "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-14, June 2018.

[ISIS-SR-EXT] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", Work in Progress, draft-ietf-isis-segment-routing-extensions-19, July 2018.

[OSPF-SR-EXT] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-segment-routing-extensions-25, April 2018.

[OSPFv3-SR-EXT] Psenak, P., Ed., Filsfils, C., Previdi, S., Ed., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-13, May 2018.

[PCEP-SR-EXT] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <;.

[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <;.

[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006, <;.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <;.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <;.

[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <;.

[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <;.

[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <;.

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <;.

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <;.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <;.

[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <;.

[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, <;.

[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <;.

[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, <;.

[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, <;.

[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, <;.

[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018, <;.

[SR-CENTRAL-EPE] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", Work in Progress, draft-ietf-spring-segment-routing-central-epe-10, December 2017.

[SR-MPLS] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-14, June 2018.

[SR-YANG] Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", Work in Progress, draft-ietf-spring-sr-yang-09, June 2018.