2.7.3 分析节点
系统提供所有分析组件的完整高可用性功能,类似于配置节点,分析节点是无状态的,分析节点的失效不会导致系统丢失信息,当一个分析节点失效,系统查找服务器将会将会把功能转移到一个可工作的分析节点上,并且所有上行REST API同样使用查找服务器去检测节点的失败和功能节点的转移,失效的分析节点将会从可用的节点池中剔除,剩下的分析节点中的一个将会执行工作,收集数据和处理查询。
OpenContrail提供数据库组件的完整的高可用性,数据库集群设置有多重备份的属性,当数据库节点失败,数据本身可具备弹性,集群可以在多个数据库节点失效时具备弹性,当数据库节点失效,分析节点可以平滑的从失效节点到可用节点上,在这个过程中,我们将会把数据队列清空,在转移过程中数据的丢失将会非常小。
2.7.4 虚拟路由器代理
虚拟路由器的高可用性基于包括BGP在内的很多路由协议的平滑重启,如果虚拟路由器代理因为任何原因重启(崩溃,升级),虚拟路由器的转发平面将会基于由虚拟路由器代理在重启前安装的转发状态继续转发数据。
当虚拟路由器代理失效,虚拟路由器的转发平面运行在一个“无脑”模式,所有的转发状态都是保持原有,当虚拟路由器代理重启,将会重新和冗余的控制节点建立通讯关系,并且从控制节点上重新学习状态,重新在转发平面上安装状态,替换原由的状态。
当虚拟路由器代理完成从控制节点的状态学习,完成转发平面内的状态重新安装,所有转发平面的状态全部被刷新。
2.7.5 虚拟路由器转发平面
如果虚拟路由器转发平面因为任何原因(崩溃,升级)重启,将会影响特定服务器的流量处理。
这种情况不可避免,因为我们在每一个路由器上只有一个转发平面和转发实例,所以,保证路由器的越简单越好,减少崩溃和升级的可能,是非常重要的。
3 数据模型
系统所有状态的基础,不管是配置,运行还是分析,都是数据模型的集合。每个数据模型定义了组件的集合,语意,以及他们之间的关系。系统运行在他们的数据模型上来执行工作:创建和更新组件和关系,转换“高层级”组件到“低层级”组件,安装低层级组件到网络环境中,创建所需要的连接和服务。数据模型提供确定的性能给可供操作的模块,并且为模块定义确定的需求。数据模型如此设计的主要结果是系统具有分布式,可灵活,高可用性,易于升级和具备弹性。
数据模型是从本质上从表层提供一个具有注释的图表来展现组件,和通过连接展现组件之间的关系,系统使用一个数据模型语言(DML)Data Modeling Language 去定义他们,一些组件的语意和他们之间的关系,在数据模型中直接体现,例如图表的表层可以展示抽象或者具体的组件,并且连接可以展示一对组件之间是“父子”关系还是从属关系。剩余的语意可以通过表层或者链路的注释来描述,一对表层之间的连接链路可以注释上需要的带宽,路由实例之间的链路可以注释需要的路由策略(译者注:vertices翻译过来时顶层,最顶的意思,实际上个人理解就是在ppt里面画图上的最上层的图标)
3.1 程序模型
配置和运行状态的数据模型使用IF-MAP定义,其自身数据保存在一个Cassandra数据库中,这个数据库提供持续的,可用的和可扩展的规格参数。一个使用Redis的“发布订阅模型”总线覆盖在顶层,作为内存关键值存储。模块和数据库互操作,可以选择定于制定类型的更新,当模块发布一个更新到一个组件,更新会发布给其他订阅该类型组建的模块。
数据模型的所有修订必须具有向后兼容的能力,从另一个角度说,参考数据模型的程序必须可以和以前一样持续工作,而不需要修改。这就意味着对于数据模型的改变只能扩展现有组件,连接和注释,但是必须不能改变现有组件的语意,或者他们之间的关系。进而,修改永远不能和一个组件或者链路类型相悖。例如组件之间的关系可以向后兼容,可以修改到数据模型中的未来需求必须是增量的,注入到现有运行模块的改变,而不需要重新编译。
访问数据模型是经由一个RESTful API,从模型定义自动产生,进一步,为其他语言(Python,Java等等)的绑定也会产生,允许成需要使用这些语言在模型中操作数据。
运行在这些数据模型的模块必须是事件驱动的。这意味着两件事:第一,一个模块必须监听“发布订阅模型”总线的更新;第二,当得到特定行为所需要的所有信息时,就要执行行为。更新可能来自任何顺序—发布订阅模型总线不会保证更新的顺序或者管理归属—这是每个模块的责任。进一步说,模块必须要可重启,如果崩溃,或者强制重启(如更新),将会重新连接数据库,重新请求状态并持续处理。为完成这些,一个模块必须要通过数据模型或者“这个网络”保持所有数据库的非临时状态,模块可以重新从对等体请求状态信息。最后,模块必须是有弹性的,他们必须具有分布式的工作特性。实例必须依据当前的负载决定创建或者终止。完成这一目标需要分布式数据库保持数据模型,并且具有分布式的条目(例如为独立的ID产生)协调服务(译者注,这段比较晦涩,也翻译的不是很准确)
3.2 配置和运维数据模型
数据模块包含一个层次化的模型,呈现成一个树状的,带有注释的直连非循环图表(DAG)。DAG的顶点展现的组件可能是管理名称,或者是物理或者逻辑的资源。DAG之间的连接体现的是组件之间的关系。一个组件可能有0个或者多个子集但是必须有一个明确的父集(除了根之外,根不需要父集),删除一个组件就会隐形的删除下面的子树。一个组件可以参考另外一个组件--用一个“参考点”作为维护。删除参考的组件就削弱参考点。删除显著参考的组件是不允许的。可以不存在组件的“弱参考”,一个组件的“弱参考”可能被删除。(译者注:这段是描述组件之间的关系,意义不大,可以看下面的图就会理解的多一些)
如图20所示,DAG的根层下面显示的是系统的多个领域的组件,例如“管理域”(AD),可能是一个数据中心集群,一个POP节点,一个办公网中心,或者是一个广域网。一个AD具有一个全局的管理员去进行管理,AD还有一个为内部可能使用的标识关联的命名空间。例如,IP地址,域名和路由实例ID的标识。
一个AD中包含一个或者多个租户或域,举例来说,DC内的租户可能是可口和百事。在POP或者CO的租户可能是业务客户或者宽带业务的服务部门。
一个租户可以包含多个项目,租户中的一个部门,例如市场部将作为一个项目存在,项目包含虚拟网络(VN),DC中的一个VN可以包含一个应用层的一系列虚拟机。POP上的VN可能是为企业客户的VPN,使用类似策略的一组移动宽带用户,或者是企业网络中的一组用户。
一个项目包含服务实例,网关和策略。一个项目同时具有安全组,管理员可以制定“规则”到端点,这些规则可以为端点定义未来的策略。
虚拟网络VN包含端点,在DC域,端点就是虚拟机,对于业务边缘,端点就是客户站点(CE),端点作为安全组中的一部分,可以参考安全组。
数据模型的其他组件是路由实例“RI”,一个VN会编译进入一个或者多个RI,在虚拟路由器里面部署,另外其他的组件是RT,用于控制RI之间的路由泄漏。
在数据中心中的内容做了层次化的部署,但是这种部署已经足够包含其他领域。在一些案例中,层次化的特定层级可能是冗余的,在这个案例中,一个独立的实例可以用在这个级别去维护层级。举例来说,如果租户的概念不需要,那就是一个租户作为作为部署的基本租户层级,如果需要新的层级,那么必须向后兼容(译者注:这部分的内容主要是介绍业务的部署模式层次化,例如,把数据中心分成多个租户,然后每个租户下面还可以开启多个部门,每个部门下面在开启project,然后在划分VR和VN,当然,如果环境比较简单的话,就意味着数据中心只有一个租户,这个租户有没有部门没关系,开启project,然后划分VR和VN,具体看下面的图表会比较容易理解)
假定层次化的一个新的层级-部门—部署在租户和项目之间,可以很简单的添加进来,当然,这种需求可以向后兼容,这就意味着三件事
1.部门必须是层次化中的可选级别,这就意味着,必须可以直接在租户下面创建项目并且也可以在部门下面创建项目
2.一个项目可以作为租户的子集存在,直到这个子集被删除。
3.一个新的项目可以作为租户或者部门的子集,但是不同属于两个。
同样,一个应用,如果请求一个租户的子集,就必须准备接受其他类型的子集,可以简单的忽略他们,但是一定会引发问题,或者造成失败。(译者注)
前面的图表左面显示的是做为租户和项目之间父集-子集关系的数据模型,在项目上的虚线连接一个新的级别—部门,右面是数据模型的一个实例,有租户t1和项目t1.p2,用橙色表示,这是原始的数据模型,同时也展示了一个部门t1.d1,并且另外一个项目t1.d1.p1,用紫色表示,这就遵循了修改后的数据模型,注意每一个项目只能属于一个父集,橙色项目t1有自己的父集,紫色项目t1.d1也有自己的子集。
3.2.1 高层级和底层级数据模型
所有的组件和关系存在于常见的数据模型。在高层级和低层级内部的组件也有些区别。配置状态需要考虑通过外部系统(协调系统或者应用)创建的组件,并且作为高级数据模型的一个部分,例如租户和项目。模块创建的组件处于运行状态,同时也要作为低层级考虑的部分,因为他们处于内部网络环境的抽象层中,如路由实例。一些组建需要同时被配置和创建,在高层级和底层级均有涉及,例如RT—会被创建,同时也会配置,使得系统可以和外部的BGP speaker通讯。
进一步说,一些物理设备条目也会显示在数据模型中。举例来说,每个服务器上的虚拟路由器的实例都会显示,系统感兴趣的每个BGP speaker(在控制节点内部,同时包括OpenContrail的对等体,例如DC网关)也会显示。最终,物理和虚拟的平台也展示出来,这些组件用来监控BGP或者XMPP会话,以及他们之间的服务链接。
3.2.2 服务连接数据模型
一个服务“链”既是在跨越两个VN对之间数据流的标准,从VN出来的流量可能在到达另外一个VN之前通过仲裁图示经过一个服务节点,流量可能会基于服务选择不同的路径(例如,一个IDS可能指引流量到一个DPI引擎),或者为了监控的目的复制流量。
服务链的定义包含两个部分:从入口VN,到设置的服务部分,在到出口VN的流量路径和应用在每一个服务部分的服务模板。如图所示,每一个定义都会注释到组件上。
4 OpenContrail使用案例
OpenContrail有三个当前可用的应用案例---企业的私有云架构即为服务(b)和运营商的虚拟私有云,网络功能虚拟化(c),本文并不能全面的提供完整的应用案例,但是可以提供一个应用案例的简单描述。
4.1 数据中心领域应用案例
4.1.1 数据中心内部协调器的职责
在我们深入探讨数据中心应用案例规范之前,讨论数据中心内部协调器的职责是非常必要的。
在数据中心内,协调器(Openstack, CloudStack, VMware, Microsoft System Center, 等等)管理着数据中心多诸多关键要素。
- 计算
- 存储
- 网络
- 应用
SDN控制器的职责是继续应用的需求协调网络和网络服务(如负载均衡和安全),并指定计算和存储资源。
协调器使用SDN控制器的北向接口在抽象层的最高层级协调网络,例如:
- 为租户创建一个虚拟网络,在数据中心内部或者是跨越数据中心。
- 为租户虚拟网络附加一个虚拟机
- 连接虚拟租户虚拟网络到一些外部网络,例如互联网或者VPN
- 在一组虚拟机或者租户网络的边界应用一个安全策略
- 在虚拟网络中部署网络服务(例如负载均衡器)
SDN控制器的责任是将这些抽象层高层级的请求转化成物理或者虚拟网络设备上实际的操作,例如:
- 物理交换机,如架顶(TOR)交换机,汇聚交换机,或者单层交换矩阵
- 物理路由器
- 物理服务设备例如防火墙和负载均衡器
- 虚拟服务-例如虚拟防火墙
4.1.2 虚拟多租户数据中心
虚拟多租户数据中心使用案例允许多个租户存在于一个数据中心,多租户意味着租户共享同样的物理基础环境(服务器,网络,存储)但是逻辑上彼此分割
租户的概念着在不同的描述下可以有不同的定义
在运营商数据中心提供公有云服务,是一个客户或者是客户的一类服务
- 在一个企业数据中心部署私有云,意味着可能是一个部门或者是为用户提供的一个服务。
- 因为一些网络架构(特别是常见的点到点VLAN)具有每数据中心4096个租户的限制,所以,租户的数量很重要。
不是所有的数据中心都是多租户,一些大型内容提供商(例如Facebook)具有私有数据中心,仅作为内部应用,目前还没有提供云服务。尽管这些数据中心可以支持多租户行为,但是并不去使用多租户的定义。
例如,早期的亚马逊网站服务(AWS)支持多租户,但是从网络方面去看租户并不是相互隔离(所有的租户连接相同的三层网络),直到亚马逊引入一些高级服务(叫做虚拟私有云-VPC),允许每个租户可以获得一个或者多个私有隔离网络。
图23介绍了在不同市场划分下虚拟化和多租户的需求,虚拟化的使用,不同的市场分段使用不同的协调器和hypervisor。
- 在企业市场方面,商业协调器被广泛使用,随着云的逐渐采用和向SDN的演进,也存在和开源(如OpenStack或者CloudStack)集成的需求
- 在架构即服务(IaaS)和公有云市场,开源协调器(OpenStack,CloudStack)和hypervisor(如KVM,Xen)经常被使用,可以用于定制化,开销和扩展的原因。
- 大型内容提供商(如Google和Facebook)经常建设他们自己的协调器软件并且不使用hypervisor(因为性能和 扩展性的原因)(译者注,这段只能赞同一点点)
通常情况,如24图所示,每一个租户相当于运行在物理服务器上的虚拟机的集合,hypervisor包含虚拟交换机(vSwitch)连接虚拟机到物理网络和其他虚拟机,应用也可以直接运行在物理服务器上(不是在虚拟机中),如右侧的绿色服务器(B)现实。
在图24中,数据中心网络可能会有多层网络,或者在图25中,数据中心网络可能是单层网络(如Fabric)
服务器使用物理数据中心网络互联,在图24中,网络分成两层(接入和核心)网络,也可能是三层(接入,汇聚,核心)网络,或者一层(如Q-Fabric)网络。对于overlay解决方案中,数据中心网络建议是Layer 3网络(IP或者MPLS)。
在最简的网络架构,如图26所示,云提供商为每个虚拟机指定IP地址,给定租户的虚拟机不在同一个L2网络中。所有的虚拟机(从同一个租户或者不同的租户)可以通过路由IP网络相互通讯
例如,亚马逊网站服务,弹性计算云(EC2)默认给每一个虚拟机一个私有IP地址(可以在亚马逊EC2网络里互联)和一个公有IP地址(通过NAT和互联网通讯),当虚拟机建立后,亚马逊自动生成私有和公有IP。亚马逊EC2弹性IP地址功能指定有限的(默认五个)静态IP(给租户用于分配给VM)用于和互联网连接。
在一个网络中隔绝租户里面的相互访问,每一个租户可以被指定一个私有的L2网络,如图27所示,租户网络允许虚拟机和其他同一个租户的虚拟机相互访问,除非是策略限制。租户网络相互之间隔绝,一个租户内的虚拟机不能和其他租户的虚拟机相互访问,除非被特定策略允许。同样,除非是特定策略允许,虚拟机不能实现互联网访问。
租户私有网络通常成为虚拟网络。在给定的租户网络中的所有的虚拟机在一个L3子网。租户可能允许允许使用他们自己的IP给虚拟机,或者云提供商可以分配IP地址,任何一种方式下,在不同的租户里IP地址可能不唯一(如相同的IP地址可能用在两个不同租户的两个虚拟机中)
一个租户可能会有多个虚拟网络,这些虚拟网络之间通过使用三层路由器,防火墙,NAT,负载均衡或者其他服务有可能互联,也可能不互联。
作为一个虚拟租户网络隔离的案例,亚马逊虚拟私有云服务(VPC)允许租户创建一个或者多个子网,并且将他们相互连接,或者到互联网,或者使用路由器或者服务(如NAT)到特定网络。
使用案例包括一个逻辑集中的协调层(在前面都没有显示)去管理租户网络
- 添加和删除租户
- 定义租户网络的带宽,QOS和安全属性
- 其他
协调层必须覆盖租户网络的所有方面(计算,存储,网络和存储)和支持快速改变。
4.1.3 连接租户到互联网/VPN
在这个案例里,租户连接到互联网或者通过VPN连接到企业网络,VPN可以是L3VPN,L2VPN,SSLVPN和IPsec VPN等等。
数据中心网关的功能是连接租户网络到互联网或者VPN,网关的功能可以部署为软件或者硬件形式(例如使用网关路由器)
4.1.4 数据中心互联
在这个案例中,多个数据中心通过广域网(WAN)进行互联。
数据中心可以是在灾难恢复上使用活跃/备份模式,在灾难避免时使用活跃/活跃方式,或者永久的双活,在双活案例中,租户可能在多个数据中心中存在虚拟机,数据中心互联技术使得跨越所有数据中心的给定租户的虚拟机处在同一个虚拟网络中。
DCI必须满足如下网络需求
- 存储的复制
- 允许租户网络使用覆盖的IP地址跨域数据中心
- 全局的负载均衡
- 为容灾实现虚拟机跨越数据中心迁移
数据中心互联上存在很多技术,包括裸光纤,SONET/SDH, DWDM, 伪线, Layer 3 VPN, E-VPN等等,不同于数据中心网络,在DCI的广域网上,带宽是一个稀缺资源,所以流量工程经常使用,保证资源的有效利用。
4.1.5 网络监控
在数据中心网络一直得经常需要在网络中特定的节点复制特定的流,并且为了未来的分析需要发送到一个或者多个监控设备,这就是所谓的网络监控或者TAP使用案例
监控可能是临时的,举例来说,做网络的debug,或者监控可能是永久的,例如为了常规审计的原因
常见的监控部署,是配置交换机的端口分析(SPAN)功能在网络中,发送复制的数据到特定的端口。远程SPAN是更高级的功能,允许复制的流量可以通过GRE发送到远端分析设备上
一个集中的SDN系统可以用于
- 在网络中的监控选择点(TAP)创建一个通道,监控设备收集和分析流量
- 要求网络中交换机和路由器轮询流量的特定流进入通道进行分析。
4.1.6 动态虚拟服务
在这个使用案例中,网络服务如防火墙,入侵防护系统,入侵监测系统,负载均衡,SSL负载,缓存和广域网优化都被部署在租户网络中
这些服务由服务节点提供,可以放置在图31中的各种位置
服务可以部署在多个位置
- 在hypervisor上
- 在虚拟机内
- 在物理设备上
- 在物理或者虚拟交换机上商用ACL
- 在路由器或者交换机的服务板卡上开启服务,或者本身在转发ASIC上就具备支持此类服务的能力
服务可能会关联一个或多个VM,例如使用一个安全策略到一个或多个VM上,
取而代之的是,服务可能被关联在网络边界上,例如应用安全策略在网络边界,或者安装负载均衡设备在网络边界,如图32所示,网络边界可能是
- 租户网络和外部网络之间的边界(互联网或者企业VPN)
- 租户网络之间的边界
- 同一个租户的多个网络之间的边界
4.2 SP环境下的NFV
4.2.1 服务注入
边界路由器需要应用一些服务(防火墙,DPI,caching,HTTP包头丰富)到访问用户的流量上。这些服务可能是由一个路由器的服务卡提供,也可能是有物理服务组件或者云中的虚拟物理组件实现。
SDN系统用于创建和管理虚拟或者物理的服务,并且创建服务链,为访问用户的流量形成服务的流量链,这些可以基于本地的配置但是更多是通过一个集中的策略服务器来完成。
4.2.2 服务案例-虚拟CPE
在宽带接入网络中,每一个接入访问者会被提供一个用户前端设备(CPE)-通常是多业务服务器。运维者希望这些CPE可以提供更多的功能以便和OTT厂商竞争,但是这又面临挑战,因为
- CPE厂家增加新功能缓慢,硬件功能增加有限,(为实现新功能)替换设备又代价昂贵。
- 诸多不同的CPE设备在网络中又带来功能支持的不一致性。
在虚拟CPE使用案例中(也就是云CPE案例)运维者可以解决这些问题
- 使用简单的CPE仅支持基本的二层和三层功能
- 虚拟化剩下的服务,在虚拟机中运行,或者集中式的运行在通用x86硬件上,被集中的协调和预留管理
基于服务器的虚拟CPE可以部署在不同的位置
- 附着在宽带网关上
- 在BNG的服务卡上
- 在BNG和CPE的线卡上内部支持
- 数据中心
- 综合上面全部
5 OpenContrail系统和MPLS VPN的比较
如图33所示,OpenContrail系统的架构在很多方向上和MPLS VPN相似(另外一个类似的地方是,比较控制VM和路由引擎,比较虚拟路由器和线卡)
两个架构类似的地方包括
在OpenContrail系统的底层交换机类似于在MPLS VPN中的P路由器,OpenContrail系统使用MPLS over GRE 或者 VXLAN作为封装协议,不需要底层交换机支持MPLS,唯一的对底层交换机的要求仅仅是知道如何把一个单播数据包从一个物理服务器到另外一个物理服务器。
- OpenContrail系统中的虚拟路由器相当于MPLS VPN中的PE路由器,和无力的PE路由器一样,虚拟路由器中也包含多个路由实例
- OpenContrail系统中的VM相当于MPLS VPN中的CE路由器,在OpenContrail系统中,不需要PE和CE之间的协议,因为CE路由可以通过其他机制被查找。(译者注,因为相当于是主机,所以静态路由就好了)
- 在OpenContrail系统中MPLS over GRE隧道和VXLAN隧道相当于MPLS VPN中的MPLS over MPLS
- OpenContrail系统中的XMPP协议综合了MPLS VPN中的两个协议的功能。
- XMPP分发路由协议,类似于MPLS VPN中的IBGP
- XMPP推送特定类型的配置(如路由实例),类似于MPLS VPN中的DMI(Device Manageability Instrumentation)
- OpenContrail系统提供三个功能
- 集中控制,类似于MPLS VPN中BGP的RR
- 管理,向虚拟路由器的配置下发,类似于MPLS VPN中NMSAnalytics.分析
- OpenContrail支持包括layer 3的overlay,等同于MPLS L3 VPN,也支持Layer 2的overlay,等同于MPLS EVPN。
6 Acronyms
Acronym |
Meaning |
AD |
Administrative Domain |
API |
Application Programming Interface |
ASIC |
Application Specific Integrated Circuit |
ARP |
Address Resolution Protocol |
BGP |
Border Gateway Protocol |
BNG |
Broadband Network Gateway |
BSN |
Broadband Subscriber Network |
BSS |
Business Support System |
BUM |
Broadcast, Unknown unicast, Multicast |
CE |
Customer Edge router |
CLI |
Command Line Interface |
COTS |
Common Off The Shelf |
CPE |
Customer Premises Equipment |
CSP |
Cloud Service Provider |
CO |
Central Office |
CPU |
Central Processing Unit |
CUG |
Closed User Group |
DAG |
Directed Acyclic Graph |
DC |
Data Center |
DCI |
Data Center Interconnect |
DHCP |
Dynamic Host Configuration Protocol |
DML |
Data Modeling Language |
DNS |
Domain Name System |
DPI |
Deep Packet Inspection |
DWDM |
Dense Wavelength Division Multiplexing |
EVPN |
Ethernet Virtual Private Network |
FIB |
Forwarding Information Base |
GLB |
Global Load Balancer |
GRE |
Generic Route Encapsulation |
GUI |
Graphical User Interface |
HTTP |
Hyper Text Transfer Protocol |
HTTPS |
Hyper Text Transfer Protocol Secure |
IaaS |
Infrastructure as a Service |
IBGP |
Internal Border Gateway Protocol |
IDS |
Intrusion Detection System |
IETF |
Internet Engineering Task Force |
IF-MAP |
Interface for Metadata Access Points |
IP |
Internet Protocol |
IPS |
Intrusion Prevention System |
IPVPN |
Internet Protocol Virtual Private Network |
IRB |
Integrated Routing and Bridging |
JIT |
Just In Time |
KVM |
Kernel-Based Virtual Machines |
LAN |
Local Area Network |
L2VPN |
Layer 2 Virtual Private Network |
LSP |
Label Switched Path |
MAC |
Media Access Control |
MAP |
Metadata Access Point |
MDNS |
Multicast Domain Naming System |
MPLS |
Multi-Protocol Label Switching |
NAT |
Network Address Translation |
Netconf |
Network Configuration |
NFV |
Network Function Virtualization |
NMS |
Network Management System |
NVO3 |
Network Virtualization Overlays |
OS |
Operating System |
OSS |
Operations Support System |
P |
Provider core router |
PE |
Provider Edge router |
PIM |
Protocol Independent Multicast |
POP |
Point of Presence |
QEMU |
Quick Emulator |
REST |
Representational State Transfer |
RI |
Routing Instance |
RIB |
Routing Information Base |
RSPAN |
Remote Switched Port Analyzer |
(S,G) |
Source Group |
SDH |
Synchronous Digital Hierarchy |
SDN |
Software Defined Networking |
SONET |
Synchronous Optical Network |
SP |
Service Provider |
SPAN |
Switched Port Analyzer |
SQL |
Structured Query Language |
SSL |
Secure Sockets Layer |
TCG |
Trusted Computer Group |
TE |
Traffic Engineering |
TE-LSP |
Traffic Engineered Label Switched Path |
TLS |
Transport Layer Security |
TNC |
Trusted Network Connect |
UDP |
Unicast Datagram Protocol |
VAS |
Value Added Service |
vCPE |
Virtual Customer Premises Equipment |
VLAN |
Virtual Local Area Network |
VM |
Virtual Machine |
VN |
Virtual Network |
VNI |
Virtual Network Identifier |
VXLAN |
Virtual eXtensible Local Area Network |
WAN |
Wide Area Network |
XML |
Extensible Markup Language |
XMPP |
eXtensible Messaging and Presence Protocol |
7 References
[AWS] Amazon Web Services. http://aws.amazon.com/
[AWS-EC2] Amazon Eleastic Compute Cloud (Amazon EC2) http://aws.amazon.com/ec2/
[AWS-EC2-EIP] Amazon EC2 Elastic IP Address. http://aws.amazon.com/articles/1346
[AWS-EC2-INSTANCE-ADDRESSING] Amazon EC2 Instance IP Addressing.http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html
[AWS-VPC] Amazon Virtual Private Cloud (Amazon VPC). http://aws.amazon.com/vpc/
[AWS-VPC-SUBNETS] Amazon Virtual Private Cloud Subnets.http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html
[cassandra] Apache Cassandra website. http://cassandra.apache.org/
[draft-rfernando-virt-topo-bgp-vpn] “Virtual Service Topologies in BGP VPNs.” IETF Internet Draft draft-rfernando-virt-topo-bgp-vpn.https://datatracker.ietf.org/doc/draft-rfernando-virt-topo-bgp-vpn/
[draft-mahalingam-dutt-dcops-vxlan] “VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks.”IETF Internet Draft draft-mahalingam-dutt-dcops-vxlan. https://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/
[draft-marques-l3vpn-mcast-edge] “Edge Multicast Replication for BGP IP VPNs.” IETF Internet Draft draft-marques-l3vpn-mcast-edge. https://datatracker.ietf.org/doc/draft-marques-l3vpn-mcast-edge/
[draft-ietf-l3vpn-end-system] “BGP-signaled end-system IP/VPNs.” IETF Internet Draft draft-ietf-l3vpn-end-system.https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/
[draft-raggarwa-sajassi-l2vpn-evpn] “BGP MPLS Based Ethernet VPN.” IETF Internet Draft draft-raggarwa-sajassi-l2vpn-evpn.https://datatracker.ietf.org/doc/draft-raggarwa-sajassi-l2vpn-evpn/
[ietf-xmpp-wg] IETF XMPP working group. http://datatracker.ietf.org/wg/xmpp/
[if-map] if-map.org website. http://www.if-map.org/
[juniper-why-overlay] “Proactive Overlay versus Reactive End-to-End.” Juniper Networks.http://www.juniper.net/us/en/local/pdf/whitepapers/2000515-en.pdf
[redis] Redis website. http://redis.io/
[RFC4023] “Encapsulating MPLS in IP or Generic Routing Encapsulation.” IETF RFC4023. http://tools.ietf.org/html/rfc4023
[RFC4271] “A Border Gateway Protocol 4 (BGP-4).” IETF RFC4271. http://www.ietf.org/rfc/rfc4271.txt
[RFC4364] “BGP/MPLS IP Virtual Private Networks (VPNs).” IETF RFC4364. http://tools.ietf.org/html/rfc4364
[RFC6513] “Multicast in BGP/MPLS VPNs.” IETF RFC6513. http://tools.ietf.org/html/rfc6513
[snort] Snort Website. http://www.snort.org/
[snort-rules-intro] “A Brief Introduction to Snort Rules.” The Security Analysts. http://www.secanalyst.org/2010/05/27/a-brief-introduction-to-snort-rules/
[xmpp] XMPP.org Website. http://xmpp.org/
[zookeeper] Apache Zookeeper website. http://zookeeper.apache.org/