虽然依旧能在市场上看到思科的可扩展网络控制器(XNC)，但是你可能已经注意到思科在最近的一段时间内，一直在谈论其开放SDN控制器（替代XNC）。
显然，思科拥有了基于OpenDaylight氢版本的其他控制器，XNC已经到了退出历史舞台的时刻。那么该控制器对OpenDaylight架构做了哪些根本性的改变在下面我们将谈到。
OpenDaylight的核心
思科的开放SDN控制器的变化在控制平台的服务抽象层，位于南向接口之上，如OpenFlow。这意味着隔离了应用程序所在的北向接口。这样，应用程序和网络设备端都可以与抽象层进行交互，这意味着你不需要担心是否一个应用程序知道如何与特定的设备交流。
2014年初发布了OpenDaylight的第一个版本——氢，使用了由API驱动的服务抽象层(AD-SAL)，但在思科XNC中，AD-SAL模式有其局限性，也就是它需要知道网络中设备所有的类型。如果要引入一个新的接口，必须要更新更新设备的驱动和控制器。
所以即使推出了OpenDaylight氢版本，思科仍然帮助推动另一种模式:模型驱动的服务抽象层(MD-SAL)。MD-SAL的关键是Yang模型而不是设备APIs。应用程序可以向模型请求更新，然后抽象层向网络设备转发请求。
在这个模型中，控制器不需要识别网络设备的类型。该模型还能使OpenDaylight更模块化；开发团队可以独立工作，并且整合他们的代码。
潜水艇和浴缸
为了适应MD-SAL，思科的XNC派上了用场。所有基于OpenDaylight的控制器基础设施必须调整。(AD-SAL仍可用，但MD-SAL显然OpenDaylight的未来。)
没有生产基于氢版本控制器的供应商未受影响，如博科。他们在氦版本发布以后，正好可以利用MD-SAL生产自己的控制器。
其他供应商也做了许多工作，NEC就在最近完成了虚拟租户网络的移植，以适应MD-SAL。
惠普虽然还在用它的OpenDaylight控制器，但同时，该公司已与收购的ConteXtream收录了一些基于OpenDaylight的代码。在最新的锂版本中，AD-SAL已经不建议使用了。预计在2016年的下一个版本中AD-SAL将完全消失。
MD-SAL是OpenDaylight的核心元素。它反映了你会从任何平台构建的SDN控制器中获得模块驱动的举动。这也是OpenDaylight项目合作作品的开放模式的一个例子。虽然有人人提出了反对意见，认为MD-SAL太复杂，就像使用“潜艇穿越浴缸”，但是通过激烈的辩论，MD-SAL被看作是长期的解决方案。
