rfc1333.txt

RFC规范的翻译稿

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PeerInPackets                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PeerInDiscards                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PeerInErrors                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PeerInOctets                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PeerOutLQRs                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PeerOutPackets                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PeerOutOctets                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	下面的各个域实际上并不经过输入链路传输。相反，它们逻辑上被实现者的Rx过程加
到包上。
	
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SaveInLQRs                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SaveInPackets                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SaveInDiscards                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SaveInErrors                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SaveInOctets                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Magic-Number：
	魔术数（Magic-Number field）是2个Octets和辅助检测looped-back条件下的链路。除
非由配置选项修改，魔术数必须以零值传输并且在接收端被忽略。如果磋商了魔术数，则输
入LQR包应该被校验以保证当地端看不到自己的魔术数和looped-back链路。参考魔术数配
置选项的进一步解释。
	LastOutLQRs：
	LastOutLQRs是4个Octets，是从最近接收的PeerOutLQRs复制过来的。
	LastOutPackets：
	LastOutPackets是4个Octets，是从最近接收的PeerOutPackets复制过来的。
	LastOutOctets：
	LastOutOctets是4个Octets，是从最近接收的PeerOutOctets复制过来的。
	PeerInLQRs：
	PeerInLQRs是4个Octets，是从最近接收的SaveInLQRs复制过来的。
	无论何时发现PeerInLQRs域为零，LastOut域是不确定的，并且PeerIn域包含对端的
初始化值。
	PeerInPackets：
	PeerInPackets是4个Octets，是从最近接收的SaveInPackets复制过来的。
	PeerInDiscards：
 	PeerInDiscards是4个Octets，是从最近接收的SaveInDiscards复制过来的。
	PeerInErrors：
	PeerInErrors是4个Octets，是从最近接收的SaveInErrors复制过来的。
	PeerInOctets：
	PeerInOctets是4个Octets，是从最近接收的SaveInOctets复制过来的。
	PeerOutLQRs：
	PeerOutLQRs是4个Octets，是从接收的OutLQRs复制过来的。这个数必须包含此LQR。
	PeerOutPackets：
	PeerOutPackets是4个Octets，是从当前的MIB ifOutUniPackets 和 ifOutNUniPackets
复制过来的。这个数必须包含此LQR。
	PeerOutOctets：
	PeerOutOctets是4个Octets，是从当前的MIB ifOutOctets复制过来的。这个数必须包
含此LQR。
	SaveInLQRs：
	SaveInLQRs是4个Octets，是从接收的InLQRs复制过来的。这个数必须包含此LQR。
	SaveInPackets：
	SaveInPackets是4个Octets，是从当前接收的MIB ifInUniPackets 和 ifInNUniPackets
复制过来的。这个数必须包含此LQR。
	SaveInDiscards：
	SaveInDiscards是4个Octets，是从当前接收的MIBifInDiscards复制过来的。这个数必
须包含此LQR。
	SaveInErrors：
	SaveInErrors是4个Octets，是从当前接收的MIB ifInErrors复制过来的。这个数必须包
含此LQR。
	SaveInOctets：
	SaveInOctets是4个Octets，是从当前接收的InGoodOctets复制过来的。这个数必须包
含此LQR。
	注意InGoodOctets和MIB ifInOctetes计数器不一样，因为InGoodOctets不包括被丢掉
的或者有错的包中的Octets。
2.7 报告传输
	当PPP链路控制协议进入打开状态(the Opened state)，链路质量监控过程可以开始发送
LQR。如果接收到指定LQR包的协议拒绝，LQM（链路质量管理器）过程必须终止发送
LQR。
	一般说来，当链路的LQR计时器超时时就发送LQR。如果没有使用LQR计数器，则
一旦收到进入的LQR就产生一个LQR。磋商过程确保至少链路的一方使用LQR计时器。
	另外，无论何时接收到两个连续的具有相同的PeerInLQRs值的LQR，就产生一个LQR。
这表明一个LQR已经丢失过，或者实现者以低于对端的速率发送LQR，或者对端加速LQR
产生以更好的量化链路错误。无论何时LQR被发送，LQR计时器必须重新启动。
2.8 计算
	每当从输入链路接收到LQR包，Link-Manager就比较相关的域。用当前LQR的各个域
值减去前一个LQR的各个域值就可以得到绝对的“delta，”，这样链路的两端可以看到变化
了。
	如果接收的PeerInLQRs域为零，则LastOut域是不确定的，并且PeerIn域包含对端的
初始化值。这时不作任何计算。
	实现注意：
	下面的计数器达到最大值后会变成0。必须注意这点，保证此时能够计算出正确的"delta"
	LastOutLQRs。域可以直接和PeerInLQRs域比较来决定丢失了多少outbound的LQR。
	LastOutLQRs。域可以直接和OutLQRs计数器比较来决定有多少outbound的LQR仍在
传递中。
	PeerInPackets的变化可以和LastOutPackets的变化比较来决定输出链路上丢失包的数
目。
	PeerInOctets的变化可以和LastOutOctets的变化比较来决定输出链路上丢失Octets的数
目。
	SaveInPackets的变化可以和PeerOutPackets的变化比较来决定输入链路上丢失包的数
目。
	SaveInOctets的变化可以和PeerPackets的变化比较来决定输入链路上丢失Octets的数
目。
	PeerInDiscards和PeerInErrors可以用来决定是否包丢失是因为对端的拥塞而不是链路
失败。
2.9 失败检测
	当链路在链路的两个方向上正常工作时，LQR是多余的。传输LQR的最大时间间隔应
该选择为最小限度的干涉传输的值。
	当在任一个方向上存在可测量的数据丢失时，如果全部吞吐量是充分的，则这种条件是
不足够解释链路丢失的。除了能够测量到丢失率的峰值，快速发送LQR是没有什么结果的。
必须选择一个长时间间隔以足够保证有一个好的数据平滑影响，相应的短的时间间隔可以确
保快速响应失败。如果链路输入正常，输出情况糟糕，则输入的LQR会表明在链路的输出
方向上存在高丢失率。快速发送LQR是没有帮助的，因为它们可能会在到达对端的链路上
丢失的。
	如果链路输出正常，但输入情况糟糕，则输入LQR将会频繁丢失。在这种情况下，应
该以更快的速率发送LQR。这主要依靠对端做的信息策略决策。对端也可以在相应中发送
LQR（复制PeerInLQRs域），这样某些LQR也许能成功到达。
	如果LQR在期待的时间内没有到达，或者接收的LQR表明链路情况真的很糟，则至少
发送一个额外的LQR。算法决策需要至少两个round trip时间间隔。由于链路高负载或者输
出LQR丢失，这个丢失率可能是暂时的。
2.10 策略建议
	LQR包提供了一种机制决定链路质量，但是这受限于每个实现者决定什么时候链路可
用。建议这个策略实现一些滞留以至于链路不会摇摆。一种策略使用 K out of N 算法。在
这个算法中考虑到好的质量，对于链路的后N周期必须有K次成功。
	从差质量链路恢复的过程不需要被说明和对于不同的实现者可以不同。一个建议的方法
是立即关闭所有其他的网络层协议（例如使IPCP发送一个终止请求），但是继续传输LQR。
一旦链路质量又达到可接受的标准，就重新配置网络层协议。
安全考虑
	安全问题不在此备忘录讨论范围内。
参考文献

    [1]   Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.

   	[2]   McCloghrie, K., and M. Rose, "Management Information Base for
         Network Management of TCP/IP-based internets: MIB-II", RFC
         1213, March 1991.

    [3]   Rose, M., and K. McCloghrie, "Structure and Identification of
         Management Information for TCP/IP-based Internets", RFC 1155,
         May 1990.
致谢
	此文档的一些内容来自RFC1172，它是由 Drew Perkins of Carnegie Mellon University和
Russ Hobby of the University of California at Davis共同制定的。
	特别感谢Craig Fox (Network Systems), and Karl Fox (Morning Star Technologies)的基于
实现经验的设计建议。
主席地址
	可以通过现任主席联系工作组。
	Brian Lloyd
      Lloyd & Associates
      3420 Sudbury Road
      Cameron Park, California 95682

      Phone: [phone]

      EMail: [e-mail]
作者地址
	关于此备忘录的问题可以直接联系：
	William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      P O Box 6205
      East Lansing, MI  48826-6025

      EMail: [e-mail]

完整版权说明
   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   只要在所有复本与推导性工作中包含上面的版权声明和这段文字，就可以全部地或
者部分地且没有任何限制地复制这篇文档与其译本以及把它提供给其它文档，同样也可以准
备、复制、出版与发行推导性工作，而且需要评述此推导性工作否则就得解释它，或者辅助
此推导性工作的实现。然而，此文档本身不可以做任何修改，诸如删除版权声明或者因特网
社区或其它因特网组织的涉及，除了当需要开发因特网标准的目的时之外且在此种情况下必
须遵循在因特网标准过程中定义的版权程序，或者除了当要求把它译成其它语言（即不是英
文）的目的时之外。
在上面准予的有限的许可是永久性的，而且因特网社区或者它的继承者或指派者都将不
会废除它。
在此包含的这篇文档与信息是基于“AS IS”而提供的，并且因特网社区与因特网工程
任务组织声明了所有的授权、表达或含义，且包含对任何授权的限制，比如这里信息的使用
不会违反任何授权或者出于特殊目的的商品性或适切性的任何含蓄授权。
致谢
感谢因特网社区当前为RFC编辑提供了功能基金。


RFC1333——PPP Link Quality Monitoring                              PPP 链路质量监控


1
RFC文档中文翻译计划