ONF组织的SDN架构文档——四个架构（三/二）
5.3提供虚拟网络，非递归式的SDN提供商
在第5.2章节，每一个NE都有一个相关的客户agent。它包含着从自身NE中虚拟出来的虚拟资源。概念上的资源是跨度多个物理NEs的，由SDN控制器对其进行扩展。这个章节与5.2章节的主要不同是：这一章节的控制器client可以约定跨越多个物理NEs的虚拟资源；这样，资源在控制器server中是可扩展的。提供商通过在SDN控制器server中定位客户环境需求的完整表现形式，为客户提供了一个完整的虚拟网络视图；并且也避免了server的NEs直接暴露给客户信任域。
一个虚拟网络至少包含一个虚拟NE（VNE）。一个VNE是子网的一个抽象，被控制器视作物理NE来对待。一种极端的情况是（5.2章节），VNE与底层的物理NE是一对一映射的；另一种极端情况是，整个VN被视作一个NE（如图4.15中的Green-1）。在VNE-subnetwork中的链路是隐蔽的，而外部的端口是暴露的。类似VNE上的端口，连接是不受限制的（或者不当成端口，而是通过适配手段连接），都没必要去为它们做担保。VNE上的端口可能最终被追溯到不同的物理NE上。图片5.3中I-CPI显示的I-CPI实例代表了一种中间立场。
“绿”SDN控制器期望虚拟网络看起来像真实的网络，就像5.2章节中的一样。“绿”期望管理常用的操作，像发送简单的转发流规则到NE端口。这个命令实际上是跨度整个子网的。“蓝”通过创建一系列的转发规则来实施这些命令。这些流规则被发送到与“绿”相关的设备上（图4.13）；或者映射这些命令到已存在的或动态建立的隧道中（或是两者的结合）。
因为“绿”VNE在物理上可能跨度多个“蓝”的NEs，因此当“绿”要扩展自己的抽象资源时，可能在同一个地点上就没有物理NE。处于较低层的SDN控制器，为上层提供了跨度多个网络的抽象，就需要对上层的扩展需求负责。因此，agent G的环境必然要从“蓝”NEs移动到“蓝”SDN控制器SDNCB中；在控制器中，它的表现形式是一个由虚拟器支持的，代表着整个“绿”VN的 RDB。反过来，这些代理环境也会向扩展的“蓝”NEs发送必要的命令。和从“绿”控制器扩展南向接口的命令范围一样，“蓝”虚拟器有责任综合来自底层网络的信息，其综合的形式对“绿”的虚拟网络要有意义。图5.3显示了这种情况。
图5.3也现实了第二个客户“红”，它有自己完全拥有的独立VN资源数据库，策略和虚拟器。一般来说，“绿”SDN控制器是自己的NEs的一个协调管理者，同样的，还有来自“蓝”的可见NEs。
“蓝”只在SDNCB上规定与客户相关的信息，而不是在“蓝”NEs中。“蓝”NEs上所有的动作是由SDNCB的DPCF在NE agents0上来执行的。具体是由SDNCB的虚拟器和策略实施者通过一个可信任的D-CPI来将客户信息和动作发送的。对于NEs，这与第5.1章节所描述的是一样的情形。
“蓝”OSS为“绿”执行以下的任务，并且也会为其它客户执行同样的流程：
1.在控制器SDNCB上实例化客户指定的代理，例如agent G。这个过程包括创建主RDB，起码也要创建一个RDB的空架子。
2.在控制器SDNCB上，“蓝”从主RDB分配资源到agent G是通过协协调器功能组件的方式实现的。
作为资源分配功能的一部分，“蓝”可能需要通过SDNCB agent0来建立必要的隧道或者其它隐藏的网络服务，不仅如此，还需要控制合适的瓶颈（OAM,保护，PM）。这些都为“绿”呈现了简单的链路端点资源，但是对于“蓝”来说这些是连通性的服务。
3.为agent相应地实例化一个虚拟器，并且安装策略。虚拟器为底层的DPCF功能和客户RDB操作做翻译工作。虚拟器向“绿”SDN控制器暴露“绿”agent的RDB，也可能是暴露出比第2步形成的资源集合更抽象、更不具体的资源，就像图中所示的I-CPI。这个抽象的不同是：它是来自agent G完整的RDB但是，是受限制的抽象。
虚拟器也是一个策略执行点（PEP）。策略可以保证“绿”得到合同约定的服务，同伙私也可以避免“蓝”的资源被错误使用，恶意使用或者其它的问题。策略也指定了“绿”可以使用的动作（actions）的子集：什么信息可以查询，什么通知信息可以订阅。策略定义了“绿”和“蓝”之间指定的标识符如何翻译。另外，如果有必要隔离多个客户的地址空间，策略也将指定如何将客户流量包装和转换。同之前一样，策略在图中显示为一个加粗的线条，连接着“蓝”的虚拟器和“绿”的代理环境。这个线条的颜色也意味着服务部分被（蓝）拥有，蓝具有加强策略的实权。
4. 建立 IP连接，安全证书等等，允许SDNCG和处于SDNCB中它的代理通信，与此同时还有它的RDB。
“绿”OSS在控制器SDNCG上执行补充操作。除去一个安全关联（note）之外，这个和第5.2节的描述一样。
Note – 如果“绿”SDN控制器在自己的会话中控制个人的NEs，那么很自然地，它就需要和每一个“绿”VNEs建立完整的安全会话（如图5.2所示），不需要知道和关心他们是否存在于agent RDB中。把这些会话通过多路复用技术放到一个单独的容器会话中，只需要单独的安全连接即可。
5.SDNCB可能会为SDNCG的动态查询提供响应附加值的特性，以此来声明或发布额外的资源。这样的查询是与agent G直接有关的，因为在“绿”环境与“蓝”环境间再无其他连接。
访问额外资源仍然需要受到策略的约束，但是策略没必要必须处在SDNCB中。策略也可能是保存在OSS中的元策略，也可能是有各自的OSS根据需要来决定的。在这种情况下，SDNCB会在收到这样请求的时候去查询“蓝”OSS来做决策。当“蓝”授予或回收再利用资源时，需要相应地去更新SDNCB的主RDB和agentG RDB。
或许可以通过用户下载式的特征包来使SDNCB可以用假设问题的形式来响应“绿”的查询，例如要求“蓝”提供价值的，或其他数字资源的选项，因为可能受到“绿”的最大可接受属性的限制。
图5.3显示了“蓝”SDN控制器的一个agent0，它代表着“蓝”的兴趣和“蓝”可直接控制资源的能力，或者代表着“蓝”自己的用途，或者代表着服务“蓝”客户的代理（例如，上面的第二步建立隧道），与此代理相关的虚拟器和策略都会比普通agent的操作域广，且拥有特权。
另外，“蓝”可以通过一个或多个app服务代理支持应用程序，这些程序直接来自SDN控制器，每一个应用是更具RDB和策略定义的。
第5.2章节的结构部署是在特殊条件下推荐的。总结5.3章节的结构优点，可以总结为以下几点：
*“蓝”OSS不需要反反复复地重配置它的NEs为它的客户部分。“蓝”NEs的所有活动是由“蓝”NEs的agents0来决定的，而此时，SDNCB协调所有由“蓝”发放给客户们的服务。客户指定的开通服务只出现在SDNCB
*NEs不再直接暴露给客户SDN控制器，也不在需要为客户提供代理和策略。（数据层的相互连接当然是必须的，但是承担更少的安全风险）
** 整体的复杂性基本没变，但是复杂性迁移到了SDN控制器上。NE的燃尽部分变得简单了。
** 竞争有限的物理资源，例如端口、队列、转发表都直接对控制器SDNCB可见，这样可以由控制器仲裁，使网络最优化。
**非SDN NEs 可以只支持少量的SDN原则，如果有任何的变动，因为多数SDN的特性都是在控制器上实现。
**可以用现存的EMS或OSSs来作为SDN控制器与NEs之间的协调角色（调制器），但这样可能会带来性能和灵活性的缺陷。这样有利于融合现存网络到SDN领域中。
在我们讨论的控制器章节里，第5.3章节是最重要的一章，因为它将虚拟网络本地化（或集中化）到了SDN控制器中。第5.4章节继续展览一种递归式的控制器虚拟化。
图5.4显示了一个递归的客户-服务模型。”蓝”有一些资源，在图中显示在最低层次，但是这些资源并不都是100%的物理网络。“蓝”将虚拟网络服务向一个或几个客户提供，例如“绿”或“粉”。但是与第5.3章节相反，“红”现在是中间商“绿”的客户，而不是直接作为“蓝”的客户。
“绿”0SS和SDN控制器与前几个章节述说的“蓝”服务器表现相同；同样的，“红”SDN控制器和“绿”服务器也很相似。客户端（例如,SDNCR）看不到下面层次对服务(例如，SDNCG)的迭代，并且服务（例如，SDNCB）也不知道自己的客户（例如，SDNCG）提供什么应用。
5.5总结
通过OSS，一个提供商可以为它的客户和应用分配资源和建立环境。
总的来说，一个SDN控制器扮演着一个服务器的角色，应用程序扮演着客户端的角色；控制器向它的应用程序暴露受管理对象的实例集合，并且满足那些应用程序对受管理实例的需求，这些受管理的实例来自数据层的基础设施。应用程序和数据层平面都可以是虚拟的，其最高表现形式就是迭代的层级结构。
在专用资源模型中，服务器分配一个预先协商好的资源集合（受管理的资源）给客户。这个资源的集合是不会改变的，除非商业关系发生变化。
专用资源模型可能需要被扩展为允许共享资源。在可共享资源的扩展中，提供商的策略可以允许客户创建额外的受管理对象实例（代表资源），或者对已有资源设置属性来增强性能。客户也可以放弃花费不合理的资源。
在各自的控制域内，根据需求，客户与服务器都需要保证事务的完整性。
服务器和它的客户们在不同的信任域。有共同的信任域是一种特殊情况。
服务器执行“保证约定服务”的策略，同时保护自己和其他的客户免受流氓攻击。
服务器有责任去隔离用户之间的流量。根据协议，服务器可能为客户提供底层网络的服务，例如隧道和防护。这些功能对于客户是不可见的。
客户代码不可以在服务器的信任域中执行。然而，是允许客户下载应用程序到系统平台上的，这个系统平台也支持服务器SDN控制器的部分和全部功能。因为SDN控制器需要的信息和状态同步无法满足，这样的客户代码将被视为在SDN控制器外部。这样的代码将会通过控制器的A-CPI接入点来与SDN控制器连接。A-CPI的信任域边界在服务器信任域中识别不需要的可执行客户代码。
（未完待续……请看下一篇。转载请注明出处！）
ONF组织的SDN架构文档——四个架构（三/二）相关推荐
- ONF组织的SDN架构文档——四个架构（三/一）
5 控制功能和交互行为 在协调(coordination)功能的辅助下,控制(control)功能是SDN的核心.集中讨论这些内容,同样也是以迭代的方式,这部分另外增加了详细的层次,来介绍了4单元所引 ...
- ONF组织的SDN架构文档——原理与架构构件（二/二）
4.4应用层 图4.4扩展了图3.3中SDN架构里的SDN application块. SDN原则允许应用在业务和策略允许的前提下指定需要的网络资源和行为.从SDN到应用程序层的接口叫做A-CPI.图 ...
- ONF组织的SDN架构文档——原理与架构构件（二/一）
4原理和架构构件 这节介绍SDN原理,形成SDN架构的功能实体和组织关系,随后详细介绍. 4.1原理 ONF从一个较高的视角对SDN进行介绍[1],一些基本的SDN原理在其中有引证,他们的应用在此 ...
- vue前端架构文档_Dubbo分布式架构搭建教育PC站-Vue前端：课程和登录页
srcouterindex.js import Vue from 'vue'import VueRouter from 'vue-router'import Vuex from 'vuex'impor ...
- linux期中架构文档,Linux期中架构 - osc_jbr77wuo的个人空间 - OSCHINA - 中文开源技术交流社区...
1 在构建完模板后 开启虚拟机后 需要再重启一次 以解决网卡不能看见的问题 ########################################add begin 2018-05 ...
- Spring架构文档：程序员（工程师）的圣经
圣经 作为一名工程师,尤其是服务端工程师,在Spring架构大行其道的时候,只有熟悉Spring的架构,才能有未来啊! 一.Spring的架构文档 Spring的架构文档 这个有空的时候,多读读!
- [转]OpenContrail 体系架构文档
OpenContrail 体系架构文档 英文原文:http://opencontrail.org/opencontrail-architecture-documentation/ 翻译者:@KkBLu ...
- uml具有多种视图_UML建模与架构文档化
UML(统一建模语言) 是用元模型描述的,元模型是4层元模型体系结构模式中的一层.此模式的其他层次分别是元-元模型层.模型层和用户对象层. 在原模型层,UML元模型 又被分解为三个子逻辑包:基础包(核 ...
- 脚本文档_创建完美的架构文档脚本
脚本文档 描述 (Description) System views allow us to gain access to information about any objects within S ...
最新文章
- HDU 4300 Clairewd’s message
- VS中编译64位程序以及遇到的问题（E0000235）
- vue教程2-03 vue计算属性的使用 computed
- 2.2.1 Sqoop1的基本架构
- boost::fibers模块实现异步调度的测试程序
- GNU C中的零长度数组
- Android仿QQ5.0侧滑菜单ResideMenu的使用和源码分析
- JZOJ5944信标
- 远程客户端连接MysqL数据库太慢解决方案
- python小例子之8 -- decorator的使用
- 赛锐信息：SAP ABAP 模块化
- 迭代器 in C++
- XCL-Charts圈图
- 主成分分析与探索性因素分析
- AIX补丁中TL、SP、CSP、IF、PTF的含义
- FMEA-MSR步骤三：功能分析
- BugTracker配置
- 在Android运行cocos Demo游戏
- 《数论概论》读书笔记(第一章) 什么是数论？
- 在HTML中添加视频的代码