OPNFV SFC简介
今天主要让大家了解下下ODL 中SFC的实现，以下如有描述不准确的地方请指正。
1 基本概念
本架构参考ODL SFC项目，其已经合并到OPNFV的Brahmaputra平台
1.1 Service Functions
SF提供特定的网络服务，例如Firewall，NAT，QoS，DPI等。在OPNFV中，SF指提供虚拟网络功能的设备。
1.2 Service Function Forwarders
SFF是Service Chaining的核心组件，在OPNFV中，他是一个OVS bridge，在每个compute节点上都有一个br-int桥作为SFF。SFF的职责是引导Traffic到SF或是下一个compute节点，可以通过SDN控制器例如ODL对SFF进行编程。
1.3 Service Chains
在ODL的SFC项目中，Service Chains由如下组件构成：
SFC：Service Chain Function由多个有顺序的SF组成
SFP：Service ChainPath一个SFC的实例。
RSP：Rendered Service Path是实际Service Chain的实现。通过SFP和SFC来创建一个Service Chain。如果SFP没有提供SF的实例，那么根据SFs算法选择一个，当创建完RSP后，ODL将OpenFlow流表下发到SF上。
1.4 Classifiers
Classifier是进入Service Chain的第一个点，Classifier映射Traffic进入Service Chain，并将Traffic封装到VXLAN-GPE-NSH tunnel中。可以通过Matching来实现Classifier，例如简单的如ACL，复杂的如PCRF，DPI等。
2 Service Chaining Encapsulation
SFC的实现依赖于VXLAN-GPE-NSH协议的支持，下边我们分别讲解下NSH和VXLAN-GPE
2.1 为什么需要NSH
如果没有NSH，Service Chain会遇到如下问题：
- 当前的Chian的实现，都是基于VLAN或是Routing的静态配置的。
2.在Service chain形成之后，数据业务的路径和网络的拓扑都不能动态的修改
3.不能动态的插入新的业务到Chian中
4.不能提供端到端的可视化，OAM，trouble shooting和性能管理
5.SF之间彼此独立，不能共享Path和Metadata信息
通过NSH，Traffic可以很容易的穿过Service Chain。如果没有NSH封装，那么在Traffic经过的每个SF上都需要对流量进行分类识别，不仅影响性能,而且不利于扩展。在NSH header中值得关注两个字段：
1）NSP（NSH Path）：业务Path ID，可以给每个业务分配一个NSP，SF根据NSP对Traffic进行处理。
2）NSI（NSH Index）：NSI指报文在Service Chain中的跳数，初始值为255，每经过一个SF，减一，如果NSI减到0，则丢弃此包，避免产生环路，类似IP报文中的TTL。
2.2 VXLAN-GPE
在ODL SFC中NSH被封装在VXLAN-GPE（VXLAN Generic Protocol Extension）报文中，VXLAN-GPE-NSH报文封装格式如下：
VXLAN-GPE特点：
1.支持对多种协议的封装，包括IPv4，IPv6，NSH，Ethernet，标准VxLAN仅支持Ethernet报文
2.协议类型字段（P-bit）
3.In-Band OAM flag（O-bit）
4.新增Version字段
5.低8bit用于协议类型，高8bit预留
6.为VXLAN-GPE分配新的UDP端口
其头部如下所示：
VXLAN-GPE Header
VxLAN-GPE与VxLAN的区别：
1. VXLAN-GPE可以转发VXLAN的包，因为VXLAN承载的是Ethernet报文，其VxLAN-GPE的UDP端口号与VxLAN相同
2. VXLAN不能转发VXLAN-GPE的包
3. 在VxLAN与VxLAN-GPE共存的环境中，VxLAN-GPE需要使用新的UDP端口
4. VxLAN-GPE通过NSH携带Metadata信息，而VxLAN不支持NSH
3 VNF Manager
在OPNFV SFC项目中，需要VNF Manager对SF的VM进行生命周期的管理，这里选择Openstack的Tacker对VNF进行管理。Tacker接收ODL SFC的配置，管理SF VMs，并且转发此配置到ODL SFC中，时序图如下：
3.1 Tacker
Tacker是Openstack的官方项目，提供 ETSI MANO架构中的 VNF Manager和NFVO功能。Tacker架构如下：
VNFM功能：
1.VNF基本生命周期管理，包括创建，删除，更新
2.VNF的健康检查，提供ping，http等各种方法监控VM，业务是否正常
3.提供VNF的auto scaling功能
4.实现VNF初始化配置
NFVO功能：
1.通过模板（TOSCA&HEAT）提供VNF端到端的部署
2.支持SFC，Tacker负责提供SFC Driver，ODL SFC或是Neutron负责功能实现。
3.VIM资源的调度，检查和分配。
4.可以管理多个VIM和Sites。
5.支持物理NF（Network Function）和虚拟NF
3.2 Tacker-ODL SFC实现架构
此图为ODL实现SFC功能的架构，除了控制器方案，还可以通过Neutron来实现SFC。
4 OPNFV SFC Network Topology
下图为OPNFV Brahmaputra平台的SFC的网络拓扑：
5 OVS NSH patch workaround
ODL使用NSH-VXLAN-GPE封装实现SFC，VXLAN在SF VM中终结，这点是很重要的，这样SF可以看到NSH Header，处理NSI和NSH Metadata。而在Openstack中，VXLAN终结在OVS Bridge上，不是在VM里。当前OVS的版本（2.5）还不支持NSH头，但是社区通过一个私有分支提供了NSH初始版本。当前VXLAN的封装/解封装通过VTEP实现的，而OVS希望通过FLOW实现。
下图为报文发送到SF的流程：
1.通过GBP（Group Based Policy）将Client报文redirect到Ingress Classifier
2.Classifier对报文进行识别分类，分配NS，进行VXLAN-NSH封装，然后发送的SFF
3.SFF解封装VXLAN报文，如果需要发送到SF，则通过VTEP发送到Linux Kernel
4.VTEP对报文进行第二次的VXLAN-NSH的封装.
5.封装完成之后，查询Linux Kernel Route表，从TAP口发送回SFF。
6.在SFF中，报文根据VXLAN匹配要去的SF，然后将报文上送给SF
7.从TAP口将VXLAN-NSH报文上送给SF。
下图为从SF发送到SFF的流程：
1.SF将封装好的VXLAN-NSH报文发给SFF
2.SFF根据入端口和VXLAN匹配此报文，交给Linux Kernel处理
3.报文查询路由通过VTEP口返回SFF
4.VTEP解封装VXLAN-NSH
5.SFF继续下一步处理，将报文交给下一个SF，或是从Egress Classfier出去。
6 参考资料
https://wiki.openstack.org/wiki/Tacker
http://artifacts.opnfv.org/sfc/brahmaputra/docs/design/architecture.html#Service -chains
https://docs.google.com/presentation/d/18AGaiysVgHOd_fIHVpObMO7zUkMjJGOQ98CUwkxU1xo/edit#slide=id.p20