一、ODL的诞生背景
随着互联网的普及，用户数量不断攀升，网络不堪重负。移动终端发展势如破竹，智能手机不断更新换代，各种手机软件层出不穷，手机控随时随地上网，导致流量需求与日俱增，负荷过度的网络无法满足用户需求。网络体系庞大，架构臃肿，不够灵活，不能适应不断涌现出的新业务需求，服务质量得不到保证。网络体系复杂，网络操作需要与其他IT操作的集成与协作，导致网络部署困难。网络更新麻烦，动手操作过多，网络管理员分身乏术。改良已经无法解决现有的网络问题，网络改革势在必行，于是SDN应运而生。
SDN是美国斯坦福大学clean slate研究组提出的一种新型网络架构。传统网络采用分布式策略工作，由设备制定转发策略，而SDN架构中设备不运行任何协议，转发表由控制器下发给设备，实现数据平台与控制平台的分离。SDN的核心思想就是控制与转发分离，将软件应用到网络控制中，并起到主导作用，而不是由固定模式的协议控制网络。SDN的目的是提高网络的可控性与可编程性，可以根据用户需求灵活地提供不同质量等级的服务。
二、ODL诞生的利益分析
SDN的提出立刻就在业界引起了轩然大波，尤其是一直被网络设备商压制的网络用户，将其视为摆脱网络设备商牵制，翻身做主人的机会，于是2011年一个以网络用户为主导的非营利性组织ONF就此诞生了。ONF宗旨是制定SDN统一标准，推动SDN产业化。ONF的工作重点是制定唯一的南向接口标准openflow，制定硬件行为转发标准，并且推出了一系列openflow 协议，其中较为稳定的是openflow1.0和openflow1.3版本。ONF从用户的角度制定协议，必然可以维护用户的利益，但是其间也出一些问题。
网络设备的研发十分复杂，是一个系统化工程，需要结合方方面面考虑，需要丰富的实战经验，而这些正是网络用户所缺乏的，因此直接导致openflow协议过于理想化，只能在实验及简单网络环境中应用，无法实现大规模商用。这种情况下ONF不得不接受网络设备商的参与，2013以设备商和软件商为主导的另一SDN组织ODL腾空出世，网络设备商出于自身利益出发，也加入到SDN大军中。并不是网络设备商都不计较利益，不计得失地贡献自己的技术，设备商也有自己的考量，越来越多的人看好SDN，这是一股不可逆转的趋势，与其坐等网络用户摆脱自己，不如化被动为主动积极参与其中，众多设备商联手研发出统一的控制框架，其中可以嵌入一些服务与应用模块，各大设备商都争相在大框架中融入更多的自己的技术，因为贡献越多意味着影响越大，在ODL中争得一席之地，才能为以后的发展留下生机。换句话说，置之死地而后生，贡献出自己的核心技术，这些技术随着SDN的推广被推向世界，说不定柳暗花明又一村呢！无论各自的目的是什么，ODL与ONF有共同的目的，推动SDN和网络功能虚拟化发展，打造统一开放的SDN平台，推动SDN产业化。
由此看来，ODL是SDN大环境下的必然产物，不仅仅得到网络用户的认可，还受到网络设备商的鼎力支持，注定在SDN发展中脱颖而出，成为SDN的灵魂产物之一。
三、ODL开源社区
ODL是由Linux基金会推出的一个开源项目，集聚了行业中领先的供应商和Linux基金会的一些成员。其目的在于通过开源的方式创建共同的供应商支持框架，不依赖于某一个供应商，竭力创造一个供应商中立的开放环境，每个人都可以贡献自己的力量，从而不断推动SDN的部署和创新。打造一个共同开放的SDN平台，在这个平台上进行SDN普及与创新，供开发者来利用、贡献和构建商业产品及技术。ODL的终极目标是建立一套标准化软件，帮助用户以此为基础开发出具有附加值的应用程序。
为了促进SDN发展，让更多的人认可SDN思想，开源社区开发者、开源代码、以及项目管理者组成了ODL开源社区，无论是有进取心的IT人士，网络服务供应商还是云服务供应商都可以加入ODL社区，ODL社区采用开放的管理模式，无论什么人都可以贡献代码，参选加入技术指导委员会，以多种途径参与项目方向走势讨论。
社区领导层主要包括董事会和TSC，董事会和TSC在不违反社区规章制度的条件下有权逐渐改变管理方式。董事会负责项目管理、运行以及市场相关决策。TSC主要负责项目选择、技术决定，保证项目透明度，以及项目生命周期管理。ODL厂商成员分别分为铂金成员、黄金成员、白银成员，会员等级越高会费也就越高。其中铂金会员有Brocade、Cisco、Citrix、Dell、Ericsson、HPE、Intel、Red Hat，黄金会员有NEC，白银会员有6WIND、A10networks、ADVA、Arista Networks等。下图罗列出了会员的图标：
四、ODL社区管理
大型社区通常有两类管理模式：业务管理和技术管理，ODL也不例外，其技术指导包含技术指导委员会和主要组件的项目管理者，而业务领导实例化为董事会。
OpenDaylight社区通过“技术指导委员会章程”规定两者的职责和权限，董事会主要负责设定ODL的策略方向（包括ODL的范围、技术愿景、方向），并对TSC提出的项目发布计划进行指导。而TSC则在董事会设定的策略方向内提供技术指导，制定发布规划、确立发布质量标准、挑选最佳的开发程序、监控技术进程，如果提交者和项目负责人之间出现技术冲突，TSC还需要负责调停。不仅如此，TSC还是ODL与其他联盟和组织之间的接口人。
任何组织和个人都有可能成为TSC成员。TSC最初有白金会员分别指定一个代表组成，TSC组织成立后，将会通过投票的方式将一些活跃的代码提交者选举为TSC成员。为了保证ODL的公平性和中立性，任何厂商都不可以控制投票权，如果发现与白金会员有关的非指定TSC成员（新选举出的TSC成员），该白金会员指定的TSC会员代表必须马上辞职。对于TSC成员（包括主席）的选举办法，董事会每年都会重新评估。
ODL包括多个小项目，每个项目的运营都离不开以下几类角色：贡献者（Contributor）、提交者（committer）和项目管理者（project leader）
贡献者负责开发代码或贡献其他成果，通过贡献高质量修补程序和功能优化代码有可能被选举为提交者。提交者负责控制技术方向，决定项目的设计、代码和修补等，具有将代码提交到源代码管理系统的权限，但其权限仅限项目本身，一个项目的提交者通常没有其他项目的提交权限。项目管理者负责制定项目的整体方向并向TSC汇报，项目管理者通常从提交者中通过投票的方式选出。五、ODL社区运营模式
ODL社区的运行模式自主、开放，奉行协作原则，只要你有能力就能参与其中。这是一个开源组织，并不是只有会员才能使用里面的代码，每个人都可以使用ODL的代码，为它做出贡献。这种运行方式激励了更多人参与ODL代码编写，ODL为大家合作、探究、讨论提供了良好的平台。虽然代码本身非常重要，但人们创建这些代码的方式、彼此协作的途径以及代码部署的操作机制同样不容忽视。
ODL的项目并不是一成不变的，而是不断地提出新项目，待项目成熟后即可加入ODL核心项目。项目提出后进入生命周期，做出相对应的模型，解释每个部分实现什么功能，根据模型写代码，用这种方式将项目模块化，大家协同合作，查缺补漏。每个项目需要包括贡献者、社区成员以及一个共同推选出的项目负责人，规定项目负责人是ODL项目的创始成员，这些最熟悉源代码的专家可以给其他项目参与者更好的引导。一个新项目不仅仅需要资深成员，还需要新成员的加入，资深成员需要在项目启动三个月内选拔新成员参与项目，项目才能获得TSC的批准。采取这种方式不但鼓励新成员更加深入地参与进社区项目，同时为社区注入源源不断的新生力量。核心项目的负责人不仅是项目的领导者，也是TSC的组成成员，在TSC中代表自己的项目团队。
ODL董事会与TSC都采用投票制度，无论什么等级的成员最多只有投一票的权利，并且在董事会中任何一个供应商都不可以掌握控制性投票权，没有一家公司可以拥有2个及以上的董事会席位。公开、透明、开放的运行模式保证ODL项目一直沿着SDN的方向发展，而不是取决于某个供应商。
SDN成为网络改革的焦点。与此同时，ODL开源社区愈加受到行业内人士的青睐，ODL集聚了最好的文化资源和最好的人力资源，为社区获得可持续优势提供了有利条件。ODL社区以开源形式推出ODL控制器，具有风险低、产品透明、行业适应能力强等特点，人们可以根据自己的意愿决定是否配置这个框架，以此减小接受新技术的风险，同时，人们可以利用已有的基础设备，实现新的SDN功能。ODL社区的开放性促进了SDN的广泛传播，让更多的人有机会接触到SDN，见证SDN的发展。
六、ODL控制器
ODL拥有一套模块化、可插拔灵活地控制平台作为核心，这个控制平台基于Java开发，理论上可以运行在任何支持Java的平台上，从Helium版本开始其官方文档推荐的最佳运行环境是最新的Linux（Ubuntu 12.04+）及JVM1.7+。
ODL控制器采用OSGi框架，OSGi框架是面向Java的动态模型系统，它实现了一个优雅、完整和动态的组件模型，应用程序（Bundle）无需重新引导可以被远程安装、启动、升级和卸载，通过OSGi捆绑可以灵活地加载代码与功能，实现功能隔离，解决了功能模块可扩展问题，同时方便功能模块的加载与协同工作。自Helium版本开始使用Karaf架构，作为轻量级的OSGi架构，相较于早前版本的OSGi提升了交互体验和效率，当然其特性远不仅仅于此。
ODL控制平台引入了SAL（服务抽象层 ），SAL北向连接功能模块，以插件的形式为之提供底层设备服务，南向连接多种协议，屏蔽不同协议的差异性，为上层功能模块提供一致性服务，使得上层模块与下层模块之间的调用相互隔离。SAL可自动适配底层不同设备，使开发者专注于业务应用的开发。
此外，ODL从Helium开始也逐渐完成了从AD-SAL（Application Driven Service Abstraction Layer）向MD-SAL（Model Driven Service Abstraction Layer）的演进工作，早前的AD-SAL，ODL控制平台采用了Infinispan技术，In nispan是一个高扩展性、高可靠性、键值存储的分布式数据网格平台，选用Infinispan来实现数据的存储、查找及监听，用开源网格平台实现controller的集群。MD-SAL架构中采用Akka实现分布式messageing。
七、ODL控制器设计原则
ODL在设计的时候遵循了六个基本的架构原则（以下来自opendaylight官方文档）：
1、运行时模块化和扩展化（Runtime Modularity and Extensibility）：支持在控制器运行时进行服务的安装、删除和更新。
2、多协议的南向支持（Multiprotocol Southbound）：南向支持多种协议。
3、服务抽象层（Service Abstraction Layer）：南向多种协议对上提供统一的北向服务接口。Hydrogen中全线采用AD-SAL，Helium版本AD-SAL和MD-SAL共存，Lithium和Beryllium中已基本使用MD-SAL架构。
4、开放的可扩展北向API（Open Extensible Northbound API）：提供可扩展的应用API，通过REST或者函数调用方式。两者提供的功能要一致。
5、支持多租户、切片（Support for Multitenancy/Slicing）：允许网络在逻辑上（或物理上）划分成不同的切片或租户。控制器的部分功能和模块可以管理指定切片。控制器根据所管理的分片来呈现不同的控制观测面。
6、一致性聚合（Consistent Clustering）：提供细粒度复制的聚合和确保网络一致性的横向扩展（scale-out）。
八、ODL控制器架构
如图1.2所示，ODL控制器主要包括开放的北向API，控制器平面，以及南向接口和协议插件。北向API有OSGI和REST两类，同一地址空间应用使用OSGI类，而不同地址空间的应用则使用REST类。OSGI是有状态的连接，有注册机制，而rest是无状态链接。上层应用程序利用这些北向API获得网络智能信息、运行算法进行分析并且设计部署新的网络策略。
控制器平台包括一系列功能模块，可动态组合提供不同服务。其中主要包括拓扑管理、转发管理、主机监测、交换机管理等模块。服务抽象层SAL是控制器模块化的核心，自动适配底层不同的设备，使开发者专注于业务应用的开发。SAL北向连接功能模块，以插件的形式为之提供底层设备服务。南向连接多种协议插件，屏蔽不同协议的差异性，为北向功能模块提供一致性服务，SAL起到中间调度作用。
南向接口支持多种不同协议，如openflow1.0、openflow1.3、BEG-LS等。底层支持混合模式交换机和经典openflow交换机。
九、ODL的发展
ODL成立不到一年就推出了首个开源版本氢（hydrogen），氢计划中有多个项目，大概有五、六个项目里程碑，发布了基本版，虚拟化版和服务提供商版。基本版有一个标准的控制平台，包括Open Flow的设备，插件覆盖范围很广，有一些可选的设备可以加入进去，可以做交换机的管理，还有其他的功能都能够覆盖到。
虚拟化版增加了一些服务，主要运用了虚拟化技术，主要添加了VTN和open DOVE的相关模块。最大化利用物理设备资源的同时，提高服务人性化程度，用户可以部署自己的虚拟网络而无需了解底层复杂的物理拓扑。
服务提供商版在基本的版本上面增加了一些功能，增加了SNMP、PCEP的协议，在控制器平台里面还加入了一些其他的功能。
2014年9月29日发布了Helium版本，这里面不再需要三层代理，而是OpenDaylight处理三层的路由功能，Lithium版本在2015年发行，2016年2月也发布了Be版本的OpenDaylight。
本文转自d1net（转载）