SDN 网络 IPv6 组播机制研究

背景：

随着互联网的迅猛发展，诸如视频直播、网络教学等实时业务的广泛应用，多个接收者需要同时从一个或多个源节点接收相同的流媒体数据，网络传输的信息容量大大增加，占用大量的网络带宽。对这些应用需求，传统的点播技术，不仅对源节点资源和网络带宽的消耗很大，同时用户数量的扩展受到限制。比较而言，组播是一个很好的传输方案。由于传统网络中路由器需要预先配置，然后才可以动态支持组播订阅者的加入、离开操作和组播树的生成操作，并且传统网络中的路由器没有针对用户对带宽的大需求来动态选择传输路径，很容易造成链路拥塞，不能够为用户提供较好的服务质量，难以在传统网络中大规模部署。

以 OpenFlow 技术为核心的软件定义网络（SDN）框架具有集中控制的功能，能够自己感知网络拓扑的变化，在细粒度的路径选择、接入控制、负载均衡方面有着天然的优势，为 IPv6 组播功能的实现提供了好的解决方案。为了解决 SDN 网络下的 IPv6 组播问题，提出了在 SDN 控制器中设计组成员管理、带宽拓扑维护、组播树的构建三个功能模块，不再需要部署分布式的组播路由协议。

SDN 简介：

SDN 是来源于斯坦福大学的 Clean Slate 项目组，他们有一个宏伟的目标，就是要重造因特网，改变现有的僵化的网络架构模式，以求建立一个可扩展的高性能的现代化网络架构。2009 年，SDN 概念入围 Technology Review 年度十大前沿技术。 2012 年 4 月，ONF 组织发布了 SDN 白皮书，提出了一种类似于操作系统的思想:把网络中的所有网络设备当成被管理的资源，控制器相当于一个操作系统，管理这些资源。这个控制器抽象网络设备，对网络设备进行维护，并把这些网络设备信息提供给上层应用。上层应用通过统一的可编程的接口来对这些网络设备进行配置和管理，实现相关的网络应用功能，不用再去关心底层的网络拓扑的变动。提出了 SDN 三层模型(物理设备层、控制层、应用层)获得了业界广泛认同。

在 SDN 网络的实践方面，OFELIA、Internet2、FIRE 和 GENI 等科研组织在真实环境中部署了 SDN 网络。华为、锐捷、思科、Pica8 等厂商积极投入人力、物力进行研究，研发出支持 OpenFlow 协议的 SDN 控制器或 SDN 交换机。在 SDN 网络的企业部署方面，Google 把基于 OpenFlow 技术的 SDN 网络大规模部署在数据中心，使网络资源利用率得到了显著提高并且降低了网络运维的复杂度。

SDN 的网路架构图如下所示：应用层主要是完成用户意图的各种上层应用程序，对网络资源的统一管理。控制层的核心功能是实现网络内部交换路径计算和边界业务路由计算、流表控制和下发等功能。转发层主要由交换机之间的链路构成基础转发网络。转发过程中所需要的转发表项是控制器下发的流表，交换机依据流表转发，本身不具有逻辑判断功能。

1533697242600020022.png

SDN 网络架构图

ONOS 控制器

SDN 控制器对整个 SDN 网络架构的性能有着决定性的作用。目前，已经有二十多种由不同语言、不同机构研发的控制器，特别是开源社区提供了很多的控制器，如 Nox,RYU,Floodlight,OpendayLight,ONOS 等。其中，ONOS 控制器是第一款面向运营商的商业级别控制器。支持多种南向接口协议，抽象屏蔽了协议差异性，以高可靠性和高可用性著称，更适合运营商场景。ONOS 的设计高度层次化、模块化、抽象化。ONOS 的内核是由很多遵循同一架构设计的子系统组成的，核心层在设计上遵循“针对接口编程，不针对具体实现编程”的面向对象设计原则，将子系统提供的服务功能抽象成接口，呈现给顶层的应用和底层的协议插件。子系统的结构如下图所示。

1533697290577042200.png

ONOS 控制器子系统结构

• App Component：应用程序通过 AdminService 和其他服务接口聚合消息，被 Manager Component 使用和操作。

• Manager Component：对网络的抽象，是协议无关的，对上提供统一的北向接口。主要包括 Manager 和 Store，Store 则负责数据的存储，查询，更新以及东西向同步等，所有来自 Manager 中与数据相关的操作都会通过 Store 来完成。Manager 也会将 Store 中的事件抛出并实现 ListenerService 接口，其它应用通过 ListenerService 接口即可实现事件的监听。

• Provider Component：Provider 是协议相关的，主要为核心层提供抽象的数据类型，Provider 通过核心层提供的 ProviderService 接口向核心层注入网络信息，Provider 也会暴露 Provider 接口给核心层，接收来自核心层的 command 消息。每个 Provider 需要在 ProviderRegistry 进行注册，才能被 ProviderService 识别。

架构实现

在 ONOS 控制器的适配层、核心层和应用层开发实现 IPv6 组播功能。包括适配层对交换机端口状态的维护；核心层对订阅者信息和订阅者直连交换机信息的维护；应用层对组播路径选择的维护。架构实现图如下图所示。

1533697329516076019.png

实现架构图

带宽拓扑适配器组件实现对交换机及其端口状态的维护，OpenFlowDeviceProvider 类是 ONOS 控制器中已经存在的交换设备抽象类，但没有提供获取实时端口带宽的方式。为了获得实时的端口可用带宽信息，在 OpenFlowDeviceProvider 类中设计了 PortStatsCollector 类。

组成员管理组件需要实现对组播订阅者的维护和订阅者端交换机信息的维护，并通知组播选路模块给组播订阅者选择路径。组成员管理组件的实现依赖设备管理子系统、数据包管理子系统、主机管理子系统，该组件由组播订阅者信息维护和订阅者端交换机维护两部分组成。

组播选路组件，当有组播订阅者加入组播组时，组播选路组件要依据当前的网络拓扑和链路带宽信息为组播订阅者选择传输路径，并且要考虑组播订阅者是新加入一个组播组还是加入一个已经存在的组播组，针对两种这两种情况有不同的选路算法。如果是新加入一个组播组，则组播流量是从组播发送端传送给接收者的；如果是加入已经存在的组播组，则组播流量是从转发组播流量的交换机多端口复制转发过来的。

实验结果

数据平面用 Mininet 模拟器模拟 6 台交换机，Mininet 在 Mininet 模拟器中通过 xterm 命令开启三个主机是一个能够创建包含虚拟主机、交换机、控制器和链路的网络平台仿真器，Mininet 主机运行的是标准的 Linux 网络软件，Mininet 的虚拟主机、交换机、链路和控制器是由软件创建，使之看起来像一个完整的网络。在 Mininet 模拟器中通过 xterm 命令开启三个主机，给组播发送端配置的 IPv6 地址为 fc00::1/64，两个订阅者配置的 IPv6 地址为 fc00::2/64 和 fc00::3/4。三个主机分别运行各自的接收组播流量的程序，输出接收组播流量的来源和接收时间。实验结果如下图，两个订阅者可以同一时刻能收到相同的数据。

1533697375869025277.png

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/163