4.4应用层
图4.4扩展了图3.3中SDN架构里的SDN application块。
SDN原则允许应用在业务和策略允许的前提下指定需要的网络资源和行为。从SDN到应用程序层的接口叫做A-CPI。图4.9显示SDN应用自身就可以支持A-CPI代理，用来为其他应用层次提供查询功能，这将在4.1部分中介绍。应用层中不同层次的应用，根据器所处的层次高低会有不同程度的抽象。
注：SDN社区经常把A-CPI叫做北向接口（NBI）或北向API。参考2.3部分
一个SDN应用可能会调用其他外部服务，也可能协调多个SDN控制器来达到某个目的。OSS链路和coordinator功能识别除了上面的功能。与架构中其他组件一样，SDN应用需要一定数量的前提知识作为环境和操作角色。
*一个应用层实例可能作为一个信息模型服务器，这种情况下，它发布信息模型实例给其它应用所用。通常，其它应用是作为客户，与SDN应用服务代理交互的，如图4.9所示。
*一个应用层实例这种情况下，它操作有其他服务器实体公布出的信息模型实例。这个服务器实体可能是一个SDN控制器，或者是一个底层的应用
*一个应用层实例可能同时扮演着以上两者的角色。例如，一个路径计算引擎（PCE）可能依赖于一个SDN控制器提供的虚拟网络拓扑信息（维护路径管理数据库），同时也为SDN控制器提供路径计算服务
应用与控制器之间的A-CPI活动，典型地包括查询或者通知虚拟网络状态，并且下发命令去改变其状态。例如，去创建或修改网络连通性、路径或修改数据层中节点间数据流的处理方法（指定带宽或QoS）。A-CPI接口可能也会用于其它额外的功能，例如，作为注册服务的接入点来注册服务链，服务链可以贯穿一层或者多层4-7个服务（note），或者作为输入来控制虚拟网络的功能。
注- 在网络行为方面，服务链是通过一些合适的组件集合来监视网络流量。在A-CPI增加值可能有指定一串组件功能的作用，这些功能供SDN控制器选择，以便找出最优的功能实例，应用的相关的流转发规则中。应用程序也支持组件属性的编程，甚至在拓扑中产生新的虚拟网络功能实例。
图4.10显示了终端用户系统可以出现在数据层和应用层范围的可能性。一个终端主机或网络应用可以使用这个模型。防火墙或者DDOS检测器可以作为这个模型的应用案例:终端客户可以发信号以告示它的存在或者得到期望的状态（note）。
注– 例如，微软的Lync客户终端可以报告或请求某特征的服务，然后一个集中的协调功能就会就网络资源实例出一个回应。
A-CPI的特征将在下面更具体地陈述（6.8节）
4.5 虚拟化
SDN的控制（control）与管理（management）部分必须设计成在抽象的、虚拟的资源上进行操作。虽然有连续的虚拟层，但是虚拟资源追根到底是对物理资源的包装。虚拟化是通过一个共同的信息模型来表征物理资源的特性。这部分描述了虚拟化网络资源的可行性。
我们都记得，SDN的数据层就是一个网络，由一些转发流量或产生流量的节点构成，消耗，存储，以及处理流量。这些节点被称作网络元素（NEs--network elements），它们被链路相互连接起来。NEs为客户端设备（clientequipment)以及其他的网络提供外部数据层端口（port）。因为SDN可预见的优点是基于集中式的管理，所以SDN控制器将控制不止一个NE。
下面的内容，对抽象和虚拟化的过程循序渐进地展开。首先，从一个假设的提供商环境（蓝色部分）开始，然后扩展至代表着特定客户的虚拟网络（绿色和红色）。
图4.11重用了图2.1来作为例子网络，这个网络为“蓝色”所拥有。途中的矩形代表着网络元素(NEs)。线条代表着链路。这些链路可能复合的，也可能是过度型的，传输着相同的或不同特征类型的信息，而且这些信息也可能是被保护的也可能是虚拟的（例如，网络中的客户层：由底层网络服务层提供服务）。开放的端点（endpoints）表明是数据层的流量接入点（handoff points）用来与外部的网络设备相连。外部的端口（ports）被两个客户使用，分别是“绿色”和“红色”.
考虑到真实网络的规模和复杂性，图4.11中所示的图已经是对底层物理网络的一个抽象。
提示：抽象是把实体中我们感兴趣的特征表现出来，同时对无关的特征隐藏或概述。虚拟化就是针对特定客户或应用的选择需求进行的抽象。
图4.11中，有选择的特征抽象反映出简化真实网络的意图。
图4.12显示了同样的底层网络抽象，且已经被提供商“蓝”为客户“绿”提供了抽象。这个图中显示“蓝”为“绿”在每一NE和连路上保留了资源。网络拓扑因此显示的和之前的图一样，但是4.11中的NEs已经被虚拟网络所替代，成为VNEs（note）。之前为客户“红”所标注的端点也都消失了。因为保密的原因，“蓝”承诺“红”必须从这张图中隐藏自己的网络细节。
VNEs在绘画颜色上的不同。在这个例子中，VNE代表着NE资源的子集，这个子集归客户“绿”所管。同样地，虽然在图中没有显示，但是链路的容量和性能都有所削减，只为“绿”客户保留了它所有的资源能力。
如图所示，底层网络包括冗余资源，可以明显地容纳许多可能的链路和节点故障。但是，假设客户“绿”并没有准备支付冗余设备。然后，虚拟网络（VN）的图就不再是4.12的。提供商“蓝”就可能分配缩减的VN资源给“绿”，只提供必要的连接，但是没有多余的可见路由冗余（note）如图4.13所示。
注 - 由于链路可能是内部保护，不能肯定客户“绿”的VN没有冗余，但是显然它的可用资源比之前的拓扑少了，网络的能力也变弱了。这幅图的作用就是用来解释：简单的VN是可以不受保护的。
到目前为止，所有virtualizations在“蓝”网络提供商空间存在，并且提供商为客户“绿”识别属于它的专用资源。
一个VN（子网）还可以被抽象到一个更简单的VN。提供商“蓝”需要一个分配给客户“绿”的内部资源视图。然而，“绿”可能并不关心看到所有的这些资源；它们与“绿”的使用并没有关系。另外，由于策略的原因，“蓝”也不愿意暴露自己的网络细节。因此，从“蓝”提供给“绿”的VN的可见视图可能是更进一步抽象过的。例如，与“蓝”自己的视图比更加不具体。图4.14呈现了一个可能的VN，这个VN通过共同的CPI（图4.16）由“蓝”提供给“绿”。每一个VNE是一个由“蓝”保留的资源集合，其表现会像图4.13一样，是更细粒度的模型。
总结以上内容：“蓝”SDN服务提供商的控制器需要知道各个层次的抽象，但是视图4.13只是为其内部使用。对内部预定的资源命名是“蓝”提供商自己决定的事情。被预定的资源对象实例（ports，虚拟NES）通过CPI(图4.14)对“绿”SDN控制器可见，其命名是由“蓝”“绿”协商得到的。标识符可能是预先按合约商谈的，也可能是通过CPI在运行时协商的。
如图4.15，“绿”也可以协商得到最简单的可行VN，一个简单的VNE，用一个矩形显示（客户视图用绿色，提供商底层视图用灰色）。客户“绿”可能指定这个VNE叫做“Green-1”。
假设“绿”想创建一个转发规则，例如在它的端口G1和G25之间（或者是把G1H和G25的两个IP子网连通）。对于“绿”的SDN控制器，它看到的是视图4.15所示的抽象NE，因此只需要发送一条转发规则到这个“交换机”中。“蓝”的SDN控制器需要翻译“绿”的这一条指令来建立转发规则，在视图“4.13”的环境下重新解释这条指令以满足“绿”的需求。然后，将这个规则映射到蓝色网络（视图4.11）。如果“绿”的指令是用IP表达的转发规则，那么“蓝”就需要在底层网络中的第三层（L3）的节点来实施这个请求，将其映射到已有的通道或者是映射到新建立的通道。下面段落进一步详细地讨论。
虚拟化的一个重要原因是“蓝”提供商必须把“绿”的流量与其他的客户隔离的流量隔离，而且这种隔离的需求是在对绿没有任何了解且没有合作的基础上进行的。有三种情况，其中任何一个可以沿着在端至端路径特定链路中使用。
（a）用例1：隔离可以通过物理途径达到；例如，如果“绿”协商要求使用专用媒介，波长/频谱或者直流时段。
（b）分组业务可能需要隔离，如果不能保证不同的客户端之间不存在的地址空间重叠。地址的唯一性担保可能需要在数据层（data plane）的转发端口（handoffpoints）用访问控制列表强制执行。如果还有封装的需要，可以用以下两种方式实施：
I. 用例2：由一个附加的封装层的方法，例如用VLANIDs服务（S-VIDs）[10]
II. 用例3：在同样的层，通过网络地址转换（NAT）的方式映射
选择封装方式是“蓝”策略的问题；它的实现细节对“绿”是不可见的。“蓝”在选择网络端口时，可能是选择边界设备（在端口G1和G25之间的资源），也可能没有这个必要。“蓝”改变来自“绿”的流量为隔离形式，然后再逆转这个格式到“绿”网络所在的输出端口。“蓝”的基础设施转发封装的流量，通过自己的网络所在的地址空间。
在蓝的基础设施中，封装的隔离可以采取隧道的形式。这些都是“蓝”的服务层的子网连接，而显示给“绿”的是简单链接。为了建立转发关系，“绿”只需要将流量映射到正确的隧道近端和远端连接端点。“蓝”可预先配置子网连接作为提供给“绿”VN的一部分。如果蓝可以拦截绿色的转发请求，蓝色也可以动态创建隧道。在任何情况下，“蓝”就伴随着隧道的建立去提供必要的功能，例如OAM和保护。隧道设置和操作对“绿”是不可见的。
“绿”的管理人员，对如何使用他们的VN会有不同的需求。例如简单的连接请求（像之前提到的）或者更详细的控制。图4.16展示了“绿”如何在自己内部对所得到的VN（如图4.14）进行进一步的抽象，抽象到单一NE,如图4.15所示。如图所示，该抽象（及其随后的解释）可以完全在“绿”自己的空间内完成，并且完全不需要涉及到“蓝”的规范等相关知识。如果“绿”只关心边界端口（edge ports）的连接，以及其他应用程序处理的性能优化，这可能是合适的。
图4.16也显示了“蓝”如何分配资源，以给另一个客户“红”提供不同的VNs
假设“绿”打算升级到一个更高的可用性服务，要求（可见的）路由冗余。服务提供商“蓝”可以重新修改底层VN，从图4.12恢复冗余资源的部分或全部，但就没有必要在CPI上更新由“蓝”提供给“绿”的VN。“绿”会看到改变，但能感觉到预期的可用性提升。
数据层的进一步思考
以上所示的网络已经被严重抽象以突出讨论的要点。一个不太抽象的视图可能揭示出重要的附加信息，例如该子网是多层（note），这意味着端口和链路可能（也可能不会）支持不同的特征信息。链路可能是复合的，并可能有多个端点。层之间可能需要适应。一个给定的层可能具有能力的极限，资源开销需要加以控制的，特别是对于操作者，管理和维护（OAM）层。为了网络得到更好的生命力，冗余技术可能在一个或多个层被利用。
注 - 在分层网络中，为每种技术将控制器分开是值得推荐的，例如在分组和光学层之间。这个架构既不指定，也不排斥技术层（technology layer）的分离。
这些方面都是重要的，但需要大量的额外规范，因此特定领域的ONF工作组（WGS）将把他们包括在架构和信息模型开发上，例如，光传输、无线和移动工作组（WGS）。从该文件的角度来看，可以认识到对状态和结构的需要远远超出了简单视图所暗示的。正如第4.3节所指出的，这些状态和结构中的一部分可以从SDN控制器中转移到数据面（data plane）的硬件和软件中。
4.6管理（Mangement）
管理部分负责基础设施支持的任务，这个任务不会由应用、控制器以及数据平面本身去执行。管理部分也会根据策略或其它原因执行限制操作：对应用、控制平面（controller-）、和数据平面的行为进行限制。或许，限制这些任务被SDN控制器组件执行的唯一原因就是SDN控制器可能处在一个客户信任域中；而商业上的原因是任务的核心管理和支持功能在提供者的信任域内完成。虽然代理策略可以被使用，达到完全信任控制器，但透明的策略和策略执行软件仍然必须由供应商的管理员来安装。出于安全原因，默认情况下建议不要暴露什么任何信息。
SDN架构的识别出经典的管理功能，如设备清单，故障隔离，软件升级之类的，但对于它们在很大程度上超出SDN范围。SDN其中一个好处就是允许客户（外部信任域）来执行多数管理动作，当前这些动作还是由管理系统执行。随着时间的推移，传统的OSS接口预计将扮更小的角色，通过SDN控制器，作为客户端应用将担负更多的责任。
在SDN的范围内是SDN特定的管理功能，即记录和表达提供商和客户之间的业务关系（策略），并配置SDN实体环境和初始化参数。其中包括协调数据平面连接点（handoff points），识别约定（identification conventions），可达性和逻辑与物理实体（entity）之间的凭证。SDN架构需要把这些信息注册到相应的SDN NEs中，控制器中，以及应用中，但是不指定OSSs的属性和结构。
通常情况下，在每一个数据平面、控制器和应用层实体之间的客户端-服务器对处在不同的信任域（如图4.1）。其中，信任边界存在于SDN层次结构中，相应的信任边界也存在于管理域。在本文档中，管理者即OSS系统，在不同信任域可能需要交换信息，但这种交流超越了SDN架构的范围。
有两个管理角色是公认的：服务器管理和客户管理。服务器管理的责任与那些客户机管理的责任是不一样的。
两个管理器共同的责任：
*为它们的独立实体分别配置，以便它们可以彼此通信。这些配置信息包括：一致性、协议选择、可达性、安全策略和证书。
服务管理器的责任：
*实例化服务器环境中的代理，用来代表真实的或虚拟基础设施中客户指定的环境。这包括资源分配和策略的安装，并有可能下载客户定制的或特殊功能的模块。客户指定的配置可能包括协议或发行级别（例如，OpenFlow-switch1.3）的选择。服务器自身感兴趣的SDN控制功能（SDN control）是由处于服务器信任域（note）中的代理提供的。
Note – 第五部分消息描述了代理的功能
*同时更新客户特定（或定制、指定）的资源配置和策略。这可能是由于诸如业务重新协商或有新增网络而导致，或响应请求来释放合同中约定的按需计费资源。一个特例是当业务协议终止时，删除一切与指定客户相关的资源。
*审计业务承诺的资源分配和策略的合规性的。这包括确认资源不重复预订、单独的客户流量相互隔离。用于此目的工具，包括通知在内还有如安全警报或连接故障通知。
*订阅通知服务（notification）以及为了SLA监控、安全监控、故障管理、计费、网络规划，或其他目的而订阅的收集统计数据信息的服务。这些都是现有的功能，除了可能在（实现）细节上不同外，基本保持不变。
客户管理器的责任：
客户管理的责任与服务管理的责任相似，只是从相反的角度出发。
*客户端SDN控制器（或应用程序）需要的信息可能不能从服务中发现，特别是数据平面邻接在外部网络的端口信息。如果是这样，客户管理必须提供这些信息。
*虽然客户SDN控制器可以从下一层的代理得到资源视图，客户管理还是希望能够实例化出一份属于自己的、有关合同商定的资源和策略的视图。这可能有利于协调，或有利于客户控制器的审计能力。相对于已经发现的资源和动作，对预期的资源和动作（actions）审计可能是一个重要的安全特性。
*操作之前和操作过程中，服务器管理要保证该客户得到不超过合同指定的更多服务，而客户管理要保证它得到不比合同规定少的服务。客户管理可以查询性能或状态信息，或从它的服务控制器代理订阅运行时异常和性能监控通知服务，以帮助这一评估。
管理器本省可以是一个业务或运营支撑系统（BSS/OSS），一个网络管理系统，或者甚至是一个单元管理（element management system ）。这个文档使用属于OSS来包括所有的可能选择。关于OSS更加详细的能力以及OSS内部通信已经超出了本架构的讨论范围。
特殊的情况下，客户和服务可以在同一信任域内存在的，这样可能会有利于简化架构的边界通道（border crossings）。图4.17显示了在一个信任域内，一个通用的管理接口通过SDN控制器。
图4.17中的虚线显示了在一个信任域中，SDN控制器如何代理管理模块，在OSS和应用之间（或NE之间）建立通信。这也展示了数据中心（DCs）中部署SDN常用的方式。云/数据中心管理系统是一个典型的应用，它的NEs和SDN控制器（note）在同一个信任域中。SDN控制器可以直接实施需要的管理功能，代理那些其他地方已经实施的。
Note - 在这个例子中，cloud/DC管理系统将会自己负责安全相关的考虑，如隔离租户之间的信任域。在这种情况下，只有它自己扮演着SDN控制器的角色。
4.7信息模型
在软件定义网络中会有种类繁多的组件来提供各种需求服务，这些组件之间又有多种多样的通信协议。然而，减少协议的总类是合情合理的，这个架构没有强制要求专用协议。重要的是，所有通信实体共享一个共同的信息模型。不能把它与常见的数据表现[7]（representation）混淆在一起，它是一个协议的问题。确实，当环境许可时，信息模型的元素表意可能含蓄，不像协议传达的明确信息。
这个架构模型的SDN的操作，通过各种接口操作被管理的对象的实例（MOS）。对MO实例的操作包括大家熟悉的CRUD：创建，读取，更新，删除；以及对MO类中定义的方法调用和订阅通知。因此，信息模型是架构的核心功能，会随时间的变化而变化。
信息模型是一个描述架构的关键组件。此架构建议灵巧地去重用已有的信息模型。信息模型不必是来自广泛的工业界，工业界的模型也不能直接或完全就引入到SDN信息模型。适应SDN环境需要考虑SDN特殊的特性和最佳的实践经验。然而，生成的SDN模型需要选择和记录，以便它可以被SDN之外的社团所理解和使用。这样可以压缩学习曲线，并促进向现有架构融合的过程。
从ONF的工作中可能出现新的信息模型，这些模型应该得到工业界团体的反馈，这样才是最好的趋向标准化的道路。
（未完待续……请看下一篇。转载请注明出处！）
