基于SDN的卫星网络及南向接口协议扩展
2017-08-11冯淼淼徐展琦汪春霆张亚生肖永伟
冯淼淼,徐展琦,汪春霆,张亚生,肖永伟
( 1.西安电子科技大学 综合业务网理论及关键技术国家重点实验室,陕西 西安 710071;2.通信网信息传输与分发重点实验室,河北 石家庄 050081 )
基于SDN的卫星网络及南向接口协议扩展
冯淼淼1,徐展琦1,汪春霆2,张亚生2,肖永伟2
( 1.西安电子科技大学 综合业务网理论及关键技术国家重点实验室,陕西 西安 710071;2.通信网信息传输与分发重点实验室,河北 石家庄 050081 )
针对卫星通信系统配置更新不灵活、管理复杂等问题,将软件定义网络框架引入卫星网络。简要介绍基于SDN的星地混合网络架构,分析SDN架构中的南向接口协议在卫星网络中的适用性。针对卫星交换节点特性与功能,扩展和增强南向接口OpenFlow协议的功能,以利用多流表架构实现卫星节点多粒度交换,增加对微波端口特性的支持,通过控制器实时获取卫星性能参数,达到对卫星网络节点的灵活配置。
软件定义网络;卫星网络;OpenFlow协议扩展;多流表
0 引言
卫星网络以其独有的特性在通信广播、军事侦察、气象预报、导航定位等领域得到大量应用,更在5G网络的发展中扮演重要角色[1]。然而,卫星网络面临的星地之间距离过大、全局网络状态更新过慢、路由算法不稳定等问题,使其无法适应快速变化的网络状态,提供细粒度的网络服务。
软件定义网络 (Software Defined Network,SDN)[2]作为一种控制转发分离的新型网络架构,凭借其灵活性、开放性及可编程性赢得广泛关注。很多研究将SDN架构引入卫星网络,解决卫星网络配置更新不灵活、管理偏复杂等问题。软件定义卫星 (Software Defined Satellite,SDS)[3]通过对卫星有效载荷的定义实现软件定义功能,执行不同的业务,满足用户多种需求,灵活可控。软件定义卫星网络 (SDS Networks,SDSN)[4]架构通过位于地面站的控制器集中管理全局化网络视图,更加灵活地配置卫星交换体制、链路通信协议,部署更细粒度的管理策略,提供更好的通用性。OpenSAN[5]架构将GEO组作为控制层,解决控制平面与转发平面资源消耗过大的问题。另外,部分研究者将SDN与网络功能虚拟化 (Network Function Virtualization,NFV)[6]结合用于星地网络。文献[7-8]将SDN/NFV技术应用于地面与卫星网络的融合,使其覆盖范围更广、资源利用更优化,且具有更好的网络弹性及部署通信服务的灵活性。然而,上述研究却未考虑OpenFlow在卫星网络中的适用性。OpenFlow协议是针对地面以太网提出的,有线网络的信道传输特性较好,需收集的信息少;而卫星网络支持节点多粒度交换,并采用激光微波混合的无线传输方式,需要获取更加复杂的特性。
本文基于SDN构建星地混合网络架构,实现对卫星性能参数的实时监测,掌握变化频繁的卫星网络状态,提供更加细粒度的管理服务。OpenFlow协议作为标准的南向接口协议,在地面网络的研究中已取得重大进展[9],而在卫星通信网络中的应用有待深入研究。本文重点研究OpenFlow协议对于卫星网络的适用性及其功能扩展,旨在使SDN与卫星网络更好地融合,构建一个灵活、可控的卫星网络。
1 基于SDN的星地混合网络
1.1 网络架构
图1给出基于SDN的星地混合网络架构,它由数据平面、控制平面和管理平面组成。按照SDN架构自底向上,通信卫星GEO作为数据平面中的转发设备,根据控制器上传的流表规则负责转发;位于地面站的SDN控制器拥有对卫星网络的全局视图,实时监测卫星状态,动态合理地调配卫星资源;地面子网中的网络控制中心通过软件编程经控制器实现对卫星的灵活配置,满足用户多种需求。
图1 基于SDN的星地混合网络架构
1.2 接口协议适用性
SDN北向接口是用户业务以及各种网络业务开发者有效控制和利用网络的门户,开发者以软件编程的形式调用各种网络资源,全局掌控和调度网络资源,实现软件可编程控制的网络[10]。目前,表征状态传输 (REpresentational State Transfer,REST)[11]是应用最广泛的北向接口。本文所提架构中,控制器与网络控制中心均位于地面网络中。因此,已有的北向接口应用于卫星网络无需改进。
OpenFlow协议作为公认的南向接口协议标准,负责控制平面与数据平面之间的信息交互。控制器通过OpenFlow协议向底层转发设备下发相应的流表,转发设备只需按照流表定义的规则实现匹配转发即可[12]。不同于地面OpenFlow交换机,卫星网络中GEO通信卫星作为转发设备,由位于地面站的控制器上载流表信息,卫星根据其流表进行转发。因此,现有的OpenFlow协议并不适用于卫星网络中。为了使OpenFlow支持卫星网络特性,包括卫星节点多粒度交换和激光微波混合特性等,需要对OpenFlow v1.5[13]做出一定的功能扩展。
2 卫星多粒度交换扩展
星地混合网络的卫星节点是整个网络的核心,一般是具有星上交换能力的GEO卫星,不仅要支持传统的IP交换、ATM交换、电路交换,而且还要支持光纤交换和光波长交换[14],而OpenFlow协议仅能对以太网中的IP分组进行处理,并不支持多粒度交换。故而本文将OpenFlow协议标准中的多流表匹配框架应用到多粒度交换的扩展中,使其适用于卫星网络。
2.1 多流表匹配框架
如图2所示,本文采用多级流表处理架构完成卫星多粒度交换扩展,各级流表完成不同粒度交换。多流表对流表进行特征提取,将匹配过程分解成多个步骤,形成流水线的处理形式,以减少流表尺寸和降低总流表数,提升流表处理效率[15]。流表ID从0开始依次递增,随着流水线继续进行,交换粒度越来越小。
图2 卫星多粒度交换流表匹配架构
当数据包到达入端口,则进入Table 0进行匹配,若匹配到相应表项,则根据该流表项指定的动作进行下一步处理,跳转至下一级流表继续匹配或直接退出,结束流水线;反之,若未匹配,则将数据包打包成PacketIn消息发往控制器,等待控制器下发策略,做进一步的处理。
图3给出多流表匹配框架中Payload Gran域的格式,它指示当前载荷之上是否存在更小的交换粒度,若存在,则跳转进入相应流表,继续流水线处理;否则,停止流水线,直接转发输出。
图3 Payload Gran域的具体结构
Hierarchy:表示当前位于何种交换级别。
000:表示当前处于端口交换级别;
001:表示当前处于波带交换级别;
010:表示当前处于波长交换级别;
011:表示当前处于SDH交换级别;
010:表示当前处于ATM交换级别;
其余的IP、ATM、SDH、WL、WB均为标志位,指示当前交换粒度之上,是否存在相应的交换粒度。
2.2 匹配域扩展
上述多流表匹配框架中,各级流表的匹配字段并未包含在OpenFlow v1.5协议中。因此基于Openflow v1.5原有的44个匹配域,增加以下扩展域。
enum oxm_ofb_match_fields {
……
OPFXMT_OFB_PAYLOAD_GRAN =45,/* The smaller switching granularity on current switching. */
OFPXMT_OFB_ATM_VPI =46,/* ATM VPI. */
OFPXMT_OFB_ATM_VCI =47,/* ATM VCI. */
OFPXMT_OFB_IN_TDM_SLOT =48,/* SDH switching input TDM slot. */
OFPXMT_OFB_IN_OPT_WB =49,/* Optical waveband switching,input waveband id. */
OFPXMT_OFB_IN_OPT_WL =50,/* Optical wavelength switching,input wavelength id. */
} ;
3 微波端口与馈电链路的特性扩展
3.1 微波端口特性扩展
星地混合卫星网络中,卫星与地面站及卫星之间激光链路与微波链路共存。微波链路建设成本低,传输可靠性高,应用广泛;而激光链路可用带宽大,不受频率分配限制,且保密性好,弥补了微波链路数据中继能力相对不足的问题。OpenFlow v1.4已增加对光端口特性的支持,所以本文通过增加新的端口特性来支持微波传输,包括支持配置及监测微波的频率及功率等。扩展主要包括微波端口修改特性、统计特性和描述特性3部分。
OpenFlow协议为上述3个特性提供扩展域,分别为ofp_port_mod_prop_experimenter、ofp_port_stats_prop_experimenter、ofp_port_desc_prop_experimenter。下面以微波端口修改特性为例具体说明其定义。
/*Port mod property types.*/
Enum opf_port_mod_prop_type {
OFPPMPT_ETHERNET =0 /* Ethernet property. */
OFPPMPT_OPTICAL =1 /* Optical property. */
OFPPMPT_EXPERIMENTER =0xFFFF /* Microwave property. */
} ;
Struct ofp_port_mod_prop_experimenter {
uint16_t type; /* OFPPMT_EXPERIMENTER. */
uint16_t length; /* Length in bytes of this property. */
uint32_t experimenter; /* Experimenter ID which takes the same form as in
struct ofp_experimenter_header. */
uint32_t exp_type; /* Experimenter defined. */
uint32_t freq_band; /* Which wave band has been used,L,S,C,X,Ku,K,or Ka. */
uint32_t freq; /* The “center” frequency. */
uint32_t freq_offset; /* signed frequency offset. */
uint32_t grid_span; /* The size of the grid for this port. */
uint32_t tx_power; /* tx power setting. */
} ;
OFP_ASSERT(sizeof(struct ofp_port_mod_prop_experimenter)==32) ;
3.2 卫星馈电链路特性扩展
相较于有线网络,卫星网络具有更加复杂的特性,需要获取更多的网络性能参数。控制器端通过OpenFlow可获得的信息仅是交换机的基本配置信息和流表相关的统计信息,并不能监控卫星的实时运行状态。通过新增消息类型实现Experimenter Multipart消息的扩展,使控制器端可实时收集卫星的状态信息,动态合理地调度卫星资源。
struct ofp_experimenter_multipart_request {
uint32_t experimenter;
unit32_t exp_type;
} ;
struct ofp_experimenter_multipart_ reply {
uint32_t experimenter;
uint32_t exp_type;
uint32_t bandwidth; /* 传输总带宽*/
uint32_t bandwidth_used; /* 已占用带宽*/
uint32_t EIRP; /* 全向辐射功率,单位为dBW */
uint32_t Nf; /* 噪声系数,单位为dB,典型值为7 dB*/
uint32_t Te; /* 等效噪声温度,单位为K,典型噪声温度为1 000 K */
uint32_t C_N; /* 载噪比 */
uint32_t Ws; /* 饱和通量密度,单位为dBW/m2*/
} ;
3.3 错误及告警消息扩展
灵活的卫星网络配置不仅体现在可通过控制器监测卫星网络状态,还包括卫星将异步状态及错误信息及时上报给控制器,利用OpenFlow协议扩展域experimenter给出扩展的错误消息定义及相关的错误代码如下。交换机能够向控制器上报卫星表面温度过高、当前传输误码率过高及负载过大等问题。控制器主动发送询问消息结合卫星自主上传异步状态及错误信息,便于更好地掌握卫星网络状态,优化卫星网络配置。
struct ofp_error_experimenter_msg {
struct ofp_header header;
uint16_t type; /* OFPET_EXPERIMENTER*/
uint16_t exp_code; /* Experimenter defined*/
uint32_t experimenter; /* Experimenter ID*/
uint8_t data[0]; /* Variable-length data. Interpreted based on the type and
experimenter. No padding*/
} ;
OFP_ASSERT(sizeof(struct ofp_error_experimenter_msg)==16) ;
enum ofp_experimenter_code {
OFPEC_HIGH_TEM =1,/* 卫星表面温度过高 */
OFPEC_HIGH_SER =2,/* 传输错误率太高 */
OFPEC_HEAVY_LOAD =3,/* 负载过大 */
} ;
4 结束语
本文将SDN架构与卫星网络相结合,提出基于SDN的星地混合网络架构。通过地面的控制器和网络控制中心,实现对卫星的实时控制,并根据卫星网络当前状态及时调整路由策略,部署更加细粒度的服务,提升卫星网络整体性能。另外,本文重点讨论OpenFlow协议在卫星通信网络中的适用性,并基于卫星节点的多粒度交换体制和激光微波混合互联等特性,进行协议扩展,使OpenFlow协议更具通用性。
[1] Evans B,Onireti O,Spathopoulos T,et al. The Role of Satellites in 5G[C]∥2015 23rd European Signal Processing Conference (EUSIPCO). Nice,France: IEEE,2015: 2756-2760.
[2] Jammal M,Singh T,Shami A,et al. Software Defined Networking: State of the Art and Research Challenges[J]. Computer Networks,2014,72(11): 74-98.
[3] Yang X N,Xu J L,Lou C Y. Software-Defined Satellite: A New Concept for Space Information System[C]∥2012 Second International Conference on Instrumentation,Measurement,Computer,Communication and Control (IMCCC).Hangzhou,China: IEEE,2012: 586-589.
[4] Tang Z,Zhao B,Wanrong Y,et al. Software Defined Satellite Networks: Benefits and Challenges[C]∥ Computing,Communications and It Applications Conference (ComComAp). Beijing,China: IEEE,2014: 127-132.
[5] Bao J,Zhao B,Yu W,et al. OpenSAN: a Software-defined Satellite Network Architecture[C]∥Proceedings of the 2014 ACM Conference on SIGCOMM. Chicago,Illinois: ACM,2014: 347-348.
[6] Mijumbi R,Serrat J,Gorricho J L,et al. Network function virtualization: State-of-the-art and Research Challenges[J]. IEEE Communications Surveys & Tutorials,2016,18(1):236-262.
[7] Ferrús R,Sallent O,Rasheed T,et al. Enhancing Satellite & Terrestrial Networks Integration Through NFV/SDN technologies[M]. United Kingdom: Emerald Group Publishing Limited,2015:215-237.
[8] Ferrús R,Koumaras H,Sallent O,et al. SDN/NFV-enabled Satellite Communications Networks: Opportunities,Scenarios and Challenges[J]. Physical Communication,2015,18(2):95-112.
[9] 左青云,陈鸣,赵广松,等. 基于OpenFlow的SDN技术研究[J]. 软件学报,2013(5):1078-1097.
[10]Chaudhari S,Mani R S,Raundale P. SDN Network Virtualization Survey[C]∥ International Conference on Wireless Communications,Signal Processing and Networking (WiSPNET). Chennai,India: IEEE,2016: 650-655.
[11]Zhou W,Li L,Luo M,et al. REST API Design Patterns for SDN Northbound API[C]∥ The 28th IEEE International Conference on Advanced Information Networking and Applications (AINA-2014). Victoria,Canada: IEEE,2014: 358-365.
[12]Jarraya Y,Madi T,Debbabi M. A Survey and a Layered Taxonomy of Software-defined Networking[J]. IEEE Communications Surveys & Tutorials,2014,16(4): 1955-1980.
[13]Open Networking Foundation. OpenFlow Switch Specification Version 1.5.1(Protocol version 0x06)[EB/OL]. [2015.03]. https:∥www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/open flow/openflow-switch-v1.5.1.pdf.
[14]马方. 星地混合网信令协议的扩展及其原型实现研究[D]. 西安: 西安电子科技大学,2016.
[15]谢亮. 软件定义网络中OpenFlow交换机流表优化技术研究[D]. 杭州: 浙江大学,2015.
SDN-based Satellite Networks and Southbound Interface Protocol Extension
FENG Miao-miao1,XU Zhan-qi1,WANG Chun-ting2,ZHANG Ya-sheng2,XIAO Yong-wei2
(1. State Key Laboratory of Integrated Service Networks,Xidian University,Xi’an Shaanxi 710071,China;2.State Key Lab of Information Transmission and Distribution in Communication Networks,Shijiazhuang Hebei 050081,China)
In view of inflexible configuration update and complex management of satellite communication system,the software defined network (SDN) framework is introduced into satellite networks. This paper briefly introduces the terrestrial satellite hybrid network architecture based on SDN,and analyzes the applicability of southbound interface protocol in SDN architecture to satellite networks. Based on characteristics and functions of satellite switching nodes,the function of southbound interface OpenFlow protocol is extended and enhanced to realize satellite nodes multi-granularity switching by taking advantage of multi-table architecture. Additionally,the support for microwave port characteristics is added,which enables the real-time acquisition of satellite performance parameters through a controller and achieves flexible configuration of satellite network nodes.
software defined networks (SDN); satellite networks; OpenFlow protocol extension; multi-flow table
2017-05-10
国家自然科学基金项目(61572391)
冯淼淼(1992—),女,硕士研究生,主要研究方向:卫星网络和软件定义网络。徐展琦(1962—),男,博士,教授,主要研究方向:光网络、宽带卫星、SDN/NFV。
10. 3969/j.issn. 1003-3114. 2017.05.05
冯淼淼,徐展琦,汪春霆,等.基于SDN的卫星网络及南向接口协议扩展[J].无线电通信技术,2017,43(5): 19-23.
[FENG Miaomiao,XU Zhanqi,WANG Chunting,et al. SDN-based Satellite Networks and Southbound Interface Protocol Extension [J].Radio Communications Technology,2017,43(5):19-23.]
TN 927
A
1003-3114(2017)05-19-5