opendaylight框架分析说明.pptVIP

opendaylight分析

opendaylight总体架构分析模块，osgiBundle与floodlight之间的简单比照SAL层之OFPacket的处理流程Md-SAL－模型化驱动简单分析Clustering－集群

与Floodlilght的简单区别采用OSGI框架，各模块间功能隔离开来，有利于扩展性、而且可以动态部署。OSGI的依赖关系管理，有多种实现方式，可以通过DependencyManager对象来注册效劳，并通过反射注明依赖的效劳。而Floodlight只是单纯的java包之间的引用，扩展性不好，支持的南向接口少，目前只有OF1.0；但是易于上手。是一个Openflow控制器.

OpenDayLight中的bundles核心基类：ComponentactivatorabstractBase实现了Osgi提供的BundleActivator,以自己定义的容器接口iContaineraware,从中发现各个bundle之间、Componet之间、全局和容器Container之间的依赖和调用关系。bundle的抽象基类，管理全局和容器相关的效劳，当然bundle本身就是一个大效劳。Container是OpenDaylight中的一个网络域，有很多链接信息、整个域网络信息等，由ContainerManager管理容器。而OSGI管理各个bundle;每个具体的接口实现和容器的Container为关键字通过DependencyManager(依赖管理)创立一个Componet，每个Component就是一个效劳，里面说明了导出的接口和依赖的接口。DM以Component的形式来管理依赖关系。

主要方法如下：

Start(context)启动方法，会遍历其所提供的实现，依次配置依赖关系。getGlobalImplementations()获取全局的实现类，其导出接口的实现类。getImplementations()获取容器相关的实现。Configureglobalinstance(c,Imps[i])，c是前面提到的componentconfigureInstance〔〕在一个容器中配置实现的依赖关系。containerCreate(StringcontainerName)配置Componet，里面说明了导出的接口和依赖的接口，最后放到dm及缓存中。会在CM的bundle启动中调用。CreateServiceDependency()生成效劳依赖对象，需要被子类调用，在配置componet的依赖关系的时候需要用到。6

SAL效劳抽象层主要作用将效劳抽象出来，不管控制器和网络设备之间使用何种协议，提供协约国的一效劳，是odl的核心设计，支持多种南向协议，为各模块和应用提供一致的效劳，这些效劳的实现，是由插件公开(基于已存在的组件〔如OF〕和网络设备的功能〕)的所提供的接口，但是与SAL是松耦合的。具体将请求，映射到相应的插件，完成效劳。所提供效劳DataPacketServices为数据报文的处理，提供效劳TopologyService为应用提供节点和链路的更新信息，Inventoryservice为如节点或者节点连接提供API查询FlowProgrammingService流编程效劳Resourceservice资源效劳，

对于一个Packet-in的处理过程

OF中的核心，Controller南向设备通信的控制台，与Flooodlight中的Controller类功能类似，相对简化，Of报文首先到达Controller,会将此报文发送对已经注册过监听of报文的类中进行处理，其中DatapacketMuxDemux只处理packet-in报文，其会进一步处理，交由处理DiscoveryService〔处理的是LLDP〕,其后，交给实现了IpluginoutdatapacketserviceSAL层处理，最后交给实现了Ilistendatapacket监听报文的应用。这与Floodlight处理报文的过程同。

DataPacketservices举例来说报文的简单处理过程首先OF组件收到APR,需要交到ARPHandler处理，将首先根据类型，调用IPOPS到SAL,交由SAL层Sal中的datapacketservice实现了IPOPS其会通过dispacthPacket()方法，其会调用?实现IListendatapacket的应用，最后会将其送到ARPAPP处理。

TopologyService如前面所讲，报文经Controller处理后，，DiscoveryService收到报文，因为其实现了?Idatapacketlisten?,