今天主要让大家了解下下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会遇到如下问题：
1.当前的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 参考资料