云网融合PCEP应用及端到端保障方案

王越，王爱俊，徐洪磊

（中国电信股份有限公司研究院， 北京 102209）

1 引言

2 PCEP在云网融合场景的应用

作为当前云计算市场竞争的核心，云网融合已经成为全球领先运营商正积极推进的发展战略。云网融合不仅需要利用虚拟化技术实现传统网元设备算力、网络和存储等基础设施的集中解耦、融合和重构，保证资源的一体化供给，更要求承载网络能够根据各类云服务需求按需开放网络能力，实现网络与云的敏捷打通、按需互联，并体现出智能化、自服务、高速等特性，实现一体化智慧运营和服务保障。从网络架构的角度出发，以DC（data center）为中心构建网络，重点解决云资源池和互联网数据中心的链路扁平直达问题，做到东西流量和南北流量并重。在目前的数据中心中，云资源和网络资源大多基于OpenStack 的 Neutron 组件实现对接，功能有限，无法实现在广域网进行大量的网络配置和调整，尤其在面对混合云、跨云互联以及多点入云等场景，稍显力不从心。此外，随着网络规模的增长，对网络进行精细化管控问题也变得尤为突出。

在云网融合大趋势推进运营商向IP网络智能化逐步演进的背景下，控制器作为SDN架构的核心组件其重要性日益凸显，且从以对内应用为主，逐步转向以对外提供服务为主。作为整个网络体系的“大脑”，控制器利用北向接口使业务具备能够便利调用底层网络资源的能力，实现资源的统一调度和管理。南向接口则负责与底层设备通信，通过业务功能抽象屏蔽了底层物理转发设备的差异，实现了资源的虚拟化，完成了对底层设备的集中统一控制[2]。

当前，在运营商的IP网络中，二层数据报文中只有源和目的地址的字段，是面向无连接状态的逐跳式服务，缺少针对数据流量路径的控制消息。为更好地实现流量感知和路径优化，提供应用驱动的网络服务，保障关键业务质量，均衡流量分布，运营商通常会采用多协议标签交换（multi-protocol label switching，MPLS）网络或者IPv6网络的方案。随着业务量的增加，网络规模不断扩大，这样的做法将过多的复杂协议引入封闭的网络设备，网络设备不仅需要承担数据转发、路由管理、路由协议解析等任务，还要消耗大量计算资源进行复杂约束条件的路由运算[3]，给网络基础架构带来额外负担的同时，增加了管理难度和运维工作量。

PCEP（path computation element communication protocol，路径计算单元通信协议）作为基于TCP的路由集中控制方案，是由IETF的PCE（path computation element，路径计算单元）工作组于2006年为MPLS网络域间流量工程等应用提出的通信协议[4]。其最初应用于光网络，随着南向接口技术在SDN体系发展的日趋成熟，PCEP也不断扩充和完善，逐步实现了面向分段路由的以及LSP保护路径的扩展等能力[5]。作为众多南向接口协议（如BGP LS、OpenFlow、Netconf）中较为成熟的PCEP，其采用了集中式的路径计算模型，该协议将路由器的CSPF（constrained shortest path first）功能抽离，通过集中部署控制器或者PCE，根据全网的带宽、代价、标签等全局资源视图进行约束路径计算，以集中算路的方式，为各类应用计算最优路径，下发给网络设备，控制报文转发，实现全局统一调度，完成路径计算和路径建立转发功能的分离[6]，保障流量端到端全局最优，是一种应用较为广泛的网络路径计算协议。相比较于分布式路径计算，通过PCE实现集中算路的方式在解决复杂网络环境跨层、跨域的端到端约束路由计算方面更具优势，同时能够有效降低运维复杂度与难度，为简化网络运维，提升网络质量提供了可能。

3 基于PCEP协议的流量端到端保障方案

3.1 端到端保障方案需求

在路由管控方面，传统的MPLS-VPN在原有IGP（interior gateway protocol）基础上增加LDP（label distribution protocol）实现标签的转发过程，由于 LDP不具备流量工程，而通过 RSVP-TE（resource reservation protocol-traffic engineering）实现显示路径计算信令较为复杂，同时庞大的TE链路信息扩展和维护困难，设备协议开销以及运维复杂度较高，无法实时采集监控网络质量情况并完成最优路径的自动优化，因此信息交互效率低。作为新兴技术的SRv6，虽充分利用 IPv6扩展头的机制，通过SRH（segment routing header）中的IPv6地址标识segment实现流量的引导转发，但因SRH信息的引入，报文开销较大、网络链路带宽利用率低。此外SRv6报文处理对芯片要求较高。现网设备芯片难以支持对128 bit SID（segment ID）的扩展头SRH复制和操作，无法实现向SRv6的平滑升级演进，给运营商部署SRv6带来较大成本压力。

考虑到MPLS以及SRv6类型方案要么利用L3 VPN技术，要么利用SRH扩展IPv6包头，对于IPv4网络，缺乏良好的解决方案。针对IP网络中无连接的状态，本文利用 PCEP转控分离的机制，提出了一种基于 PCEP的流量端到端保障方案。该方案有效利用了二层以太帧结构中的VLAN信息，通过PCE实时收集全网资源信息，响应转发节点请求，完成智能路径计算和头端计算路径自动下发，从而保证在本地 IP环境实现面向连接的网络通信及端到端业务保障[7]。相较于MPLS、SRv6等方案，本方案利用了全新的VLAN地址空间，避免了与其他已有协议的冲突，能够同时适用于IPv4和IPv6网络。

通过PCE的全域资源感知，能够获得云网资源的一致质量保证，确保业务的一体化规划和运维管理，实现云业务和网络业务的深度融合。结合Telemetry和Netflow等技术亦可实现业务流量可视化和按需调度，保证网络资源和云资源的一体化弹性供给和敏捷服务。

正因为鲁西化肥在液体肥研发中紧盯绿色发展需要，服务于“土壤修养”的目标，其系列液体肥的PH值为中性，适用多种作物，真正实现有效改良土壤。

3.2 端到端保障方案模型架构

基于 PCEP的流量下发保障方案，主要思路是控制器根据网络约束参数完成关键数据业务端到端的初始化路径计算，并通过和设备建立PCEP将结果以三元组和交叉表方式通过南向接口下发至设备。设备收到信息，在本地形成路由映射表和路由交叉表，根据表项内容，将数据流量封装对应的VLAN_ID进行转发，实现数据流量的二层封装和面向连接的快速转发，保障业务端到端质量。

本方案系统主要包括SDN控制器、边缘路由设备（入口路由器和出口路由器）、转发路由设备。

其中，SDN控制器通过PCEP分别与系统边缘设备、转发路由设备建立连接，根据实际业务需求，完成业务端到端保障路径的计算，形成三元组信息和网络交叉信息分别下发至边缘和转发设备；边缘入方向设备（入口路由器）负责向控制器发送路径请求初始化确认信息，同时根据控制器下发的路径计算结果在本地形成路由映射表，设备依据此表对接收的数据报文进行匹配，对匹配的报文封装对应的VLAN-ID进行转发；转发路由设备根据控制器下发的路由交叉表，完成从入方向子接口标识到出方向子接口 VLAN-ID标识的交叉转发和数据再封装。而边缘出方向设备（出口路由器）则将VLAN-ID解封装，并基于数据目的地址进行转发。

在实际业务场景中，可以在网络拓扑中边缘入方向设备和出方向设备分别部署多个BGP session，不同的BGP session分发不同的前缀，并具有不同的BGP 下一跳。在控制层，入口路由设备通过BGP可以学习网络拓扑中由控制器约束的基于同一BGP session的源/目的peer的不同路径，即源和目的BGP前缀。控制器作为PCE则根据网络拓扑、流量工程策略（TE policy）等参数信息计算满足约束条件请求的路径，通过 PCEP的PC初始信息将路径通过三元组信息——源 BGP peer、目的BGP peer、VLAN-ID下发至作为路径计算客户端（path computation client, PCC）的入口路由设备，完成VLAN路径的初始化。入口路由设备收到 PCEP下发的三元组信息后，向控制器发送 PCRpt消息完成确认，同时形成基于源/目的BGP前缀的映射路由表，最终转化为实际的隧道和隧道路径的配置。

在转发层，当入口路由设备接收到数据报文时，会将数据报文的源/目的地址和映射路由表中源BGP前缀、目的BGP前缀进行匹配，如果一致，则将数据包打上对应的VLAN-ID标签，并创建对应的VLAN子接口进行转发。

转发路由器收到封装对应VLAN-ID的数据报文后，通过匹配控制器下发的VLAN交叉表，将数据报文原有VLAN信息解封装，打上新的VLAN-ID标签，同时创建对应的VLAN子接口进行转发。

出口路由设备则根据映射信息，将封装VLAN-ID的二层包头去掉，对报文进行三层转发。实现了在本地 IP环境下，面向连接的网络通信及端到端业务保障。解决了传统IP报文无连接无状态的痛点。

3.3 基于PCEP架构的VLAN流量转发流程

对于现网中较为复杂的网络拓扑，网络设备之间往往会存在多个BGP session，不同的session用于承载不同的数据业务流，用于实现流量的端到端隔离和不同级别的 SLA（service level agreement）等级保障。基于前述端到端保障方案模型架构设计，PCEP架构的VLAN流量转发方案的实施流程如图1所示。

图1 基于PCEP协议的流量端到端保障方案

在R1和R8之间通过不同的子接口创建3个BGP实例，分别对应3个BGP session，不同的BGP session分发不同的前缀，并具有不同的BGP下一跳。

若要对R1和R8之间的某些关键业务进行流量端到端保障。在BGP session 1中业务流量的源IP前缀（source IP-prefix）和目的 IP前缀（destination IP-prefix）分别为P1和P8，入口设备通过 BGP可以学习到网络拓扑中基于 BGP session 1的源/目的peer的不同路径前缀P1、P8。

控制器和入口设备R1通过PCEP建立连接。控制器根据全局网络拓扑、TE policy等参数信息计算全局优化路径，形成基于BGP session 1的三元组信息（BS1_R1、BS1_R8、VLAN12），其中，BS1_R1和BS1_R8分别表示基于BGP session 1的 R1和 R8的逻辑子接口地址，VLAN12表示R1到R2路径所对应的VLAN。控制器将该三元组信息通过PCEP下发至R1，R1收到信息后返回PCRpt确认信息。

入口设备R1根据收到的三元组信息，结合之前学到的路径信息形成基于源/目的 BGP前缀的映射路由表，示例见表1。

表1 映射路径表

其中，P1前缀和P8前缀分别对应sessioni中业务流量的 source IP-prefix和 destination IP-prefix，P1前缀匹配N条源IP，P8前缀匹配M条目的 IP，因此该路由表针对 session 1共有N×M条路径组合。

当入口设备接收到数据报文后，会查找映射路由表，需要保障的报文通过映射路由表的匹配被打上VLAN12标签，送至对应BGP session 1的逻辑子接口进行转发。

对于中间设备R2、R4、R6，控制器会下发交叉路由表。交叉路由表中的条目为VLAN键值对，对于R2，条目是（VLAN12、VLAN24），当收到封装对应VLAN-ID的数据报文后，中间设备R2会将报文解封装，去掉由R1打上的VLAN12标签，打上VLAN24标签送至R4，同时R4创建对应的VLAN子接口进行转发，R4和R6的操作同理。

出口设备R8收到SDN控制器下发的交叉路由表，当R8收到R6送来的报文，通过匹配路由表得知自己是最后一跳目的地址，则不进行任何封装，直接将VLAN-ID的二层包头去掉，对报文进行三层转发。

至此，对于从R1到R8的数据报文，只有匹配到P1和P8前缀的数据业务，才能使用端到端的逻辑通道，并且该逻辑通道的路径是可由SDN控制器通过PCEP下发特定路由信息进行规划的，对于其他接口进入的数据，则依据传统的路由表进行转发，实现了在本地IP环境下，面向连接的网络通信及端到端业务保障的诉求。

以太接口的大规模部署，使得利用二层帧结构中包含的信息简化端到端数据转发成为可能。PCEP架构基于VLAN的流量转发，充分利用了二层VLAN信息，以PCEP为基础实现了流量的全场景接入，在尽可能保留 PCEP结构的同时简化了报文的端到端路径计算和转发过程，能够满足多业务流量不同路径转发需求，确保关键业务的优先级和服务质量，从而实现灵活组网以及多维度SLA路径规划。

4 结束语

本文提出的基于 PCEP的流量端到端保障方案，可针对特定客户、特定应用进行端到端业务保障，实现IP场景面向关键业务的确定性传输，相较于当前主流的MPLS和SRv6的解决方案，可以减少标签资源的占用，减轻标签转发表的维护工作量，提高转发效率，提高整个网络传输效率。借助网络云虚拟化、白盒、云原生化等核心能力落地，可实现业务的快速开通和确定性转发。本方案利用顶层控制器完成端到端的流量和业务管理，能够保证全网资源的优化调度和协同编排，有助于构建云网资源一体化管控的云网操作系统，完成云网资源的统一抽象、统一管理、统一编排、统一优化，实现云网融合大环境的网络智慧化运营，助力构建简洁、敏捷、开放、融合、安全、智能的云网生态系统。