ONF组织的SDN架构文档——概述（一）

1.适用范围

        这个文档描述了SDN架构。文档的目的是为ONF工作组未来的工作做详细指导和说明，同时也可以作为ONF对外交流的一个参考文档。它的姊妹文档（框架文档）描述了ONF想要达到的设计目标。此文档只是从一个较高的角度描述了达到此目标的一些方法。

       SDN架构从一个较高的角度出发，给控制器指定了参考点和接口。架构描述了大量SDN控制器和NE（network element）内部的功能。其中架构图中所示的功能模块并不是都要求实现。且内部的核心功能模块的接口也并没有指定。

        SDN控制器和NE具体指定的行为只限定在需要互操性的部署实施上。注意，此架构并不指定接口间具体使用的通信协议。

*注：接口间备选的协议包括OpenFlow switch（OFS）[2]和OF-Config（OFC）[3]

        SDN架构允许一个SDN控制器管理大量数据层资源。大量不同数据层的存在，SDN提供一种可能性来同一、简化不同资源的配置工作。

此架构也意识到，如果SDN成功，它必须能在现存的、有很多不同参与者的环境中能够可实施，如包含不同组织、企业的环境。这就引起了有关策略和信息共享的安全边界的新的需求。现实世界中有很多约束条件，如与现存的企业和业务的支持系统共存的需求，以及其他类似的管理和控制技术领域。在不太复杂环境中，例如有限规模的企业网络，从原有的架构中借鉴并选取适当功能子集形成自己的架构。

        SND架构建议，当使用一些通用的模型和机制可能会减少标准化、集成、验证工作时，建议使用它们，这就意味着在行得通时尽量使用现存的标准或者公认的好的做法。

        一个系统架构把一个系统分割成不同的模块，通常用于控制复杂度，用于允许独立运行和软件代码重用，或者用于满足其他技术或商业目标。然而，没有中性的设计。选择使用组件划分的方式（其中组件间的接口已经定义且组件间的协议是开放的或专有的）会对最终交付给终端用户的服务的种类产生深远影响。因此一个架构必须选择并决定如何把系统分割成多个模块，这些方式和理由都在此文介绍。架构应是基于合适的原则而不是拘泥于细节来建立的，这样做是为了以后在ONF工作组或应用中，当需要做大量的各种决定时能够通过之前早已指定的、清晰阐述的原则，使得做决定更加的容易便利。与此同时，架构也认识到， SDN应对的环境十分复杂，需要进一步的扩展和说明。

这个文档具体的目标包括：

a)定义一个SDN架构

b)提供信息模型开发的基础

c)详细的描述实体，允许函数和接口定义的派生

d)提供一些指导和一个在ONF工作组中活动的框架

e)作为一个参考手册，关于扩展，错误，遗漏，和其他合适的变化

f)作为一个评估和比较各种声明是符合SDN架构的各种解决方案的一个参考。

g)促进SDN技术定向于工程师、架构师、和解决方案专家

h) 在整个SDN社区提供更多可被利用的价值

2 定义、缩写以及约定

2.1 定义

2.2 缩写词

2.3 约定

3 SDN概述

        这部分用两种形式描述此架构，图3.1是个从高的视角来描述架构的概况，图3.2则尽可能简洁的描述架构的关键的地方。剩下的部分讲解此架构的起源，解释此架构，及扩展引用。

3.1描述性概况

        最初的观点认为SDN分为基础结构层，控制层，应用层（在本文中将使用数据层，控制层和应用层代替）。基础结构层包括网络单元（NE），SDN控制层通过它的南向接口使用下层NE提供的服务。应用层通过控制层的北向接口（NBIs）发送请求。控制层作用是接受应用层的应用请求后启动相应的底层NE完成应用响应。由于网络资源有限，SDN会根据算法解决资源竞争问题。

        上述概念需要进一步改进，此文定义了一些 函数、接口、组件，解释他们之间的关系，并指导信息模型的开发，但是不过分细化具体规范。

        一些概念上的修正表明，一些控制不可避免的仍然存在于各个层中，而不是全部在控制层其它层没有。但是我们感兴趣的是一个SDN控制器和它相邻的实体。同一水平的群组称为plane，而网络中使用layer（层）术语。

        图3.2使用修正过的术语，添加了管理功能，而一些的简化的SDN模型没有管理模块尽管一些管理函数可以被应用层接口（A-CPI）而替代，但是一些管理功能是必不可少了。如在数据层，在最初建立NE、设定SDN控制部件、配置SDN控制器时是就需要管理功能，在控制层，管理模块就需要配置一些策略，来界定对SDN应用的控制范围，同时管理模块还需要监视系统运行状态。在应用层，管理模块一般用于配置SLAs（service level agreements），在所有层，管理模块配置SAs（security associations），使得各个分布式模块能安全的进行相互交流。

        上图中在通过接口相互传递的信息通过建模形成一个与协议无关的实例。

        SDN预测未来客户端应用可能会直接拥有SDN控制器的访问权限，动态和细粒度的控制网络资源。

        意识到供应商和客户之间有一个商业边界的可能性，因此通过SDN架构确定出一个SDN控制器和使用此控制器的应用之间的商业或组织机构界限，这是很重要的。因为提供商和客户是在不同的信任域中。

        不同颜色表示不同信任域，每信任域有自带的管理功能。信任域在逻辑上可以扩展成其他信任域的组成部分。意思是说如下图，绿和红在蓝色信任域中，逻辑上扩展意思是说蓝色区域的管理员管理在其中的绿色和红色信任域的代码的安装和管理。

        agent蕴含着共享和虚拟化底层资源的含义

        agent是指NEs的端口由SDN控制的（而不是混合或继承的端口）或者是指面向SDN应用的虚拟网络的细节是由SDN控制的，但是同时要使一个客户的服务于另一个客户的相互隔离。在SDN控制器中，不同的代理通过网络在横向角度从不同程度的抽象，在纵向角度不同的函数集，来显示其控制作用。SDN控制逻辑的任务是对来自所有SDN应用的网络请求进行映射和仲裁，然后转化成相应的控制NE资源的命令（NE资源必须能被该代理使用）。NE和SDN控制器中的协调器安装客户特有的资源和来自管理器的策略。混合代理商可能同时在任意个NE和SDN控制器中存在，但是逻辑上只有一个管理器接口，因此每一NE和SDN控制器中只有一个协调器。

        Clause4中将进一步思考SDN原理的含义和应用，然后介绍一些重要的实体，他们的函数和交互包含此架构。

        因为SDN控制器是在此架构的中间位置clause5将夸大控制层函数和接口，clause6介绍应用注意事项。

        在【4】附录中的文章也总结了ONF SND 架构 本文的架构和引文中有矛盾地方以本架构为先。

3.2对架构的简明描述

        Figure介绍了SDN架构主要的构件和接口。对于构件的物理实现本架构没有说明。

数据层（Data Plane）

数据层包含是一个包含一个或多个NE的集合，每个NE是一个流量转发或流量处理的资源集合

资源指对底层物理实体的抽象。

控控制层（Controllerplane）

控制器的集合。每个控制器有独占一组资源的权利，这些资源是由数据层中一个或多个NE提供。

Clause4.3.5介绍资源如何按照尽最大努力或先来先服务的原则进行共享的。

SDN控制器可以额外的添加接口。

SDN控制器最基本的功能是响应应用的请求，同时使得各个应用相互隔离，

为了实现此功能，一个SDN控制器可能和其他的对等的控制器、附属控制器、或非SDN的环境等交换信息。

SDN控制器一个通用但是不是必需的功能是在一个反馈环路中担当控制单元的，对从错误中恢复、对重新优化资源配置、或其他事件等网络事件作出响应

应用层（Application plane）

应用层包含一个或多个应用。每个应用有独占一组资源的权利，这些资源是由控制层中一个或多个SND控制器提供。

可以有额外的应用接口

一个应用可能调用其他应用或与其他应用协作。一个应用也可能担当SDN 控制器的角色。

Management

每个应用、SDN控制器、NE都与管理员有个基本的接口，管理员最小功能是从低层的资源池中分配一些资源给高层中特定的客户实体，建立可达性信息，来允许低层和高层实体间相互交流

可以有额外的控制功能模块，由于一些约束条件，应用、SDN控制器、或NE能独占给定的资源。

Administration

每一个manager与它所管理的资源都处在同一个管理域

ONF 协议

OF-config protocol用在management接口的功能模块处

OF-config protocol用在D-CPI可能用在A-CPI的功能模块处

（未完待续……请看下一篇。转载请注明出处！）