在向电信级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还让运营商可以通过遥控来预测并对客户的需求作出实时的反应,从而进一步助力其对业务进行定制化裁取,以实现营收最大化的目的。
原文地址:http://blog.csdn.net/pmc/article/details/41478223