5 控制功能和交互行为
在协调（coordination）功能的辅助下，控制（control）功能是SDN的核心。集中讨论这些内容，同样也是以迭代的方式，这部分另外增加了详细的层次，来介绍了4单元所引入的原则和组件。总结协调（管理）功能和控制功能的区别如下：
*协调功能执行与向客户分配资源相关的功能，以及根据策略界定这些资源。这些功能出现在单个信任域中。
*当一个资源被分配到客户，资源就有效地属于客户的SDN控制器（DPCF）了，可以在合法策略范围内任意使用。控制器所在的信任域是与它所控制的资源的控制域分开的。
为了清晰，这部分内容被组织成四部分，其复杂程度逐渐递增，每次功能的增加将使其能力增强。相应的，一些内容也会有所重复。这个架构支持最复杂的场景，但是要知道，一个具体实现的复杂性可能会被减少，减少多少的程度依赖于业务需要和投资人的组织情况。
四个场景如下：
1.单人的SDN提供商；
2.有客户的、暴露底层网络的SDN提供商；
3.提供虚拟网络，非递归式的SDN提供商；
4.提供递归式的虚拟网络的SDN提供商
如前，管理者“蓝”被视作是架构最低层的拥有者，而“绿”和“红”是代表着客户。
5.1 单人的SDN提供商；
说到底，所有的网络都是基于物理网络元素（NEs）的集合之上的。从这个层面开始是有益的，考虑NEs的集合构成一个或多个子网，这些子网处于一个SDN控制器的控制域中。图5.1所示的就是这样的一个子网，被提供商“蓝”所拥有和操控。NEs1到NEsn构成了SDN控制器SDNCb（b是下标）的网络控制域（NCD）。这部分的一切都是处在“蓝色”信任域中。
数字圆圈指明这个网络在处于SDN控制下时活动的序列。
1.每一个NE被认为包含一个协调器（coordinator）功能。但对协调器是如何出现的并没有指明。它可以是由“蓝”OSS实例化，或者也可能是NEs的软件部分，设备启动即装载。
通过协调器的方式，“蓝”OSS为每个NE实例代理，图中指定的代理实例为agent0（note）。“蓝”OSS也实例一个虚拟器（virtualizer），来支持agent0；该虚拟器的功能是映射分配给agent0的资源到NE的硬件抽象层（HAL）。
Note - 标识符并没有什么特殊的含义，它是由服务提供商决定的，表示服务商的选择。
2.每一个NE被认为有自己的主RDB，用来为本NE中的所有资源建模（note1）。通过协调的方式，“蓝”OSS把资源从主RDB分配到agent0（注2），分配出去的资源被保存为agent-local RDB。一个代理代表着专用于特定客户的特定的资源，并且为该客户表示执行上环境。在这个示例（case）中，agent0表示NE的资源归“蓝”所有。
Note1 - 没有指定如何填充NE的主RDB，或者也没有指定它要成为独立的一部分。它可能是由“蓝”OSS部分下载的，也可能是由NE中的一个发现函数在初始化的时候填充的，或者也可以简单地只是NE的硬件和状态视图。
Note2 - 不是所有的NE资源必须属于SDN控制器。其中永远禁止访问的资源的例子就有身份、可达性和证书包，这些信息是用来让NE联系OSS的。另外一个例子是由于非同步的非SDN协议造成的，这种协议出现在混杂网络中，用来负责NE中脱离的资源。
3.“蓝”OSS在一些平台上，或平台集合上初始化一个SDN控制器SDNCB，它的功能包括协调器和一个DPCF。“蓝”也在SDNCB中初始化一个主资源数据库RDB，并且可能部分或完全地用自己的资源计划和可用数据库（inventory data base）填充它。
Note - NE和拓扑发现可以是网络自身的功能（第5步）。它可以恰当地帮助SDNCB，使先前预装入RDB的信息和实际探测到的网络一致。当有不一致的情况时，要发出异常。
4.“蓝”为控制器和NE的协调器提供建立通信的信息。重要的信息包括身份，可达性（IP地址，DHCP参数等），以及安全策略和凭据
5. NEs与SDN控制器建立通信。SDNCB使它的主RDB与底层的实际资源一致，例如，多个NE的agent0的并集构成RDB。SDNCB可能也需要发现和审计网络拓扑或者其他的元信息（meta-information），这些信息通常不能被NE的agent0直接访问。
这些资源现在就可以被SDNCB按自己的需求使用了。控制器与NE间的交互被建立成一系列基于NE中agent0-RDB的信息模型的操作行为。
6.通过SDNCB的协调器，“蓝”OSS用虚拟器为SDNCB实例化代理，用来为应用程序层提供它想提供的服务，并用SDNCB主RDB中的资源填充它，同时根据策略，限制提供给应用程序的执行能力。
到这里，“蓝”网络已经准备好，可以将SDN控制的网络服务提供给应用程序客户了。同样的，这个配置过程也显示了一些部署的最终目标（note）。它与最初的SDN规范和实施有较大的兼容性，最初的规范更注重在硬件上的直接实施，而没有去关注商业和控制器功能与网络的可信边界。
Note - 图4.17和图5.3共同呈现了一种案例（case）：配置的方式可以支持更高层次的应用，如解决多租户问题的应用。
“蓝”可能也会通过这个注册过程，提供传统的通信服务，即由传统的管理模块控制的服务，而不是由SDN应用模块控制。“蓝”可以通过SDN控制使用它的NEs，但是不会直接支持网络识别的应用。这对于融合整网到SDN来说是很有用的一步。
5.2有客户的、暴露底层网络的SDN提供商
图5.2显示了下一步全网络的进化范围和能力的演变。这里，服务商“蓝”为客户“绿”提供了一个虚拟的网络SDN服务，在图中，客户“绿”的表示符和下标是“G”。暴露给“绿”的虚拟网络被抽象到只包含挑选的端口和供应商支持的资源，但是是直接映射到“蓝”的物理网络元素上。VN暴露给“绿”的可能因此是图4.12或4.13，而不是图4.14或4.15。后续的章节将会放开这个限制。
Note - 这种配置在实际的开放中是不推荐的；将会有解释说明为什么。第5.3章节描述了较受欢迎的一种实现，这种实现移除了NEs的复杂性，有利于SDN控制器；移除了客户的虚拟VEs必须由一个提供商的NEs提供的限制，并且不需要直接与不可信的客户控制器相连以及直接和服务提供商的基础设施相连。
在网络服务可用之前，“蓝”和“绿”必须协商一个商业和技术的协议。至于是以何种方式协商就不属于本文档讨论的范围。我们只需知道，“蓝”和“绿”的0SS都对它们共同的技术协议有了解。与必要的资源相同，商业协议在“蓝”与“绿”的网络之间，也指定了数据平面的接入点（handoff points）。在某些情况下，这些接入点都是可以由网络自身检测到的，但是它们通常还是被希望通过OSS（note）预先装入到控制器。
Note - 作为一个策略的问题，可以想到“蓝”是不会随意暴露自己的网络端口的，第三方服务商也不会。如果“蓝”发现来自“绿”的某信号在一个不期望出现的设备端口出现，例如由于接线错误，“蓝”就会产生一个异常，而不是去接受它，这样做只是为了安全别无其他用途。只有在有限的环境中——像数据中心——才可能把端口视作无差别的开放可访问池。
出发点是“蓝”完成了第5.1章节描述的配置过程。
1.“绿”OSS在它自己控制的合适平台上实例化一个SDN控制器SDNCG。用5.1章节的方法维护架构的一致性，SDNCG包括一个协调器，一个DPCF(数据平面控制功能)，还需要至少一个主RDB的架子。“绿”可以在此之后添加虚拟器和应用代理，如第5.1章描第6步描述的。
“绿”OSS可以预先用信息模型，也即“蓝”提供给它的部分或全部资源来填充它的主RDB，同时也将对资源（note）的可操作行为、权限等附加信息填充进去。这些动作（actions）的例子包括创建CFM MEPs或者设置性能，监控收集点的信息，并在超过阈值时发出警报通知。这些资源和册率可以知道SDNG的执行，并且可以被用来审计资源和能力。在第5步我们将看到这些用途。
Note - “绿”OSS 也规定了访问与安全的策略，用来管理“绿”SDN控制器和多个“蓝”的NE代理的通信。
2.异步地，“蓝”OSS为“绿”实例化代理，在相关的NE上指定agent G。
3.根据商业和技术协议，“蓝”OSS为“绿”分配资源和建立策略。协调器逻辑上将资源转交给agent G的RDB。在图5.2中，用深蓝色的条来表示避免“绿”对“蓝”有非授权企图的策略（note）。策略实施在虚拟器功能组件中。
Note - 图中也显示了与“蓝”的策略与自己的agent的关系。提供商特殊领域的策略在接下来会讨论。
4.“蓝”OSS服务商提供SDNCG的身份，可达性和安全信息给每一个NE。这样做是为了允许让SDNCG和“蓝”NEs中的agent G可以通信。当“蓝”支持除“绿”以外的其他客户时，每一个客户的agent-controller的关系有它们自身的通信策略和证书。
5.“绿”SDN控制器SDNCG和每一个NE中的绿agent建立共同的通信。SDNCG可能会上载或审计每一个agents G的RDB，以此来填充或调节自己的主RDB，然后SDNCG就可以随意使用分配到的资源了。
“绿”-“蓝”间的客户端-服务端关系是多对多的。“蓝”可以用上面同样的流程，来为多个客户支持多个专属的agent。“绿”SDN控制器也可以协调来自多个不同提供商的VNs，和它自己直接管理的NEs。
“绿”现在可以通过实例化出虚拟器和代理来支持自己的每一个应用客户端，来从自己的主RDB中为代理们分配资源。
“蓝”有全部资源的信息以及对资源有完全的控制权，可以决定是否要把资源提供给某个代理。“蓝”有没有自己专用的代理并没有强制规定（note），也可以有自己的代理，标识为0。如果这样一个代理存在，策略将会赋予它扩展的或特定范围和权限。提供商代理策略可能会阻止“蓝”去操作已经赋予给“绿”的资源，但是也可以强制要求不接受过这个阻止。
Note - 如果“蓝”的NE不是SDN控制的（如混杂网络）那么这种情况下“蓝”OSS将不会实例化一个专用的“蓝”代理。
“蓝”有义务处理属于自己（提供商）的问题。其中这些问题可以由“蓝”OOS通过NE协调器来负责；其他的问题可以由“蓝”OSS来管理，其工作方式就像SDNCB的应用客户端，因此也是通过多个agent0 在策略特权内执行操作。其他的操作就需要SDN控制器自己的逻辑去驱动了，例如，再优化资源分配。
“蓝”提供商的功能，举几个例子：
*“蓝”以服务的方式，将管理的资源隐式地或显式地提供给“绿”。最主要的一个例子就是通道（tunnel），也即是服务层的网络连接端口对客户层网络可见。“蓝”也会操作自己的通道来OAM（Operations,administration, maintenance），保护或恢复，性能监控，测量或策略，等等。来作为服务的保证。这些服务层的细节对“绿”是不可见的。
* 缺陷检测，报警定时和声明，失败信息从D-CPI通过虚拟器向受影响的agents传播。
* 基础设施安全监控，当意外发生，向“蓝”OSS报告安全警报。安全监考、安全日志。
* 为了维护的目的，可以将底层的资源移出服务范围（或管理锁定），然后通知收到影响的agents（可用状态标记为不可用）。
* 在一些事件发生时，重新分配和声明资源的功能。如，当客户的业务关系发生改变时；有瞬变（transient）要求时（即，客户要请求预定的资源或者先来先服务资源分配方式，只要在签订的“保护伞”商业协议范围内就可以满足）；持久服务（客户协商增加资源，不再需要给定的资源，或者业务关系终止）。资源的重分配也可能是由于网络扩建或者全网的再优化。
* 管理几个客户协商的共享资源，这是为客户提供最好的体验，可以用权重或者优先级的方式来分配资源。
* OSS交互能力，像前面提到的。
* 通知SDNCB代理（agent）G失败
至少，以上一些“蓝”的功能影响到的资源和状态对“绿”是可见的。因此“蓝”agent0和协调器与agent G是有轻微整体和部分的关系。“蓝”agent0 或协调器可能从agent G收到资源请求和异常，并且从“蓝”资源空间中交流通知和其他信息。在上面的一个例子中，“蓝”管理“资源锁定”就必须触发至少一个通知到SDNG，如果不发送的话，NE自身就会保护“绿”的资源不被侵犯。
“蓝”与agent G 的集成可能在NEs中，也可能是在SDNCB中。
策略加强是在虚拟器功能模块中实施的。策略的特点包括：
* 允许客户使用他们想用的任意地址空间是一件很一般的事情。在任意客户选定的层，用封装的方式可以隔离客户。封装的技术是由提供商的策略决定的；特定的参数需要在agent RDB中保存。
*封装对于客户是不可见的，不管是在客户的虚拟数据平面还是在客户的控制器平面都不可见。代理与控制器之间的指令和回复都需要用客户的地址空间，但是代理必须把它们翻译成封装的格式（note）
Note – 如果openFlow-switch被用作控制协议，packet-in/ packet-out功能和转发表实体必须剥离它们各自的封装标签（或翻译）包括在北向以及南向接口。
* 客户希望通过他们自己的规范来识别他们的资源。虚拟器在客户与提供商之间做身份转换。至少，（在这种情况下）在RDB中，一些客户的命名规范能被”蓝”OSS识别和安装。这也是作为业务和技术在数据平面接口端的协商。
* 策略实施点必须在客户上下文环境中翻译事件和动作，不止翻译名字。硬件设施错误或者管理锁定，例如，可能要翻译端口掉线信息到几个不同的客户控制器，并且要触发客户的各式各样的保护或恢复行为。将资源赋予给客户agent时，要想客户报告创建对象的通知，而删除资源的时候也要向客户报告删除对象的通知。
SDNCB和SDNCG可能都需要订阅通知，调用警报通知功能（这里经常把功能称作控制），更具阈值建立PM搜集点，等等。但是“绿”只在自己可控的资源范围内。作为一个可以加强SLA监控能力、提升客户与提供商环境之间的故障排除能力，SDNCB要能看见“绿”的视图以及通知信息。（未完待续……请看下一篇。转载请注明出处！）
