自动交换光网络 ASON的信令要求( 五 )


连接控制器误动作引起消息误解码缺陷 。本建议不讨论检测某个元件误动作的机制 。
Ca11C和CC将缺陷信息通知治理平面 。图1提供了Ca11C处理呼叫请求的参考流程 。根据这个网络模型,以下不具体说明建立和释放呼叫以及操作中发生各种缺陷的信令流程,具体参见G.7713 。
4 信令协议
4.1 信令协议要求
呼叫和连接控制治理通过信令协议完成,以实现端到端光连接的建立、修改、状态查询、释放以及恢复 。信令协议应满足以下要求:
(1) UNI、I-NNI和E-NNI信令协议的选择应相互独立 。
(2)信令应遵循ITU-T G.8080和G.7713 。
(3)信令应该支持显式路由方式,可以采用严格和松散方式 。
(4)信令应该支持单一连接和一组连接两种连接治理方式 。(可选)
(5)信令应该支持故障通告 。
(6)信令应支持回溯(crank-back)和重路由(Reroute),用于解决请求冲突和连接恢复 。
(7)信令应支持每个连接全局唯一的标识 。
(8)信令应对所有请求同时支持肯定和否定响应,必要时包括原因 。
(9)信令应支持代表连接特点的所有连接属性 。
(10)对于网络内的所有域而言,域间信令协议对于域内信令协议不可知 。
域间信令应答应在连接的边界不使用UNI信令协议(即与连接两端的客户设备是否支持UNI信令无关) 。
目前ITU-T规范了三种信令协议,分别是G.7713.1-专用网络-网络接口协议(PNNI)、G.7713.2-资源预留协议流量工程扩展协议(RSVP-TE)和G.7713.3-路由受限-标记分配协议(CR-LDP),下面分别对RSVP TE和CR-LDP信令协议进行描述,PNNI协议因使用的范围不广,在此不再具体描述 。
4.2 RSVP-TE协议
4.2.1 RSVP协议概述
90年代中期,RSVP被开发用以防止网络阻塞,RSVP是一种网络控制协议,与路由协议结合使用,目的是使IP网络提供有一定QOS保障的服务 。
RSVP的预留请求由“f1owspec”和“filter spec”组成,它们组成的一对称为“flow descriptor”,f1owspec规范所需要的QoS,filter spec与会话规范一起定义数据分组,以便接收f1owspec定义的QoS,f1owspec用来在节点的分组规划或链路层机制中设置参数,而fi1terspec用于在分组分类器中设置参数,对于目标为某个特定对话而与该会话的任何fi1terspecs都不匹配的数据分组作为尽力而为的业务来处理 。
RSVP的预约风格分为三种:通配过滤风格(Wi1dcard-Filter:WF)、固定过滤风格(Fixed-fi1ter:FF)和共享显式风格(Shared-EXPlicit:SE) 。
总的来说,RSVP的特性如下:
RSVP对于单播和多对多的多播应用完成资源预留,动态适配来改变组员和改变路由 。
RSVP是单工的,即它使用单向数据流来预留资源;
RSVP是面向接收者的,即数据流的接收者发起和维持该数据流使用的资源预留 。RSVP是基于接收方的资源预留协议,发送方首先发出PATH信息,经过下层路由协议多点投递到每个可能的接收方,接收方根据各自对于服务质量的需求,确定它们各自的需求和资源预留能力,从而给出的RESV信息,通过PATH信息路径反向回送到发送方,每个经过的路由器都将进行接纳控制和资源预留,假如失败则通知接收方,否则将资源预留请求递交给前一个路由器.为使接收方能够在路由器可接收的范围内给出预留请求,PATH信息将携带发送方支持的通信需求,PATH信息分组路由器可能会修改PATH分组有关可用资源的描述以通告接收方;上述过程都认为返回发送方及路由器资源通告的RESV信息是PATH信息经过的反向路径 。-RSVP在路由器和主机中是“软”状态的,答应网络动态变化以及由此引起的路由变化;
RSVP不是一种路由协议,但是它依靠现有和未来的路由协议,每个路由器预留的资源是“软”的,即这些资源需要由接收端定期地刷新;

推荐阅读