?? rfc1333.txt
字號:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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: (916) 676-1147
EMail: brian@ray.lloyd.com
作者地址
關于此備忘錄的問題可以直接聯系:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6025
EMail: bsimpson@ray.lloyd.com
完整版權說明
Copyright (C) The Internet Society (2001). All Rights Reserved.
只要在所有復本與推導性工作中包含上面的版權聲明和這段文字,就可以全部地或
者部分地且沒有任何限制地復制這篇文檔與其譯本以及把它提供給其它文檔,同樣也可以準
備、復制、出版與發行推導性工作,而且需要評述此推導性工作否則就得解釋它,或者輔助
此推導性工作的實現。然而,此文檔本身不可以做任何修改,諸如刪除版權聲明或者因特網
社區或其它因特網組織的涉及,除了當需要開發因特網標準的目的時之外且在此種情況下必
須遵循在因特網標準過程中定義的版權程序,或者除了當要求把它譯成其它語言(即不是英
文)的目的時之外。
在上面準予的有限的許可是永久性的,而且因特網社區或者它的繼承者或指派者都將不
會廢除它。
在此包含的這篇文檔與信息是基于“AS IS”而提供的,并且因特網社區與因特網工程
任務組織聲明了所有的授權、表達或含義,且包含對任何授權的限制,比如這里信息的使用
不會違反任何授權或者出于特殊目的的商品性或適切性的任何含蓄授權。
致謝
感謝因特網社區當前為RFC編輯提供了功能基金。
RFC1333——PPP Link Quality Monitoring PPP 鏈路質量監控
1
RFC文檔中文翻譯計劃
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -