博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SDN第四次作业
阅读量:5094 次
发布时间:2019-06-13

本文共 1436 字,大约阅读时间需要 4 分钟。

1.阅读

了解ryu控制器

了解onos控制器
了解opendaylight控制器

2.书写博客

文献阅读时,注意比较各个控制器之间的实现技术异同。书写一篇博客,博客内容为,简单表述控制器的架构技术。

首先,先描述各个控制器的概念。

ONOS(Open Network Operating System)

顾名思义就是要定义一个开发的网络操作系统,其核心的服务对象是服务提供商(运营商就是其中的大头)。服务对象是运营商,重点考虑可靠性、性能,并在白盒系统上创建高性能可编程的运营商网络。

ONOS拥有良好的可扩展性、可靠性,除此之外,他们的性能良好能用于商业化产品。具备一个完整的SDN控制器平台所需的性能特征,是一个一体化的网络操作系统。

OpenDaylight

是由设备商主导的一个开源控制器,采用折中的方案,即以开放专用接口的方式保留传统设备,采取以退为进的方式维护自己的利益,设备商拥有丰富的设备研发经验, OpenDaylight是SDN开源控制器框架,以协作方式,模型驱动架构,更易于SDN的开放和创新。

Ryu控制器

用了开放型的转换器,客户可以设置他们的网络,通过某一种网络接口几乎在瞬时间Ryu就可以获得认可,并且可以实现自如的转换,所以开放源、开放流式的设置,尤其适用于Ryu。

ONOS架构概述:

1287333-20171217204001874-1736035121.png

以下是ONOS与OpenDaylight的异同点。

从结构层次上仿佛大同小异,都包含:北向接口、核心层、服务抽象、南向接口协议

如上一小节讲到的,ODL和ONOS的起源以及服务的对象不同,也使二者在架构设计细节上有比较大的差异。
ODL有丰富的南向接口:OpenFlow、NETCONF、OVSDB、BGP、PCEP……,就是将设备端目前实现的并且能抽象成设备北向接口的协议尽可能多地暴露出来,从外部看ODL支持丰富的南向接口功能强大(也确实强大),但是变相地提升了控制器设计的复杂度,也增加了控制器与不同网络设备对接的难度。换言之,接口协议定义越丰富,也就意味着控制器和网络设备的“种类”就越多,相互之间的兼容性、互通性问题就越复杂,控制器和网络设备之间的捆绑性就越强。
•ODL通过MD-SAL(模型驱动的服务抽象层,各位看官可先忽略其具体内容,以后的文章将对该层的工作原理做详细介绍)将南向接口与其核心层互联起来,由于模型本身具有厂商自定义属性(ODL中并没有严格限定,允许各开发者定义自己的YANG模型),不同南向协议之间相同的功能都可以抽象成不同的模型,这也使得在ODL上各个设备产商可以根据当前自有设备的具体实现,将功能抽象成有局部差异的模型,甚至可以抽象出“产商特色”的模型,也就意味着集成一个特定的网络设备功能到ODL上还是非常便利的。
而ONOS服务于服务提供商,注重的是可靠性和性能,这两点也体现在其轻量化的设计中(特别还沿用AD-SAL(API驱动的服务抽象层,该模式曾在ODL氢版使用过,后续的ODL版本里被MD-SAL替代)的方式,整体设计比ODL要简单):
•可靠性方面,ONOS采用的集群技术基于Hazelcast开源分布式内存数据库,Hazelcast是一个高度可扩展的数据分发和集群平台,可用于实现分布式数据存储、数据缓存。ONOS提供许多常见的分布式原型,开发人员利用现有服务,很方便就能构建分布式业务。

转载于:https://www.cnblogs.com/dark-Earl/p/8053209.html

你可能感兴趣的文章
树形dp
查看>>
git学习
查看>>
基于JavaBean,JSP实现登录并显示分页信息的小系
查看>>
QT5.3 杂记(转)
查看>>
如何跟开发就测试范围进行沟通?
查看>>
js模板引擎-art-template常用总结
查看>>
jQuery中的模拟操作
查看>>
红黑树的删除压力测试和完整性检查
查看>>
Ajax 分页
查看>>
关于GreenOdoo的一个Bug
查看>>
有网络信号,但输入密码却无法连接的解决方法
查看>>
自己写的DBHelper感慨颇深
查看>>
DeferredResult使用方式和场景
查看>>
WIN XP 添加删除WINDOWS组件时,指定的系统光盘路径
查看>>
email 正则
查看>>
GIS简单计算Helper类
查看>>
PHP 把返回的数据集转换成Tree树
查看>>
布隆过滤器
查看>>
Spring 3.x MVC 入门2 -- 通过示例初步感受spring mvc
查看>>
Unique Paths 解答
查看>>