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的流程：