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产品中管理和控制层面混杂到一起，给未来进一步的扩展带来极大的挑战。

RFC中的奇葩(2) - The Twelve Networking Truths

http://tools.ietf.org/html/rfc1925

12个网络相关的事实，发表在1996年的愚人节。

虽说是在愚人节，讲的东西却颇有道理。以幽默的方式阐述了设计网络这个前无古人的大工程中要注意的事实。

1）必须要能工作。。
2）不能增加光的速度。。
3）足够的推力，猪也可以飞，但显然没必要这么做。一个是很难控制它的着陆，另一个是当它们飞在空中经过的时候，坐在下面是一件很危险的事情。。
4）有些东西，不实际体验下，永远难以很好的认识和理解。
5）把多个问题糅合到一起，提出一个复杂的解决方案，不是一个好主意。
6）把问题转移到其他地方，比解决它要容易。
7）永远是某个存在。（怀疑有遗漏，推论是凡事总有tradeoff）
8）比你想象的更为复杂。
9）对所有的资源，你总是需求更多。
10）一个尺寸不能适应所有的事情。
11）所有的老主意总会被再次提出，换个名字，换个表达方式，不管是否工作的好。
12）在设计协议的时候，完美的目标，不是说无法再添加什么上去了，而是说无法再拿掉什么了。

理解网络元素

这里谈的网络，是以互联网为代表的计算机网络。
现实的网络要远比人们想象的复杂，无论是从拓扑结构还是底层设备上。
理想的网络模型，交换设备（各层的交换机、路由器、网关）连通主机，而在实际中，还存在大量的其他类型的盒子，比如负载均衡、防火墙、IDS，等等等等。
在云计算数据中心网络中，各类带有复杂功能的盒子更多，更杂乱。
那么，如何理清各种盒子（网络元素）对于正确理解网络本身就十分重要。

从网络的主要功能角度出发来看，网络的存在是为了信息的交互，因此，其最根本的功能是转发。无论一个盒子是几层设备，它的功能都是某种意义上的转发。而且这个转发，对终端用户来说应该是透明的，即用户不应该也不需要知道中间的信息。源主机只需要知道目的主机的信息，然后把流量扔出去，怎么转发到目的主机是网络的事情。同样的，目的主机收到的流量，只知道是源主机发过来的，也不需要知道具体是怎么发过来的。

基于“网络的存在是为了转发”这一原则，可以把现在的网络元素分为三大类。
第一类是基础转发盒子（basic forward network element），代表设备为传统意义上的安全middlebox，一头进流量，处理完了，从另外一头扔出来。这类盒子的特征是转发的方式是固定的，跟流量无关的。
第二类是根据流量转发的盒子（traffic aware network element），代表设备为各种交换设备。这些设备往往有多个接口，各个接口之间如何转发并非固定，而是需要根据traffic 的内容（典型的是包头中的目标值）来进行“动态”决策。
第三类是高级智能盒子（advanced smart network element），代表设备为负载均衡系统等。这类设备不光需要检查traffic的内容，还需要考虑其它相关的因素，比如服务器负载情况，各种QoS情况等。

这三类盒子，越往上，功能越复杂，同时支持的网络协议层数往往也越多。现在middlebox在网络中很热门，因为使用middlebox往往可以实现十分复杂的处理功能，这些middlebox也大多都是第三类元素。随着技术的进步，可以预见，第三类盒子的存在将越来越多。特别配合SDN技术，对这些盒子的管理将更加容易和多样化。

当然，现在有很多盒子同时把多种功能做到了一起，但万变不离其宗，仍然可以从这三个层次去理解它。

控制科学的机遇和前路

控制科学在上个世纪七八十年代经历了黄金时期，控制理论在包括化工类生产等方面得到了极大的应用。
然而，此后，理论方面的研究停滞不前，也没有太多的新应用场景，导致控制科学发展进入了相对平稳的阶段。
到了今天，众多新型产业快速发展起来，从中也可以看出一些机遇涌现。

第一个还是机器人方面。
机器人产业的需求也来越大，特别是带有一定简单AI功能的机器，比如无人机，智能运输设备。必将在未来得到极大的发展和应用。这块是其他学科很难介入的地方，正需要新一代的控制科学。

另外就是现在的数据中心管理。信息技术的发展使得各种IT资源都集中起来，以数据中心的模式进行运营。而数据中心中诸多的资源，几乎时时刻刻都需要进行管控，比如服务器、网络，如何进行合理的调度优化，这恰好也是控制科学可以大放异彩的地方。

最后一个就是生物科学。生物科学是特别复杂的系统学科，方方面面都需要进行智能的优化技术。

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日已经定为“全民健身日”，但好像不见丝毫举动。比较有诚意的举措是全民放假，体育场馆免费开放。话说现在搞锻炼的成本真是高啊。

RFC中的奇葩(1) - Discard Protocol

RFC见证了互联网的发展历史。
一群技术人在一起，总会产生很多让人忍俊不禁的故事，包括几个著名的愚人节发布的RFC。
本系列将关注RFC中一些“卓尔不群”的经典提案。

本文提到的RFC其实还真是一个挺有用的RFC，发表于1983年，全文就1页，在http://tools.ietf.org/html/rfc863。主要用处就是定义了Discard Protocol，即丢弃服务。

简单的说，该RFC干的事情就是定义了啥都不干。

该RFC煞有其事地分了TCP和UDP两种情况进行讨论，定义了端口号9。

让人对当年神往不已。

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

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