作者：Liviu Pinchas, Tao Lang - PMC-Sierra
Eddie Millsopp, Dermot Flanagan - Asidua
OpenFlow定义了软件定义的网络（SDN）中的开放通信协议，从而将控制平面与转发平面分隔开来，并将控制平面集中在控制器之中，数据平面则位于网络设备之上（OpenFlow交换机），而控制平面的决策如高层路由决策等则转移至一个独立的控制器。此交换机和控制器通过OpenFlow协议来进行通信。
在OpenFlow交换机上实现的机制包括：
· 多次分类，其间将分组头域组合而成的关键字与规则集进行匹配
· 依照分类结果，收集动作规则集中的指令
· 在最后一次分类完成后，执行动作集
指令可包括：删除分组、将分组转发给控制器、转发到特定端口/队列，改变头、头进栈/出栈、转发至特定逻辑端口（链路汇聚）或组（组播、扩散）及测量。
图1 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规范之外的扩展功能，从而实现高效的故障监测和保护倒换机制。
由于故障监测和保护倒换能力需要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控制器必须要能够通知交换机来自动产生这些消息。产生分组的能力与代表工作者与保护者的小组容器实体相关。
必须创建出新的逻辑端口来对分组生成进行初始化，该逻辑端口应该具备与分组生成相关的一些特殊属性，包括：
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方向的保护倒换和故障监测
原文地址：http://blog.csdn.net/pmc/article/details/40429103
