位置/身份分离协议(LISP)重要的开源项目为OpenLISP.但是,OpenLISP本身并不支持网络移动性.为此,分析了OpenLISP的实现架构,将数据平面从FredBSD内核移植到了Linux内核,并在其基础上进行移动性支持功能扩展,最后通过网络基本通信功能测试、移动通信功能测试以及移动场景下VLC播放器视频传输试验,其ping测试的平均延时为1.230 ms,平均移动切换延时为2.009 s,验证评估了OpenLISP对网络移动性支持的功能和性能.
Currently, OpenLISP is an important open source implementation of locator/ID separation protocol (LISP), which implements its full standard features through independent data and control plane. However, OpenLISP doesn't support mobility. The architecture of the OpenLISP was analyzed, and then the data plane was migrated from FreeBSD kernel to Linux kernel and the original OpenLISP to support mobility was extended. Finally, by both fixed and mobile communications, as well as video transmission utilizing VLC media player in mobile scenario, the average delay of ping operation was 1.230 ms and the average handover delay was 2.009 s. The results verified the functionality and performance of OpenLISP for network mobility support.
位置/身份分离协议(LISP,locator/ID separation protocol)是最初由Cisco公司提出的位置与身份分离方案[1],它通过位置和身份信息的解耦合避免了IP语义重载,并能良好地支持节点移动性. LISP协议采用“映射-封装”机制,以终端身份标识(EID, endpoint id)为索引查询映射系统,使用所返回的路由位置标识(RLOC, routing locator)对报文进行封装并发送.目前,该协议的RFC已成为IETF标准[1],Cisco也在IOS中支持LISP功能,具有大规模部署的可行性. OpenLISP[2-3]作为首个实现LISP的开源项目,它较完整地实现了协议规定的位置和身份分离功能,但却未能对网络移动性进行支持.
对OpenLISP的实现架构进行了分析,把仅支持FreeBSD内核的OpenLISP数据平面成功迁移到Linux内核下,并以此为基础,增加了终端注册机制和映射表项更新机制,实现了OpenLISP的移动性功能扩展.最后,通过网络基本通信功能、移动通信功能以及移动场景下VLC视频传输试验测试,对基于OpenLISP的网络移动性方案的功能和性能进行了验证.
1 OpenLISP实现架构分析OpenLISP采用控制平面和数据平面分离的方式实现,其控制平面运行在用户态,而数据平面运行在内核态,二者通过Mapping Socket进行交互.控制平面主要包含EID-RLOC映射对的注册和查询,而数据平面主要对接收到的数据报进行封装和解封装. LISP协议为映射系统提供了一个开放性的接口[4],允许采用不同的映射方法.在OpenLISP中,目前仅实现了对LISP授权数据库树(LISP-DDT, LISP delegated database tree)这种分布式映射系统的支持,DDT的层次化查询机制类似于DNS. OpenLISP的整体架构如图 1所示.
控制平面的功能是维护EID-RLOC映射数据库,并处理来自入口隧道路由器(ITR, ingress tunnel router)的映射查询消息以及来自出口隧道路由器(ETR, egress tunnel router)的映射注册消息. ITR和ETR统称为xTR.
OpenLISP控制平面采用用户数据报(UDP,user datagram protocol)协议实现,其监听端口为4342,接收到的Map-Request会依次进入控制平面Socket队列,由控制平面主进程转交给相应的线程处理.
OpenLISP控制平面的映射查询过程如下:映射解析器(MR, mapping resolver)接收来自ITR的封装控制消息(ECM, encapsulated control message)后,并转发到DDT节点,根据DDT节点返回的Map-Referral消息进行迭代查询.当映射服务器(MS, mapping server)接收到Map-Request消息时,会把相应的ECM消息转发给对应的ETR,最后由ETR直接向ITR发送Map-Reply消息.如果设置了映射查询代理模式,也可以由MS代ETR进行Map-Reply响应.
ETR向MS发送Map-Register消息注册映射对,MS根据消息标志位向ETR回复Map-Notify消息确认注册.
1.2 OpenLISP的数据平面OpenLISP数据平面的功能是实现对报文的封装和解封装,其中需要解决的两个关键问题就是“什么时候需要封装”以及“用什么进行封装”.前者需要借由内核协议栈解决,后者则依赖于本地存储数据结构——映射表.
OpenLISP的数据平面在内核中的协议栈中增加了4个函数:lisp_input ()和lisp_output ()分别执行流入和流出的IPv4 LISP报文的解封装和封装操作;类似地,lisp6_input ()和lisp6_output (),则是用于处理IPv6 LISP报文.
LISP考虑了与传统IP网络的兼容性,所以OpenLISP在接收到来自链路层的报文后,会先根据UDP端口号判断报文是否为LISP报文,如果是,则根据类型分别送入lisp_input ()或者lisp6_input ()函数进行解封装操作,然后再重新传送到传统协议栈的网络层,由处理传统IP报文的ip_input ()或ip6_input ()函数进行相应操作,最后转送到传输层.类似地,在接收到来自传输层的报文时,LISP报文会被送往lisp_output ()或lisp6_output ()进行封装,之后与非LISP报文一样再通过ip_output ()或ip6_output ()送往链路层.
如图 1所示,映射表由两个部分组成:LISP DB (LISP database)和LISP Cache. LISP DB存储的是本地LISP域EID-RLOC映射对,在封装时用作源RLOC;LISP Cache中存储的是其他LISP域的EID-RLOC映射对,在封装时用作目的RLOC. LISP DB和Cache在逻辑上是独立的,但是在物理实现时是合并的. OpenLISP中使用Radix树来组织LISP DB和Cache信息,LISP DB和Cache的记录位于同一棵树上,使用flag标识域加以区分.
1.3 映射套接字将OpenLISP移植到Linux内核时,通过Netlink机制来实现映射套接字通信协议,用于控制平面和数据平面之间的交互.一方面,控制平面可以通过映射套接字操作位于内核的数据平面映射表,并通过该套接字接收数据平面处理后反馈的确认信息,其基本操作有增加表项,删除表项和查询表项,分别对应MAPM_ADD、MAPM_DELETE和MAPM_GET 3种消息类型; 另一方面,数据平面可以通过映射套接字向控制平面发送消息通告,如cache未命中等,从而触发控制平面执行映射查询等操作.
2 移动性支持功能扩展 2.1 终端注册机制移动终端注册机制用于移动终端向xTR主动注册,包括注册和保活两个阶段,如图 2所示.当移动终端接入新的xTR时,需要主动向xTR发出终端注册请求消息,xTR把移动终端的EID以及自身的RLOC映射对<EID,RLOC>写入LISP DB之后,发送终端注册确认消息.
移动终端注册成功后,需要定时向xTR发送终端保活请求消息,xTR则回复终端保活确认消息.如果xTR在一定时间内没有接收到终端保活请求消息,则说明该移动终端已经发生移动,xTR会删除LISP DB中相应的映射表项,并执行映射表项更新机制.
2.2 映射表项更新机制当终端断开与前一个xTR的连接,移动到新的局域网,并与该局域网的xTR重新创建连接时,终端的身份-位置映射对已经发生了变化,为了使终端在新的局域网能够照常通信,需要通过映射表项更新机制维护映射系统的EID-RLOC映射对的一致性,如图 3所示.
当移动终端接入新的局域网A时,通过终端注册机制向xTR注册,xTR更新LISP DB后,向映射系统通告其LISP DB信息,映射系统根据该通告消息更新对应xTR的映射对信息后,向所有xTR发送map-push消息,使所有xTR更新LISP cache表中有关局域网A的映射表项.
当终端离开该局域网时,其xTR通过超时感知移动终端已经离开,在删除LISP DB中对应的映射对后,向映射系统发送删除信息.映射系统删除LISP DB中的特定映射对,并向所有xTR发送map-push消息,使所有xTR删除过期的映射对缓存.
3 实际场景试验 3.1 试验场景搭建OpenLISP的实际试验场景如图 4所示.所有路由器与主机均采用Ubuntukylin14.10操作系统,其中xTR配置为Intel E5处理器,12 GB内存,BCM5709千兆有线网卡以及Cisco AE1000无线网卡.
1) 测试方法.先配置主机A的EID1(192.168.10.1) 以及主机B的EID2(192.168.0.1),并将主机A接入ITR以及将主机B接入ETR.ITR、ETR通过向MS发送Map-Register消息注册EID1-RLOC1、EID2-RLOC2映射对,然后由MS向ITR和ETR返回Map-Notify消息进行注册确认.
2) 验证方法.在主机A发送目的地址为的ICMP Echo Request报文,若可以收到ICMP Echo Reply报文,则LISP网络基本通信功能得以验证.
3) 测试结果.基于主机A的和主机B的EID可以收发ICMP Echo Request和Reply报文.每个ping操作的延时如图 5所示,平均RTT为1.206 ms.
先配置主机A的EID1(192.168.10.1) 以及主机B的EID2(192.168.0.1),并将主机A接入ITR以及将主机B接入ETR.然后,将移动主机A与ITR断开并接入ITR’所在的无线WiFi热点.通过测试主机A是否能与主机B继续通信来验证映射对EID1-RLOC1是否更新为EID1-RLOC3.
在主机B测得发出每个数据包的ping操作延时如图 6所示.序号20~25没有测试到ping操作的延时,这是因为切换过程中出现了丢包.延时由于无线网络环境不稳定有较大程度的波动.移动后ping测试的平均RTT为1.230 ms. 10次移动切换的移动接入延时(含接入WiFi)如表 1所示.平均通信中断延时为5.92 s,平均WiFi接入延时为3.911 s,平均移动切换延时为2.009 s.
1) 测试方法. VLC视频传输试验场景如图 4所示,在VLC视频服务器(即主机B)上配置主机A的以及端口号P,使用UDP模式推送视频流.然后将移动主机A接入ITR所在的无线接入点,在A上打开VLC视频播放器,播放视频流.此时A上可以播放视频.主机A移动后,接入ITR’所在的无线接入点.
2) 验证方法.接入ITR'后,如果在A上的VLC播放器可以正常接收并播放视频,则LISP网络在移动场景下的VLC视频传输功能得以验证.
3) 测试结果.移动后主机上VLC播放器可以正常接收并播放视频.客户端所接收的视频流不是从移动切换前断开的部分继续播放,而是从服务器端当前推送的时间节点开始接收播放.这是由于流视频采用的是UDP方式进行发布,而切换过程中发生了丢包导致的.
4 结束语OpenLISP将LISP协议分为数据平面和控制平面来实现,适合于部署高性能的现实网络场景.但是OpenLISP本身并不提供移动性支持,所以在对OpenLISP的通信流程和实现架构进行详尽分析的基础上,增加了移动终端注册机制和映射表项更新机制,使得OpenLISP具有移动性支持扩展功能.最后,通过实验测试验证了OpenLISP对于网络移动性支持的功能,其ping测试的平均延时为1.230 ms,平均移动切换延时为2.009 s.
[1] | Farinacci D, Lewis D, Meyer D, et al. RFC 6830—2013, The locator/ID separation protocol (LISP)[S]. CA: Internet Engineering Task Force (IETF), 2013. |
[2] | Phung D C, Secci S, Saucez D, et al. The OpenLISP control plane architecture[J]. IEEE Network, 2014, 28(2): 34–40. doi: 10.1109/MNET.2014.6786611 |
[3] | Iannone L, Saucez D, Bonaventure O. Implementing the locator/id separation protocol: design and experience[J]. Computer Networks, 2011, 55(4): 948–958. doi: 10.1016/j.comnet.2010.12.017 |
[4] | Fuller V, Farinacci D. RFC6833—2013, Locator/ID separation protocol (LISP) map-server interface[S].[S.l.]: Internet Engineering Task Force (IETF), 2013. |