码迷,mamicode.com
首页 > 其他好文 > 详细

SDN第四次作业

时间:2017-12-19 12:33:59      阅读:109      评论:0      收藏:0      [点我收藏+]

标签:相互   简单   col   str   添加   框架   设备   class   需要   

简单表述控制器的架构技术

作业链接

  • RYU控制器

在RYU控制器架构中,包括:Non-OF protocols、OF protocols、各种libraries以及内嵌的APP,同时,RYU控制器提供给用户统一的RESTAPI,供用户基于RYU框架开发自己的APP,同时,开发者可以根据自己的需要。添加所需的组件和库文件。值得注意的是,RYU架构只是提供给开发者一个平台,相当于一个没有应用软件的操作系统,开发者想基于这个框架实现自己想要的功能,就必须通过RYU提供的API编写相应功能的APP,这些APP就相当于我们操作系统的应用软件

  • ONOS控制器

ONOS服务于服务提供商,注重的是可靠性和性能,这两点也体现在其轻量化的设计中(特别还沿用AD-SAL(API驱动的服务抽象层,该模式曾在ODL氢版使用过,后续的ODL版本里被MD-SAL替代)的方式,整体设计比ODL要简单)

  • ODL控制器

ODL有丰富的南向接口:OpenFlow、NETCONF、OVSDB、BGP、PCEP……,说白了就是将设备端目前实现的并且能抽象成设备北向接口的协议尽可能多地暴露出来,从外部看ODL支持丰富的南向接口功能强大(也确实强大),但是变相地提升了控制器设计的复杂度,也增加了控制器与不同网络设备对接的难度。换言之,接口协议定义越丰富,也就意味着控制器和网络设备的“种类”就越多,相互之间的兼容性、互通性问题就越复杂,控制器和网络设备之间的捆绑性就越强。
ODL通过MD-SAL将南向接口与其核心层互联起来,由于模型本身具有厂商自定义属性(ODL中并没有严格限定,允许各开发者定义自己的YANG模型),不同南向协议之间相同的功能都可以抽象成不同的模型,这也使得在ODL上各个设备产商可以根据当前自有设备的具体实现,将功能抽象成有局部差异的模型,甚至可以抽象出“产商特色”的模型,也就意味着集成一个特定的网络设备功能到ODL上还是非常便利的。

SDN第四次作业

标签:相互   简单   col   str   添加   框架   设备   class   需要   

原文地址:http://www.cnblogs.com/DarlingT/p/8064634.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!