CN104113791A - 一种自动交换光网络演进系统及方法 - Google Patents

Abstract

本发明公开了一种自动交换光网络演进系统及方法，涉及自动交换光网络。本发明公开的方法包括：置于网元内部的瘦客户端向置于软件定义网络(SDN)的应用端发起应用请求；所述应用端对所述应用请求进行运算，并将处理结果发送给所述瘦客户端；所述瘦客户端将所述处理结果翻译成本网元可执行的指令进行相应操作。本发明还公开了一种自动交换光网络演进系统。本申请技术方案借助SDN架构与云计算平台为用户提供简单、高效、安全的服务。

Description

一种自动交换光网络演进系统及方法

技术领域

本发明涉及自动交换光网络，特别涉及一种基于软件定义网络(SDN，Software Defined Network)架构和云计算平台技术演进自动交换光网络(ASON，Automatic Swtiched Optical Network)。

背景技术

ASON是业界普遍认为的传送网的一个发展方向，ASON的发展将传送网络从过去的单一的链路提供功能逐步发展到具有智能化的能够满足各种业务要求的网络平台。

而当前ASON架构如图1所示，其网络中每个设备多少有点儿智能，但是非常有限，它们只能根据本节点的进出数据流做出被动响应，无法及时知道其他节点的动态状况。各个网络节点离散式自我控制，就像只见个别树木或树叶，没有大家统一协调的控制平面，不见整个网络森林。所以对整个网络来讲，尽管实现了动态路由协议，其架构基本是固定和静态的。传统网络所谓动态调度实现基础也就是二层和三层实现链路资源动态分配，而对于四到七层与二三层相匹配进行调度，则心有余而力不足。即便有折中解决方案，也需要在固定位置安装昂贵的硬件设备。

此外，当前ASON架构的GMPLS控制平面接口如图2所示，该控制平面与传送平面集成，管理越来越复杂，创新缓慢，而虚拟化资源移动性要求更加强大、灵活、简单的控制平面。面向工作负载的网络需要控制平面与资源本身解耦，造成控制平面与传送平面之间的差距越来越大，用户为使用网络所付出的总拥有成本越来越大。明显体现在为了应对日益庞大复杂的ASON网络和应用，单独节点内提供给ASON硬件支持需要不断提升，而这些昂贵的硬件资源只有在网络发生变化时才会发挥作用，网络稳定期间其硬件资源白白在浪费，换言之我们硬件提升的越多，这种浪费会越加严重，矛盾日益明显。

发明内容

本发明所要解决的技术问题是，提供一种自动交换光网络演进系统及方法，以便为用户提供简单、高效、安全的ASON云服务。

为了解决上述技术问题，本发明公开了一种自动交换光网络演进方法，包括：

置于网元内部的瘦客户端向置于软件定义网络(SDN)的应用端发起应用请求；

所述应用端对所述应用请求进行运算，并将处理结果发送给所述瘦客户端；

所述瘦客户端将所述处理结果翻译成本网元可执行的指令进行相应操作。

较佳地，上述方法中，所述瘦客户端包括网元交叉矩阵控制器。

较佳地，上述方法中，所述瘦客户端还包括终端适配器。

较佳地，上述方法中，所述应用端至少包括网络呼叫控制器、连接控制器、路由控制器、链路资源管理器以及SDN协议控制器。

较佳地，上述方法中，所述瘦客户端向所述应用端发起的应用请求为新增请求时，包括如下操作；

所述瘦客户端收集当前网元内硬件资源信息，进行资源模型抽象，转换成标准的流程表格式，并发送给所述应用端；

所述应用端将收到的流程表信息描述为所述瘦客户端所在网元内不同逻辑层次的联通性矩阵，并结合域内其它网元信息，映射为不同逻辑层次的流量工程链路进行存储。

较佳地，上述方法还包括，所述应用端接收管理平台发起的业务建立请求；

所述应用端进行路由查询，得到有效的路由计算应答后，分解建立请求，针对连接路径上每个节点上的网络交换子模块，通过流程表描述方法下发本地业务打通请求；

当连接路径上所有网络交换子模块都应答成功后，连接建立成功，并应答所述管理平面业务建立成功。

本发明还公开了一种自动交换光网络演进系统，包括瘦客户端和应用端，其中：

所述瘦客户端，包括设置在网元内部的网元交叉矩阵控制器，将所述应用端发送的处理结果翻译成本网元可执行的指令进行相应操作；

所述应用端，包括部署在云端的网络呼叫控制器、连接控制器、路由控制器、链路资源管理器以及软件定义网络(SDN)协议控制器，对所述瘦客户端发起的应用进行运算，并将处理结果发送给所述瘦客户端。

较佳地，上述系统中，所述瘦客户端还包括设置在网元内部的终端适配器。

较佳地，上述系统中，所述瘦客户端向所述应用端发起的应用请求为新增请求时，

所述瘦客户端中的终端适配器收集当前网元内硬件资源信息，并进行资源模型抽象，转换成标准的流程表格式，发送给所述应用端；

所述应用端中链路资源管理器将收到的流程表信息描述为本网元内不同逻辑层次的联通性矩阵，并结合域内其它网元信息，映射为不同逻辑层次的流量工程链路进行存储，并提供给所述应用端中路由控制器。

较佳地，上述系统中，管理平台向所述应用端发起业务建立请求时，所述应用端中网络呼叫控制器接收所述业务建立请求，网络控制器向路由控制器进行路由查询，网络控制器得到有效的路由计算应答后，向连接控制器发起连接建立请求，连接控制器向SDN协议控制器发起连接建立申请，SDN协议控制器分解建立请求，针对连接路径上每个节点上网络交换子模块，通过流程表描述方法下发本地业务打通请求；

当全路径所有网络交换子模块都应答成功后，SDN协议控制器应答连接控制器成功，标明该连接建立成功，并在该呼叫的所有连接都建立成功后，呼叫控制器应答管理平面业务建立成功。

本申请技术方案借助SDN架构与云计算平台为用户提供简单、高效、安全的服务。

附图说明

图1为当前ASON架构结构示意图；

图2为当前ASON架构中GMPLS控制平面接口示意图；

图3为本实施例中提出的第一种ASON云体系结构示意图；

图4为图3所示的ASON云体系结构中SDN架构示意图；

图5为本实施例中提出的第二种ASON云体系结构示意图；

图6为单域ASON云控制示意图；

图7为多域ASON云控制示意图；

图8为基于Open Flow的ASON云架构示意图；

图9为Flow Table处理示意图；

图10为本实施例中一种节点添加入ASON云控制流程示意图；

图11为Flow Table格式示意图；

图12为本实施例中另一种节点添加入ASON云控制流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文将结合附图对本发明技术方案作进一步详细说明。需要说明的是，在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

实施例1

本申请发明人提出可借用SDN架构，使得云计算平台满足ASON应用功能需求。即将ASON功能划分为瘦客户端和主应用，将瘦客户端部署在设备上的主控单板上，而主应用则部署在云计算平台上，与其它应用共享硬件平台，从而具备外置式功能。另外，在SDN架构的控制器上集中运算，在全局资源视图上统一调度，提高运算成功率，即具有了集中式功能。

基于上述思想，本申请发明人主要从如下两方面考虑，提供一种自动交换光网络演进系统。

一、将ASON云作为纯软件，从网元节点内分离，统一部署在云计算平台。

共享云计算中心硬件资源，利用其虚拟化技术部署ASON应用，重新划分ASON架构。例如图3所示将原ASON体系结构中网元交叉矩阵控制器和终端适配器依然保存在网元内部，作为ASON云的瘦客户端，而其他组件作为ASON云实体迁移到SDN框架下(具体如图4所示)作为其应用层(Application Layer)软件。或者按照图5所示的，当ASON云与网管充分互通后，可以继续弱化网元内部终端适配器，将终端适配器也迁移到SDN框架下纳入ASON云中，与其它组件一起作为SDN框架其应用层软件。并最终将SDN的控制层(Control Layer)和应用层作为软件应用部署到云计算平台的一个虚拟机(VM，Virtual Machine)上，享受云计算的现有成果，这样设计，具有如下优点：

1分布式计算：较现有单板业务运算能力实现质的飞跃，其运算性能将仅依赖于网络传递性能。

2热备份：当某个ASON应用异常时，可以利用云计算热备份技术，实现对业务透明，无缝完成备份与切换。

3云存储：当前环境中，受单板上硬件资源制约，留给应用的存储空间十分有限，例如障、调试信息等。进而制约后期的故障定位、解决。利用云存储可以享受近似无穷的存储空间，为故障异常定位提供更为充分、完整的保障。

4负载均衡：当大量业务发生故障时更为明显，硬件运算负载均衡将帮助所有业务快速恢复。

5统一资源视野：当前多点同时故障时，由于分布式计算各自为战，资源争抢冲突大，有可能首次恢复失败，这样会延长业务恢复时间。而ASON云具有管辖范围内的统一资源视野，可以有效降低资源冲突，快速恢复故障。

二、简化ASON架构，逐步弱化对GMPLS协议依赖。

在传统ASON架构中，主要应用着以GMPLS为代表的三大传统协议，包含信令协议(RSVP、CD-LDP和PNNI)、路由协议(OSPF)、链路管理协议(LMP)。如图1所示的当前ASON体系架构，包含了多个模块，且其对协议控制器依赖大，软件架构复杂，开发成本较大。而借助SDN模型的集中控制INNI、ENNI和UNI接口的协议可以逐渐简化(具体可参见图2中GMPLS控制平面接口定义)。

具体地，单域内应用ASON云时，将简化INNI接口。

由于ASON云基于SDN架构(具体可见图4所示)，单域内可以由一个控制器(controller)来管理，域内信令协议、路由协议可以考虑被裁剪。具体可见图6。

多域内应用ASON云时，将简化ENNI接口。

当多域协作，且都基于SDN架构时，可以简化ENNI口信令和路由协议，使用控制器间交互来完成跨域协作。具体可见图7。

客户侧设备应用SDN，将简化UNI接口。

当客户侧设备也是基于SDN时，可以使用控制器间协同来完成端到端协作，简化UNI接口。具体可见图8。

还要说明的是，SDN控制器可以是在同一云中，也可以部署在不同云中通过私有云间互通来完成控制器间的协作，其私密性、安全性由私有云互通本身来保证。

基于上述思想，本实施例提供的自动交换光网络演进方法，至少包括如下操作：

置于网元内部的瘦客户端向置于SDN网络的应用端发起应用请求；

应用端对上述应用请求进行运算，并将处理结果发送给瘦客户端；

瘦客户端将收到的处理结果翻译成本网元可执行的指令进行相应操作。

下面结合附图对本实施提供的方法作进一步详细说明，其中，SDN架构采用Open Flow协议来描述，ASON云实现可以但不限于Open Flow架构，凡在SDN框架下的协议都可以应用。

如图8所示，现有ASON架构被重新划分，网络呼叫控制器、连接控制器、路由控制器、链路资源管理作为应用端，部署在SDN的应用层(ApplicationLayer)。应用层和控制层(Control Layer)则统一作为云计算平台中一个虚拟机。终端适配器和网元交换矩阵控制器继续保留在网元设备内部，作为瘦客户端，相当于SDN中基础层(Infrastructure Layler)组件配合Open FlowSwitch完成Flow Table抽象(可见图9中Flow Table示意图)，和根据FlowTable完成本网元内实际业务打通。

为了兼容现有用户对ASON业务的理解，Call、Session、tunnel、LSP、流量工程链路(TE-Link，Traffic Engineering Link)、FA-LSP等概念依然遵从现有ASON标准定义。当前链路资源管理模块将负责翻译适配Flow Table为现有ASON中传统TE-Link相关概念。路由控制器依然根据TE-Link相关属性进行路径计算，应用路由选择规则。

下面以新的节点加入ASON云控制为例来详细说明上述方法的实现过程。

例如，有新的节点加入图3所示的ASON云架构中，加入的具体步骤如图10所示，包括如下步骤100至700：

步骤100，瘦客户端中的终端适配器收集当前网元内硬件资源信息；

步骤200，终端适配器进行资源模型抽象，转换成标准的Flow Table表格式(具体参考图11)，对应SDH、PTN、OTN等网络设备特点其表格式可以有针对性的扩展，已达到描述本地资源目的，并通知给网元交换矩阵控制器(Open Flow Switch)；

步骤300，Open Flow Switch通过Open Flow协议上报信息给应用端(本实施例中应用端也可称为Open Flow Controller)；

步骤400，Open Flow Controller将继续通过Open Flow协议上报给链路资源管理器模块；

步骤500，链路资源管理器模块将收到的Flow Table信息描述为本网元内不同逻辑层次的联通性矩阵，并结合域内其它网元信息，映射为不同逻辑层次的TE-Link，具体逻辑层次划分可以用户来定义，可以参考业务速率和信号类型来进行划分和映射。一并提供给路由控制器，方便后续算路使用。

步骤600，终端用户可以通过NMI接口配置到链路资源管理器，更新设置TE-Link的不同属性；

步骤700，链路资源管理器更新后重新通知路由控制器变更信息。

当有新的节点加入图4所示的ASON云架构中，其新节点纳入ASON云控制的实施步骤如图12所示，其与图11的实施步骤的差别主要体现在第一步，即在图4所示的ASON云架构中第一步应为：终端适配器从管理平面(网管)处收集当前网元内硬件资源信息。

下面分别介绍三种场景下ASON云如何在Open Flow框架下完成业务建立过程。

一、针对单域内应用ASON云在Open Flow框架下完成业务建立过程如图12示，包括如下步骤1201至1206：

1201、管理平面(网管)通过NMI接口给应用端的网络呼叫控制器下发业务建立请求；

1202、网络呼叫控制器向路由控制器进行路由查询；

1203、网络呼叫控制器得到有效的路由计算应答后，向连接控制器发起连接建立请求；

1204、连接控制器向SDN协议控制器发起连接建立申请；

1205、SDN协议控制器分解建立请求，针对连接路径上每个节点上网络交换子模块(Open Flow Switch-n)，通过Flow Table描述方法下发本地业务打通请求；

1206、当全路径所有Open Flow Switch都应答成功后，SDN协议控制器也应答连接控制器成功，标明该连接建立成功。但该呼叫的所有连接都建立成功后，呼叫控制器应答管理平面业务建立成功。

二、针对跨域应用ASON云在Open Flow框架下完成业务建立过程又分为如下几种情况。

1、当前所有域都是应用ASON云时

跨域应用ASON云方法，其业务建立过程基本与单域相同，主要区别体现在不同域的应用端(Open Flow Controller)需要完成现有PCE的类似的协商过程，可以考虑分为两种情况：

第一种，当跨域的Open Flow Controller在同一云中，或者说不同Controller间为完全信任关系时(类似控制平面接口中INNI关系，例如为一个运行商管辖时)，业务运算和控制可以协商一个主Controller完成，共享不同Controller间的Flow Table和链路资源管理器抽象出来的资源模型。

第二种，当跨域的Open Flow Controller不在同一云中，或者说不同Controller间不是完全信任关系时(类似控制平面接口中ENNI关系，例如为不同运营商管辖时)，Controller间算路与协商可以参考现有ASON标准中PCE相关算法实现。

2、当部分域应用ASON云，而部分域仍沿用现有ASON技术时，可以分为两种场景：

第一种场景，当首域为ASON云方式时，可以通过ENNI接口将下游ASON域的域内抽象链路和配置的域间TE-Link作为管道来使用，通过描述管道的特性帮助ASON云中路由控制器完成路由计算；

第二种场景，当首域为现有ASON技术的网络时，ASON云需要配合网管生成域内抽象链路和域间TE-Link，使首域的的PCE或者本地路径计算单元能完成跨域算路任务。

三、针对客户侧设备接入ASON云网络在Open Flow框架下完成业务建立过程又要考虑如下两种场景：

第一种场景，当客户侧设备也支持SDN的Open Flow协议时，可以将UNI接口的呼叫转变为Open Flow Controller到Controller间的呼叫，以此来完成完成端到端的业务建立；

第二种场景，当客户侧设备不支持SDN的Open Flow协议时，需要OpenFlow Controller中的RSVP/LDP模块处理UNI的呼叫请求(具体可以参见图8)，并把此呼叫请求传递给网络呼叫控制器模块，网络呼叫控制器完成后续呼叫和连接的建立过程。

需要指出的是，本实施例的方法的实现依赖于SDN架构和云计算平台，但不包含SDN和云计算平台本身的实施细节，具体选用哪种SDN协议和云计算平台用户可以根据自身的情况来选定。ASON云只是基于SDN和云计算上的使用者，以此来重构ASON现有软件架构，提供一种新的自动交换光网络演进方法。

实施例2

本实施例提供一种自动交换光网络演进系统，至少包括瘦客户端和应用端。

瘦客户端，包括设置在网元内部的网元交叉矩阵控制器，将应用端发送的处理结果翻译成本网元可执行的指令进行相应操作；

优选地，瘦客户端还可能包括设置在网元内部的终端适配器。

应用端，包括部署在云端的网络呼叫控制器、连接控制器、路由控制器、链路资源管理器以及软件定义网络(SDN)协议控制器，对瘦客户端发起的应用进行运算，并将处理结果发送给瘦客户端。

具体地，瘦客户端向应用端发起的应用请求为新增请求时，上述系统中各部分的操作如下：

瘦客户端中的终端适配器收集当前网元内硬件资源信息，并进行资源模型抽象，转换成标准的流程表格式，发送给应用端；

应用端中链路资源管理器将收到的流程表信息描述为本网元内不同逻辑层次的联通性矩阵，并结合域内其它网元信息，映射为不同逻辑层次的流量工程链路进行存储，并提供给应用端中路由控制器。

另外，管理平台也可能向上述应用端发起业务建立请求，此时，应用端中网络呼叫控制器接收业务建立请求，网络控制器向路由控制器进行路由查询，网络控制器得到有效的路由计算应答后，向连接控制器发起连接建立请求，连接控制器向SDN协议控制器发起连接建立申请，SDN协议控制器分解建立请求，针对连接路径上每个节点上网络交换子模块，通过流程表描述方法下发本地业务打通请求；

当全路径所有网络交换子模块都应答成功后，SDN协议控制器应答连接控制器成功，标明该连接建立成功，并在该呼叫的所有连接都建立成功后，呼叫控制器应答管理平面业务建立成功。

在其他场景中，上述系统的具体操作过程可参见实施例1中的相应描述，在此不再赘述。

从上述实施例可以看出，本申请技术方案主要将离散式自我控制转变为集中式控制，借助SDN架构与云计算平台为用户提供简单、高效、安全的服务。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

以上所述，仅为本发明的较佳实例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种自动交换光网络演进方法，其特征在于，该方法包括：

置于网元内部的瘦客户端向置于软件定义网络(SDN)的应用端发起应用请求；

所述应用端对所述应用请求进行运算，并将处理结果发送给所述瘦客户端；

所述瘦客户端将所述处理结果翻译成本网元可执行的指令进行相应操作。

2.如权利要求1所述的方法，其特征在于，所述瘦客户端包括网元交叉矩阵控制器。

3.如权利要求2所述的方法，其特征在于，所述瘦客户端还包括终端适配器。

4.如权利要求1至3任一项所述的方法，其特征在于，所述应用端至少包括网络呼叫控制器、连接控制器、路由控制器、链路资源管理器以及SDN协议控制器。

5.如权利要求4所述的方法，其特征在于，所述瘦客户端向所述应用端发起的应用请求为新增请求时，包括如下操作；

所述瘦客户端收集当前网元内硬件资源信息，进行资源模型抽象，转换成标准的流程表格式，并发送给所述应用端；

所述应用端将收到的流程表信息描述为所述瘦客户端所在网元内不同逻辑层次的联通性矩阵，并结合域内其它网元信息，映射为不同逻辑层次的流量工程链路进行存储。

6.如权利要求4所述的方法，其特征在于，该方法还包括：

所述应用端接收管理平台发起的业务建立请求；

所述应用端进行路由查询，得到有效的路由计算应答后，分解建立请求，针对连接路径上每个节点上的网络交换子模块，通过流程表描述方法下发本地业务打通请求；

当连接路径上所有网络交换子模块都应答成功后，连接建立成功，并应答所述管理平面业务建立成功。

7.一种自动交换光网络演进系统，其特征在于，该系统包括瘦客户端和应用端，其中：

所述瘦客户端，包括设置在网元内部的网元交叉矩阵控制器，将所述应用端发送的处理结果翻译成本网元可执行的指令进行相应操作；

所述应用端，包括部署在云端的网络呼叫控制器、连接控制器、路由控制器、链路资源管理器以及软件定义网络(SDN)协议控制器，对所述瘦客户端发起的应用进行运算，并将处理结果发送给所述瘦客户端。

8.如权利要求7所述的系统，其特征在于，所述瘦客户端还包括设置在网元内部的终端适配器。

9.如权利要求8所述的系统，其特征在于，所述瘦客户端向所述应用端发起的应用请求为新增请求时，

所述瘦客户端中的终端适配器收集当前网元内硬件资源信息，并进行资源模型抽象，转换成标准的流程表格式，发送给所述应用端；

所述应用端中链路资源管理器将收到的流程表信息描述为本网元内不同逻辑层次的联通性矩阵，并结合域内其它网元信息，映射为不同逻辑层次的流量工程链路进行存储，并提供给所述应用端中路由控制器。

10.如权利要求8所述的系统，其特征在于，管理平台向所述应用端发起业务建立请求时，

所述应用端中网络呼叫控制器接收所述业务建立请求，网络控制器向路由控制器进行路由查询，网络控制器得到有效的路由计算应答后，向连接控制器发起连接建立请求，连接控制器向SDN协议控制器发起连接建立申请，SDN协议控制器分解建立请求，针对连接路径上每个节点上网络交换子模块，通过流程表描述方法下发本地业务打通请求；

当全路径所有网络交换子模块都应答成功后，SDN协议控制器应答连接控制器成功，标明该连接建立成功，并在该呼叫的所有连接都建立成功后，呼叫控制器应答管理平面业务建立成功。