运营商网络采用SDN所面临的挑战（二）
在向电信级SDN演进的进程中，我们需要一起来深入研究一下MPLS-TP OAM以及OpenFlow所需的新扩展功能。MPLS-TP对故障监测和保护倒换提出了明确要求，而OpenFlow目前则尚未对故障监测或出错恢复提供明确支持。
故障监测
故障监测从NNI到UNI方向进行。然后，从MPLS-TP流中抽取OAM包，重新转送至合适层级的监测实体，如区段、LSP和PW等。Y.1731提供的故障监测利用的是名为RMEP（远端MEP或者维护端点Remote
MEPs or Maintenance Endpoints）的实体。RMEP通过中断及处理远端传送的连续性检测消息（CCMs）来监测在MEP及对端MEP之间连接的“活跃性”。
OpenFlow设计中所需要的扩展功能包括：
1． OXM MATCH域需要扩展，以使OAM包中OAM特定的域的相应匹配成为可能，例如，在CFM、MA_ID、MEP
ID及MD层。
2． 需要新的ACTION类型来表示需要OAM处理。这个新的ACTION类别包括在代表RMEP的INDIRECT组的容器的ActionSet中。这一新ACTION类别专门用于所需的OAM处理；
因此，会有多个ACTION类别（如，MPLS_OAM_CCM, MPLS_OAM_DMM）。
下图描绘了故障监测功能，并且展示了实时与非实时的两种场景。实时场景中的CCM展示出如何用一个组来表示故障监测功能，该组即为相应的工作者或保护者实体的监测组。
MPLS-TP OAM 故障监测
监测包的产生
包产生是在UNI到NNI方向进行的。OAM包以特定的频率产生出来，并插入到合适的MPLS-TP通道。Y.1731要求包产生的监测必须支持3.3ms的时间间隔。很显然，采用通常的OpenFlow方法是无法实现的。故而，需要考虑对OpenFlow控制器作出改进（使之能够下指令给交换机来自动产生这些消息，并让包产生能力通过诸如状态、频率等属性与工作和保护流对应的组容器的实体相关联）。
保护倒换
由于线性保护G.8131和RFC6378中提出的保护倒换的实时性要求，保护倒换必须由交换机自动进行，而无需控制器的交互干预。因此，需要对OpenFlow协议进行扩展，以支持控制器来指定特定保护实体的保护倒换功能。线性保护（LP）堆栈需要指出交换机将会在信号出错时自动执行保护倒换（由CCM出错发出通知）。对容器的属性进行扩展，根据容器监测组中的信息，含入一个说明是否允许自动倒换的属性，即可实现上述功能。
保护倒换及故障监测（UNI到 NNI方向）
整合全部元素
MPLS-TP的例子显示出，要通过OpenFlow在运营商网络中实现SDN还存在一些非常艰巨的挑战。除了MPLS-TP
OAM, 其他一些关键性的要求，如定时与同步、流量管理等也需要对OpenFlow进行类似的扩展，才能满足运营商网络的要求。
克服这些挑战的方法是采用可编程的数据通道架构。可编程数据通道还需要软件的辅助与补充，该软件需要能满足严格的电信以太网的实时性要求，此外，还能提供所需的灵活性与使用的便捷性，以随着标准的演进而迅速地添加新的功能。
PMC的WinPath?处理器系列产品的设计初衷即是为了支持目前尚未定义完全的、未来的协议。WinPath的可编程数据通道及灵活的加速器支持的协议范围极其宽广，已经过实际使用的验证，可以随网络发展而演进。SDN也不例外。WinPath的独特设计使之特别适用于实现高效而灵活的OpenFlow交换设备。PMC在生态圈中的合作伙伴Asidua提供一套WanStaX软件栈，既能支持OpenFlow
1.3.2，也能通过CFM ITU-T Y.1731栈来支持 OAM功能。
WinPath 的技术优势及可编程数据通道不仅能满足运营商出于CAPEX和OPEX的考量而部署SDN的需要，还支持实时的业务修订以适应客户不断变化的需求。WinPath允许实时修改复杂参数以实现动态SLA，并通过OpenFlow为运营商提供了控制流量参数的能力。除了助力实现电信级功能之外，WinPath还让运营商可以通过遥控来预测并对客户的需求作出实时的反应，从而进一步助力其对业务进行定制化裁取，以实现营收最大化的目的。