OpenDaylight的终端用户现在可以放心的是，OpenDaylight早起版本中的数以千计的功能支持不足的现象一去不复返了。OpenDaylight最新的版本Carbon展示了该平台的用户一直期待的成熟度和生产级质量，该版本能够显著改善安全性、稳定性和网络可编程性。
OpenDaylight Carbon版本的推动目标是提高ODL服务的稳定性和可靠性。也就是说几个项目可以使用Aries Blueprint进行定制配置子系统的服务激活，这一工作从Boron版本中开始，在Carbon版本中得到了改进。Blueprint在该版本中更容易记录和调试，从而产生更有效且令人满意的应用程序开发试验。由于Blueprint支持并行服务激活，启动控制器和提供服务之间的延迟较少，应用程序配置与代码布线分开，因此可升级性得到改善。这是非常重要的，因为大多数升级OpenDaylight的运营商希望能够在不同版本之间保持配置，且接收内部布线更改。
为每个项目添加Apache Karaf 4.X功能是希望在OpenDaylight下一个版本Nitrogen版本中使用新的容器，此外Carbon版本还增强了测试功能，以确保功能导入所有适当的运行时包，从而提高ODL功能的稳定性。这一基础有助于社区的开发者在Nitrogen版本开发周期中执行Karaf升级。
Yang 1.0数据建模语言的RFC 6020已经被新的Yang 1.1数据建模语言RFC 7950所取代，对于应用程序开发人员来说，这意味着他们现在可以在Yang模型中使用Yang 1.1结构。此外，使用RFC 7950的南向Netconf设备的互操作性在Carbon版本中成为可能。
NETCONF集群实现通过集群单例服务进行重新架构变得更加稳定，并大大提高了测试覆盖率。最终用户可以实现与Boron版本一致的NETCONG集群体验，但是在分布式控制器部署中可以更放心地使用NETCONF。
尽管目前还没有任何消费应用程序，但是Carbon版本中包含了MD-SAL Binding Specification version 2的前瞻性版本，新版本的绑定规范解决了初始版本中发现的几个问题。该版本是基于Twirl实现，具有与V1版本规范中xtend相似的功能，但是是以Scala而不是Java生成代码。生成的Scala代码被注入到Java运行环境中，并且可以被传统的Jaca客户端访问。
Carbon版本包含最新的标准化的RFC 8040，RESTCONF的实现。到目前为止，OpenDaylight用户可能最熟悉与RESTCONF Draft 02 API进行交互，Draft 02 API仍然在OpenDaylight中很好的兼容，因为很多软件仍然依赖该API实现。新的RFC 8040RESTCONF API通过单独的端点提供，OpenDaylight鼓励用户开始探索并使用标准版本的API，因为社区支持DRAFT 02版本的时间具有很大的不确定性。
此外，通过在AAA项目中添加基于模型的授权模式，可以提高RESTCONF的安全性。运营商现在可以在运行时将URL端点集合动态限制为特定类别的用户，这种加强的授权机制适用于两种RESTCONF版本。AAA贡献者还增加了对基于模型的证书管理的支持，虽然证书管理功能目前旨在Carbon版本中与OVSDB相集成，但计划在未来提供与其他南向协议的集成。
在NETCONF项目中添加了基于IETF Call Home的Draft 08初始实现，该实现目前不是集群感知，而是提供呼叫归属功能的基本功能。总体而言，这改善了OpenDaylight的集成点，并增强了运营人员将ODL自动化的能力。
Carbon新增的一个项目是Daexim，该项目支持以JSON格式导入和导出MD-SAL数据存储区的数据。Daexim在指定版本之间不能支持Yang数据模型的更改，开发人员可以编写外部裸机来操纵导入导出的数据，从而为ODL版本之间的升级提供便利。
此外，Carbon还包括 jsonrpc的首个具体化应用，该项目旨在加强与控制者的外部沟通和联合。jsonrpc为ZMQ公开了一个经过良好测试的版本。相比较于RESTCONF、NETCONF或其他一些北向接口，应用程序开发人员可以挂接总线来操纵数据，实际上这解锁了使用支持ZMQ集成的非JRE语言编写控制器应用程序的功能，从这个角度来说，它开创了一套全新的开发人员参与项目的能力。
总体而言，Carbon提供更高的稳定性，安全性和增强的网络可编程性。这些基础工作将能够促进在下一个版本Nitrogen中实现Karaf升级，服务激活大大稳定且能够更好地进行测试，以确保更加一致和友好的运营经验。增加的新功能能够帮助与控制器进行通信、导出数据，并且能够更好地配置ODL。
微信ID：SDNLAB
长按左侧二维码关注
