云南龙网

  1. 首页 > 云知道 > >

PPP 链路质量监控( 五 )

云知道


目 。
SaveInOctets的变化可以和PeerPackets的变化比较来决定输入链路上丢失Octets的数
目 。
PeerInDiscards和PeerInErrors可以用来决定是否包丢失是因为对端的拥塞而不是链路
失败 。
2.9失败检测
当链路在链路的两个方向上正常工作时，LQR是多余的 。传输LQR的最大时间间隔应
该选择为最小限度的干涉传输的值 。
当在任一个方向上存在可测量的数据丢失时，假如全部吞吐量是充分的，则这种条件是
不足够解释链路丢失的 。除了能够测量到丢失率的峰值，快速发送LQR是没有什么结果的 。
必须选择一个长时间间隔以足够保证有一个好的数据平滑影响，相应的短的时间间隔可以确
保快速响应失败 。假如链路输入正常，输出情况糟糕，则输入的LQR会表明在链路的输出
方向上存在高丢失率 。快速发送LQR是没有帮助的，因为它们可能会在到达对端的链路上
丢失的 。
假如链路输出正常，但输入情况糟糕，则输入LQR将会频繁丢失 。在这种情况下，应
该以更快的速率发送LQR 。这主要依靠对端做的信息策略决策 。对端也可以在相应中发送
LQR（复制PeerInLQRs域），这样某些LQR也许能成功到达 。
假如LQR在期待的时间内没有到达，或者接收的LQR表明链路情况真的很糟，则至少
发送一个额外的LQR 。算法决策需要至少两个roundtrip时间间隔 。由于链路高负载或者输
出LQR丢失，这个丢失率可能是暂时的 。
2.10策略建议
LQR包提供了一种机制决定链路质量，但是这受限于每个实现者决定什么时候链路可
用 。建议这个策略实现一些滞留以至于链路不会摇摆 。一种策略使用KoutofN算法 。在
这个算法中考虑到好的质量，对于链路的后N周期必须有K次成功 。
从差质量链路恢复的过程不需要被说明和对于不同的实现者可以不同 。一个建议的方法
是立即关闭所有其他的网络层协议（例如使IPCP发送一个终止请求），但是继续传输LQR 。
一旦链路质量又达到可接受的标准，就重新配置网络层协议 。
安全考虑
安全问题不在此备忘录讨论范围内 。
参考文献
[1]Simpson,W.,"ThePoint-to-PointProtocol",RFC1331,May1992.
[2]McCloghrie,K.,andM.Rose,"ManagementInformationBasefor
NetworkManagementofTCP/IP-basedinternets:MIB-II",RFC
1213,March1991.
[3]Rose,M.,andK.McCloghrie,"StrUCtureandIdentificationof
ManagementInformationforTCP/IP-basedInternets",RFC1155,
May1990.
致谢
此文档的一些内容来自RFC1172，它是由DrewPerkinsofCarnegieMellonUniversity和
RussHobbyoftheUniversityofCaliforniaatDavis共同制定的 。
非凡感谢CraigFox(NetworkSystems),andKarlFox(MorningStarTechnologies)的基于
实现经验的设计建议 。
主席地址
可以通过现任主席联系工作组 。
BrianLloyd
Lloyd&Associates
3420SudburyRoad
CameronPark,California95682
Phone:(916)676-1147
EMail:brian@ray.lloyd.com
作者地址
关于此备忘录的问题可以直接联系：
WilliamAllenSimpson
Daydreamer
ComputerSystemsConsultingServices
POBox6205
EastLansing,MI48826-6025
EMail:bsimpson@ray.lloyd.com
完整版权说明
Copyright(C)TheInternetSociety(2001).AllRightsReserved.
只要在所有复本与推导性工作中包含上面的版权声明和这段文字，就可以全部地或
者部分地且没有任何限制地复制这篇文档与其译本以及把它提供给其它文档，同样也可以准
备、复制、出版与发行推导性工作，而且需要评述此推导性工作否则就得解释它，或者辅助

推荐阅读


上一篇：转社保需要测试报告吗

下一篇：在EXCEL中如何取消共享