模型驱动的SDN北向接口技术研究.pdf

- 1 - 中国中国科技论文在线科技论文在线 模型驱动的模型驱动的 sdn 北向接口技术研究北向接口技术研究 韦楠，张彬* 作者简介：韦楠（1989-），男，研究生，主要研究方向：网络信息管理相关技术 通信联系人： 张彬 （1970-） ， 女， 副教授， 主要研究方向： 网络信息管理相关技术. e-mail: （北京邮电大学信息与通信工程学院，北京 100876） 5 摘要摘要：sdn 控制器作为 sdn 网络的控制中枢，其目的是将整个网络统一管理，协同部署。 作为控制器与上层应用之间的接口，sdn 北向接口技术必须良好地应对上层应用爆炸式增 长的情况，才能使 sdn 发挥其应有的能力。opennml 是本文提出的一种模型驱动的北向 接口解决方案， 它包括整体结构设计和语言模型设计两部分内容。 它从业务的角度解决了北 向接口的实际问题。 10 关键词关键词：sdn；北向接口；floodlight；pyretic； 中图分类号中图分类号：tp39 research of model driven sdn north bound interface wei nan, zhang bin 15 (information and communication engineering school, beijing university of post and telecommunication,beijing 100876) abstract: sdn controller is the control center of the network, which aims to unify the entire network management, collaborative deployment. as an interface between the controller and the upper application, sdn northbound intrface technology must reponse well to the explosive growth 20 of sdn application.opennml is a proposed model-driven northbound interface solution, which includes the overall structural design and design language model of two parts. it is from a business perspective to solve practical problems of nbi. key words: sdn; nbi; floodlight; pyretic 25 0 引言引言 传统网络中数据层与控制层高度耦合、 硬件设备极度复杂、 网络操作和技术更新举步维 艰，sdn（软件定义网络）的诞生与发展，被视为能够彻底改变这一现状。由 onf 提出的 sdn 架构是当前主流的软件定义网络架构，它提出以控制层为中心，北向和南向分别连接 应用层与数据转发层的三层模型，模型中各层间的接口被定义为北向接口和南向接口。以30 openflow 为基础的南向接口，为解耦数据层与控制层、简化硬件设备提供了理论基础和解 决方法。而面向具体网络用户和业务的北向接口则为上层应用提供服务，是 sdn 网络向应 用层开放的“窗口”。 sdn 发展到今天，openflow1提供了 sdn 控制器与底层网络通信的标准化协议，解决 了控制器南向的大部分问题。 业内聚焦于使用openflow提高网络配置和网络管理的易用性、35 安全性， 并致力于提出高效的解决方法， 用于网络和数据中心虚拟化和无线应用的构造。 sdn 网络应用的实质是操作底层交换机流表，为了在单控制器上层运行这些应用，sdn 需要提 供一个操作平台， nox2, beacon3和 maestro4是网络操作系统的三个实现， 此外各大研究机 构提出了 20 种以上的控制器实现，包括 opendaylight、floodlight5等。北向接口方面，由 bigswitch 发布的 floodlight 包含 restful 的 api； foster et al.6提出了一种用于简化应用部40 署的网络编程语言 frenetic7； nec 提出的 trema8使用 ruby 和 c 语言来开发 openflow 应用； dreamerslab 开发了 node.flow9， 这是使用 node.js10开发的用于使用 javascript 语言 - 2 - 中国中国科技论文在线科技论文在线 开发流控制器的扩展包。 由于业务层的复杂性和多变性， 北向接口标准在业内并没有达成共 识，已有的实现很难满足充分的开放性、便捷性、灵活性，因此北向接口的设计很大程度上 决定着 sdn 的发展前景。 45 1 北向接口相关技术研究北向接口相关技术研究 与南向接口方面已有 openflow 等国际标准不同， 北向接口缺少业界公认的标准， 因此， 北向接口的协议制定成为当前 sdn 领域竞争的焦点。现在业界提出了很多方案，有些从用 户角度出发，有些从运营角度出发，有些从产品能力角度出发，他们都各有利弊。主要可分 为以下几类： 50 1.1 传统传统网络管理网络管理技术技术 1.1.1 snmp snmp为网络管理系统提供了底层网络管理的框架，对管理信息提供了比较完整的建 模。snmp采用manager/agent管理模型，其中，agent用来管理网络设备，收集管理信息并 发送给manager；manager负责处理、存储收到的信息，以及将数据信息显示给用户。 55 snmp 的主要问题是可扩展性和效率问题。 可扩展性是指单个的管理器可管理的代理的 数目。效率是指系统在传输或者处理数据时操作的快慢和有效性。随着管理数据的增加，可 扩展性和有效性就变成了一个问题。 1.1.2 netconf netconf 协议定义了一种简单的管理网络设备，获取配置数据信息，升级和操作新的60 配置数据的机制。这个协议为设备提供了应用编程接口（api），设备可以使用这个 api 来 发送和获取全部或部分的配置数据集。netconf 协议使用远程过程调用（rpc）机制在客 户端（client）和服务器（server）之间通信。客户端可以是一个脚本或者是作为网络管理程 序（者）的一部分的应用程序。服务器是网络中的设备。客户端使用 xml 封装 rpc 并且 通过一个安全的、面向连接的会话将其发送给服务器端。服务器以 xml 封装的数据作为应65 答。请求和应答的内容都由 xml dtd 或 xml schema 描述，使得通信双方都能在交换的 数据上施加语法限制。 netconf 及大地减少实施的费用并且能够实时地获得设备的新的特 征。也就是说，应用能够同时得到设备用户接口的语义和语法信息。 作为网络发展的优秀成果，传统网络管理技术在设计思路与原理、接口规范、底层安全 性和功能完备性性上存在优势，它们通常使用标准的配置文件格式（xml），以网络设备70 的配置为主要对象来工作，能够适应大规模网络的复杂环境。但是，由于它们采用 xml 表 示信息和报文，包含了大量的解释字段，在传输效率上较低，同时大量的 xml 解析工作难 以对业务提供有效的高级封装，对人工成本要求很高。 1.2 领域特定语言（领域特定语言（dsl） 不像通用目的语言那样目标涵盖一切软件问题，领域特定语言（dsl）是专门针对某一75 特定问题的计算机语言。通常情况下，dsl 自己定义语法，然后通过代码生成技术将 dsl 代码转成一种通用语言代码，或者写一个 dsl 语言的解释器。 1.2.1 floodlight api 北向接口的设计思路之一是开放一套遵循 rest 风格的网络 api， 其实质是以控制器作 - 3 - 中国中国科技论文在线科技论文在线 为网络后台服务器，上层应用或使用者以 http 请求的方式获取网络资源或能力。rest 风格80 的 api 以资源的角度观察整个网络， 分布在各处的资源由 uri 确定， 而上层的应用通过 uri 来获取资源的表征。 作为一种 sdn 北向接口， rest api 几乎天然地支持了网络资源的抽象， 以资源的方式 抽象了网络实体。而且，web 应用本身的灵活性和可移植性也可以在 sdn 网络应用开发中发 挥很大的作用，用户可以在有浏览器的任何地方使用接口。不仅如此，通讯本身的无状态性85 可以让不同的服务器来处理一系列请求中的不同请求，提高服务器，也就是控制器，的扩展 性。 但是， 其不足之处也显而易见： 因为rest只支持http 最基本的四种http操作 （post、 put、get 和 delete），导致难以以高级的视角抽象网络能力；接口由控制器向上层开 放，api 的修改和扩展都需要修改控制器逻辑，与控制器耦合度过高；一成不变的接口难以 做到定制化。 90 1.2.2 pyretic pyretic 是 sdn 编程语言项目 frenetic 中的一员，旨在提高 sdn 编程的抽象化程度。它 由两部分组成：首先，pyretic 定义了一种编写 sdn 网络 app 的领域特定语言，它植根于面 向对象的编程语言 python，提出了一整套用于查询、定义和更新网络的声明抽象。其次， pyretic 工程包含一个运行时系统，该系统完成 pyretic 代码的编译，并保证程序高效运行于95 网络设备当中。 pyretic 将 sdn 网络北向接口简单而直观地抽象为三个方面： 网络状态监控、 协议表达和网络配置的动态更新。 网络状态监控方面， 主要是对在网络中传输的数据包流进 行分类、过滤、传输和聚合。协议表达也就是包转发协议的指定和构成。作为网络中转发规 则的体现，协议可认为是网络功能的实现。动态更新是网络运行中非常常见的应用场景，网 络中的协议时常需要从原有的更新为现在最新的，此时一致性更新协议就变得尤为重要。 100 综上可见，pyretic 为 sdn 北向接口的使用者提供了高级的编程语言，它以服务的角度 将需求划分为三类， 支持不改变其现有设备架构的条件下提升配置管理的灵活性， 很好的满 足了面向服务的需求。此外，由于 pyretic 植根于 python，它很好的支持动态扩展，开发者 可以像为 python 编写库一样为 pyretic 提供扩展。最后，pyretic 作为一种独立的领域特定语 言，不受制于任何一种控制器。 105 但是，作为 sdn 网络的北向接口，pyretic 并没有为使用者提供完整的网络资源抽象， 使用者只能通过查询语句来实现对网络的查看， 这种方式在大规模网络的场景下显得捉襟见 肘。不仅如此，pyretic 为所有用户提供单一的接口，无法为不同的管理员提供定制功能。 1.2.3 yang yang 是专用于 netconf 协议的一种数据建模语言。它对 netconf 中涉及到的配110 置数据和状态数据、rpc（remote procedure call，远程过程调用）、通报等都给出了有效 的支持。基于 netconf 的各项操作，yang 模块将所有数据定义成节点的层次结构。其 中每个节点有名字、值和子节点集合。yang 对节点以及节点间的相互关系给出了清晰准 确的描述。yang 将数据模型组织成模块和子模块形式，并定义了内部数据类型，也支持 派生类的定义。yang 支持采用可重用的节点分组定义的复杂类型。派生类型跟组合都支115 持定义和使用分别在两个不同的模块中进行。 按照 netconf 的规定，yang 以设备的本地管理结构的平滑整合为目标。这就使得 在实现的过程中通过适度调节访问控制机制来决定是保护或暴露数据模型中的元素。 这也充 分体现了面向对象思想的优势。 - 4 - 中国中国科技论文在线科技论文在线 业内的北向接口绝不仅仅是上文的几种实现，至少已有的约 20 种控制器实现中，几乎120 每种都对外提供北向接口， 用于上层应用开发和资源管理。 这也从一个侧面表现出北向接口 标准还很难达成共识，已有的实现还没有满足充分的开放性、便捷性、灵活性。 2 北向接口的功能需求分析北向接口的功能需求分析 软件定义网络技术为网络技术的革新提供了平台， 相对于复杂而封闭的传统网络， sdn 为网络应用提供了高度的灵活性，而这种灵活性的承载者正式 sdn 北向接口。从应用层角125 度分析北向接口的需求可大致分为业务需求、用户需求、功能需求和非功能需求几类。比如 某互联网公司构建数据中心的业务、政企单位建立虚拟专网、电信运营商网络的应用、互联 网公司业务部署中的应用等等。用户则可能包括厂商开发人员、第三方开发人员、网络管理 维护开发人员、网络业务的最终用户等。作为北向接口的实际使用者，用户需求可以视为北 向接口设计的根本出发点。作为接口，北向接口的基本要求是实现一些既定的功能，比如查130 询网络状态、协议表达（路由算法，负载均衡和存取控制等）和网络配置的动态更新等。除 此之外， 也有一些非功能性的需求对北向接口提出要求， 最典型的莫过于北向接口的独立性， 简而言之就是成熟的北向接口不应受制于某一个控制器，应当是独立于控制器的存在。 结合上层应用的业务功能需求，用户需求、功能需求和非功能需求，本文提炼出五点北 向接口的需求关键点： 135 2.1 网络抽象网络抽象 是对网络的抽象能力是北向接口的最基本要求， 包括物理网络拓扑视图、 虚拟网络视图、 qos 相关链接视图等等。此外，这种抽象能力不应仅仅是网络信息的展示，而应体现网络的 能力。比如，网络管理员需要从 a 设备的 80 端口建立到 b 虚拟网络间的连接，在合理的北 向接口场景下，管理员只需要输入连接的源和目的 ip、端口、连接带宽等信息即可创建，140 而不是编辑流表。 2.2 面向服务面向服务 因为 nbi 的最终功能诉求是网络使用者和业务 app，所以它不应仅仅针对网络的配置 和管理，应提供更高级的面向服务的接口。在大多数应用场景中，网络业务逻辑的创建和修 改占有大部分比重， vpn 创建、 环路检测、 路径计算等高频使用的业务功能应被封装到 nbi145 当中，或者由 nbi 提供封装的能力。 2.3 管理员定制管理员定制 传统管理员需要学会网络的完整实现原理，从信号、信道到数据编码，从多路复用到数 据交换，从计算机硬件到网络通信协议，网管的学习曲线往往冗长而复杂，而实际工作中使 用本环境需要的网络能力即可完成日常工作。 此外， 现实中不同的网络管理员对网络能力的150 需求不尽相同，且网络提供商对网络能力需要进行权限控制。因此，为了降低网络管理员学 习成本，满足现实要求，优秀的北向接口应针对不同类型的网络管理者提供定制化的服务， 网络提供商为管理员提供所需求的业务能力，管理员无需关心整个 nbi 的原理。 2.4 动态可扩展动态可扩展 相比于传统网络中网络技术掌握在少数核心厂商手中的情况， 软件定义网络中各个模块155 耦合性的降低为网络技术的革新提供了良好的环境， 同时也为面向用户的北向接口提出了挑 - 5 - 中国中国科技论文在线科技论文在线 战，北向接口应该具有良好的可扩展性，这样才能随着底层技术的共同革新。 2.5 独立于控制器独立于控制器 网络集中化控制的控制器是 sdn 网络的核心，北向接口实质上就是控制器面向开发者 的接口。当前业界有许多控制器的实现，如 floodlight、opendaylight、nox 等等，它们160 都各具特色，且在功能和性能上存在差异。除此之外，随着 sdn 技术的发展，单控制器网 络已经难以满足网络需求，控制器集群成为发展方向。基于这种情况，如果每个控制器都具 有各自的北向接口，网络接口将变得异常复杂，这无异于是网络技术的后退。北向接口的设 计应该独立于控制器存在， 不同的控制器使用同一套北向接口， 这样才能为使用者提供稳定 便捷的服务。 165 3 北向接口解决方案设计北向接口解决方案设计 3.1 基于基于 sdn 控制器的北向接口架构设计控制器的北向接口架构设计 针对上文总结的 sdn 北向接口的需求，结合业界已有的两类北向接口实现，本节拟提 出一个面向服务的解决方案 opennml，其设计架构是： 170 图 1 opennml 架构图 首先，整个接口依托一套模型驱动的脚本语言，但不应当是单纯的语法，应当由模块化 的架构组成，各模块分别负责网络中不同元素的封装，各模块互不干扰，相互协作。 第二，在应用场景下，网络创建者首先根据语言模型的抽象对各模型进行实例化，语言175 模型要求能描述网络的所有信息，并将实例交予引擎处理后存储。其次，应用开发者访问引 擎获得权限（即下文的开放模型），并基于已有的权限，把需要的业务逻辑添加到语言中， 形成 app。 最后，语言模型的设计是 opennml 架构的设计基础，第一，物理网络要求它能描述网 络的固有资源，如网络中已有的各类设备。第二，语言模型应该提供对网络资源的操作行为180 的高层次抽象，以满足北向接口面向服务的需求。最后，opennml 是模型驱动的一套架构， 面向服务的同时，用户作为模型组成架构的一部分，以实现用户定制化。 - 6 - 中国中国科技论文在线科技论文在线 3.2 语言模型设计语言模型设计 原有网络在管理和维护方面存在的问题是：设备层封闭化、异构化、离散化，管理和维 护工作量大， 并要求对底层技术和标准深入理解， 因此对维护人员的业务与专业要求非常高，185 进一步加大了管理和维护工作的难度。 而模型驱动工程和特定领域语言通过将领域内的业务 和专业知识进行抽象描述， 形成领域模型， 从而实现专业的领域模型构建和非专业的领域模 型操作分离， 使得领域的专业人员可以聚焦于领域模型的开发与构建， 而非专业人员可通过 特定领域语言来实现相关的业务操作。因此，opennml 语言模型的设计也采用类似的模块 化设计，各模块在逻辑上分三层： 190 图 2 语言模型结构 3.2.1 抽象层抽象层 抽象层主要描述网络的固有信息，它将其分为三类：网络资源、网络能力和网络用户。 抽象层位于最底层，是 opennml 北向接口的基础，旨在为用户提供高层次的网络抽象，包195 含实体模型、能力模型和用户模型三个方面。 实体模型完成对网络中资源的抽象， 网络是由路由器、 交换机等各式各样的物理设备和 设备之间的链接组成的，北向接口作为 sdn 向上层用户开放的“窗户”，对网络物理设备 的抽象是基本要求。相对于 restful 接口使用 uri 标识网络资源的方式，opennml 提供了 更加高层次的解决方案。 它提供了一类原语用于描述网络物理设备， 相似于面向对象编程中200 的类，原语为物理设备提供了高度封装性。不仅如此，原语的设计甚至可以实现实体间的继 承。实体模型原语定义如下： 图 3 实体模型 205 能力模型表示的是网络中一些原生操作的抽象， 比如在两设备之间建立链接 （包括虚拟 链接）、建立虚拟网络等。在大多数北向接口的实现中，能力往往不被单独抽象，而是通过 提供配置流表的操作来完成， 但同一类别的流表操作通常大同小异。 同样是建立链接的例子 中，如果要链接 ab 设备和 cd 设备，这两种操作只有源设备和目的设备有所不同（假设其 - 7 - 中国中国科技论文在线科技论文在线 他链接参数相同），这时使用传统方式会产生大量的冗余操作。能力模型就是对这种“大同210 小异”的操作的一种抽象，无论是控制器提供的方法还是上层用户定义的能力，opennml 都使用能力模型来对之进行抽象，这样用户在使用能力时只需输入能力构建时定义的参数， 即可获得预期的输出。 其原语设计采用与实体模型类似的语法结构， 只是增加了输入和输出 参数类型。 215 图 4 能力模型 用户模型。上文分析的五点北向接口需求中，有一点是管理员定制化服务，也就是不同 的用户不能具备统一的操作权限，不同用户查看同一网络时，展现的内容应当是定制化的。 比如作为某互联网企业的网络运营团队，他们针对网络管理的范围仅限于该企业涉及的网220 络，无需关心其他信息，这时运营团队作为用户模型在 opennml 中存在。再比如某网络运 营商完成了某地的物理网络搭建后， 需要将网络中资源分配给不同的客户， 每个客户应具备 不同的网络权限，这时每个客户都是一个用户模型。由上例可以看出，opennml 架构中应 存在一个管理员角色， 管理员负责配置用户的权限， 管理员配置用户权限的过程也就是开放 层的工作内容。 225 图 5 用户模型 抽象层层应用场景如下，假设有某 sdn 网络 s，其物理网络架设完毕，通过 openflow 协议和控制器的处理，软件设备也已经完成。此时 opennml 引擎的基于控制器的设备发现230 功能， 能够识别网络中已有的设备并把它们抽象成实体模型， 同时网络中的原生操作也会被 抽象。此外，opennml 支持网络的创建者（总管理员）新建实体、能力或用户，比如新建 创建虚拟专网的能力，只需指定抽象所需参数即可。至此，网络的抽象层工作完毕，整个物 理网络抽象到了 opennml 所依托的脚本语言中。 3.2.2 开放层开放层 235 所谓开放层可以理解为用户权限的配置层， 开放层实质上就是网络资源能力和用户之间 的映射关系。 如上文所说，为实现用户对网络的定制化开放，sdn 网络中应存在用户和其他两类网 络抽象层内容的映射关系， 这种映射关系就存储在开放层中的开放模型中。 网络总管理员只 需配置开放模型即可实现网络对用户的定制化。 在传统的北向接口中， 通常只会为上层提供240 统一的接口，任何用户使用的接口没有差异，这样没有支持用户定制化功能的实现，对运营 - 8 - 中国中国科技论文在线科技论文在线 商权限控制和用户局部访问的需求难以满足。 开放模型使用键值对的数据结构存储用户对网络资源与能力的映射， 用户模型的标识作 为键，实体模型和能力模型的标识作为值，两者共存在实体模型中。 245 图 6 开放模型 在与上文相同的应用场景网络 s 中，抽象层完成网络抽象，创建者完成用户和新实体、 能力的新建后，开放层开始工作。网络创建者此时可以对已有的用户进行开放模型配置，比 如向用户 u1 开放创建虚拟专网的能力 c1， 只需把键为 u1 的开放模型实体赋值为 c1 即可。 250 3.2.3 业务逻辑层业务逻辑层 用户可以在业务逻辑层为网络资源和能力增加逻辑。 业务逻辑层主要是面向实际用户网络创建者新建的用户的一层， 该层显示了用 户被赋予的实体和能力。 用户可以为实体或能力增加逻辑， 逻辑可以直接体现在脚本语言中， 也可以使用外部的工具实现。 由于用户的定制化管理， 业务逻辑建立在更加高层的封装之上，255 用户无需关心复杂的接口语言和实现， 只要将业务的实际逻辑添加到已有的能力和实体之上 即可。实际的生产场景下也正是如此，网络开发者往往不想关心底层 openflow 控制器的详 细接口，他们只需要知道网络运营商提供了哪些服务就可以把所需的业务逻辑增加到网络 中。比如网络开发者需要开发一个 sdn 网络应用，实现一次性创建 10 个虚拟网络，使用 opennml 结构，他只需从网络创建者获得创建虚拟网络的能力，并获得相关实体的操作权260 限， 然后使用任何一种语言或者工具循环生成包含对应实体 （即三个虚拟网络实体和虚拟网 络中的子设备实体）opennml 脚本语言，该脚本语言就是应用的载体，使用时再将该脚本 语言输入到引擎编译即可。 4 结论结论 本文首先分析了在 sdn 网络背景下，北向接口的相关技术。然后从应用的角度分析了265 使用者（包括运营商和应用开发人员）对北向接口的需求，并凝练为网络抽象、面向服务、 管理员定制、 动态可扩展和独立于控制器五点。 最后根据五点需求， 给出了相对完整的 sdn 北向接口的整体解决方案框架，设计了框架中的抽象基础语言模型。 当我们以需求的角度审视 opennml，可以首先看到，在语言模型中，实体模型很好的 完成网络抽象工作，网络中的一切资源都能被实体模型直观地表示。第二，能力模型将控制270 器的功能封装为方法，开发者无需关心底层实现，直接使用即可，很好的满足了面向服务的 需求。第三，在 opennml 中存在两种用户角色网络创建者和应用开发者，网络创建者 配置的开放模型限制了开发者可操作的实体与能力， 不同的开发者可以看到定制化的网络资 源。第四，作为一种语言，opennml 可以支持类似 java 语言一样第三方开发的扩展包来提 供扩展功能，而且业务逻辑的增加支持使用任何语言创建，满足动态可扩展的要去。最后，275 语言编写完成后，需要由引擎编译并交予控制器处理，引擎不仅作为编译器，而且可以被认 - 9 - 中国中国科技论文在线科技论文在线 为是面向不同控制器的接口，针对业内的多种控制器实现，只要使用不同的引擎（可以由控 制器开发者提供）即可支持多种控制器工作。 参考文献参考文献 (references) 1 n. mckeown, t. anderson, h. balakrishnan, g. parulkar, l. peterson,j. rexford, s. shenker, and j. turner, 280 “openfl