SRv6 在 SFC 中的应用

SFC 通常指一组 SF（Service Function，业务功能）节点组成的序列。为满足特定的商业、安全等需求，对于指定的业务流，通常要求在转发时经过指定 SF 序列的处理，这些 SF 包括 DPI（Deep Packet Inspection，深度包检测）、FW、IPS（Intrusion Prevention System，入侵防御系统）和 WAF（Web Application Firewall，网络应用防火墙）等多种 VAS 节点。

SFC 的架构主要包括以下关键部分。

• SF：提供特定网络服务的节点，这些网络服务一般处在 OSI（Open System Interconnection，开放系统互连）模型的四层~七层，例如 DPI、FW、IPS 等。这些服务通常又是网络增值服务，所以也可以将 SF 等同于 VAS。

• SFF（Service Function Forwarder，业务功能转发器）：支持 SFC 的转发器，一般挂接 SF 节点，用于将报文转发到 SF 节点。

• SFP（Service Function Path，业务功能路径）:SFC 对应的转发路径。

• Classifier（流分类器）：用于将数据流分类，并转发到对应的 SFP。流分类器是 SFC 的起点，一般支持基于五元组的流量分类规则。

• SFC Proxy：为不支持 SFC 的 SF 节点提供代理接入 SFC 的能力。

SR-MPLS 和 SRv6 都支持 SFC。相比于 SR-MPLS,SRv6 还可以通过 SRH TLV 携带 SFC 的元数据，可以更好地支持 SFC，所以本节将重点介绍基于 SRv6 的 SFC。目前业界主要有两种 SRv6 SFC 解决方案。

• Stateless（无状态的）SRv6 SFC：指不在 SFF 上维护每个 SFC 的转发状态的解决方案。

• Stateful（有状态的）SRv6 SFC：需要在 SFF 上维护每个 SFC 的转发状态的解决方案，其实是一种 SRv6 与 NSH 结合的方案。

1. Stateless SRv6 SFC

在 SRv6 网络中，可以通过 SID 的组合来实现转发路径的编程，即显式路径编程。若编程的路径依次穿过指定的 SF，则实现了 SFC，这就是 Stateless SRv6 SFC 的主要思想。

在 Stateless SRv6 SFC 方案中，通过 Segment List 指定了 SFC 的转发路径，SRH TLV 也可以携带 SF 相关的元数据，因此不需要 NSH 来指导报文的转发，也不需要在 SFF 上维护每个 SFC 的转发状态。

Stateless SRv6 SFC 方案里包含如下关键组件。

• SRv6-aware SF：支持 SRv6 的 SF 节点，可以直接连到 SFF。SF 需要发布对应的 SID，这个 SID 与服务功能对应，所以被称为 Service SID。

• SRv6-unaware SF：不支持 SRv6 的 SF 节点，需要先在 SFF 和 SRv6unaware SF 之间部属 SRv6 Proxy 来完成 SRv6 报文的处理。

• SRv6 Proxy:SRv6 的代理，SRv6 Proxy 完成报文从 SRv6 网络转发到 SRv6-unaware SF 以及从 SRv6-unaware SF 返回 SRv6 网络的代理。根据代理类型的不同，存在多种代理 Service SID。

• End.AS:Static Proxy（静态代理）SID，由 SRv6 Proxy 节点发布。End.AS 的功能是剥离 SRH，并将原始报文通过对应的接口或者虚拟接口（比如 VLAN ID 对应的接口）发送到 SF。携带指定 VLAN ID 的报文从 SF 返回 SRv6 Proxy 之后，根据 VLAN ID，将缓存的 SRH 插回报文中，继续转发。通过静态配置生成 SRH 与虚拟接口的映射关系，所以称其为静态代理 SID。

• End.AD:Dynamic Proxy（动态代理）SID，由 SRv6 Proxy 节点发布。End.AD 在静态代理 SID 的基础上增加了动态学习的能力，将 SRH 与虚拟接口的映射关系由静态配置改变为根据接收到的报文的 SRH 动态生成。

• End.AM:Masquerading Proxy（伪装代理）SID，由 SRv6 Proxy 节点发布。End.AM 的功能是将真正的目的地址，即 Segment List 中的 SID[0]更新到 DA，从而伪装出携带真实目的地址的 IPv6 报文，转发到 SF。SF 返回的报文在 SRv6 Proxy 处需要将下一个 SID 替换成 DA，继续转发。

Stateless SRv6 SFC 只需扩展发布 Service SID 信息，就能实现 SFC，且不需要在 SFF 上维护每个 SFC 的状态，所以相比 NSH 简单许多，有效地降低了 SFC 的部署难度，成为当前部署 SFC 的新选择。

当然，Stateless SRv6 SFC 也存在一定的问题，例如当 SF 数目过多时， Segment List 中 SID 数目比较多，SRv6 报文头开销相对较大。当前大部分 SF 还不支持 SRv6，所以还需要部署 SRv6 Proxy，这在一定程度上增加了部署 SFC 的难度。

2. Stateful SRv6 SFC

Stateful SRv6 SFC 结合了 SRv6 和 NSH 两种技术，主要面向 SF 支持 NSH 但不支持 SRv6 的场景，是一种从非 SRv6 网络向 SRv6 网络演进的过渡型方案。在 Stateful SRv6 SFC 方案的标准文稿中，主要描述了两种解决方案。

方案一：业务平面为 NSH，指导整条 SFC 转发，SRv6 只用于连接 SFF 的隧道技术。

方案二：SRv6 Segment List 携带整条 SFC 转发路径信息，贯穿整条 SFC 的多个 SFF，但 SFF 到 SF 之间通过查询 NSH 转发表进行转发。

方案二与方案一的不同点在于入节点通过 SRv6 把整条 SFC 的路径显式地编程到 Segment List 中，而不是由 NSH 把多段 SRv6 隧道串联起来。方案二与方案一的共同点是 SFF 到 SF 这段路径的路由依然由 NSH 来决定。

总体来看，Stateless SRv6 SFC 不必在 SFF 上维护每个 SFC 的状态，当 SF 支持 SRv6 时，方案的实现难度更小。Stateful SRv6 SFC 的两种方案虽然都需要维护每个 SFC 的状态，但都兼容基于 NSH 的 SFC 解决方案，也不要求 SF 支持 SRv6。基于 NSH 和 SRv6 结合的转发在一定程度上减少了 SRv6 报文头中 Segment List 内 SID 的数量，缩短了报文头的长度，是 NSH 网络向 SRv6 网络升级的一种可选的过渡方案。