我对OpenDaylight/ONOS开发的一些看法

笔者是一名从事交换机测试多年的测试工程师，尤其是最近两年专注于OpenFlow交换机的测试。在接触到的客户中，很多人想将自己的网路向SDN去转。交换机可以采购，但是完全符合自己部署运维要求的控制器基本上是找不到的。那么一个很自然的想法就是能否基于目前最受欢迎的两款开源控制器OpenDaylight和ONOS来做一些开发，再加上OpenFlow交换机来搭建自己的SDN网路。下面是基于我对这两款控制器粗浅的认识给的一些建议，将控制器的内部视作黑盒，只谈对外呈现。

关于SDN的本质属性，借用卫峰的话来说，就是下面三点：

控制面和转发面分离
有开放的编程介面
集中式的管理

只要符合上面三点就可以说是SDN。不过，我这里要聊的，是和OpenFlow强相关的SDN。OpenFlow将之前网路设备对于报文的操作和转发进行了原子化。例如三层转发，分离抽象成了

修改source/dest mac-----> set_field:xx->eth_src/eth_dst
IP TTL减1-------------------->dec_nw_ttl
从某个埠转发出去----->output:x

这样至少带来了如下的好处

(1)可以组合编排出之前不曾有的操作，例如单播和组播之间互转

(2)具体业务可以通过这些原子操作的list来进行描述，方便编程

作为整个网路的大脑——控制器——就被提升到了核心的位置，而交换机不再有自我学习表项和自主决定编辑转发的能力，对于接收到的报文的处理完全按照控制器下发的流表描述来做。因为table-miss表项的存在，对于前面表项匹配不到的报文，一般丢掉或是上送控制器，由控制器来做判断和处理。

对于控制器来说，其应用层介面被定义为北向介面，其数据转发层的介面被定义为南向介面。控制器上运行的App，通过调用它提供的API，将App的逻辑翻译成南向介面的协议(例如OpenFlow)，然后通过南向介面下发给交换机。

作为目前最受欢迎的两款开源控制器，OpenDaylight和ONOS在业界非常的火，至于Ryu/floodlight之类，只能靠后站了。但是它们还是各有侧重点的。OpenDaylight作为企业主推的控制器，支持的功能较多，也更庞杂；而ONOS是运营商主推的控制器，更加贴近运营商的场景。它们的共同点，就是已经集成进了很多APP，可供使能和去使能，尤其是提供了很全面的REST API，可以非常方便地操作flow/group/meter。至于具体的表项该如何获取，

OpenDaylihgt可以通过YangUI/Yangman填入表格来获取JSON body
ONOS可以通过ONOS Core REST API，仿照给出的示例，填入Frame内容

这些通过基于REST over HTTP，非常容易用Python等编程语言进行调用。

但是，但是，能够操作这些openflow的表项，距离一个真正可用的APP，还有很大的距离，最大的问题就是无法响应openflow交换机上发的报文。下面是几类最常用的Switch-to-Controller的报文：

Packet_In：一般用来将没有具体匹配项的报文，通过table-miss流表上送控制器(前面要加上packet_in的报头)。一个典型应用就是首包上送，然后控制器下发适配的流表，这样后续同类报文就可以直接按照流表转发了。
Send_Flow_Rem：控制器下发流表的时候，将流表中的该flag置起。当流表被删除的时候(往往是因为timeout)，会通告控制器，方便控制器及时更新流表记录的资料库。
Port_State：当交换机的埠up/down的时候，通过该消息通告控制器，供控制器了解网路中的拓扑变化，及时作出策略调整提供依据。

作为控制器来说，交换机上报的这些消息，都是它采取或是改变策略重要的参考。因此这里需要解析交换机上送的OpenFlow协议报文，提取其中的重要信息，然后作出决策，再通过对交换机下发OpenFlow协议报文，体现出自己的管理意志。那么此时，只有那些REST API肯定就远远不够了，需要自己编写App并打包进控制器，并在控制器上运行。当然，App中还是可以调用已经提供的各种API，就没有必要自己再写一份了。具体如何实现，就看开发者

对网路业务的理解程度
对控制器架构的掌握
Java编程实现的能力
是否需要重构WebUI
是否需要集成一些自己的运维工具

至于参考，最好的肯定是官方提供的文档(Wiki)，还有控制器开源代码中自身提供的一些sample-case，谷歌也是必不可少(就不喷某度了)。另外国内的sdnlab也不时提供一些好的技术类的分享文章，可以看看别人踩过哪些坑。