作者简介：毛健炜，2016/09-至今，研究生，北邮未来网络实验室(FNLab)；ONOS中国区大使
研究方向：SDN/NFV，运营商、数据中心网络，萌芽中的架构师
SDNLAB 文章发表：http://www.sdnlab.com/14484.html
因为7、8月我跟小伙伴们在备战今年的全国大学生SDN大赛，9月在全身心投入准备特殊人才保研的专家答辩，所以好久没有新文章跟大家见面啦。现在一切尘埃落定，继续卯足了劲头向前冲，弥补这几个月落下的学习进度哈！
前段时间学了OpenFlow 1.3，感觉跟1.0比起来就是改头换面，焕然一新。
改进了Match，改变了Action的地位和执行方式，引入了流表流水线处理，新加了Instruction、Meter Table、Group Table等，刚开始接触的同学可能一下子都不容易把握它们的整体脉络。
我在完整地学习了OpenFlow1.3的主要部分之后，做了这份梳理图（PDF）给大家，这也是我的学习笔记和梳理总结啦，希望跟大家共同进步哦！
以下是我在完整地学习了1.3的主要部分之后，觉得各方面比较重要的points：
还是很推荐大家去阅读协议原文，各种你不清楚的情况，都讲得很详细。OpenFlow 1.3 协议原文
对于以下各项的排序，是大致按照各项间的引用、我猜大家看本文时的思考和理解的顺序来的。
★★以下内容默认大家是在看过我的梳理图（PDF）的基础上哈。
Action
从OF1.0学习过来的同学请注意，1.3中Action可看成分为了两种，Action Set和 Action List。
Action Set是跟每一个数据包绑定的，一起走过流水线的每一步，受Instruction的修改，最后统一执行到数据包上的。
Action Set可以这么理解：
数据包背上了一个名叫Action Set的小背包，顺着流水线徒步旅行，每到一个地方，就往背包里放一点纪念品或者拿出去一些东西，等走过了最后一个景点，来到了旅途的终点，再打开背包，回味旅途的点点滴滴。
Action List则跟1.0时候的Actions很像（感觉似乎一样），就是匹配到哪条流表项，就执行一下。只是有个前提，它是各种Instruction中的一种，即Apply-Actions。
Action Set中，每种类型只能有一个，可以多个set-field，但每种set-field只能有一个。
Metadata
这也是1.3的新东西，它是一个64 bits的数据，也是跟每个数据包绑定的，可以作为匹配域，跟随原先的IP、MAC等，一起参与流表的匹配过程，匹配源IPv6是OXM_OF_IPV6_SRC，匹配Metadata是OXM_OF_METADATA。它是由流表的Instruction去修改的。
看完Metadata，我第一时间想到的是唐僧取经的通关文牒，到一个地方，有需要的话就盖个章，改一改，到了另一个地方，还要给人家拿去看看，大家可以想想是不是这样，哈哈。
流水线(Pipeline Processing)
- 只能GoTo序号更大的表
- 流水线走完以后（即没有GoTo的Instruction），则开始执行数据包的Action Set
使用流水线，实现了一定程度的聚合，节省了对TCAM等SDN专用交换芯片的存储空间的占用，上学期看盛科最新的芯片好像能支持64K数量的流表了。空间很宝贵的呀！
对于流水线这块，协议里给了几张图，挺不错的。
Table-miss
这种流表要说特殊嘛其实也没什么特殊的。
数据包无法匹配流表中的其他所有表项时，就会匹配这条流表项，因此：
- wildcard all match field，通配掉所有的待匹配域，所有包都会匹配上这条表
- have the lowest priority(0)，拥有最低的优先级
1.0中匹配不到任何流表时，交换机会主动Packet-in上报，但是1.3的Table-miss给了我们更多选择：上报、丢包、去另一张表。
By the way，无法匹配时1.3中默认是丢包，但可以通过数据面配置协议去设定其他处理方式。
但是，我们应该注意到：
Table-miss不是默认存在于流表中的，它跟其他流表一样，由控制器下发或移除，移除！
但协议还是把它单独提出来说了，且看，它的特殊性就在于：
“The match of the table-miss flow entry may fall outside the normal range of matches supported by a flow table, for example an exact match table would not support wildcards for other flow entries but must support the table-miss flow entry wildcarding all fields.”
这段我理解得可能不是特别好，但我们能知道的是，即使流表在实际的实现上有某些限制条件，比如匹配域不支持通配，但它也必须支持Table-miss的存在，也推荐向后兼容“上报、丢包、去另一张表”这三种处理方式。请回忆，Table-miss wildcards all match field。
1.3的两大新货，Group Table和Meter Table，Group没有太需要提醒的点，倒是Meter有些需要注意的地方。
Meter Entry
1.一条流表只能绑定一条Meter Entry，一条Meter Entry能被多条流表绑定。
协议里有更详细的场景、说明，但我觉得最核心的就是这两句。
梳理图（PDF）中右侧的那张大图，就是这方面的一个展示，只是梳理图中是按协议中的说法——“不允许交集”，来画的。
2.Band的选取，其实就是用不同的Rate在数轴上画几条线，当前的速率做类似的“下取整”，取到哪个Rate就执行哪个Band的Type操作
Instruction
- 每种类型的Instruction只能有一个，跟Action Set一样
- 各Instruction在一定程度上也是按“协议”顺序执行
结语
最后，在实践方面，请同学们注意一下协议中这一章节：
A.2.3.6 Flow Match Field Prerequisite
还有这个表：
Table 11: Match fields details.
That’s all of my notes, wish to chat with you!
今后就要投入ODL、ONOS的怀抱啦，正在拜读 地球某某 老师的《ODL MD-SAL APP架构入门》，希望能早日步入ODL的大门！
想到以后能一直做SDN和未来网络其他方向的事情，就抑制不住心中的激动！
小伙伴们，一起加油！
北京，海淀
