ONF组织的SDN架构文档——原理与架构构件（二/一）
4原理和架构构件
这节介绍SDN原理，形成SDN架构的功能实体和组织关系，随后详细介绍。
4.1原理
ONF从一个较高的视角对SDN进行介绍[1]，一些基本的SDN原理在其中有引证，他们的应用在此有简略的总结，在后续章节中有更详细的介绍。
*控制器和数据层的分离原理
这个原理要求控制层和数据层可分割，但是也要知道，控制依然能在数据层中被执行。在SDN控制层和NE之间的D-CPI通过此方法定义：SDN控制器可以代理NE重要的功能，同时也能持续了解到NE的状态。clause4.3列出了在SDN控制中哪些NE功能应该被代理和哪些功能应该保留的标准
*逻辑上集中控制
与设备自身控制相比，集中式的控制器能从更广阔的角度来看在它控制下的资源，对于如何部署这些资源可能会作出更好的决策。考虑到网络资源全球化不断增加，但是对网络资源缺少详尽了解，去耦和控制权集中化使得可扩展性得到改善。出于对SDN网络扩展或安全边界的考虑，SDN控制器可能被迭代开发，变得拥有丰富的功能，在clause5 中有介绍此问题。
*向外部应用开放抽象网络资源和网络状态
在任何抽象水平和粒度下，应用都可能存在，由于北向接口要求抽象程度提高属性通常被描述成不同的抽象程度。因为接口是用来公开资源和状态的，应用和控制器都有接口，所以，应用和控制之间的差异就不明确了。相同的功能接口在不同使用者眼中可能是用处不同的。就像对于控制器而言，各个应用程序可能以对等的方式交互，或者以C/S形式。
网络资源抽象和应用（经由A-CPI的应用）声明的原理要考虑网络的可编程性。使用有关资源和状态的信息，通过SDN控制器，应用可以详细描述它们的网络服务需求和要求的变化，也能够通过编程的对网络状态作出反应。
进一步，分层次地迭代应用/控制器层的概念和信任域的概念也让应用程序得以创造，使应用程序的创建可能变成组件的组合，把组件应用程序组合成一个更全面的服务。
SDN架构通过识别基础功能实体、定义实体间不同的接口需要交换的信息和操作，来阐明以上提到的原理的含义和影响。这个架构进一步把这些功能实体分解为最基础的功能组件集合，这些功能部件基本不能再分解。
该架构引入信任域边界的概念，这对广泛的商业化是很重要的。此架构在特定的可信任域中定义组件，并对其他信任域开放自己的参考接口（reference point）。强大的抽象障碍有利于保护相关人的商业利益，同时也有助于识别和适应不同的信任关系。架构的一致性有助于促进安全措施的设计和审核。
从一个较高的视角看SDN，SDN垂直架构是服务器把信息模型实例公布给客户端，基于信息模型实例，客户可以执行创建-读取-更新-删除（CRDU）和规范操作。这也强调了一个通用信息模型的重要性。从这个角度来说，management管理功能的职责是实例化信息模型和开放层间接口的执行力的策略，尤其是在不同的信任域之间的接口能力的开放。Figure4.1阐明了，C/S架构（控制器/代理）模型在多个SDN控制器构成层级结构时的环境中是可行的。
等级层次结构有两个目的：
缩放和模块化：每个连续的高等级都有可能向更高的抽象和更广的范围发展。
安全：在每个不同的信任域中，每个层都可能存在。为了加强域间的安全，层接口可作为一个参考点。
在递归的层次结构中，一个SDN控制器或一个应用可能把自己当成一个信息模型实例的直接控制器，此信息模型实例代表一个合适抽象的虚拟网络（VN）。从这个参照中，它支持一个数据控制器层的接口，D-CPI。无论是一个NE（或者虚拟NE），或另一个ＳＤＮ控制器，或者甚至是个应用，他的下级实体把上级实体看成一个应用，由Ａ－ＣＰＩ支持。从一个全局视野来看，其中一个或者所有这些接口可能以中间件ＣＰＩｓ（intermediate CPIs ---Ｉ-ＣＰＩＳ）的形式出现。于是出现了一个结果是，除了物理NEs以外，一个给定的实体可能占用数据层或控制层或应用层中的任意一个，这取决于观点和角度。
所有北向接口会公开管理对象实例供客户使用，但是出于不同的抽象等级。
在任何一个递归层次中，一个资源被理解为是只服从一个控制实体的。然而一个SDN控制器可能支持任意数量的D-CPI实例，下层资源是不受一个以上的D-CPI实例支配的，也没有被某个SDN控制器支配的资源。资源分配到哪个可信域的是mangment的功能。
注：clause4.3.5介绍资源共享
有些应用有原子语义要求，也就是说事务完整性（ＡＣＤＩ的性质 atomicity, consistency, isolation, durability）因此应用引起的全局扩张和抽象的操作也就暗示了事务语义存在于每一个下层，并且一直向下到到硬件。进一步说，失败的事务不能有滞留的资源。每一个等级都递归地精心安排它下层实体的事务语义。
注：分布式的事务完整性带来了很大的代价，它可能不是在任何情况下都是必须的。如果事务完整性不被支持，应用者应该考虑使用其他方式从事务失败中恢复过来，特别是有手工分配的资源的恢复。在一些情况下，内置的超时足以恢复滞留的资源。
４.２数据层
数据层包含直接处理客户流量的资源，同时含有必要的支撑资源以保证合适的虚拟化、连通性、安全性、可用性和质量。
Figure4.4相较于3.3，对NE资源视图进行了扩展。
SND关注于流量转发和流量处理功能，比如QoS（Quality of Service）、过滤、监控或跟踪。流量通过物理或者逻辑接口进入或离开数据层，可能被导入导出转发或处理模块。流量处理过程通过OAM引擎（操作（Operation）、管理（Administration）、维护（Maintenance））、一个加密模块，一个虚拟网路模块。可能是SDN控制器来控制流量转发模块和流量处理模块，也可能是实现部署的与一个给定的SDN控制器相关联的独立的机制来实现模块的控制。数据层使用在控制层作出的转发决策。原则上它不能自主制定转发决策。但是控制层可能会配置数据层，使得数据层能自动响应网络事件比如网络故障，或者使得数据层能支持如ＬＬＤＰ，ＳＴＰ，ＢＦＤ，或ＩＣＭＰ交付的功能。（链路层发现协议(Link Layer Discovery Protocol、Spanning Tree Protocol、BidirectionalForwarding Detection、InternetControl Messages Protocol）
D-CPI包含如下功能：
*实现RDB公开的所以功能的可编程控制
*Capabilities advertisement
*事件报告
数据层代理是在数据层中执行SDN指令的实体。
通过数据层协调器的management模块来分配数据层资源给不同的客户代理并建立管理使用资源的策略。
在此架构中各个层的代理和协调器服务于同样的目的，对此的介绍在Clause5中
在递归的最底层，数据层资源如包括软交换机（soft switches）在内都是物理实体。在更高一级的抽象层，数据层资源不必是物理实体，比如虚拟NEs。就其它层来说，SDN架构运行在一个抽象的数据层模型之上，只要此模型advertised的功能被正确运行，底层的差异对于架构来说是透明的。Clause4.5讨论虚拟化。
Management chooses which resourcesin which NEs are to be controlled by a given SDN controller
Management选择在NEs中被一个SDN控制器控制的资源, 在5.1中介绍相关的操作。这些资源被当成虚拟NEs（VNEs virtual NEs）的集合，这些资源相互连接形成一个子网。在P37中的figure 4.14中介绍了，通过连续的抽象，VNE可能自己就是一个子网。
此架构没有对数据层的技术强加任何的限制。SND控制器可能使用已经存在达到技术来编写数据层比如DWDM，OTN，Ethernet IP等，或者在一个新出现的数据层技术上进行编写。4.3控制层
尽管在其他层中都存在不同程度的控制现象（这也是为什么叫做控制器层而不是控制层的原因），但是SDN控制器层中才是存在控制器的层（含有一个或多个控制器）。本章介绍SDN控制器的功能组件，以及该组件与其他控制器和其他administrative domains 的关系。会面会介绍，不是所有的SDN控制器功能都能分配给特定的功能组件；此架构认为，分配一些对于本部件来说多余的功能是没有意义的。
4.3.1概述
此架构没有详细说明SDN控制器的内部设计。全文中提到的控制器中的功能组件只是为了解释说明用的。
SDN控制器逻辑上是集中式的
*控制器通常有子网范围，该子网可能跨越单一物理NE
*与其他实体没有资源冲突；SDN控制器被认为是虚拟资源的拥有者，而这些虚拟资源是management分配给SDN控制器的。
功能和服务（服务是控制器外部可观测行为的一部分）包括完全可见的信息模型实例。依据环境，可能需要的额外的功能如下：
*拓扑知识和路径计算（为了实现这些功能控制器可能调用其他服务）
*通过更高级别的抽象资源创建和抽象资源维护来为他的应用程序建模，使用的资源被强制执行的策略所限制。资源的虚拟化和控制可能是递归的。
SDN控制器应该用于协调大量相关的资源，
并且分布于大量次级平台，在此过程中，SDN控制器有时还要保证事务完整性。这就需要精心orchestration了。由于orchestrator自身具有的功能，orchestrator有时被当做一个SDN控制器，但是低级别控制器作用于受限制，于是不排除使用低级别SDN控制器的需要，在SDN控制器自己的控制域内执行orchestration。
4.3.2 SDN控制器
此SDN架构没有详细说明SDN控制器的内部设计和应用。它可能是一个单一的整体过程，它也可能是一个相同进程的联合，用来分担负载，或者用于彼此防止故障发生；可能是一个功能组件的集合，每个组件不相同，各个功能组件相互协调；他也可以为他得功能订阅外部服务，如路径计算。这些可选项的任意组合都允许，SDN控制器被认为是个黑盒，根据外部可观察的行为来定义它。控制器组件可以在任意的计算平台上任意的执行，包括一个物理NE的本地计算资源。控制器组件也可能在一个分布式的、可能移动的资源上如在数据中心的虚拟机器上（VMs virtual machines）
此架构从SDN原理中（clause4.1）得到SDN控制器必需的外部行为。
其中一个原理是实现逻辑上集中控制，下面探究此原理；这里足可以说明SDN控制器被理解成是拥有全局作用域的，（SDN为了一些全局性问题存在的）同时也足以说明组件应理解为用来共享信息和状态，由此导致没有其他Block的需要考虑来自控制器的冲突或矛盾的命令。Tothe extent that the OSS affects resources or states, it is subject to the samecoordination requirement with any SDN controllers that may be involved.
多种manager或控制器组件可能有网络资源的结点写访问权限，但是为了遵循SDN原理，他们必须也要：
a)被配置成能够控制资源或活动的不相交集合，或者
b）能与其他manager或控制器组件相互同步，使得让他们不发送前后不一致或矛盾的命令
注1:在对分布式网络资源的分布式计算控制中，严格的状态同步可能会带来过多性能或复杂性的代价。最终状态收敛而不是严格收敛的应用是未来一个研究的主题
注2从underlying数据层资源来看，控制器的内部一致性假设和状态一致性的问题相分离。总是希望SDN控制器能处理相关的事件，这些来自基础结构不同部分事件是异步可见的.
对于自举，同步，事件迁移，备份，审计，控制器软件发布管理等都属于“黑盒”SDN控制器的内部要做的工作，不是SDN架构的事，于是在本文没有介绍，而不是忽略他们的重要性。
4.3.3 SDN控制器功能模块
虽然SDN控制器是个黑盒，但是在概念化控制器中的一组最小功能组件集合时是很有用的。也就是说ＤＰＣＦ（data plane control function）协调器，仿真器，代理，（原文有介绍这四个概念）。为了实现逻辑上集中式的要求，ＳＤＮ控制器可能包含任意附加功能，一个ＲＤＢ（ｒｅｓｏｕｒｃｅ ｄａｔａ ｂａｓｅ）为现在的信息模型实例和必要的支持功能来建模。ｃｌａｕｓｅ５详细介绍ＲＤＢ和他的划分。
4.3.4控制授权
尽管一个重要的SDN原理是数据层和控制层去耦，但是在数据层中的代理同样可以行使控制，就像ＳＮＤ控制器一样，有控制能力，但是没有把它放在控制层中。进一步讲，很多都有控制的模块都可以考虑在ＮＥ中使用运行，如OAM，ICMP，MAC learning，neighbordiscovery，recognition andintegration, protection switching等。
对与去耦原理，一个稍有不同差别的解读是允许ＳＤＮ控制器把一部分控制功能下放到数据层，这些功能按照控制器方式运行。这个解释对于在现实中使用ＳＤＮ原理很重要。
符合以下条件的是鼓励控制器把一些控制功能模块放在数据层的：
*网络事件需要快速实时响应
*大量流量需要处理
*面向字节或者位的功能，不容易被分包，例如重复性的SDH多路复用段开销
*低价值、可能不断重复的，可预测的，容易理解的，完全标准化的行为，如加密，BIP，AIS嵌入，MAC learning，CCM交换
*控制器出故障或者重新初始化时的生存能力或持续性能力（Survivability or continuity ）
*在数据层silion中一般可被访问的功能如保护开关状态机，CCM计数器或时钟
*把功能模块拆分出来没有太大作用
假设原始数据可以达到，SDN控制器通常可以选择不delegate a control function,但是可以选择自己执行必要的操作。上面的准则会告诉我们如何选择是具有实用性的。
在决定是否delegate a function时，SDN控制器必须明白delegate function的candidate替代者能不能完全满足他的需求。这可能需要内置或者配置的知识，并且是/或者是需要查询candidate的功能和能力。
来自delegatedfunction的通知建议使用publish/subscribe模型。通知的例子：
*被授权的控制功能模块可能被要求需要做报告
1状态或属性值的改变，如端口的开关，操作状态的使能或禁用
2针对性能监控(performance monitoring (PM) )计数器的TCAs（Threshold crossingalerts 超过阈值报警）
3硬件故障，恢复，初始化，因为这些活动会影响SDN控制器控制范围内的资源
4手动或自动保护开关事件和结果
在数据层的授权控制功能模块可能执行标准的协议，汇报中间结果或最后的结果，异常或状态改变。
例如：
1 通讯加密，包括密钥交换和更新
2 CFM: 802.1ag or BFD
3 802.1X authentication agent
4 GMPLS ，提供SDN控制器，使用信号接入方式穿过administrativedomain 域界限，此时SDN可能不再被支持
4. 3.5共享资源
在图4.2中的数据层模型中是假设资源是给客户或者应用使用的，在一个专用的资源模型中，很少有机会增加基础资源的使用效用。一个解决此问题的方法是约定使用尽最大努力共享资源的方式，可能同时使用优化的并加权的通讯约定。资源共享特征的扩展是可能实现的，例如，资源的提供者可以储备一些未授权的资源用于响应用户请求时分配（同时进行相应的记录），是按照先来先服务的原则，或者按照预先商定的顺序分配。
最大化资源的利用率意味着这些资源可能被超额认购。
一个客户请求一个非专有的资源，可用的资源可能不足或者根本就申请失败，所以客户必须能够处理这些意外。对于不能获得共享资源的可接受程度可能事先提供者和客户达成约定。
另一种资源共享的方式是，每一用户得到一个资源的一小部分，例如一条连接的20%的带宽。在一些简单模型中如用户需要拥有所有管理目标实例，此时不能使用此方法。在能使用此方法情况下，一些此类资源可能静态分配，而不是等到有需求请求是才分配。对于上述的超额认购问题可以一定程度避免。
SDN控制器有责任管理分配给多个用户或应用的资源，无论是动态还是静态的，对于每个相关用户使用共同的标准。请求的改变和资源的释放时会引起一些优化，通过资源提供网络来实现。此架构没有把此责任分配给某一个特定的SDN控制器组件。
4.3.6 多管理域（Multiple administrative domains）
在figure4.4中介绍一种情况，每个administration有自己的网络，这些网路是相互连接的。拓扑和figure2.1相同，但是颜色改变，不同颜色表示不同子网的拥有者。
图4.5中多个子网组成成了administrative domains，并抽象视图，并用红色代表重要的事情。也就是说红色的能看到它自己NEs的所有细节和端口，但是蓝色和绿色被抽象的尽可能简单。
假设每个administrations都有SDNC（SDN控制器）无论什么颜色
Figure4.6显示了红色SDN控制器联系的方式
（a）绿模块提供一个服务，能够无缝的包含绿色和蓝色。为了红色域。蓝色的资源租给绿色。红蓝之间没有业务联系，红蓝之间资源相互联系只能通过绿色提供的虚拟的方式
（b）没有特别的理由让绿色作为红色的服务提供者，所以如此图一样变换位置
（c）红色与蓝绿都有合约关系
第四种选择，在administrativedomains中红色可能有个数据层切换点，它和administrativedomains没有SDN programmaticrelationship（例如蓝色没有对同等域提供SDN控制的可见性）红色SDNC可能认为它网络中的这个模块静态不提供连通性，例如作为一组管道，或者运行传统的路由和信令协议去学习可达性和建立到达或通过这个域的连通性。
本文其他地方介绍架构时考虑到了下面这种情况：当SDN控制器通过A-CPI提供服务，需要这种服务的客户却是另一个SDN控制器。如在4.7中白色表示客户SDN控制器或是网络感知应用程序，可能会部署大量服务控制器，When server controllers are orchestrated from a common point,基本上这个SDN控制器不需要同他周围的控制器交流，在此，如果此客户服务器为了使得服务器控制器之间可以进行有限的信息交流而进行一些优化措施是允许的。使用到的原理是逻辑上集中式控制：客户控制器可以授权控制功能在其他地方，只要他能完全能了解到对他们来说有价值的状态信息就行。
4.3.7Controller-to-controller coordination
此小节考虑如下情况：存在大量对等的SDN控制器，但是没有更高级别的SDN控制器来对他们进行部署。在把SDN控制器分离成不同的对等域时，可能会考虑如下多个方面：
*控制器可能来自不同的提供商，这些提供商之间没有实现互通性
*控制器或者底层基础设施可能被多个不同administrative组织使用或拥有
*控制器可能使用不同的技术或服务功能模块
*网络节点数或者地理跨度的可延展性，包括广域网和局域网之间的不同
*等等
在通常情况下，一个通讯服务会横跨多个数据层NCDs（network control domains），可会又经过某个不在SDN控制器控制之下的域。这些服务就需要在相关的SDN控制器和没有使用SDN管理、控制或信号传递的域之间进行协调。对等信息交换通常被称为C2C（controller-to-controller）注意在C/S关系中的控制器之间和有信息联系但是不是C2C因为不是对等网。
Figure4.8中有四个网络控制域（NCDs）NCD1…NCD4,并画出他们的SDN控制器了。图中白色和蓝绿有直接的联系但是和红色只是间接联系，NCD3是个没有SDN控制器的域，NCD3中结束或需要跨越NCD3的服务必须使用处在的信号或路由协议或者预先达成的约定。当控制器之间交流信息需要跨过另一个administrative界限（同时也是商业界限）时，安全问题和有关信息隐藏及信任的问题就成为一个重要的问题。
控制器之间信息的交换可能含有如下内容：
*SDN控制器邻接和能力发现
*数据层邻接和拓扑发现，达到策略约定程度
*状态和信息交换，包括状态订阅和属性改变通知的能力。
*与信息转发相关的信息，如到一个或多个层可达性
*路由计算信息利于路由计算代价，保护或恢复策略
*其他信息例如OAM配置，QoS评估和汇报，有关billing的使用信息
在最低软实时限度内操作要达到同步，例如在一个域中建立loopback point，然后在不同域中调用一个loopback测试，最后释放loopback point，这些信息交换通常在没有SDN控制的域中也是相互兼容的，现在的信息交换使用的是已存在的协议。至今，no C2C usecase requirements have been identified that cannot be satisfied with existingprotocols, possibly with minor extensions.进一步的商谈和策略交流才是需要更深的研究。随着SDN的不断成熟，为了更好的实现SDN C2C而开发一个新的协议的需求是未来的一个课题。
注意使用现存的协议实现的C2C关系的安全性被认为是已存在的规范和best practice的事情，如果新的协议被提议，安全问题就是新协议重要的问题了。