組織：中國互動出版網(wǎng)（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）
譯文發(fā)布時間：2001-12-28
版權(quán)：本翻譯文檔可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及組織信息。


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

PPP 鏈路質(zhì)量監(jiān)控
（RFC1333——PPP Link Quality Monitoring ）

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

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

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

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

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

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

	鏈路管理器：
		鏈路管理器傳輸和接收LQR，和實現(xiàn)所期待的鏈路質(zhì)量策略。LQR包以恒定的速
率傳輸。這個速率是由LCP質(zhì)量協(xié)議配置選項磋商得到的。
	Mux：
	Mux把來自各個協(xié)議（例如LCP，IP，XNS等等）的多元包處理成一個單獨的，連續(xù)
的，有優(yōu)先級的包流。LQR包必須被賦予可能的最高優(yōu)先級，以保證鏈路質(zhì)量信息及時被
傳輸。
	Tx：
	Tx過程維護著MIB計數(shù)器ifOutUniPackets 和ifOutOctets,和內(nèi)部計數(shù)器OutLQRs，它
用來測量在輸出鏈路上傳輸?shù)臄?shù)據(jù)量。當Tx處理LQR包時，它把這些計數(shù)器的值插入到
包中的PeerOut域。Tx過程必須跟在Mux過程后面以確保這些包以在鏈路上傳輸?shù)捻樞蛴?數(shù)。
	Rx：
	Rx過程維護著MIB計數(shù)器ifInUniPackets,ifInDiscards,ifInErrors 和ifInOctets,和內(nèi)部計
數(shù)器InLQRs和InGoodOctets，它用來測量在輸入鏈路上接收的數(shù)據(jù)量。當Tx處理LQR包
時，它把這些計數(shù)器的值插入到包中的SaveIn域（在一個依靠方式的實現(xiàn)中）。
	Demux：
	Demux過程為各種協(xié)議分解多元包。Demux過程必須跟在Rx過程后面以確保這些包
以在鏈路上接收的順序計數(shù)。
2.5 配置選項格式
	描述：
	實現(xiàn)者必須為LQR準備接收質(zhì)量協(xié)議配置選項（Quality-Protocol Configuration Option）。
然而，不需要磋商。僅在實現(xiàn)者希望保證對端傳輸不同于其他質(zhì)量協(xié)議的LQR，或者防止
對端維護自己的計時器，或者在LQR傳輸間建立最大的時間間隔，磋商是必須的。
	下面是磋商LQR的質(zhì)量協(xié)議配置選項格式的總結(jié)。各個域是由左到右傳輸?shù)摹?
    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
	質(zhì)量協(xié)議：
	c025（十六進制）（LQR）
	報告周期：
   	報告周期域（the Reporting-Period field）是4個Octets 和表明了在包傳輸間的最大時間
間隔（以1/100秒計算）。對端可以以比商議的更快的速率傳輸包。
	此值為零表明對端不需要維護計時器。作為替代，對端一旦接收LQR立即產(chǎn)生一個
LQR。當對端為帶零值的LQR已經(jīng)發(fā)送或者將發(fā)送一個包含質(zhì)量協(xié)議配置選項的配置請求
包時，它必須不被帶非零值得對端應(yīng)答。
2.6 包格式
	LQR包被封裝在PPP數(shù)據(jù)鏈路層幀的信息域中，此幀的協(xié)議域為c025（LQR）。下面
是LQR包格式的總結(jié)。域名相對于包的接收者，因為是接收者請求的配置包，各個域從左
到右傳輸。


    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                            |