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提供的限制，并且不需要直接与不可信的客户控制器相连以及直接和服务提供商的基础设施相连。
一张单程车票，一颗潇洒的心。
