《云数据中心网络与SDN：技术架构与实现》——2.3.3　RIB可编程

2.3.3　RIB可编程

RIB可编程就是通过对路由表或者其他路由相关信息进行控制，从而间接控制转发。FIB可编程主要面向OpenFlow交换机，RIB可编程则是传统路由器向SDN演化的常见路线。相比于FIB可编程，RIB的演进思路要平滑一些，在大网上具备广泛的部署基础，目前普遍为厂商和运营商所接受。

1. BGP

传统路由中，BGP是绕不开的话题，Internet的成功很大程度上要归功于BGP，几乎所有的路由器都可以提供对BGP的支持。BGP如何与SDN相联系的？首先，IBGP中天然地存在RR这种集中式的角色，域内所有BGP路由器都和RR建立IBGP邻居，然后这些路由器把自己知道的路由告诉给RR，再由RR反射给其他路由器。传统网络中，RR都是部署在硬件的路由器上的。如果把RR的代码移植到SDN控制器上，那么控制器就有了收集BGP路由的能力。如果再把控制器上的RR模块开放一些接口，使得它在反射前可以通过一些安全策略对反射路由进行过滤，或者通过一些算法来优化反射的路由，比如改写下一跳、改变Local Preference等，那么就可以实现集中式的智能选路了，这通常被称为RR+。

将RR引入SDN控制器还可以实现OpenFlow或者其他SDN网络与传统IP网络的互通，控制器一方面通过OpenFlow收集OpenFlow域的状态并为其生成路由信息，一方面通过IBGP收集IP域的路由信息，由控制器作为控制平面的网关将OpenFlow和BGP进行转化，就可以互通OpenFlow和IP网络的路由信息了。除了通过IBGP进行对接的方式，控制器还可以通过将EBGP消息在特定的OpenFlow端口进行PacketIn和PacketOut，通过OpenFlow交换机来中继EBGP与传统路由器来建立邻居，可以打通物理邻接的OpenFlow网络和IP网络。

BGP是网络领域的老江湖了，经过30多年的发展，无论是在性能还是可扩展性、可用性上都已经为业界所广泛认可，因此在看到BGP与SDN的结合点后，业界有很多声音都在呼吁用BGP取代OpenFlow。虽然有一定的道理，但是要辩证地去看待这个问题。首先，BGP与SDN控制器的集成面临着非常现实的问题。成熟的BGP代码都掌握在厂商的手里，他们是否愿意把自己的BGP集成到控制器里面去就是一个问题。而且厂商的BGP实现基本上都是基于C语言开发的，而目前主流的SDN控制器都是基于Python/Java的。如果直接重写，工作量太大，而且由于语言上的效率问题，使用Python/Java来实现BGP，尤其是RR，性能上要有很大的折损。如果直接集成，多语言的混合编程很可能引入新的性能瓶颈，未必能够达到预期的效果。比较现实的做法，是把BGP独立地跑在控制器外面，通过API来进行交互，这样的话数据库也是两套，是一种双引擎的做法。

其次，传统的BGP是专门为路由设计的，对其他网络功能并没有过多考虑。MP-BGP为BGP提供了良好的可扩展性，基于NLRI可以扩充很多的功能，如BGP-LS用于拓扑发现，BGP-LU用于分配MPLS标签，BGP-FS用于安全与策略，以及各种各样BGP-Based的VPN。但是这些BGP的扩展尚未成熟，支持的厂家互通性不够理想，而且限于路由的大框架，其灵活性上也很难有本质上的提升。另外，单纯从选路上来说，BGP主要面向的是面向分组的、无连接的路由场景，对基于流的、有连接特性的路由场景难以提供有效的支持。因此，OpenFlow既没有能力消灭BGP，BGP也没办法完全代替OpenFlow。

2. PCEP

PCEP是另外一种提供RIB可编程能力的协议。和BGP不同，PCEP主要面向的是MPLS域。在传统的MPLS网络中主要有两类场景：一类基本的场景是基于IGP中SPF的计算结果来构建起一条最小cost的标签路径；另一类高级些的场景是基于扩展IGP中CSPF的计算结果来构建起一条满足复杂路径约束的标签路径。SPF和CSPF虽然都是集中式的路由算法，但是各个路由器仍然是独立进行计算的，这可能会产生出现诸多的问题，导致全局最优的无法实现。PCEP的思想很简单，就是在网络中部署一个集中式的角色PCE，由PCE根据全局的视图来计算最优的路径信息，然后通过PCEP把计算的路由结果返回给PCC，由PCC再部署这条路径。也就是说，PCEP更适合做路径的端到端优化，而相比之下BGP只能控下一跳，适合做局部的拥塞缓解。

可以看到，PCEP对网络进行集中式控制的思想和SDN是不谋而合的，但是要清楚，PCEP不是专门为了SDN而设计的。PCEP对PCC和PCE的形态没有进行要求，PCC通常为路由器中的Agent，而PCE既可以部署到网管中，可以部署到OSS中，也可以部署到路由器中。很容易想到，如果将PCE实现在SDN控制器中，再开放出一些选路策略的接口，就能够将SDN可编程的能力引入MPLS网络中了。PCEP本质上就是一种新的RIB控制逻辑，对硬件本身没有新的要求，因此PCEP可以无缝地升级到路由器中。而且以PCEP的工作模式，只要全局视图能够收集上来，算光层的路径也没有任何问题。因此，PCEP目前被广泛地认为是大网向智能调度、甚至IP+光协同的支撑性技术。

不过，PCEP仅仅是一种PCC和PCE间交互转发路径的通道，至于路径是怎么算出来的并不在PCEP的范围内。计算路径要依赖的全局视图，PCPE只能收集路径状态，拓扑要靠BGP-LS，TED要靠OSPF-TE/ISIS-TE，设备和流量状态要靠SNMP/NetFlow。组网上，PCEP一般也只和路径起点的Ingress Router相连，端到端路径的开通还是要靠IGP/LDP/RSVP/BGP-LU这些来分发标签。不过，PCEP中的OBJECT和BGP中的NLRI一样，也具备很强的可扩展性，因此PCEP在IETF的工作组也在提各种各样的PCEP扩展，希望能够在PCEP中原生地支持上述协议的一些功能。不过这些扩展离成熟还差得比较远，目前来看，想拥有一套完整的PCEP调度方案，还是需要配套好多协议的。

PCEP做路径计算确实是很不错的，但是OpenFlow控制器也可以做状态收集，复杂路径的计算，现在对光层的支持也在日渐完善，那么PCEP的调度方案和OpenFlow的调度方案有什么不同呢？功能上，PCEP想做的事情少，可以把路径计算这件事做得更好，这是没错的，后面提出来的Stateful PCEP能够支持维护路径的状态。不过前面说了，想做的事情少意味着PCEP要配合其他的协议来做解决方案，多个协议要良好地配合在一起，增加的开发与维护成本又有多少呢？性能、扩展性、可用性上，如果说BGP的优势在于实现已经趋于成熟，那么PCEP的第一个RFC也是2009年才成稿的，协议本身相比于OpenFlow又能成熟到哪里去呢？目前，还没有一家厂商敢说PCEP可以在运营商现网落地带业务了。

上面对BGP、PCEP发了几句牢骚，并不是说OpenFlow就有多好，而是想说请多给OpenFlow一些耐心。到底是FIB可编程好，还是RIB可编程好？要笔者来说，BGP现网上很成熟，但想在SDN里面用好还要下很大的工夫，PCEP做转发控制更专业，但场景也相对受限，OpenFlow更灵活，但想上规模需要花精力去填坑。抛开场景和技术条件来谈哪个协议好哪个协议不好，是没有任何意义的。没有最好的，只有最合适的。