云南龙网

  1. 首页 > 云知道 > >

ISO8473基础上的端系统与中介系统间的路由信息的交换(11)

云知道


的后果 。首先 ， 每个引起重定向的PDU都会使得额外的PDU被产生和传输 ， 这会增加开销 。
另外 ， 每次保持定时器时间到 ， 被重定向的端系统至少使用错误的路由发送一个PDU 。
A.1.2配置信息的保持定时器实例
与以上类似的问题也发生在配置信息上 。假如一个ISHPDU的保持定时器设置得很长 ，
并且发出该ISHPDU的IS忽然变得不可达 ， 就会形成黑洞 。在这段时间内 ， 端系统假定该
中介系统会继续为它转发PDU ， 从而无法与其他系统正常通信 。而当该定时器时间到时 ，
该端系统才发现没有可用的中介系统 。
无论何种情况的问题发生 ， 都要求错误信息的响应能够正确无误地找到源头 。为了达到
这一点 ， 配置信息和路由重定向信息在源头计算好并准确无误地传到接收端 。
A.2路由重定向信息的刷新和定时
本协议答应端系统在保持定时器还未时间到、并且为收到新的重定向信息的情况下对路
由重定向信息进行刷新 。这种过程在无连接网络中经常使用 ， 它被称作“反转路径信息”、
“前一跳缓存”等 。
刷新重定向信息有很明显的好处 ， 但是假如处理得不好很可能出现严重后果 。为了是重
定向信息安全刷新 ， 必须保证以下几点：
1． 已经收到的PDU的源地址必须和前面的RDPDU的目的地址一致 。不可以
把短地址、组地址或类似的地址当作一致的 。
2． 收到的PDU中的服务质量参数必须与相应的重定向信息中的一致 。不能保
证服务质量参数相同的PDU通过同一路径发送 。很有可能对某些服务质量
参数来说某条路径是个黑洞 。
3． 收到的PDU的前一跳必须与重定向信息中的下一跳相符 。非凡的 ， 送来PDU
的SN_UNITDATA.Indication原语中的SN_Source_Address参数必须与重定
向中的SN_Destination_Address一致 。着保证了接受重定向信息的IS正是原
先的发送者 。
注重 ， 以上条件仍然答应重定向刷新在最有利的情况下进行 。比如目的地是另外一个
ES 。
A.3系统初始化
本协议被设计用来是两种系统能够尽可能自由地通信 。所以 ， 端系统要求子网上所有
的中介系统报告配置信息、或者中介系统要求所有的端系统报告配置信息都是不可能的 。
在某种操作环境下 ， 系统受到很大的限制 。在网络达到正常运行之前 ， 端系统必须先
尽快发现一个中介系统 。反过来 ， 中介系统是否也要发现端系统呢？这基本上有配置定时器
决定 。在开销和配置信息的适用性上要有权衡 。减少配置定时器的值意味着信息的适用性 ，
同时也意味着开销的增加 。
我们推荐以下这种方法来解决以上冲突 。当记录配置功能在任何一种系统中被引用
时 ， 该功能就必须判定这个信息是否之前是未知的 。假如是 ， 那么在系统的配置定时器时间
到是就要引用该功能 。然后配置报告功能生成HELLOPDU并送到原先未知的网络实体去 。
于是 ， 当ES或IS变得可操作是就立即发出配置报告 。一旦令一种系统发现了这个新的网
络实体 ， 它们就会使其知道自己的存在 。
这种方法带来的开销就要小得多 。另外 ， 由于新的配置信息被即使发现 ， 定时器的时
间被定期地延长以减少开销 。还有一个忠告：由于第一个HELLO很可能丢掉 ， 所以在系统
初始化的阶段应当以很短的时间间隔发出HELLO包 。
注重 ， 这种方法可能仅在IS或者ES ， 也可能在所有系统中执行 。该过程仅是一个本
地过程并且可能被本地系统改变 。

推荐阅读


上一篇：CDR中一个矩形如何切断线条

下一篇：360路由器助手如何快速卸载