CN102724114B - 一种基于协同代理的跨域QoS信令控制方法 - Google Patents

Abstract

本发明公开了一种基于协同代理的跨域QoS信令控制方法，包括域内协同和域间协同；对于域内的各节点，将与发送方相邻的节点作为掌控网络全局的节点；对于域间节点，将上级节点作为掌控网络全局的节点；所述域内协同中，信令根据发送方发给相邻的节点QoS需求建立路径或拆除路径；所述域间协同中，上级节点根据发送方发来的数据和当前网络状态建立路径或拆除路径。本发明利用协同代理模块的功能，针对异构网络中域间和域内两种情况，设计了两套信令协议，对建立数据传输路径的过程做出了规范。通过本信令机制，可以在宏观上控制和调整传输路径，并在网络变化的情况下，能迅速地做出反应。

Description

一种基于协同代理的跨域QoS信令控制方法

技术领域

本发明涉及一种基于协同代理在异构网络中对跨域QoS信令控制方法。针对域间和域内两种情况，借助传输路径上各个协同代理之间的协同功能，为QoS的资源预留设计了两种信令控制方法，使得无论在域间还是域内都能有效准确地保障数据流的QoS协同交互。

背景技术

首先对本说明书中用到的缩略词进行定义：

SQC：signaling for QoS Cooperation heterogeneous network，异构网络QoS协同信令，这是本专利的核心，用以规范在异构网络中的信令流程和信令消息的报文内容。

CAQF：Cooperative Agent-based QoS Framework，基于协同代理的QoS保障框架，参见《Cooperative Agent-based QoS Framework for HeterogeneousNetworks》。这是实现本专利需要借助的一个模块，见图1，该协同代理安置在网络的各个节点上，并可以进行协同交互，交互的信息包括QoS需求信息，运行态势感知信息（包括网络状态和节点状态），策略信息。协同代理之间的交互可以使其能够掌握全局网络的状态，并在网络有变化的时候，可以互相协同，更新协同代理所掌握的全局网络状态，达到对网络的实时监控。

SI：SQC Initiator，SQC发起方，指发起SQC信令的发送端，亦是数据流的发送端。

SR：SQC Receiver，SQC接收端，指接收SQC的接收端，亦是数据流的接收端。

SE：SQC Entity，支持SQC的节点，指安置了协同代理的中间节点，可以通过协同代理进行交互，支持SQC的信令机制。其中SE又分为：N-SE（Neighbor-SE），指与SI相邻的SE；P-SE（Path-SE）指传输路径上除了N-SE的其他SE；SSE（Superior SE），指在域间传输时，对其他SE拥有控制、命令等权限的上级SE。

现有技术中相关技术情况：

QoS一直是网络传输数据中十分重要的因素，如何满足数据流的QoS需求是长期以来不断研究的课题，在普通的网络中，已经有很多成熟的资源预留方案来保证端到端的QoS需求。

但在异构网络中，普通的QoS保障机制不能满足其网络特点。异构网络主要分为域间和域内两部分。域内的节点均为对等节点，与普通网络相似，但域间节点中包含上级节点，即上级节点对普通节点拥有控制权限，节点间的通信必须经过上级节点的授权才可执行。然而现有的技术不支持存在上级节点拥有控制权限的情况，也不能掌握全局网络状态，从而无法对整个数据流的传输进行宏观的控制和调整，由于在建立路径时，需要沿着路径通过信令报文来确定建立路径，而且QoS不能实时协商，因此也存在路径建立时间长，QoS协同交互差等缺点，在安全性、灵活性和扩展性等方面都有比较明显的缺陷。

目前用的较为广泛的IP网络信令协议是RSVP。RSVP是一种支持多媒体通信的传输协议，在无连接协议上提供端到端的实时传输服务，为特定的多媒体流提供端到端的QoS协商和控制功能。RSVP的工作机理：发送者在发送数据前首先发送Path报文与接收者建立一个传输路径，Path报文含有数据流标识符(ID)和QoS控制信息。沿途的各个路由器都记录这个流标识符，并为它做好保留资源的准备。接收者收到Path报文后，则使用相同的流标识符回送一个Resv报文进行应答。Resv报文沿相同的路径传送给发送者，途经各个路由器时，对Path报文指定的QoS给予确认，这条传输路径就建立完毕了。

由于Path报文和Resv报文要依此分发到路径上每个路由器，因此需要很长的时间来建立路径。一旦路径上某个路由器出现突发情况不能满足其QoS，其他路由必须等到拆除路径的消息时才会拆除，因此这段时间的数据包将会丢失。上述原因导致RSVP的灵活性比较差。在异构网络中，由于节点之间并不一定是对等的，可能会存在上级节点，上级节点对网络拥有一定的控制权限，比如发送数据时要先向上级节点请求，而RSVP扩展性较差，并不能满足这种域间的资源预留。

IETF在2001年提出了下一代信令（Next Setp in Signaling，NSIS），它在解决QoS保障机制方面也有自己的特点。IETF在2001年成立了NSIS(Next Steps InSingnaling)工作组，致力于研究下一代信令的需求、体系结构以及协议实现等问题刚。NSIS主要解决沿着数据路径的网络控制状态建立问题，它根据模块化的要求将信令协议分成了信令传输层(NTLP)和信令应用层(NsLP)两层，这种体系结构在很大程度上决定了NSIS的可扩展性。但其建立路径的形式依然和RSVP是一样的，建立路径、拆除路径等操作都存在时间较长的缺点。由于NSIS的模块并不能掌握全局网络的变化，对突发情况不能及时处理，因此灵活性仍显不足。而且在异构网络中，对于域间存在上级节点的情况，NSIS不能满足上级节点对全局网络控制的要求。

发明内容

发明目的：本发明针对现有技术存在问题与不足，提供一种基于协同代理的跨域QoS信令控制方法，本发明利用协同代理模块的功能，针对异构网络中域间和域内两种情况，设计了两套信令协议，对建立数据传输路径的过程做出了规范。通过本信令机制，可以在宏观上控制和调整传输路径，并在网络变化的情况下，能迅速地做出反应。

技术方案：一种基于协同代理的跨域QoS信令控制方法，包括域内协同和域间协同；对于域内的各节点，各个节点均为对等节点，将与发送方相邻的节点作为掌控网络全局的节点；对于域间节点，存在上级节点，该节点对其他节点拥有控制权限，将上级节点作为掌控网络全局的节点；所述域内协同中，信令根据发送方发给相邻的节点QoS需求建立路径或拆除路径；所述域间协同中，上级节点根据发送方发来的数据和当前网络状态建立路径或拆除路径，上级节点作为管理节点，可以对整条传输路径进行控制以及监控，能迅速地根据网络状态做出反应，调控整条传输路径。

所述域内协同的具体流程如下：

一，路径建立：

步骤1，发送方将数据流的QoS需求信息发给相邻的节点；

步骤2，相邻的节点根据全局网络的状态，判断路径上是否满足数据流的QoS需求，并将是否接受该数据流回应给发送方；

步骤3，路径上相邻的两个节点通信，上游节点指示下游节点为其数据流预留资源，使得这两个节点之间建立起数据传输链路；

步骤4，路径上每两个相邻的节点均执行步骤3，直到接收方和其相邻的节点之间也建立完成，则整条路径建立完成；

二，主动拆除路径：

步骤5，当发送方发送报文完毕，向相邻的节点请求断链；或者当相邻的节点通过协同代理，发现路径上某个节点不能满足当前的QoS需求时，则向下游路由器发送拆除路径消息，依次转发给路径上每个节点和接收方，路径拆除完成；

三，被动拆除路径：

步骤6，当某个节点收到建立路径消息时，由于突发情况不能满足其QoS需求，则需要回应上游节点不能建立路径；

步骤7：上游节点根据步骤6的回应，向其上游节点发送拆除链路消息，依次转发给路径上的上游节点和发送方。

所述域间协同的具体流程如下：

一，路径建立：

步骤1，发送方将数据流的QoS需求信息发给上级节点；

步骤2，上级节点判断路径上是否满足数据流的QoS需求，并将是否接受该数据流回应给发送方；

步骤3：上级节点指示路径上的所有节点和接收方发送为其数据流预留资源，进而建立整条传输路径；

二，主动拆除路径：

步骤4，当发送方发送报文完毕，向上级节点请求断链，或者当上级节点通过协同代理，发现某个节点不能满足当前的QoS需求时，则向路径上的节点和发送方发送拆除路径消息；

三，被动拆除路径：

步骤5：当某个节点收到上级节点发送的建立路径消息时，由于突发情况不能满足其QoS需求，则告知上级节点，若上级节点决定拆除路径，则逆序向路径上已经建立路径的节点告知拆除链路。

有益效果：本发明基于协同代理可以掌握全局网络状态的功能，设计了一套针对异构网络的信令机制，使得在异构网络中，可以通过协同代理来对信令进行控制。由于每个协同代理掌握了全局的网络状况，在发送端发起传输请求时，相邻的协同代理能很迅速地判断是否可以满足数据流的QoS，因此能够快速地建立传输路径，当网络出现突发变化时，也能迅速地做出反应，采取相应的调整。本专利同时为异构网络中存在上级节点的情况设计了信令协议，提供了上级节点对全局网络的宏观控制，使得网络在安全性和扩展性方面都有比较好的表现。

附图说明

图1是现有技术中协同代理的QoS协同保障框架图；

图2是本发明实施例的协同代理协同流程图；

图3是本发明实施例的域内对等节点间，SI发起的关于主动拆除路径的SQC信令流程图；

图4是本发明实施例的域内对等节点间，SI发起的关于主动拆除路径的SQC信令时序图；

图5是本发明实施例的域内对等节点间，SI发起的关于被动拆除路径的SQC信令流程图；

图6是本发明实施例的域内对等节点间，SI发起的关于被动拆除路径的SQC信令时序图；

图7是本发明实施例的域内对等节点间，SI发起的SQC信令状态迁移图；

图8是本发明实施例的域间基于SSE的SI发起的关于主动拆除路径的SQC信令流程图；

图9是本发明实施例的域间基于SSE的SI发起的关于主动拆除路径的SQC信令时序图；

图10是本发明实施例的域间基于SSE的SI发起的关于被动拆除路径的SQC信令流程图；

图11是本发明实施例的域间基于SSE的SI发起的关于被动拆除路径的SQC信令时序图；

图12是本发明实施例的域间基于SSE的SI发起的SQC信令状态迁移图。

具体实施方式

下面结合附图和具体实施例，进一步阐明本发明，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围，在阅读了本发明之后，本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。

一、协同代理的协同流程（见图2）

协同代理之间通过协同消息（Cooperation Message）交互QoS需求信息、策略信息和态势感知信息。使得每个协同代理可以通过和其他代理的协同交互掌握全局的网络状态，并且在网络状态发生变化时，通过相互协同迅速地更新本地的信息库，为接下来的操作提供支持。

二、域内对等节点间SI发起的SQC信令

域内对等节点间发送端发起的SQC信令的过程主要分为三个部分：传输路径的建立（见图3），路径建立完成后的主动拆除路径（见图3），路径建立时的被动拆除路径（见图5）。流程图给出了比较清楚的过程，各个流程的时序关系可分别参见图4、图6，通过时序图可以对每个步骤的时序关系有清晰的了解。下面对每个步骤做详细的解释说明。

·路径建立：

201：SI将数据流的QoS信息封装到Request Message中，发给SQC路径上的临近N-SE。

202：由于N-SE掌握了全局网络的状态，所以它可以知道这条路径上是否可以满足数据流的QoS需求，将是否同意用Response Message回复给SI，若同意，执行:203，不同意告知SI不能满足其QoS需求。

203：路径上相邻的两个SE通信，上游SE向下游SE发送Indication Message，指示下游SE为其数据流预留资源，当下游SE收到Indication Message后，回复Confirmation Message确认，使得这两个SE之间建立起SQC链路。

204：路径上每两个相邻的SE均执行:203，直到SR和其相邻的SE也建立完成，则整条路径建立完成

·主动拆除路径：

205：当SI发送报文完毕，向N-SE发送Teardown Message请求断链，或者当N-SE通过协同代理，发现某个SE不能满足当前的QoS需求时，则向下游路由器发送Teardown拆除路径消息，依次转发给路径上每个SE和接收端SI，路径拆除完成。

·被动拆除路径：

206：当某个SE收到建立路径消息Indication Message时，由于突发情况不能满足其QoS需求，则回复Non-Confirmation Message。

207：上游SE收到Non-Confirmation Message后，向路径上游SE发送TeardownMessage，依次转发给路径上的上游SE和发起端SI。

为了能清晰的描述各个节点的状态和变化，可参见图7，状态变迁图分析了在整个路径建立和路径拆除的过程中，各个节点根据状态的变迁来决定下一步的动作。

三、域间基于SSE的SI发起的SQC信令

域间基于上级节点的发送端发起的SQC信令的过程主要也分为三个部分：传输路径的建立（见图8），路径建立完成后的主动拆除路径（见图8），路径建立时的被动拆除路径（见图10）。各个流程的时序关系可分别参见图9、图11。下面对每个步骤做详细的解释说明。

·路径建立：

301：SI将数据流的QoS信息封装到Request Message中，发给SSE。

302：由于SSE掌握了全局网络的状态，所以它可以知道这条路径上是否可以满足数据流的QoS需求，将是否同意用Response Message回复给SI，若同意，执行步骤303，不同意告知SI不能满足其QoS需求。

303：SSE给路径上的所有SE和接收端SR发送Indication Message，指示它们为其数据流预留资源，当SE和SR收到Indication Message后，回复Confirmation Message确认则整条路径建立完成。

·主动拆除路径：

304：当SI发送报文完毕，向SSE发送Teardown Message请求断链，或者当SSE通过协同代理，发现某个SE不能满足当前的QoS需求时，则:向路径上的SE和SR发送Teardown拆除路径消息。

·被动拆除路径：

305：当某个SE收到建立路径消息Indication Message时，由于突发情况不能满足其QoS需求，则回复Non-Confirmation Message，SSE收到Non-ConfirmationMessage后，若决定拆除路径，则逆序向路径上已经建立路径的SE发送TeardownMessage。

图12给出了该信令流程的状态迁移图。

四、SQC信令的消息格式

SQC信令消息包括消息头和消息体。

·消息头格式：

消息头包括版本号、消息类型和消息标志，具体格式如下：

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|版本号|消息类型|标志

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

消息长度|数据流ID

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

版本号：4位，说明SQC的版本号，目前版本为1

消息类型：8位，用以区分不同的消息类型，目前定义了8种消息：1=Cooperation，2=Request，3=Response，4=Indication，5=Confirmation，6=Non-confirmation，7=Teardown消息体包括消息长度、当前数据流的ID、标志以及消息内容。

消息长度：8位，标识了消息内容的长度

数据流ID：24位，标识出当前报文所属的数据流

标志：8位，Response Message用到1位，该字段1表示同意发送该数据流，0表示不同意发送该数据流；Indication Message用到1位，该字段1表示向下游节点转发Indication Message，0表示不转发；Teardown Message用到1位，该字段1表示向下游节点转发Teardown Message,0表示不转发；其余位数为预留字段。

·消息体格式：

根据不同的消息类型所包含的内容不同，主要包括QoS需求信息、链路和节点状态信息以及策略信息。

QoS需求信息表示该数据流所需要的资源，其中包括：

可用性

吞吐量

时延

丢包

链路和节点状态信息表示整个网络中各个链路以及各个节点的状态，其中包括：

节点的可用性

链路的吞吐量

链路的可用性等

策略信息主要用于管理员主动配置QoS保障框架的相关功能，其中包括：

分类规则配置策略

路由规则配置策略

排队规则配置策略

调度规则配置策略

·各类消息的消息体内容

不同的消息类型所包含的消息内容不同，以下对各类消息所包含的内容进行阐述，其中*表示为可选字段：

1.Cooperation Message=[公共头]

[*链路状态][*节点状态][*策略信息]

Cooperation Message是协同代理用来交互信息的消息，其中数据流ID为0，表示不绑定任何数据流。协同代理通过态势感知得到链路状态和节点状态，通过策略控制得到策略信息，并将其封装到消息内容中，用以协同模块之间的交互。

2.Request Message=[公共头]

[QoS需求信息][*策略信息]

Request Message是发送端发送数据流时的请求消息，消息内容包含QoS需求信息，用以告知路径上的各个节点该数据流所需的QoS。

3.Response Message=[公共头]

[*QoS需求信息]

Response Message是对Request Message的回应，标志位的1位字段作为回应结果，1表示同意发送该数据流，0表示不同意发送该数据流，由于只是简单的回应，所以消息内容为可选的QoS需求信息，若存在该字段，则为向发送端协商数据流的QoS。

4.Indication Message=[公共头]

[QoS需求信息][*策略信息]

Indication Message是路径节点之间传递QoS需求的消息，该消息指示路径上各个节点为该数据流预留消息内容中的QoS需求

5.Confirmation Message=[公共头]

Confirmation Message是对Indication Message的回应，用以告知本节点为该数据流预留了相应的资源。

6.Non-confirmation Message=[公共头]

[*QoS需求信息]

Non-confirmation Message是对Indication Message的回应，用以告知本节点不能为该数据流预留相应的资源。

7.Teardown Message=[公共头]

Teardown Message是拆除路径的消息，用以告知路径上的各个节点撤销为该数据流预留的资源，将链路路径拆除。

Claims (1)

1.一种基于协同代理的跨域QoS信令控制方法，其特征在于：针对异构网络中域间和域内两种情况，设计了两套信令协议：包括域内协同和域间协同；对于域内的各节点，将与发送方相邻的节点作为掌控网络全局的节点；对于域间节点，将上级节点作为掌控网络全局的节点；所述域内协同中，信令根据发送方发给相邻的节点QoS需求建立路径或拆除路径；所述域间协同中，上级节点根据发送方发来的数据和当前网络状态建立路径或拆除路径；

所述域内协同的具体流程如下：

一，路径建立：

步骤1，发送方将数据流的QoS需求信息发给相邻的节点；

步骤2，相邻的节点根据全局网络的状态，判断路径上是否满足数据流的QoS需求，并将是否接受该数据流回应给发送方；

步骤3，路径上相邻的两个节点通信，上游节点指示下游节点为其数据流预留资源，使得这两个节点之间建立起数据传输链路；

步骤4，路径上每两个相邻的节点均执行步骤3，直到接收方和其相邻的节点之间也建立完成，则整条路径建立完成；

二，主动拆除路径：

步骤5，当发送方发送报文完毕，向相邻的节点请求断链；或者当相邻的节点通过协同代理，发现路径上某个节点不能满足当前的QoS需求时，则向下游路由器发送拆除路径消息，依次转发给路径上每个节点和接收方，路径拆除完成；

三，被动拆除路径：

步骤6，当某个节点收到建立路径消息时，由于突发情况不能满足其QoS需求，则需要回应上游节点不能建立路径；

步骤7：上游节点根据步骤6的回应，向其上游节点发送拆除链路消息，依次转发给路径上的上游节点和发送方；

所述域间协同的具体流程如下：

一，路径建立：

步骤1，发送方将数据流的QoS需求信息发给上级节点；

步骤2，上级节点判断路径上是否满足数据流的QoS需求，并将是否接受该数据流回应给发送方；

步骤3：上级节点指示路径上的所有节点和接收方发送为其数据流预留资源，进而建立整条传输路径；

二，主动拆除路径：

步骤4，当发送方发送报文完毕，向上级节点请求断链，或者当上级节点通过协同代理，发现某个节点不能满足当前的QoS需求时，则向路径上的节点和发送方发送拆除路径消息；

三，被动拆除路径：

步骤5：当某个节点收到上级节点发送的建立路径消息时，由于突发情况不能满足其QoS需求，则告知上级节点，若上级节点决定拆除路径，则逆序向路径上已经建立路径的节点告知拆除链路。