APP下载

SDN的网络模型及北向接口

2017-01-19李晨陈俏钢李凤凯吴波

中兴通讯技术 2016年6期

李晨+陈俏钢+李凤凯+吴波

摘要:网络模型及北向接口(NBI)是软件定义网络(SDN)中的关键问题。根据业界标准发展情况,提出了网络模型分为网络业务模型、网管模型、功能模型和网络设备模型,并指出了不同的模型对应了不同的需求。认为运营商、大型厂商等应定义统一的SDN模型和接口,能够推动产业链的成熟和统一。

关键词: 网络模型;业务模型;网管模型;功能模型

1 网络模型定义和特征

1.1 多层次、多视角的网络需求

不同角色的网络用户,对网络的需求是不同的。比如对于一个公有云租户,或者一个运营商网络业务的设计者来说,更加关注的是网络业务相关的指标(模型和接口),如何帮助他们快速定义自己的云网络或者短时间内推出一个新业务,而不关注网络实现的细节。对于网络架构设计者和运维人员来说,如何快速定位故障,如何设计出更加稳定、灵活和可扩展的网络,进而具体选择哪种网络技术实现是更重要的问题。

因此,同一张网络对应不同的需求,在模型和接口上也需要有层次的划分,如图1所示。

1.2 网络的多层模型

网络模型是多层次的,可以分为网络业务模型、网管模型、功能模型和设备模型,如图2所示。

网络业务模型是网络业务、应用驱动,面向用户需求,与实现技术无关,与物理网络无关的抽象模型。网络业务模型主要包括逻辑网络之间相互交互、网络策略、业务服务等级(SLA)、业务调度策略等。

网管模型在软件定义网络(SDN)中,是专注于网络的运维(OAM),运维需求驱动,面向具体运维技术相关的抽象模型,如网管模型能够看到具体的交换机、路由器设备,以及端口信息。

网络功能模型是具体网络技术的功能模型抽象,如为了实现租户隔离,将采用第3层虚拟专用网络(L3 VPN)或第2层虚拟专用网络(L2 VPN)等具体技术。

网络设备模型指对各个厂家单台网络设备的抽象,如该设备路由表项采用何种隧道以及封装、解封装描述,服务质量(QoS)队列描述,访问控制策略,以及转发协议采用OpenFlow、边界网关协议(BGP)等。

网络多层模型之间有着映射关系,业务模型中的具体指标会映射为网络功能模型中的具体技术,部分业务还需要读取网管模型中的监测控制及告警指标,触发调度策略生效。

1.3 网络模型和SDN北向接口

北向接口(NBI)是网络业务模型、网络功能模型和网管模型的一种使用方式。

在SDN网络中,控制器以上部分的接口称为NBI,通常以RESTful应用程序编程接口(API)方式与控制器交互。目前SDN的NBI主要分为基于意图的NBI和功能型NBI两大类。

结合SDN网络的层次架构,网络模型有相对应的抽象。基于意图的NBI对应了网络业务模型,它主要用于描述SDN网络使用者的需求,与技术无关,目前主要包括连接服务、资源需求、访问控制、流处理、策略逻辑等几部分内容,并且仍在完善中。功能型NBI对应了网络功能模型和网管模型,面向具体的网络功能,与网络技术方案相关的NBI接口。这部分NBI在每个场景和案例中都会有区别,所以应结合场景逐一分析,目前也在完善中,如图3所示[1]。

结合SDN的3层架构,可以对基于意图的NBI、功能型NBI与网络模型、SDN应用程序(APP)、SDN控制器以及网管的关系总结如下,具体如图4所示。

(1)基于意图的NBI是网络业务模型所需要的输入消息。业务模型可以在SDN APP内部实现(图4中绿色区域),也可以在控制器上实现(图4中黄色区域)。对应地,业务模型向功能模型的映射也分为在APP完成或控制器完成两种方式,基于意图的NBI也会终结在APP或控制器上[2]。

(2)功能型NBI是网管模型+网络功能模型所需要的输入消息。网络功能模型主要在控制器上实现,网管模型主要在运营支撑系统(OSS)网管上实现。其中控制器和OSS网管从目前的实现看,有完全独立、互相重叠、完全包含3种方式。从近期看,控制器侧重于业务下发和流量统计,网管侧重于告警、性能监测控制和日志统计,将会继续并存。

1.4 网络模型和NBI的描述形式

网络模型主要用数据模型和协议的组合来描述,和网络模型描述有关的协议和数据模型主要包括4种。

·NETCONF协议:网络设备配置协议(RFC6241),包括消息层、操作层、内容层等。

·YANG数据模型:数据模型,为NETCONF提供通用数据格式,可以用统一建模语言(UML)、压缩树的方式展现。

·RESTful协议:基于HTTP协议,包括post、put、delete、get等消息。

·RESTCONF协议:用RESTful方式访问YANG数据。

网络模型的描述形式目前主要采用YANG数据模型或一系列API消息来描述。NBI所采用的协议主要为RESTCONF或RESTful API。

2 业务/网管/功能模型

2.1 网络业务模型

网络业务模型可以用对象、操作、结果(OOR)来描述,如图5中所示,这种描述的方式也充分体现了业务描述与网络细节无关的思想。图5中业务模型表述的意思是:用户在某个上下文环境中有基于意图的表述。

首先对于对象来说,包括节点、连接和流信息,这些对象将作为网络模型所描述的主体。

其次操作分为条件、动作和限制。在满足带宽、时延等网络条件下,在匹配哪些节点之间不可互通等限制下,执行标记优先级,实现转发的操作。

最后对于结果,包括期待结果和避免结果两类,如预期保证带宽利用率大于80%,或避免端到端时延大于100 ms等。

关于网络业务模型,我们可采用3个例子加以描述。

例1:银行多站点间基于意图的需求

(1)各分支站点可以访问位于总部站点的网络服务器,不可以访问位于总部站点的户数据库。

(a)目标:各分支、总部站点网络服务器,总部站点用户数据库等;

(b)操作:可以访问,或者不可以访问。

(2)各站点间的带宽利用率保持大于80%。

(a)目标:各站点间的带宽资源;

(b)结果:期待大于80%。

例2:企业站点间视频会议服务、数据传输基于意图的需求

(1)站点间视频会议优先保证语音流畅,数据备份优先级低传输。

(a)目标:站点间的视频数据流、数据备份数据流;

(b)操作:设定优先级。

(2)数据备份的数据内容进行日志记录和安全识别。

(a)目标:数据备份数据流;

(b)操作:logging和流清处理。

例3:云计算中心网络应用场景中的几个需求描述

(1)需要构建2层、3层网络。

(a)CREATE Node l2_network Type l2-group Contain h1,h2;

(b)CREATE Node l3_network Type l3-group Contain n1,n2。

(2)链接虚拟机。

CREATE Connection c1 Type p2p Endnodes n1, n2 Property bandwidth:1024。

(3)定义业务数据流。

(a)CREATE Flow f1 Match src-ip: 10.0.1.0/24, dst-ip: 10.0.2.0/24, dst-port: 80;

(b)CREATE Flow f2 Match src-ip: 10.0.5.0/24, dst-ip: 10.0.6.0/24, dst-port: 80。

(4)部署访问控制列表(ACL)访问控制策略。

(a)CREATE Operation o1 Priority 1 Target f1 Action drop;

(b)CREATE Operation o1 Priority 1 Target f1 Action allow。

(5)部署QoS策略。

(a)CREATE Operation o3 Priority 1 Target c1 Action qos-bandwidth: 4096。

2.2 网管通用模型描述

根据电信国际电信联盟电信管理网(ITU-T TMN)的定义,网管模型定义了标准q接口,对现有网络中业务,如VPN、多协议标签交换传送应用(MPLS-TP)、网络拓扑、资源(单板、网元)等进行管理,并分为故障管理、配置管理、计费管理、性能管理和安全性管理5类功能,如图6所示。

网管模型主要由类和对象视图构成,要管理的物理或者逻辑模块抽象成对象类,网管实现成对象实例。

2.3 网络功能模型

网络功能模型是具体问题具体分析的,目前没有统一定义。以L3 VPN为例,功能模型包括:

·基本信息,如名称、类型、接口

·接口信息,如接口状态、IP地址、多媒体接入控制(MAC)地址、接口role、链路类型、虚拟局域网(VLAN)、proto等。

2.4网络业务模型和网管模型的关系

网络业务模型的操作专注业务需求,网络功能模型专注于具体技术的配置、开通,网管模型的操作专注运维。

随着网络演进,业务灵活性的增加以及SDN的逐步部署,网管模型中和业务控制管理关系密切的模型,如业务配置、业务性能、业务故障以及部分网络配置等管理,会由SDN 控制器支持的NBI实现。如在业务功能丰富的数据中心网络中,SDN网管将逐渐侧重于运维,更多利于业务控制和对时间敏感的传统网管功能模型会通过SDN功能型NBI来实现。而广域网(WAN)承载了各种复杂业务,仍有大量的传统设备。

3 数据中心场景下的网络模型

数据中心场景是目前模型和NBI相对完善的领域。在该场景下,云租户或业务系统利用网络模型订购虚拟私有云服务,包括路由器、子网、安全组策略、弹性公网IP等基础资源,以及防火墙(FW)、负载均衡(LB)、VPN等增值网络服务资源。数据中心网络模型如图7所示。

数据中心场景下基于意图的 API实例为:

(1)创建路由器API。

Post /v2.0/routers/{routerID}。

(2)创建子网API。

(a)Post /v2.0/networks;

(b)Post /v2.0/subnets,包括了地址段、掩码、网关、动态主机配置协议(DHCP)使能等参数。

(3)路由器绑定子网。

Put /v2.0/routers/{routerID}/add_

router_interface。

数据中心网络功能模型基于OpenStack Neutron,采用SDN plugin方式实现,如图8所示。

功能型API实例为:

(1)租户内2层网络隔离,使用vNet(不同 VXLAN或VLAN ID)。

(2)租户间3层网络隔离,除非明确配置,数据中心内不允许跨租户的流量访问(即租户间互访流量建议通过广域互通)。

(a)采用软件方案时,使用虚拟路由器实现在路由层面的租户隔离,每个租户使用单独的虚拟路由器;

(b)采用硬件方案时, 使用 VPN路由和转发(VRF)实现在路由层面的租户隔离。

(3)安全组隔离:通过虚拟交换机(vSW)上流表实现。

(4)FW/LB功能。

(a)采用软件方案时,使用虚拟防火墙(vFW)或虚拟负载均衡(vLB)虚拟机实现;

(b)采用硬件方案时, 使用硬件设备虚拟出多实例实现。

4 业界标准化和开源社区进展

目前关注网络模型及NBI的标准化组织主要包括开放网络基金会(ONF)、国际互联网工程任务组(IETF)和城域以太网论坛(MEF)。ONF作为SDN领域领先的标准组织,从2013年起就开始成立北向工作组,并通过几次重组,现在在信息模型工程(IMP)工作组制定功能型 NBI。同时,ONF在OSSDN中成立了BOULDER项目,专注于模型和基于意图的NBI设计,目前主要在讨论基于角色的业务模型。

IETF前期定义了大量的网络设备模型,和网络业务模型、功能模型无关。目前IETF正在L3SM工作组制订网络业务模型相关的内容,并在网络移动(NEMO)工作组商讨基于意图的模型立项的可行性。

MEF正在开展业务需求分析,主要针对2层以太网业务的YANG模型定义,尚未开展具体业务信息模型的标准化。

除了标准化组织,各个开源社区也在积极实现和推动NBI,争取形成事实标准,加速产业成熟。其中,OpenDaylight正在网络意图组成(NIC)、NEMO等项目中快速推进基于意图的NBI;OpenStack的Congress项目以及ONOS都从自己的角度定义了北向接口。

5 展望

SDN正如其定义软件定义网络,其核心价值在于软件。一方面在基础设施层面,需要软件化的控制器将网络的控制权集中,实现全局的调度,优化并提升网络利用率。更重要的是基于这个基础设施层,利用网络的开放能力,定义各种各样的网络APP,挖掘网络价值,能够更加紧密地贴合业务的需求。从这个角度讲,网络更紧耦合于业务。

要做到这一点,标准的网络模型和北向接口将成为重中之重。从业界格局看,标准化组织和开源组织在并行定义自己的模型和接口,但是各自又存在着不足。比如标准化组织流程长,定义出来的东西可能无法赶上越来越快的现网部署节奏;而开源组织短平快的方式缺少全局考虑,在新版本中经常发生变化的情况屡见不鲜。因此在这个时间点上,运营商、大型厂商等应联合标准化和开源力量定义统一的模型和接口,推动产业链的成熟和统一。

参考文献

[1] ONF. Intent Definition and Principles [R]. ONF, 2016

[2] ONF. NBI-North Bound Interface Framework: ONF2014.071.22 [R]. ONF, 2014