OpenStack 网络项目（Neutron）的历史、现状与未来

转载请注明：

http://yeasy.blogspot.com/2014/12/openstack-neutron.html

历史

OpenStack 作为最热门的云计算开源项目，自 2010 年 10 月发布第一个版本 Austin 以来，到 2014 年 10 月 发布 Juno 版本，已经经历了 10 个主要版本。基本稳定为每年 4 月和 10 月各发布一次大的版本更新。

网络功能实现是自第二个版本，即 Bexar 版本引入，最初作为 Nova 项目的一个功能 Nova-Network，仅支持所有用户共享一个底层网络（即所谓的 Flat 网络），后面自 2012 年 9 月发布的 Folsom 版本开始，将网络功能剥离出来，作为一个新的 Quantum 项目。2013 年 10 月发布的 Havana 版本中，项目改名为 Neutron。最新的 2014 年 10 月发布的 Juno 版本中，更引入了分布式路由（DVR）机制，并停止对于 Nova-Network 的支持。

各个关键版本的更新情况如下：

• Bexar 版本：
  • 引入 Nova-Network
• Cactus 版本：
  • IPv6 支持
• Diablo 版本：
  • FlatDHCP 网络下的 HA
• Essex 版本：
  • 网络功能数据模型开始从 Nova 中剥离，为独立项目做准备
• Folsom 版本：
  • 正式从 Nova 中剥离，成为新的独立项目 Quantum
  • 多租户隔离的支持
  • 插件式结构支持多种网络后端技术，包括 Open vSwitch、Cisco、Linux Bridge、Nicira NVP、Ryu、NEC
  • 支持 IP 地址的 Overlapping
  • 支持 provider networks
  • 支持基本的 L3 转发、SNAT、Floating IP
• Grizzly 版本：
  • 多网络节点支持，提高可靠性
  • 安全组
  • 支持 LBaaS
• Havana 版本：
  • 项目名称从 Quantum 改名为 Neutron
  • 多种物理网络（Linux Bridge，Hyper-V，OVS）类型同时支持
  • 引入 Fwaas、VPNaas
  • 引入 ML2 支持多种类型二层网络实现
• IceHouse 版本：
  • 一些新的插件
  • 新的 LBaaS 驱动
• Juno 版本：
  • 初步支持分布式路由（DVR）机制
  • 完整的 IPv6 支持
  • L3 agent 的 HA 支持
  • 一些新的厂商的功能插件

从上面的过程可以可以看出，网络功能从 Folsom 版本开始引进，经历了 Folsom、Grizzly、Havana、IceHouse 四个版本才形成了比较稳定的集中式网络模型。自最新的 Juno 版本开始，才开始采用分布式路由模型。

现状

作为云计算平台的基础之一，网络服务的实现无疑是最能体现技术实力之处。无论是功能全面与否、性能高低、稳定性，每一项想做到满足生产环境的众多要求，都不是那么容易的。这也是现在很多围绕 OpenStack 的创业公司立足之根本。

OpenStack 在宣传上，一直明确表明自身的网络是完全按照软件定义网络（SDN）的理念来设计的。实际上，即使是从网络已经正式成为独立项目的 Folsom 版本开始看，这种说法也是不准确的。这个不明确的设计理念也是目前 OpenStack 在网络项目上收到大量抱怨的重要原因之一。

我们知道，SDN 有几个特点，最基础的一点是以松耦合的方式来处理好控制平面与数据平面的关系。

OpenStack 在设计上的确做到了控制平面与数据平面的分离，所有的数据都存放在数据库，所有的 agent 监听来自 Neutron-Server 的消息，根据这些消息来执行本地的操作。从这个简单的模型上看，Neutron 确实采用了 SDN 的模型。

但是将控制平面与数据平面分离，这仅仅是漫漫长途的第一步。后面的如何设计数据平面，以及如何设计和实现控制平面，才是最为核心的地方。

目前，OpenStack 在这两点上是怎么实现的呢？

2009 年诞生的 OpenvSwitch 项目，提供了足够支持生产环境应用的虚拟交换机实现，可以无缝替换掉 Linux 自身的 bridge，并且还支持一系列额外的功能。看起来，这是个不错的项目。于是，在最初几个版本中，网络就同时支持了 Linux Bridge 和 OpenvSwitch。但是很可惜的是，从一开始，大家在使用 OpenvSwitch 的时候，仅仅是当作一个 Linux Bridge 替代品，在设计新的功能的时候，也局限于 Linux Bridge 所支持的功能。这导致理论上可以充当任意转发组件的 OpenvSwitch，在今天的 Neutron 项目中，大部分时候只是作为一个二层交换机在使用。

那么， 更为重要的控制平面呢？很遗憾，在这点 OpenStack 上的表现差强人意。虽不至于说存在技术漏洞，但至少控制平面缺乏统一的规划，以现代众多控制平面的实现角度去看，只能说是一堆功能放在了一起。为了解决一个部分功能，先用已有技术解决掉，而不管其它功能的实现。这也导致经常出现不同功能模块的冲突。分布式路由机制在 SDN 中是个很自然的事情，但现有的实现先后用了固定的地址映射、ARP 代理、多级的转发表、隧道、L2 Population……并不是说不能用这些技术，但是实现的复杂与紧耦合将给未来的扩展带来更多的困难。并且同时启用路由跟高可靠性、多类型服务链等等功能，现有的设计很难在不提高复杂度的前提下实现。

可能做网络研发出身的人比较难理解为何要这样设计。实际上，换个角度，从 Linux 系统自身管理的来看，这样的设计是有其合理之处的。在没有 SDN 的年代，用 Linux 自身做路由器或防火墙是很常见的事情，通过 IPtables、Linux Bridge 进行各种配置，总能满足局域网内的各种需求。然而，到了云时代，一台物理机动不动就上数十台虚拟机，甚至现在几百成千个的容器，同时是多租户的、有计费需求的、对安全可靠性需求很高的……这里面很多的场景，是之前简单应用 Linux 做服务器或网关时候所难以想象的。即使通过各种技术手段勉强解决了基本的需求，也只能造成今天这样复杂的局面。也可以想象，为何将网络接口接到交换机上这样的操作，在 OpenStack 里面是由 Nova 计算服务来负责的。

在这里也稍微感叹下，如果 OpenStack 当年没有 NASA 项目的代码基础、如果没有选择“生命苦短，我选 Python” 的 Python 语言开发，可能到今天的情况会更加不能让人满意。

当然，使用 OpenStack 除了上面的模式，还有另外一种用法：仅把 Neutron 作为一个框架，让后端的各种插件自己来实现各种网络的服务。这种情况下无疑对于现有代码的依赖最小，也无疑最为广大有自己成熟网络解决方案的厂商所推崇。但是这样的模式，肯定也不是社区能接受的情况。毕竟，仅作为一个壳子转发下各种调用，这失去了作为一个成熟云平台开源项目的意义。

未来

虽然指出了网络项目在设计上的诸多问题，笔者对于 OpenStack 仍然是推崇的。并非出于盲目喜爱开源项目的原因，更多的，自 Linux 项目后，这些年很难见到这么多业界巨头和开源届的紧密合作，一起进行一项解决实际需求的项目。

实际上，思考 Linux 项目之所以能成功的原因，很重要的一点，是 Linus 本人。并非只是因为他在操作系统内核方面的技术境界，不可缺少的一点是 Linus 本人是比较“偏执”的，他认定的事情就轻易不会改变。同时，在很长一段时间里 Linux 系统内核的维护只是由 Linus 说了算。这或许能给今天的 OpenStack 社区一些启发。OpenStack 已经成功了，再宣传赞助基金之巨、参与人数之多其实意义没那么大了。一个真正透彻理解云计算需求和技术的小团队，往往胜过大量自觉或不自觉站在各种立场上的参与者。

从目前的情况推测，在很长一段时间内，网络项目还将沿着现在的路子走下去，一方面是在分布式模型下的新的网络功能实现，以及解决与已有功能的冲突；另一方面仍然是各个厂商以插件的形式支持自己的网络方案。这两种方式发生冲突是迟早的事情，只是希望那个时候 OpenStack 中的网络已经选择了更为高效和可扩展的框架，可以真正地实现“任意替换”的软件定义网络。

附：OpenStack 发布历史（摘自官方 wiki）

Series  Status  Releases    Date
Kilo Under development Due Apr 30, 2015
Juno    Current stable release, security-supported  2014.2   Oct 16, 2014
Icehouse    Security-supported  2014.1   Apr 17, 2014
Havana  EOL 2013.2   Oct 17, 2013
Grizzly EOL 2013.1   Apr 4, 2013
Folsom  EOL 2012.2   Sep 27, 2012
Essex    EOL    2012.1   Apr 5, 2012
Diablo   EOL    2011.3   Sep 22, 2011
Cactus   Deprecated 2011.2   Apr 15, 2011
Bexar    Deprecated 2011.1   Feb 3, 2011
Austin   Deprecated 2010.1   Oct 21, 2010

2014——SDN控制平面的关键一年

作为SDN整个技术体系中最复杂，也是最为核心的部分，控制器近些年已经逐渐成为业界追逐的首要目标。

从整个SDN的发展历程来看，跟Internet的发展历程惊人的相似，都是自底向上；都是从campus推广到业界；也都是利用事实标准发展起来。

最开始的三年（07-10），大家所关注的热点还是在于数据平面以及如何与控制平面的交互，包括制定各种南向标准，包括支持SDN的软件交换机项目（包括ovs，linc等）。这一阶段，热点还是集中在学术界居多，业界也在有限度的开始观察和尝试部署sdn。同时，学术界中提出了不少的控制器初步模型和解决方案（nox，pox，floodlight等）。

接下来的三年（11-13），数据平面已经被证实足够成熟，可以用了。那么，要充分发掘sdn的巨大潜力，一个好用的控制器就成为了关键。这一阶段，业界的投入明显加大，sdn的讨论重心明显从学术界到业界转移。这一点符合基本规律。毕竟业界的开发效率和产品质量还是有保障的，而且sdn的需求根本是要落在企业头上。这一阶段中，各个企业尝试了学术界的控制器方案，但很快就纷纷采取不同的路子。

Cisco，作为事实的网络老大，最为霸气，自己内部先后并行推出多个控制器项目，包括XNC、ONE PK、ACI等。而这些项目也延续了Cisco一贯的作风，名义上开放，实际上封装自身的私有协议和产品。

Vmware，作为虚拟届的一哥，借助收购Nirica，推出NSX产品方案，其内部的控制器可以通过ovsdb来管理底下的物理或虚拟交换机。

NEC，作为很早就开始研究sdn的公司，推出了PNC，成功部署在多个实际应用案例中。

Juniper，印度哥做事情，确实喜欢剑走偏锋，在很短时间内，虚晃一枪后默默搞了个OpenContrial，也是打着open的名义来推自身的产品。

显然的是，任何一家推出的控制器都不足以让大家无条件的接受，这个时候，开源社区再次展露了它独到的魅力。

由多家IT巨头共同发起了OpenDaylight项目，现在已经吸引了越来越多的vendor参加，借助开源的力量，发出了越来越大的声音。包括Cisco在内不少家企业也基于OpenDaylight项目开发自己的内部版本。

如果sdn后续的发展路程仍然保持与internet的惊人一致，那么，控制器就跟tcp/ip一样，将成为整个行业的生死之争。

而实际上，随着OpenDaylight项目第一个release的走近，关键的2014马上就要到来了，这一年，必将不那么平静。

或许，明年此时，整个sdn控制平面行业的重新布局将尘埃落定。

Mininet 代码分析

Mininet是个很不错的模拟（emulate）网络的工具，特别在模拟SDN环境的时候。

使用Mininet可以在一台物理机上快速搭建较大规模的SDN网络进行控制器或交换机方面的验证和测试。

关于如何使用Mininet，可以参考这里或官方主页mininet.org。

Mininet的代码结构十分清晰，分析文档可从这里下载。

OpenvSwitch 2.0.0发布

作为SDN交换机的标准软实现，可以夸张一点说，OpenvSwitch的每个进展，都影响到SDN产业的发展。

特别OpenvSwitch从一开始，就实现了控制层面和管理层面的分离，其对配置的管理协议ovsdb-conf正在成为管理层面协议的标准参考。

OpenvSwitch 2.0.0版本的主要feature在于：

ovs-vswitchd已经实现了多线程；

改进对OpenFlow1.1,1.2和1.3的支持；

支持对tunneled网包的发出源和目标地址的匹配；

db中的接口表支持ifindex项；

支持linux kernel版本到3.10；

log时间戳精确到毫秒级。

跟硬件交换机项目，SDN的软交换实现确实已经远远走在了前面。

参考：http://openvswitch.org/releases/NEWS-2.0.0

SDN 产业面临的挑战

The challenges that SDN industry is meeting.

SDN技术的发展正是如火如荼，ONF的成立，ONS的举办，各种论文的发布，各种软件的编写，都昭示着SDN已经成为了一个事实上的产业。

从Openflow开始，跟随SDN的诞生、成长历程数年，欣喜于其发展速度之快，未雨绸缪，有几个挑战是SDN产业继续成熟所必须要面对和克服的。

1、基础设施。软件交换机对SDN技术支持已经较为成熟，典型的代表包括Openvswitch、Indigo等。虽然Nicira很希望将来大家都用Openvswitch实现SDN架构，但不可否认，硬件兼容交换机的缺失，极大阻碍了SDN产品的普及。目前通过ONF官方认证的仅NEC一家，而可见的硬件交换产品功能大都限制颇多，而且价格昂贵。如果这一点不能尽快解决，将会限制SDN技术的应用领域。

2、典型案例。目前可见的SDN应用场景还是中小型的网络环境中，而且往往不够复杂。虽然Google今年在Sigcomm上发表了介绍其3年前部署的B4，但实际上，B4中涉及SDN技术的真实应用十分简单，并不能作为一个完全用SDN实现的典型例子，仍是个不错的尝试。实际上，SDN从诞生之初，就跟数据中心发展的需求密不可分。而无论大型数据中心还是中小型数据中心，往往都已有成熟解决方案。特别是大型厂商的不断创新，留给SDN技术的空间不断收缩。而在广域网和运营商领域，起步则太晚，可以预计这块能做的东西也不多。私有云和企业用户倒是极为青睐SDN，但愿意公开其部署技术的例子更少。

3、技术限制。不得不承认，SDN在带来网络监控上极大便利的同时，也确实仍存在技术上的问题，比如南向接口Openflow，在表的支持方面仍不够灵活；而开放北向接口一直缺失。虽然OpenDaylight项目已经做出了不少贡献，但仍未有release出来，也将影响SDN产业的快速发展。此外，性能方面的代价，现在仍未有简洁成熟的解决方案。与此同时，Cisco的ONE，Juniper的Contrial，Facebook的OCP，都带来了不同的技术路线。

4、扩展支持。SDN解决的是网络的问题。但在现在的应用场景中，网络并非独立存在，往往伴随着各种其他资源，比如计算，比如存储，比如安全。所谓动一发而动全身。网络技术的革新，必然要求其他领域的配合和改变。Openstack之所以能被广泛部署，取代其他现有产品，很大的一个优势就是它所提供的解决方案是一体化的，并非单独替代某一项技术。因此，如何跟其他领域的管控技术融合，也将是SDN进一步发展必须要考虑的。

5、管控解耦。对于系统，特别是网络系统来说，管理和控制实际上是两码事。SDN自诞生起关注控制层，提出了合理的控制层模型。而在管理层方面一直重视不够。最近ovsdb方面的配置协议在管理层面有所进展，但整个SDN界对此的认识仍然十分落后。不少SDN产品中管理和控制层面混杂到一起，给未来进一步的扩展带来极大的挑战。

SDN国内利好

SDN已经炒了有几年了，随着云等产业的成熟，SDN也开始逐渐落地。
这方面china仍然要落后一些。
昨天（2013年8月8日）的新闻联播播出了两条消息，让人感觉国内要开始有些实际动作了。

一个是未来网络小规模试验设施开通，虽然介绍很短，但从几个闪现的画面还是看出来不少信息的。
牵头人应该是刘韵洁院士，落地在江苏南京的未来网络谷（大把的投资，好多空机房）。画面中有中科院的sofia系统，所以估计是类似geni计划的一个试验床，其中利用了sdn和ccn/ndn的一些手段，可以进行一些新协议的验证。另外，之所以叫未来网络而不是下一代网络是因为下一代网络在国内一直被认为是基于IPv6的网络。但v6这些年亚洲炒的热，拥有大块地址域的美帝等国家根本不care。SDN虽然并非是要解决地址的问题，但是新的管控手段上来后可以大量使用映射、封装来缓和一些。从消息上看，研究机构里面中科院占了大头，清华等院校在早期是领先者，但这个机会没能很好抓住。总结来看，跟企业的紧密合作很重要，不然业界难以接受新的概念。可以关注笔者在SDN刚露头的时候（09、10年）撰写的材料（https://github.com/yeasy/tech_writing/tree/master/SDN）。

另外一个是全球首款可编程网络交换机研制成功。这个其实是有夸张了，估计是第一台自主知识产权的。从图片上推测，应该是华为做的（但似乎在之前国内就有一些类似产品出来，可能还有缺陷）。可编程网络交换机是SDN的基础技术，有了交换机的可编程性，才有对网络的灵活配置和动态控制。软件的实现上ovs已经是十分成熟，足以满足产品级的应用，但放到硬件上会有一系列问题，包括表的大小、处理流程等。SDN的场景下对交换机的压力是很大的，需要很多新的考虑。现在全球范围内看能满足产品级应用的，也只有IBM的BNT系列、NEC的（Cisco老喜欢自己加封闭的东西，所以不谈也罢）。这次对华为是个不错的机会，华为走到现在很不容易，要想成功转型，在既有领域站住脚，还能开拓新的用户业务，会面临不少挑战。

ref: 新闻完整内容在：http://news.cntv.cn/2013/08/08/VIDE1375962603760867.shtml

btw，跟主题无关，才知道8月8日已经定为“全民健身日”，但好像不见丝毫举动。比较有诚意的举措是全民放假，体育场馆免费开放。话说现在搞锻炼的成本真是高啊。

Open Daylight Controller 简易入门

You can find the latest version here: https://github.com/yeasy/tech_writing/tree/master/SDN

Many contents are referenced from
www.openflow.org/wk/index.php?title=OpenDayLight_Tutorial

Open Daylight Controller代码分析 - SAL

 SAL是Open Daylight Controller最关键的一个模块。
主要包括下面的一些包。

1.1.1      org.opendaylight.controller.sal.action

1.1.1.1              Action

抽象类。

定义控制器对流的可能的抽象行动，各个具体的行动（包括Allow、Output、Flood等等）都是继承自此类。

主要方法包括获取类型、id、检查值等。

1.1.1.2              Allow

继承自Action类。

类型为ActionType.ALLOW。表示允许行动。

1.1.1.3              Controller

继承自Action类。

类型为ActionType. CONTROLLER。表示发送到控制器行动。

1.1.1.4              Drop

继承自Action类。

类型为ActionType. DROP。表示丢弃行动。

1.1.1.5              Flood

继承自Action类。

类型为ActionType. FLOOD。表示洪泛行动。

1.1.1.6              FloodAll

继承自Action类。

类型为ActionType. FLOOD_ALL。表示除了入口，从所有物理口发出。

1.1.1.7              HwPath

继承自Action类。

类型为ActionType. HW_PATH。表示将网包交给本地的硬件path进行处理。

1.1.1.8              Loopback

继承自Action类。

类型为ActionType. LOOPBACK。表示将网包回送到入口。

1.1.1.9              Output

继承自Action类。

类型为ActionType. OUTPUT。表示将网包从某个物理口发出。

给定参数为物理口，为NodeConnector类型。

1.1.1.10         PopVlan

继承自Action类。

类型为ActionType. POP_VLAN。表示去掉最外层的802.1q头。

1.1.1.11         PushVlan

继承自Action类。

类型为ActionType. PUSH_VLAN。表示在最外层添加一个802.1q的头。

其中，802.1q = [TPID(16) + TCI(16)]，TCI = [PCP(3) + CFI(1) + VID(12)]

1.1.1.12         SetDlDst

继承自Action类。

类型为ActionType. SET_DL_DST。表示设置数据层（即mac层）目标地址。

1.1.1.13         SetDlSrc

继承自Action类。

类型为ActionType. SET_DL_SRC。表示设置数据层（即mac层）源地址。

1.1.1.14         SetDlType

继承自Action类。

类型为ActionType. SET_DL_TYPE。表示设置以太类型和长度域。

1.1.1.15         SetNwDst

继承自Action类。

类型为ActionType. SET_NW_DST。表示设置网络层（即IP层）的目标地址。

1.1.1.16         SetNwSrc

继承自Action类。

类型为ActionType. SET_NW_SRC。表示设置网络层（即IP层）的源地址。

1.1.1.17         SetNwTos

继承自Action类。

类型为ActionType. SET_NW_TOS。表示设置网络的TOS域的值。

1.1.1.18         SetTpDst

继承自Action类。

类型为ActionType. SET_TP_DST。表示设置传输层的目标端口。

1.1.1.19         SetTpSrc

继承自Action类。

类型为ActionType. SET_TP_SRC。表示设置传输层的源端口。

1.1.1.20         SetVlanCfi

继承自Action类。

类型为ActionType. SET_VLAN_CFI。表示设置vlan的CIF域。

1.1.1.21         SetVlanId

继承自Action类。

类型为ActionType. SET_VLAN_ID。表示设置vlan id域。

1.1.1.22         SetVlanPcp

继承自Action类。

类型为ActionType. SET_VLAN_PCP。表示设置vlan的pcp域。

1.1.1.23         SwPath

继承自Action类。

类型为ActionType. SW_PATH。表示将网包发送给本地的软件path进行处理。

1.1.1.24         ActionType

枚举类型，定义控制支持的流行动的类型。每个类型除了一个字符串的id，还包括一个最小值和最大值，代表合法值的范围。

1.1.2      org.opendaylight.controller.sal.authorization

1.1.2.1              IResourceAuthorization

维护鉴权相关的资源数据信息的接口。相关的应用可以从此接口获取鉴权信息。

主要方法包括创建/删除角色、获取应用角色、创建/删除资源组、获取鉴权组等。

1.1.2.2              AppRole

实现了Serializable接口。表示在应用空间中的用户角色信息。

主要属性包括一个角色名称和一个角色层级。

1.1.2.3              AppRoleLevel

实现了Serializable接口。表示在应用空间中的用户角色层级。

1.1.2.4              Resource

实现了Serializable接口。表示基础资源和相关的访问权限。

主要方法包括获取资源和获取权限。

1.1.2.5              ResourceGroup

实现了Serializable接口。表示一组资源和相关的访问权限。

主要方法包括获取资源组名称和获取权限。

1.1.2.6              AuthResultEnum

枚举类型，实现了Serializable接口。

表示鉴权的可能结果，包括NONE、REJECT、TIMEOUT等等。

1.1.2.7              Privilege

枚举类型，定义了组和资源的访问权限。

包括NONE、READ、USE、WRITE。

1.1.2.8              UserLevel

枚举类型，定义在控制器空间中的用户角色层级。包括SYSTEMADMIN、NETWORKADMIN、APPUSER等

1.1.3      org.opendaylight.controller.sal.core

1.1.3.1              IContainer

用于获取给定Container的状态，声明的主要方法包括获取container flow、获取tag、获取NodeConnector等。

1.1.3.2              IContainerAware

用于创建和删除Container。

定义了下面两个方法，定义新建和删除容器时候执行的操作。

public void containerCreate(String containerName);

public void containerDestroy(String containerName);

1.1.3.3              IContainerListener

获取给定Container的状态信息。

主要方法包括更新tag、更新flow、更新NodeConnector等。

1.1.3.4              Action

继承自Property类，定义了Action类，属性主要包括一个actionValue和一个枚举类型的ActionType。

public enum ActionType {

        OUTPUT_PORT_ACTION(1<<0),

        VLAN_VID_ACTION(1<<1),

        VLAN_PCP_ACTION(1<<2),

        VLAN_STRIP_ACTION(1<<3),

        DLSRC_ACTION(1<<4),

        DLDST_ACTION(1<<5),

        NWSRC_ACTION(1<<6),

        NWDST_ACTION(1<<7),

        NWTOS_ACTION(1<<8),

        TPTSRC_ACTION(1<<9),

        TPTDST_ACTION(1<<10),

        ENQUEUE_ACTION(1<<11),

        VENDOR_ACTION(0xffff);

        private final int at;

        ActionType(int val) {

               this.at = val;

        }

        public int getValue() {

               return at;

        }

}

1.1.3.5              AdvertisedBandwidth

继承自Bandwidth类，，定义了AdvertisedBandwidth类。

1.1.3.6              Bandwidth

继承自Property类，定义了Bandwidth类，定义一些常见的带宽值。

1.1.3.7              Buffers

继承自Property类，定义了Buffers类，表示包的buffer，主要包括bufferValue属性。

1.1.3.8              Capabilities

继承自Property类，定义了Capabilities类，主要包括capabilitiesValue属性和CapabilitiesType枚举属性。

public enum CapabilitiesType {

        FLOW_STATS_CAPABILITY(1<<0),

        TABLE_STATS_CAPABILITY(1<<1),

        PORT_STATS_CAPABILITY(1<<2),

        STP_CAPABILITY(1<<3),

        RSVD_CAPABILITY(1<<4),

        IP_REASSEM_CAPABILITY(1<<5),

        QUEUE_STATS_CAPABILITY(1<<6),

        ARP_MATCH_IP_CAPABILITY(1<<7);

        private final int ct;

        CapabilitiesType(int val) {

               this.ct = val;

        }

        public int getValue() {

               return ct;

        }

    }

1.1.3.9              ComponentActivatorAbstractBase

抽象类。

实现了BundleActivator（osgi框架中定义）, IContainerAware两个接口。主要用于扩展osgi框架中定义的BundleActivator类，完成跟osgi框架打交道的一些功能，主要包括init、destroy、start、stop、configureInstance方法等。

init方法是抽象方法，在容器中激活bundle时调用。

destroy方法，在容器中停止激活bundle时调用。

start方法在bundle被启动时候调用，实现两个功能：通过调用框架中BundleContext类的registerService方法，注册自身到osgi框架，告诉框架自身属于IContainerAware服务的提供者之一，从而保证在启动容器的时候被调用；创建一个数据结构（dbGlobalInstances）来跟踪所有在每个容器中创建的实例。最后，调用init()方法。

stop方法在bundle被停止的时候调用，将所有的实例停止并执行相应的清除工作，同时osgi框架会自动将bundle解除注册。

configureInstance方法仅声明而并没有实现，需要继承类自己实现。主要是对容器中的实例进行配置依赖。

getGlobalImplementations方法仅声明而并没有实现。获取bundle支持的所有的实现。

getImplementations方法仅声明而并没有实现。统计容器中的实现的个数。

1.1.3.10         Config

继承自Property类，定义了Config类，主要属性包括configValue和几个管理状态。

1.1.3.11         ConstructionException

继承自Exception类，定义了ConstructionException类，表示创建时异常。

1.1.3.12         ContainerFlow

定义了ContainerFlow类，实现了java.lang.Cloneable和java.io. Serializable接口，表示容器流。

1.1.3.13         ContainerServiceDependency

定义了ContainerServiceDependency类，实现了org.apache.felix.dm.ServiceDependency和org.apache.felix.dm.DependencyActivation接口，表示一个容器依赖的服务。

用户可以设置服务，获取属性等。

1.1.3.14         Description

继承自Property类，定义了Description类，表示一个元素的名称属性。

1.1.3.15         Edge

实现了Serializable接口，表示连接两个NodeConector的边。注意是有方向的，包括一个头NodeConector和一个尾NodeConector。

Edge的方向是由尾部指向头部。

1.1.3.16         Host

实现了Serializable接口。

表示一台终端主机。属性包括数据层和网络层的地址。

1.1.3.17         Latency

继承自Property，定义一些常见的latency值。

1.1.3.18         MacAddress

继承自Property，包括一个控制器的mac地址和节点的mac地址。

1.1.3.19         Name

继承自Property，定义元素的名称属性。

1.1.3.20         Node

实现了Serializable接口。

定义一个普通的网络元素，属性包括类型和id。

1.1.3.21         NodeConnector

实现了Serializable接口。

定义一个通用的网络元素的挂载点，一般绑定到一个Node上。属性包括类型、id和节点。

1.1.3.22         Path

实现了Serializable接口。

一条路径由一系列的边（Edge）组成，从头结点依次指向尾节点。

1.1.3.23         PeerBandwidth

继承自Bandwidth类。

表示peer元素的带宽。

1.1.3.24         Property

抽象基础类，实现了java.io.Serializable接口，是sal中元素属性的基础。

提供了获取名称、比较、生成hash代码等基本操作。

1.1.3.25         State

继承自Property类。

定义一个Edge的状态，比如DOWN、UP等。

1.1.3.26         SupportedBandwidth

继承自Bandwidth类。

表示某条link所支持的带宽信息。

1.1.3.27         Tables

继承自Property类。

主要维护支持的datapath表的个数。

1.1.3.28         Tier

继承自Property类。

表示一个node的层级属性。

1.1.3.29         TimeStamp

继承自Property类。

按照java.util.Date规则定义的时间戳信息。

1.1.3.30         UpdateType

定义发生更新的具体类型，包括ADDED、REMOVED、CHANGED。

1.1.4      org.opendaylight.controller.sal.discovery

1.1.4.1              IDiscoveryService

主要定义了如下方法，当一条边发生变化时候产生通知。

public void notifyEdge(Edge edge, UpdateType type, Set<Property> props);

1.1.5      org.opendaylight.controller.sal.flowprogrammer

1.1.5.1              IFlowProgrammerService

流编程器的接口，声明了在一个网络节点上添加、删除、修改流的方法。

1.1.5.2              IPluginInFlowProgrammerService

流编程器的接口，需要协议插件具体实现。

方法包括添加、删除、修改流等。

1.1.5.3              Flow

实现了Cloneable和Serializable接口。

表示一条流。属性包括match、行动和附加属性（优先级、超时）等。

1.1.6      org.opendaylight.controller.sal.inventory

1.1.6.1              IInventoryService

声明了可以被应用发起面向SAL的方法。

包括：

getNodeProps获取所有存在的节点和相关的属性。

getNodeConnectorProps获取所有存在的NodeConnector和相关的属性。

1.1.6.2              IListenInventoryUpdates

声明了通知上层应用的方法。

包括：

updateNode当节点相关的属性发生更新。

updateNodeConnector当NodeConnector相关的属性发生更新。

1.1.6.3              IPluginInInventoryService

SAL调用，面向协议相关的插件。

包括：

getNodeProps获取所有存在的节点和相关的属性。

getNodeConnectorProps获取所有存在的NodeConnector和相关的属性。

1.1.6.4              IPluginOutInventoryService

描述了Iventory更新的方法，需要协议插件来进行实现。

包括：

updateNode当节点相关的属性发生更新。

updateNodeConnector当NodeConnector相关的属性发生更新。

1.1.7      org.opendaylight.controller.sal.match

1.1.7.1              Match

实现了Cloneable和Serializable接口。

描述了通用匹配网包和消息的规范。定义了一系列可以匹配的域。

1.1.7.2              MatchField

实现了Cloneable和Serializable接口。

代表一个通用的匹配域。主要属性包括类型、值和掩码。

1.1.7.3              MatchType

定义了一系列的匹配类型，包括id、值、掩码类型和范围值等。

包括IN_PORT、DL_SRC、DL_DST、TP_DST等多个成员。

1.1.8      org.opendaylight.controller.sal.packet

1.1.8.1              IDataPacketService

SAL提供给北端组件的数据包服务，需要SAL自己实现，该服务在osgi中注册。

定义了三个方法：

l         transmitDataPacket将原始包通过某个OutgoingNodeConnector发出；

l         decodeDataPacket从接收到的原始包中解析一个数据包出来；

l         encodeDataPacket将数据包编码为原始包。

1.1.8.2              IListenDataPacket

所有希望处理数据包的北端模块（比如ArpHandler）均要实现该接口。不同模块的处理可以是串行或者并行。

该接口定义了方法为

receiveDataPacket，对原始包的处理，返回SAL的是处理结果。

1.1.8.3              IPluginInDataPacketService

南端插件提供给SAL使用的数据包服务。该服务保证SAL仅使用一个协议插件。不同协议插件在注册时需要用不同的protocoloPluginType来进行区分。

定义方法为

transmitDataPacket将原始包发送到网络上。

1.1.8.4              IPluginOutDataPacketService

SAL用于拦截所有从南端协议插件传输上来的原始包。SAL可以通知南端插件数据包是否被处理或需要进一步处理。一般经过SAL处理后过程结束。南端插件通过一个IncomingNodeConnector发送网包。

定义方法为

receiveDataPacket接收原始包并进行处理。

1.1.8.5              ARP

继承自Packet类，表示一个ARP包。

1.1.8.6              BitBufferHelper

提供一些对bits流进行操作的方法，包括获取某些特定位、转化特定位的值为某类型、存储等。

1.1.8.7              Ethernet

继承自Packet类，表示一个以太网包。

1.1.8.8              ICMP

继承自Packet类，表示一个ICMP包。

1.1.8.9              IPv4

继承自Packet类，表示一个IPv4包。

1.1.8.10         LLDP

继承自Packet类，表示一个LLDP包。

1.1.8.11         LLDPTLV

继承自Packet类，表示一个LLDPTLV包。

1.1.8.12         Packet

抽象类。

表示一个通用的网包格式。提供了对网包进行操作的常见方法，包括获取/设置载荷、处理头部域等。

1.1.8.13         PacketResult

网包处理的模块处理的可能结果。

包括：

CONSUME表示网包已经被处理过，后续模块不需要再处理。

KEEP_PROCESSING表示网包已经被处理过，后续模块仍可以进行处理。

IGNORED表示网包被忽略了，后续模块应该进行处理。

1.1.8.14         RawPacket

表示一个原始包，从网络接收或即将发出的包的格式。

1.1.8.15         TCP

继承自Packet类，表示一个TCP包。

1.1.8.16         UDP

继承自Packet类，表示一个UDP包。

1.1.8.17         LinkEncap

枚举类型，网包的数据链路格式，比如ETHERNET。

1.1.9      org.opendaylight.controller.sal.packet.address

1.1.9.1              DataLinkAddress

抽象类。

实现了Serializable接口。用于表示一个数据链路层的地址。主要属性包括一个字符串的name。

1.1.9.2              EthernetAddress

继承自DataLinkAddress类，表示一个以太网地址。主要属性包括一个字节数组的macAddress。

1.1.10              org.opendaylight.controller.sal.reader

1.1.10.1         IPluginInReadService

硬件的查看接口，需要协议插件具体实现。

声明方法包括读取流、描述、NodeConnector等信息。

1.1.10.2         IReadService

获取网络节点的流、端口、队列等硬件信息的接口。

1.1.10.3         FlowOnNode

表示一个安装在网络节点上的流，主要属性包括table位置、匹配次数、统计信息等。

1.1.10.4         NodeConnectorStatistics

一个NodeConnector上的统计信息，包括网包、字节、错误等统计。

1.1.10.5         NodeDescription

网络节点的描述信息，包括制造商、硬件、软件、序列号等。

1.1.11              org.opendaylight.controller.sal.routing

1.1.11.1         IListenRoutingUpdates

如果一个模块希望知道路由引擎发布的事件，则需要实现该接口。

主要声明了recalculateDone方法，当所有的最短路径树的计算完成时候回被调用。

1.1.11.2         IRouting

声明了一些路由相关的方法。

包括获取两个节点之间的路由、获取最大吞吐的路径等。

1.1.12              org.opendaylight.controller.sal.statistics

1.1.12.1         IListenStatisticsUpdate

SAL提供，面向应用的统计信息通知接口。

1.1.12.2         IPluginOutStatisticsService

协议插件提供，面向SAL的统计信息的更新方法。

1.1.13              org.opendaylight.controller.sal.topology

1.1.13.1         IListenTopoUpdates

SAL提供，面向应用，拓扑相关的通知。

1.1.13.2         IPluginInTopologyService

SAL调用，面向协议插件请求拓扑更新的服务。

1.1.13.3         IPluginOutTopologyService

协议插件调用，面向SAL的服务。

1.1.13.4         ITopologyService

SAL为上层应用提供的拓扑相关的服务

1.1.14              org.opendaylight.controller.sal.utils

1.1.14.1         ConfigurationObject

1.1.14.2         IObjectReader

定义了从流中读取并重建对象的方法。

1.1.14.3         HexEncode

对十六进制的编码串进行操作。包括字节和hexString之间的转换等。

1.1.14.4         NetUtils

抽象类。

声明了操作网络数据结构常见的一些方法，包括获取Inet地址、获取子网掩码长度等。

1.1.14.5         NodeConnectorCreator

抽象类。

声明了创建一个NodeConnector相关的方法。

1.1.14.6         NodeCreator

抽象类。

声明了创建一个Node相关的方法。

1.1.14.7         ObjectReader

从文件系统中读取对象。

1.1.14.8         ObjectWriter

写一个对象到文件系统中。

1.1.14.9         ReadFromFile

从文件中读取内容。

1.1.14.10   ServiceHelper

辅助在OSGi框架中进行注册和取消注册。

1.1.14.11   Status

表示OSGi的服务接口函数调用的返回状态。主要属性包括一个状态码和一个描述字符串。

1.1.14.12   TierHelper

辅助管理Tier相关的信息。

1.1.14.13   WriteToFile

写到文件。

1.1.14.14   Direction

实现了Serializable接口的枚举，定义方向，包括forward和reverse。

1.1.14.15   EtherTypes

常见的802.3以太网类型、802.2+SNAP协议id。

1.1.14.16   GlobalConstants

全局的一些常量，包括：

DEFAULT("default"),

    CONTAINERMANAGER("containermanager"),

    CONTAINERNAME("name"),

    STATICVLAN("staticvlan"),

    CLUSTERINGSERVICES("clusteringservices"),

STARTUPHOME("configuration/startup/");

1.1.14.17   GUIField

GUI一些域的常量，包括用户、密码域等。

1.1.14.18   IPProtocols

常见的IP协议号。

1.1.14.19   StatusCode

状态码。通常用于表示成功或者错误状态。