SDN的网络模型及北向接口

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

摘要：网络模型及北向接口（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