MDSAL和ADSAL的区别?

已邀请:

胖欧巴 - 在SDN的路上渐行渐远

赞同来自: 君子一诺 linxi1027


首先解释一下SAL,Service Abstraction Layer,隶属于ODL Controller Platform。由运行在OSGi Framework上的Bundle实现,在ODL Controller Platform和Protocol Plugin之间实现抽象层的功能。是ODL Controller Platform的最核心模块之一,控制模块间的数据交互,数据存储读取,API调用。AD-SAL(API-Driven SAL)和MD-SAL(Model-Driven SAL)就是其两种体现形式。(注:在Helium中,使用AD-SAL的模块和MD-SAL模块的应用都存在于下一版的Lithium版本中,基本大部分使用AD-SAL的应用都会移植到MD-SAL中)
下面对两个模块进行一下介绍
AD-SAL
功能:定义抽象服务,吸收南向协议的差异,提供统一的抽象服务和API,并提供相应的Request Routing。
北向的Plugin可以通过调用AD-SAL提供的北向API来实现对南向Plugin的调用,操作其管理的设备和服务。在AD-SAL中,抽象服务由南向和北向API实现,南北向API是一对一的映射关系。这种架构比较好理解,也很常用。

AD-SAL.png


MD-SAL
功能:提供Request Routing和用来定义抽象服务和相应API的基础框架
需要强调的是,抽象服务和相应API严格的说是由各个Plugin通过yang model和service来定义,而不是由MD-SAL定义。这里会引出Yang Tools Plugin这样一个神器,他通过各个Plugin的m 用这些Sevice Interface实现具体的API和服务内容。Plugin通过MD-SAL和生成的API(RPC,Notification)、DataStore去利用其他各个Plugin的服务和数据。其实在这个架构中,所有功能模块的信息交互、数据存储调用都是通过MD-SAL来完成。简单的解释MD-SAL的主要功能就是管理基于Yang Model定义的各种Plugin。下图可以把整个过程直观的介绍清楚。

MD-SAL.png


二者相比较,在AD-SAL中,南北向API是1:1的对应关系,同一API无法被复用。所有南北向Plugin的功能都需要定义相应的AD-SAL API来承载,造成AD-SAL模块会更加庞大、实现更为复杂、维护困难性增加。而MD-SAL加入了自动化的思路,从架构上避免了很多问题,不过也增加了学习成本。
之前看了QQ群地球某某老师的教程,对二者有了更为深入的理解,这个回答很多都是参考的教程内容,如有错误,欢迎交流。

要回复问题请先登录注册