組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王奎（pywang  mailto: wangtianzhi@263.net）
譯文發布時間：2001-12-28
版權：本翻譯文檔可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及組織信息。


Network Working Group                                        		M. Simpson
Request for Comments: 1333					        Daydreamer
                                                     	May 1992

PPP 鏈路質量監控
（RFC1333——PPP Link Quality Monitoring ）

備忘錄狀態
   	此RFC 為internet community詳細說明了 IAB 標準跟蹤協議，并且請求討論和建議
以便改進。請參考IAB Official Protocol Standards 的當前版本，確保這個協議陳述和
狀態的標準化。此備忘錄的分發不受限制。

摘要
點到點協議（the Point-to-Point Protocol）提供了一種在點到點鏈路上封裝網絡層協議
信息的標準方法。PPP 也定義了可擴展的鏈路控制協議(Link Control Protocol)，它（Link 
Control Protocol）允許在鏈路生存期內對鏈路持續監控，磋商鏈路質量。
這個文檔為生成鏈路質量報告（Link-Quality-Reports）定義了協議。
此RFC是IETF(the Internet Engineering Task Force)的PPP協議工作組的成果。關于
這個備忘錄的建議請提交給：ietf-ppp@ucdavis.edu。
目錄
1. 介紹	2
2. 鏈路質量監控	2
2.1 設計動機	2
2.2 計數器	3
2.3 計算包（packets）和八位字節（octets）	3
2.4 處理過程	4
2.5 配置選項格式	4
2.6 包格式	5
2.7 報告傳輸	7
2.8 計算	8
2.9 失敗檢測	8
2.10 策略建議	8
安全考慮	9
參考文獻	9
致謝	9
主席地址	9
作者地址	10
完整版權說明	10
致謝	10

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

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

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

2.2 計數器
每種鏈路質量監控實現維持著發送和成功接受包和八位字節的數目的計數器，并且定期
的用鏈路質量報告包把這個信息發送給對端。
這些計數器類似于序列號；它們一直增加，這指示通過外部鏈路的包和八位字節的數目。
通過比較連續的LQR中的數值，LQR接受者可以計算出通過鏈路成功通信的包和八位字節
的“delta”數。比較這些絕對值數然后給出鏈路質量的跡象。除了絕對值，相對值也被傳
輸。這是因為它們能夠大大的簡化鏈路同步。
LQR使用由SNMP MIB-II[2]定義的接口計數器。當LCP進入建立階段時，這些計數器
并不初始化為任何值。
另外，LQR要求實現下面三個無符號的，單調遞增的計數器，它們符合SNMP MIB計
數器要求的類型和大小。
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必須被計算在內，包括包頭，信息域和任何填料。
FCS Octets也必須被計算在內，每幀的一個標志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-Protocol Configuration Option）。
然而，不需要磋商。僅在實現者希望保證對端傳輸不同于其他質量協議的LQR，或者防止
對端維護自己的計時器，或者在LQR傳輸間建立最大的時間間隔，磋商是必須的。
	下面是磋商LQR的質量協議配置選項格式的總結。各個域是由左到右傳輸的。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Quality-Protocol       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Reporting-Period                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic-Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         LastOutLQRs                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        LastOutPackets                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        LastOutOctets                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PeerInLQRs                            |