可编程数据平面将OpenFlow扩展至电信级应用（一）
案例：基于WinPath网络处理器的电信极OpenFlow (CG-OF)client实现
作者：Liviu Pinchas, Tao Lang - PMC-Sierra
Eddie Millsopp, Dermot Flanagan - Asidua
1. OpenFlow
OpenFlow定义了软件定义的网络（SDN）中的开放通信协议，从而将控制平面与转发平面分隔开来，并将控制平面集中在控制器之中，数据平面则位于网络设备之上（OpenFlow交换机），而控制平面的决策如高层路由决策等则转移至一个独立的控制器。此交换机和控制器通过OpenFlow协议来进行通信。
在OpenFlow交换机上实现的机制包含：
· 多次分类，其间将分组头域组合而成的keyword与规则集进行匹配
· 按照分类结果，收集动作规则集中的指令
· 在最后一次分类完毕后，运行动作集
指令可包含：删除分组、将分组转发给控制器、转发到特定port/队列，改变头、头进栈/出栈、转发至特定逻辑port（链路汇聚）或组（组播、扩散）及測量。
图1 OpenFlow交换机的概念图
2. 从数据中心的OpenFlow 到电信级OpenFlow
因为SDN和OpenFlow承诺会减少CAPEX和OPEX，因此对运营商而言非常有吸引力。
Strategy Analytics的最新研究表明，截至2017年。软件定义的网络能够为移动运营商节省大约40亿美元的资本支出[1]。举例来说。中国移动最近发布了一项雄心勃勃的计划，拟将整个分组传送网络（PTN）升级为基于SDN的超级PTN。超级PTN的特点之中的一个是在转发平面与控制平面之间採用了OpenFlow。可是，OpenFlow标准（1.3.2）缺乏对电信级功能的支持。比方，无法用OpenFlow对PTN（MPLS-TP、QoS和同步功能）的所有功能进行映射。
要想让OpenFlow为运营商所採纳，就必须使之达到电信级标准。
这包含支持多项功能，如流量管理（包含流量管制及流量整形）、多种OAM（以太网、MPLS、BFD）、50ms之内高速又一次路由的保护倒换、定时与同步、L2/L3 VPN、用于測量的统计数据搜集及记录、可观測度及调试等等。
数据平面的灵活性在实现这一复杂的功能集时意义非凡。
以MPLS-TP为例。MPLS-TP对于故障监測和保护倒换有明白要求。尽管OpenFlow眼下对故障监測或故障恢复并没有明白的支持，FlowEntries在理论上能够构建成将故障监測的PDUs转发给控制器，使之能够基于网络中的故障作出对应决策。
因为非常多故障监測机制均依赖于对每一个监測实体毫秒级的传输及监測，该方法可能会存在严重的性能和扩展性方面的问题。
指望控制器和交换机之间的通信在这些时间关键型功能之前完毕差点儿是不可能的。
除了MPLS-TP OAM以外，更多关键性的要求。如定时和同步、流量管理、MEF规范中描写叙述的各种业务等、L2/L3 VPN、以及高速重路由均须要对OpenFlow进行相同的扩充来应对电信网络的须要。
要在OpenFlow要求的框架内支持如此丰富的电信级功能。而且可以在标准重复更新的情况下添加这些功能，可编程的数据平面架构是不可缺少。
可编程数据平面架构能带来一定的灵活度和可扩展性，在此基础之上，我们将展示。无需与控制器之间明白的互动，就可以在与OpenFlow兼容的交换机上支持所需的OpenFlow 1.3.2规范之外的扩展功能，从而实现高效的故障监測和保护倒换机制。
3. 实例：MPLS-TP OAM
因为故障监測和保护倒换能力须要OpenFlow交换机给与实时的反应。现有的OpenFlow 1.3.2规范缺少必需的协议或信息来支持MPLS-TP及OAM。比如。CFM（ITU-TY.1731）须要3.3ms的分组生成能力，而线性保护RFC6378则须要<50ms的保护倒换。
本文倡导，OpenFlow交换机中的MPLS-TP和OAM支持须要OpenFlow规范作出几个方面的扩展，并建议怎样在可编程数据通道架构上支持这些扩展功能。
3.1 故障监測
故障监測在NNI到UNI方向进行。将OAM分组从MPLS-TP流中抽取出来，再又一次发送给合适层级的监測实体。如段层、LSP和PW层等等。Y.1731的故障监測运用了一个名为RMEPs（RemoteMEPS or Maintenance Endpoints）的实体。
REMPs通过中断及处理由远端发送的连续性检測信息（CCMs）来监測MEP和其同伴MEP之间的活跃度。
要支持故障监測则须要对OpenFlow规范作出几方面的扩展：
· 首先，须要扩展OXMMATCH域。以便进行OAM分组中OAM专用域的匹配，如CFM、MA_ID、MEP ID和MD级别。
· 其次，须要一个新的ACTION类型来指示出须要进行OAM处理。这一全新ACTION类型包括在 代表链路的RMEP端点的间接组对象（INDIRECT group）的唯一容器成员（bucket）所包括的动作集合（ActionSet）。该类型对所需的OAM处理而言是特定的。因此会须要几个ACTION类型，如MPLS_OAM_CCM。MPLS_OAM_DMM等。
下图概要性地描写叙述了故障监測功能。当中展示了实时和非实时两种情况。实时情况下的CCM表明故障监測功能是怎样由一个组来代表，这个组观測着对应的运行者或保护者实体。
OAM实体将执行适当的OAM状态机，如Y.1731 CCM。来监測及上报监測组的状态。
它将会生成各类事件并上报给控制器，以便监測组作出对应的状态变更。如活跃度等。这些事件都会作为新的async信息传送给控制器。
图2 MPLS-TPOAM 故障监測
3.2 监測分组的产生
分组的产生在UNI到NNI方向进行。
OAM分组会在特定频率生成并插入恰当的MPLS-TP 通道。
Y.1731要求监測分组的生成必须支持3.3ms的时间间隔。
显而易见。运用常见的PACKET_OUT OpenFlow 方法无法实现。OpenFlow控制器必需要可以通知交换机来自己主动产生这些消息。
产生分组的能力与代表工作者与保护者的小组容器实体相关。
必须创建出新的逻辑port来对分组生成进行初始化，该逻辑port应该具备与分组生成相关的一些特殊属性。包含：
1. 使能/禁止状态
2. 频率
3. 分组模板
4. 分组种类
5. 输出行为
3.3 保护倒换
因为在G.8131和RFC 6378中说明了线性保护的保护倒换的实时性要求，保护倒换必须无需控制器的不论什么干涉而由交换机自己主动进行。
故而，须要对OpenFlow协议进行扩展来帮助控制器指明某一特定保护实体的保护倒换能力。线性保护（LP）堆栈须要标识出，该交换机在信号故障时将自己主动进行保护倒换（由CCM故障作出通知）。
实现方法为扩展容器的属性，含纳一个新的属性，以实现基于容器观察组的状态来说明是否同意自己主动切换。
此外。控制器可能希望进行手动的切换。
这一点能够通过GROUP_MOD来实现。通过改变容器的顺序，使得保护容器当前占领最高优先极。从而获取流量承载。
在UNI到NNI方向的1+1保护倒换模式中。交换机能够作为工作者与保护者路径上流量之间的桥梁。因此，控制器能够将适当保护层的GROUP配置为ALL种类。该GROUP能够提供组播行为。
在1:1保护倒换模式中，交换机仅仅能作为通往活跃路径的流量的桥梁。因此，控制器能够将适当保护层的GROUP配置为FAST_FAILOVER种类，这样就仅仅会用到活跃路径。
图3 UNI到NNI方向的保护倒换和故障监測