PPP 鏈路質量監控

1.介紹
PPP有三個主要的組成部分：
1． 在串行鏈路上封裝數據報（datagrams）的方法。
2． 建立，配置和測試數據鏈路鏈接（thedata-linkconnection）的LCP協議（Link
ControlProtocol）。
3． 建立和配置不同網絡層協議的一組NCP協議（NetworkControlProtocol）。
為了在點到點鏈路（point-to-pointlink）上建立通信，PPP鏈路的一端必須在建立階段
（Establishmentphase）首先發送LCP包（packets）配置數據鏈路。在鑒定和網絡層協
議階段（AuthenticationandNetwork-LayerProtocolphases），必須檢測鏈路以決定鏈路質
量是否滿足操作需要。這種檢測是完全可選的。

如果一個實現（implementation）要求對端（peer）使用某個特定的鏈路質量監控協議，
那就必須在鏈路建立階段使用質量協議配置選項（theQuality-ProtocolConfiguration
Option）磋商特定協議的使用。

這個磋商機制在任一個方向上是獨立的。然而，如果對端同意發送質量協議包
（Quality-Protocolpackets），那么在接受方必須適當地處理這種包，即使它沒有請求這種
包或者不需要實現這種監控策略。

2.鏈路質量監控
數據通信鏈路是很少完美的。由于各種原因（例如線路噪音，設備失敗，緩存溢出等等），
鏈路上的包可能被丟掉或者被破壞。有時候，有必要決定什么時候鏈路丟數據，丟包頻率。
例如，路由器可能要暫時允許另一個路由器占的優先權。一個實現也可能使用選項斷掉和切
換到另一個替換的鏈路。決定數據丟失的過程被稱為“鏈路質量監控”。
2.1設計動機
有很多不同的方法測量鏈路質量，并且有更多的方法對鏈路質量測量有效。勝于指定一
個單獨的方法，鏈路質量監控被分為一個機制（mechanism）和一個策略（policy）。PPP
通過定義鏈路質量報告包（Link-Quality-ReportPacket）和指定一個處理過程，為鏈路質量
監控詳細說明了監控機制。PPP沒有說明鏈路質量監控策略――如何斷定鏈路質量或者當
鏈路不充分時該怎么做。這個被留做一個實現決策，并且在鏈路的各端可能是有差別的。我
們允許甚至鼓勵實現（implementations）去試驗各種鏈路質量策略。鏈路質量監控機制說
明書保證了使用不同策略的兩個實現可以通信和內部操作的。
為了允許實現靈活的策略，PPP鏈路質量監控機制以包（packet），八位字節（octets）
和鏈路質量報告（Link-Quality-Reports）為單位測量數據丟失率。每個測量方法被分別用
來測量鏈路的每半部分，包括內部和外部。所有的測量方法被通知給鏈路的兩端，以致鏈路
的每一端能夠為它的輸入和輸出鏈路實現自己的鏈路質量策略。
最后，鏈路質量監控協議被設計成可以在許多不同系統上實現。盡管通常實現PPP（特
別是鏈路質量監控）作為一個單獨的軟件過程，但是我們也預想帶硬件支持的多過程實現。
PPP鏈路質量監控機制通過仔細定義鏈路質量報告包的格式和為所有數據傳輸和接受測量
方法指定參考要點，提供了多過程實現的方法。

2.2計數器
每種鏈路質量監控實現維持著發送和成功接受包和八位字節的數目的計數器，并且定期
的用鏈路質量報告包把這個信息發送給對端。
這些計數器類似于序列號；它們一直增加，這指示通過外部鏈路的包和八位字節的數目。
通過比較連續的LQR中的數值，LQR接受者可以計算出通過鏈路成功通信的包和八位字節
的“delta”數。比較這些絕對值數然后給出鏈路質量的跡象。除了絕對值，相對值也被傳
輸。這是因為它們能夠大大的簡化鏈路同步。
LQR使用由SNMPMIB-II[2]定義的接口計數器。當LCP進入建立階段時，這些計數器
并不初始化為任何值。
另外，LQR要求實現下面三個無符號的，單調遞增的計數器，它們符合SNMPMIB計
數器要求的類型和大小。
OutLQRs：
OutLQRs是一個32位的計數器。每發送一個LQR包，它遞增1。在LCP進入建立階
段時，這個計數器必須置零，并且一直到LCP離開終止階段它一定不得被重置。這個計數
器在被插入LQR包前增1。
InLQRs：
InLQRs是一個32位的計數器。每接收一個LQR包，它遞增1。在LCP進入建立階
段時，這個計數器必須置零，并且一直到LCP離開終止階段它一定不得被重置。這個計數
器在被插入LQR包（在一個依靠方式的實現中）前增1。
InGoodOctes：
InGoodOctes是一個32位的計數器。它每次增加每個正確接收的數據鏈路層包中的八
位字節數。不像MIB的ifInOctets，在ifInDiscards和ifInErrors中計數的幀中的八位字節禁
止被計數。這個計數器在LCP進入建立階段時可以被初始化為任何值。但是直到LCP離開
終止階段前，不能被重置。
2.3計算包（packets）和八位字節（octets）
計數器的目的是為了提供一種方法來表示通過鏈路上的信息量，而不是實際的所用
的帶寬量。這種規范被設計成在各種環境中能夠產生相同的計數。例如一個單獨的設備隱式
的為實現提供分幀和封裝機制，或者在鏈路中同步到異步的轉換器在各機制中的變化。
在FCS計算時，所有的Octets必須被計算在內，包括包頭，信息域和任何填料。
FCSOctets也必須被計算在內，每幀的一個標志Octets也必須被計算在內。其它所有的Octets
（例如額外的標志序列號，逃跑位或者Octets）不得計算在內。
當在LQR中插入包和Octets計數時，這些計數必須包括LQR本身期待得數值。
2.4處理過程
PPP鏈路質量監控機制希望用一個“邏輯過程”模型。如下所示，在每個雙向鏈路的每
一端共復制了五個邏輯過程。
+---------++-------++----+Outbound
||-->|Mux|-->|Tx|=========>
|Link-|+-------++----+
|Manager|
||+-------++----+Inbound
||<--|Demux|<--|Rx|<=========
+---------++-------++----+

鏈路管理器：
鏈路管理器傳輸和接收LQR，和實現所期待的鏈路質量策略。LQR包以恒定的速
率傳輸。這個速率是由LCP質量協議配置選項磋商得到的。
Mux：
Mux把來自各個協議（例如LCP，IP，XNS等等）的多元包處理成一個單獨的，連續
的，有優先級的包流。LQR包必須被賦予可能的最高優先級，以保證鏈路質量信息及時被
傳輸。
Tx：
Tx過程維護著MIB計數器ifOutUniPackets和ifOutOctets,和內部計數器OutLQRs，它
用來測量在輸出鏈路上傳輸的數據量。當Tx處理LQR包時，它把這些計數器的值插入到
包中的PeerOut域。Tx過程必須跟在Mux過程后面以確保這些包以在鏈路上傳輸的順序計
數。
Rx：
Rx過程維護著MIB計數器ifInUniPackets,ifInDiscards,ifInErrors和ifInOctets,和內部計
數器InLQRs和InGoodOctets，它用來測量在輸入鏈路上接收的數據量。當Tx處理LQR包
時，它把這些計數器的值插入到包中的SaveIn域（在一個依靠方式的實現中）。
Demux：
Demux過程為各種協議分解多元包。Demux過程必須跟在Rx過程后面以確保這些包
以在鏈路上接收的順序計數。
2.5配置選項格式
描述：
實現者必須為LQR準備接收質量協議配置選項（Quality-ProtocolConfigurationOption）。
然而，不需要磋商。僅在實現者希望保證對端傳輸不同于其他質量協議的LQR，或者防止
對端維護自己的計時器，或者在LQR傳輸間建立最大的時間間隔，磋商是必須的。
下面是磋商LQR的質量協議配置選項格式的總結。各個域是由左到右傳輸的。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type|Length|Quality-Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reporting-Period|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

類型：
4
長度：
8
質量協議：
c025（十六進制）（LQR）
報告周期：
報告周期域（theReporting-Periodfield）是4個Octets和表明了在包傳輸間的最大時間
間隔（以1/100秒計算）。對端可以以比商議的更快的速率傳輸包。
此值為零表明對端不需要維護計時器。作為替代，對端一旦接收LQR立即產生一個
LQR。當對端為帶零值的LQR已經發送或者將發送一個包含質量協議配置選項的配置請求
包時，它必須不被帶非零值得對端應答。
2.6包格式
LQR包被封裝在PPP數據鏈路層幀的信息域中，此幀的協議域為c025（LQR）。下面
是LQR包格式的總結。域名相對于包的接收者，因為是接收者請求的配置包，各個域從左
到右傳輸。


0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Magic-Number|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LastOutLQRs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LastOutPackets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LastOutOctets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerInLQRs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerInPackets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerInDiscards|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerInErrors|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerInOctets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerOutLQRs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerOutPackets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PeerOutOctets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

下面的各個域實際上并不經過輸入鏈路傳輸。相反，它們邏輯上被實現者的Rx過程加
到包上。

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SaveInLQRs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SaveInPackets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SaveInDiscards|

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

Magic-Number：
魔術數（Magic-Numberfield）是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，是從當前的MIBifOutUniPackets和ifOutNUniPackets
復制過來的。這個數必須包含此LQR。
PeerOutOctets：
PeerOutOctets是4個Octets，是從當前的MIBifOutOctets復制過來的。這個數必須包
含此LQR。
SaveInLQRs：
SaveInLQRs是4個Octets，是從接收的InLQRs復制過來的。這個數必須包含此LQR。
SaveInPackets：
SaveInPackets是4個Octets，是從當前接收的MIBifInUniPackets和ifInNUniPackets
復制過來的。這個數必須包含此LQR。
SaveInDiscards：
SaveInDiscards是4個Octets，是從當前接收的MIBifInDiscards復制過來的。這個數必
須包含此LQR。
SaveInErrors：
SaveInErrors是4個Octets，是從當前接收的MIBifInErrors復制過來的。這個數必須包
含此LQR。
SaveInOctets：
SaveInOctets是4個Octets，是從當前接收的InGoodOctets復制過來的。這個數必須包
含此LQR。
注意InGoodOctets和MIBifInOctetes計數器不一樣，因為InGoodOctets不包括被丟掉
的或者有錯的包中的Octets。
2.7報告傳輸
當PPP鏈路控制協議進入打開狀態(theOpenedstate)，鏈路質量監控過程可以開始發送
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會表明在鏈路的輸出
方向上存在高丟失率?？焖侔l送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-basedinte.nets: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.

只要在所有復本與推導性工作中包含上面的版權聲明和這段文字，就可以全部地或
者部分地且沒有任何限制地復制這篇文檔與其譯本以及把它提供給其它文檔，同樣也可以準
備、復制、出版與發行推導性工作，而且需要評述此推導性工作否則就得解釋它，或者輔助
此推導性工作的實現。然而，此文檔本身不可以做任何修改，諸如刪除版權聲明或者因特網
社區或其它因特網組織的涉及，除了當需要開發因特網標準的目的時之外且在此種情況下必
須遵循在因特網標準過程中定義的版權程序，或者除了當要求把它譯成其它語言（即不是英
文）的目的時之外。
在上面準予的有限的許可是永久性的，而且因特網社區或者它的繼承者或指派者都將不
會廢除它。
在此包含的這篇文檔與信息是基于“ASIS”而提供的，并且因特網社區與因特網工程
任務組織聲明了所有的授權、表達或含義，且包含對任何授權的限制，比如這里信息的使用
不會違反任何授權或者出于特殊目的的商品性或適切性的任何含蓄授權。
致謝
感謝因特網社區當前為RFC編輯提供了功能基金。