新浪博客

关于SFC的一些记录(二)-NSH—Network service head

2016-02-17 12:44阅读：

http://blog.sina.cn/dpool/blog/u/1768097591

有了SFC构架，那么服务平面上的各种逻辑组件是如何完成SFC报文的转发和服务任务的，为此IETF定义了一个SFC的数据面传输协议，network service head—NSH
NSH—Network service head
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
NSH现在还是个草案draft，还在讨论之中
NSH是一个数据面传输协议，服务平面根据NSH头信息完成服务流转发控制和服务（实现SFC控制面下发的策略），这个协议可以帮助用户动态的创建部署SFC，具体NSH报头结构如下
关于SFC的一些记录(二)-NSH—Network <wbr>service <wbr>head

一个NSH头包含三部分：
1. NSH基本头信息，一个word（32bit）
2. 服务路径信息，一个word（32bit）
3. （可选的）元数据Metadata 信息---(两种模式：固定四个word或四字节对齐变长)

NSH基本头信息里面包含如下信息
Ver---版本号
O bit--- O bit=1 表示这个包的内容是操作维护信息（OAM 包）
C bit--- C bit=1 表示元数据域有用户自定义的（TLV）元数据信息
Length 6bit---表示整个NSH头的长度（word为单位）
MD 8bit---表示metadata域的格式， MD=1：固定四个word，MD=2：变长
Next Protocol 8bit---NSH携带净荷内容的格式，0x1 : IPv4 0x2 : IPv6 0x3 : Ethernet 0xFE-0xFF: Experimental

服务路径信息包括
Service path ID (SPI): 24 bits---表示一个SFP
Service index (SI): 8 bits---表示一个SFP上的SF的位置
在SFC平面上这两个信息非常重要，服务平面上SFF需要根据这两个信息来转发服务报文，SPI明确了一条服务路径，SI指定SFP路径上SF的位置
这两个信息要结合使用才能确定SF， SI在SFP上是变化的，每经过一个服务，SF或者SF-proxy会将SI减一
关于SFC的一些记录(二)-NSH—Network <wbr>service <wbr>head
从这个表可以看出，里面有两个SFP
SFP10 =SF1 NAT->SF2 FW->SF5 proxy->SF8 load balancer
SFP11 =SF2 FW->SF8 Loader balancer->SF5 proxy

NSH在一个SFC-domain的生存周期：
需要服务的数据报文进入SFC-domain，入口classifier会根据控制面配置的信息（策略）对报文进行匹配，确定报文属于哪个SFP，具体路径是什么（RSP），生成NSH，将NSH封装到数据报文前面生成SFC-NSH报文，classifier是一个SFP的逻辑起点，然后带有NSH头的报文被送往SFF，SFF检查SFC-NSH报文中NSH基本头信息，如果Obit=1，那么SFF会解析payload，执行payload里OAM消息(同时可能将SFC-NSH报文转发),如果Obit=0，SFF会解析SPI，确认这个包属于哪个SFP，解析SI，确认下一步这个SFP的第几个SF提供服务，根据确认信息将SFC报文转发到本地的SF或者将报文转发到下一跳SFF, SF处理完SFC报文后，会更新NSH，然后送到SFF继续处理，SFC-NSH报文中NSH在SFP最后的节点SFF被去掉，变成正常数据报送到SFC-domain外，或者在SF内终结.
这里可以看到：
控制面可以非常方便的利用NSH建立SFC，每个NSH的头都可以明确的代表一个SFP,反过来控制器可以提取NSH的信息,根据SPI和SI生成一个SFC完整服务链可视图,例如上面例子的SFP10 =SF1 NAT->SF2 FW->SF5 proxy->SF8 load balancer
NSH还提供了SFC链路监视和故障诊断的能力,通过SPI和SI 监控诊断程序可以马上知道某个报文在服务数据平面的位置,同时NSH支持OAM向SFC链路的每一个逻辑节点发送诊断消息,获取节点和链路的信息
Metadata提供了各个逻辑节点之间消息共享的能力, 这样上层的策略就可以不仅仅局限于传统的底层信息(例如MAC,VLAN, IP等)对数据进行处理,并且Metadata可以存在于整个service path，控制面可以利用Metadata针对整个service path做策略, 数据面的各个逻辑节点直接根据数据报文中的metadata对数据报文进行处理,这样也就隔离了SFC控制平面的策略对底层平面(underlay)的依赖
NSH是一种全新定义的格式，为了NSH报文适应传统设备和传统网络，NSH报文可以以overlay的方式穿越底层网络，用户可以在SFC-NSH数据包前加GRE 或者VXLAN等报头在传统网络上转发。
现在IETF上定义NSH支持的外层封装如下：
1. GRE+NSH
关于SFC的一些记录(二)-NSH—Network <wbr>service <wbr>head

2. VXLAN-gpe + NSH
关于SFC的一些记录(二)-NSH—Network <wbr>service <wbr>head

3. Ethernet +NSH
关于SFC的一些记录(二)-NSH—Network <wbr>service <wbr>head

加上外层封装后，SFC平面 overlay在底层网络之上，服务网络根据NSH对服务报文进行转发，底层网络（underlay network）根据外层的GRE,VXLAN-gpe或者Ethernet头进行数据转发。
底层平面和上层服务平面相互独立，但是底层网络和服务层网络直接要有一个映射关系，底层要知道真正的SFF和SF instance 的位置（locator），这样才能将数据送达。
那么由谁来建立并且维护这个映射关系？谁来完成这个映射？
这个映射关系应该由orchestrator/SDN 控制器来建立和维护，并且把映射表信息下发到SFF，由SFF来完成映射。所以SFP和SI还肩负着另外一个重要任务，做为SFC overlay网络和底层网络映射表的索引，通过映射关系定位SF在底层网络上的位置，保证底层网络能够将服务报文送到实际的SF节点，服务平面的节点和都是逻辑上的，只有完成了逻辑平面到物理平面的映射，真正的服务链才算是建立起来。
关于SFC的一些记录(二)-NSH—Network <wbr>service <wbr>head
上图的例子：
SFFa查表:
SPI=10 SI=254 -> overlay类型是VXLAN-gpe 服务的物理位置在1.1.1.112
SFFa会将将NSH报文加一个VXLAN-gpe封装，送往1.1.1.112，SFFb收到报文后解封装去掉VXLAN头，根据SPI和SI将SFC NSH报文送到SF2 FW处理。
现在结束数据面协议，后面我们看看如何利用ODL实现服务功能链


我的更多文章

下载客户端阅读体验更佳

APP专享