| PPP數據幀的格式 |
|
[ 2007-5-17 11:43:00 ]
|
想要了解PPP，個人認爲有3個關鍵的知識點。
1、PPP數據幀的格式；
2、PPP的幾種報文；
3、PPP的狀態轉移
首先說說的PPP數據幀的格式，因爲PPP是鏈路層協議，所以我們將它的數據單位稱爲幀，
| 7E | FF | 03 | 7E | |||
| 標誌 | 地址 | 控制 | 協議域 | 信息域 | 校驗 | 標誌 |
| 1B | 1B | 1B | 2B | 缺省1500B | 2B | 1B |
緊接在起始標誌字節後的一個字節是地址域，該字節爲0xFF。我們熟知網絡是分層的，且對等層之間進行相互通信，而下層爲上層提供服務。當對等層進行通信時首先需獲知對方的地址，而對不同的網絡，在數據鏈路層則表現爲需要知道對方的MAC地址、X.121地址、ATM地址等；在網絡層則表現爲需要知道對方的IP地址、IPX地址等；而在傳輸層則需要知道對方的協議端口號。例如如果兩個以太網上的主機希望能夠通信的話，首先發送端需獲知對端的MAC地址。但由於PPP協議是被運用在點對點的鏈路上的特殊性，它不像廣播或多點訪問的網絡一樣，因爲點對點的鏈路就可以唯一標示對方，因此使用PPP協議互連的通信設備的兩端無須知道對方的數據鏈路層地址，所以該字節已無任何意義，按照協議的規定將該字節填充爲全1的廣播地址。同地址域一樣，PPP數據幀的控制域也沒有實際意義，按照協議的規定通信雙方將該字節的內容填充爲0x03。（既然無意義，就可以隨便賦值了吧，呵呵，只要大家都遵守一個標準就行）
就PPP協議本身而言，我們最關心的內容應該是它的協議域和信息域。協議域可用來區分PPP數據幀中信息域所承載的數據報文的內容。協議域的內容必須依據ISO 3309的地址擴展機制所給出的規定。該機制規定協議域所填充的內容必須爲奇數，也即是要求低字節的最低位爲“1”，高字節的最低位爲“0”。如果當發送端發送的PPP數據幀的協議域字段不符合上述規定，則接收端會認爲此數據幀是不可識別的，那麼接收端會向發送端發送一個Protocol-Reject報文，在該報文尾部將完整地填充被拒絕的報文。
信息域缺省時最大長度不能超過1500字節，其中包括填充域的內容，1500字節大小等於PPP協議中配置參數選項MRU（Maximum Receive Unit）的缺省值，在實際應用當中可根據實際需要進行信息域最大封裝長度選項的協商。信息域如果不足1500字節時可被填充，但不是必須的，如果填充則需通信雙方的兩端能辨認出有用與無用的信息方可正常通信。
協議域和信息域是需要合在一起看的，目前主要用到的協議類型有LCP、NCP和普通的IP協議，而他們相對應的協議域字段則爲0×C021、0×8021和0×0021，可以看到應證了這句話：也即是要求低字節的最低位爲“1”，高字節的最低位爲“0”。而後面的信息根據不同協議包含了不同的報文內容。
| 0×C021 | LCP數據報文 | 校驗 |
| 0×8021 | NCP數據報文 | 校驗 |
| 0×0021 | IP數據報文 | 校驗 |
CRC校驗域主要是對PPP數據幀傳輸的正確性進行檢測的，當然在數據幀中引入了一些傳輸的保證機制是好的，但可以反過來說，同樣我們會引入更多的開銷，這樣可能會增加應用層交互的延遲。
最後給大家一個通過Ethereal抓下來的PPP幀，對應上面的說明，看看大家是否可以看懂：
7E FF 03 C021 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E
1.1 PPP概述
點到點協議（Point to Point Protocol，PPP）是IETF（Internet Engineering Task Force，因特網工程任務組）推出的點到點類型線路的數據鏈路層協議。它解決了SLIP中的問題，併成爲正式的因特網標準。
PPP協議在RFC 1661、RFC 1662和RFC 1663中進行了描述。
1 PPP的層次結構
PPP支持各種類型的硬件，包括EIA/TIA 232、EIA/TIA 449、EIA/TIA 530、V.35、V.21等。只要是點到點類型的線路都可以運行PPP。在數據鏈路層，PPP通過LCP協議進行鏈路管理，相當於以太網數據鏈路層的MAC子層。而在網絡層，由NCP爲不同的協議提供服務。這裏的NCP相當於以太網數據鏈路層的LLC子層。如圖1所示。
圖1 PPP的層次結構
2 PPP的功能
PPP主要完成了以下功能：
鏈路控制
PPP爲用戶發起呼叫以建立鏈路；在建立鏈路時協商參數選擇；通信過程中隨時測試線路，當線路空閒時釋放鏈路等。PPP中完成上述工作的組件是鏈路控制協議LCP（Link Control Protocol，LCP）。
網絡控制
當LCP將鏈路建立好了以後，PPP要開始根據不同用戶的需要，配置上層協議所需的環境。PPP使用網絡控制協議NCP（Network Control Protocol，NCP）來爲上層提供服務接口。針對上層不同的協議類型，會使用不同的NCP組件。如對於IP提供IPCP接口，對於IPX提供IPXCP接口，對於APPLETALK提供ATCP接口等。
1.2 PPP過程
在這步驟中，通信雙方開始交換一系列的NCP分組來配置網絡層。對於上層使用的是IP協議的情形來說，此過程是由IPCP完成的。
當NCP配置完成後，雙方的邏輯通信鏈路就建立好了，雙方可以開始在此鏈路上交換上層數據。
當數據傳送完成後，一方會發起斷開連接的請求。這時，首先使用NCP來釋放網絡層的連接，歸還IP地址；然後利用LCP來關閉數據鏈路層連接；最後，雙方的通信設備或模塊關閉物理鏈路回到空閒狀態。
圖2給出了上述過程的示意圖。
圖2 PPP過程
1.3 PPP幀格式
PPP幀格式以HDLC幀格式爲基礎，做了很少的改動。二者的主要區別是：PPP是面向字符的，而HDLC是面向位的。PPP在點到點串行線路上使用字符填充技術。所以，所有的幀的大小都是字節的整數倍。
圖3中給出了PPP的幀格式。
圖3 PPP的幀格式
PPP幀是以標準HDLC標誌字節（01111110）開始和結束的。
接下來是地址字段，缺省情況下，被固定設成二進制數11111111，因爲點到點線路的一個方向上只有一個接收方。
地址字段後面是控制字段，缺省情況下，被固定設成二進制數00000011。
因爲缺省情況下，地址字段、控制字段總是常數。因此，這兩部分實際可以省略不要（需要通過LCP進行協商）。
接下來是協議字段。用來標明後面攜帶的是什麼類型的數據。其缺省大小爲2個字節。但如果是LCP包，則可以是1字節。
接下來是數據字段。其長度可變，缺省最大長度爲1500字節。
接下來是校驗和字段，通常情況下是2個字節，但也可以是4字節。
1.4 LCP協商選項
LCP用來在通信鏈路建立初期，在通信雙方之間協議功能選項。表1列出了其中主要的選項。它們是身份驗證、壓縮、回叫、多鏈路。
表1 PPP LCP協商選項
|
特 性 |
解釋 |
協議 |
|
身份驗證 |
鏈路建立成功前要求提供正確的密碼 |
PAP，CHAP |
|
壓縮 |
在帶寬有限的鏈路提供對數據的壓縮功能 |
Predictor，Stacker， MPPC |
|
回叫 |
由被叫方重新呼叫原呼叫發起方 |
Cisco Callback，MS Callback |
|
多鏈路 |
需要的時候進行多鏈路捆綁、負載均衡 |
MP |
1.5 LCP協商的其他選項
除了身份認證方法之外，PPP的LCP還提供了鏈路壓縮、回叫、多鏈路捆綁等選項。
1 鏈路壓縮
PPP協議運行在速率十分有限的點到點串行鏈路上。爲了提高數據發送效率，可以採用對數據進行壓縮後再傳送的方法，我們將其稱爲鏈路壓縮。
LCP支持以下一些鏈路壓縮方法：Stac、Predictor、MPPC以及TCP頭部壓縮。不同的方法對CPU及內存的需求並不相同。有些需要更多的內存（內存密集型），有些則需要佔用更多的CPU時間（CPU密集型）。壓縮原理和效果也不相同。
Stac：Stac壓縮算法基於Lempel-Ziv理論，它通過查找、替換傳送內容中的重複字符串的方法達到壓縮數據的目的。使用Stac壓縮算法可以選擇由各種硬件（適配器、模塊等）壓縮或者由軟件進行壓縮，還可以選擇壓縮的比率。Stac壓縮算法需要佔用較多的CPU時間。
MPPC：MPPC是微軟的壓縮算法實現，它也是基於Lempel-Ziv理論，也需要佔用較多的CPU時間。
Predictor：Predictor—預測算法通過檢查數據的壓縮狀態（是否已被壓縮過）來決定是否進行壓縮。因爲，對數據的二次壓縮一般不會有更大的壓縮率。相反，有時經過二次壓縮的數據反而比一次壓縮後的數據更大。Predictor算法需要佔用更多的內存。
TCP頭部壓縮：TCP頭部壓縮基於Van Jacobson算法，該算法通過刪除TCP頭部一些不必要的字節來實現數據壓縮的目的。
2 回叫
回叫又稱爲回撥，是指當通信一方撥號到另一方後，由另一方斷開撥號連接並進行反向的撥號。
這對於從甲地到乙地的電話費大於從乙地到甲地的電話費的情形。這時，可以由甲方首先發起到乙方的呼叫連接，當乙方收到甲方的呼叫請求後，斷開乙方的呼叫。然後，從乙方發起到甲方的回叫。甲方應答後，雙方的通信鏈路就建立起來了。
回叫還有更安全的優點。因爲乙方在回叫之前可以驗證對方是否是合法用戶，或者可以用口令數據庫的方法或者可以用檢驗對方電話號碼的方法。
3 多鏈路捆綁
LCP的多鏈路捆綁（MP）選項通過將通信兩端之間的多條通信鏈路捆綁成一條虛擬的鏈路而達到擴充鏈路可用帶寬的目的。
LCP的多鏈路捆綁可以在多種類型的物理接口上實現，包括異步串行接口、同步串行接口、ISDN基本速率接口BRI、ISDN主速率接口PRI。LCP的多鏈路捆綁也支持不同的上層協議封裝類型，如X.25、ISDN、幀中繼等。
限於篇幅，關於以上LCP協商選項的配置這裏就不再詳細介紹了。
2 PPP配置（Cisco）
2.1 PPP基本配置
1 封裝
對於同步串行接口，默認的封裝格式是HDLC（Cisco私有實現）。可以使用命令encapsulation ppp將封裝格式改爲PPP。如圖4所示。
圖4 PPP串行封裝
當通信雙方的某一方封裝格式爲HDLC，而另一方爲PPP時，雙方關於封裝協議的協商將失敗。此時，此鏈路處於協議性關閉（protocol down）狀態，通信無法進行。如圖5所示。
圖5 兩端路由器串行接口封裝格式不一致
這時，在路由器RouterA與路由器RouterB的鏈路沒有成功建立之前，路由器RouterA及RouterB的路由表將爲空。
當路由器RouterA的串行接口Serial 0/0又改爲封裝成PPP協議時，雙方的通信將恢復正常。如圖6所示，是在路由器RouterA上產生的debug ppp events的輸出。可以發現，成功地安裝了此鏈路的路由條目。同時，系統提示該鏈路協議被激活，鏈路可用。
圖6 命令debug ppp events的輸出
同時，使用show ip route命令可以看到RouterA安裝了兩條路由條目，一條是到達網絡192.168.0.0/24的一條直連路由，另一條是到達主機192.168.0.2/32的一條直連主機路由。如圖7所示。
圖7 命令show ip route的輸出
當將路由器RouterA的Serial 0/0的封裝格式再次改爲HDLC時，命令debug ppp events將給出如圖8所示的提示信息，提示該鏈路上的路由條目被刪除。同時，系統通告該接口協議性關閉。
圖8 命令debug ppp events的輸出
同時，debug ppp negotiation的輸出也表明了這一點，如圖9所示。
圖9 命令debug ppp negotiation的輸出
2 autoselect
可以配置一個接口根據接收到的字符自動判斷遠程撥號用戶協議類型並調用相應的處理過程。如圖10所示。
圖10 autoselect命令過程
例如，如果遠程撥號用戶使用PPP協議撥入線路，線路將檢測到PPP幀的起始字符0x7E（01111110），並調用PPP處理過程。又如，當線路檢測到“回車”符後將開始一個Exec會話過程等。
autoselect命令允許線路被設置成可以接受多種類型協議的連接，如PPP、SLIP、ARAP等。以下是Autoselect命令的使用格式。
autoselect [arap|ppp|slip|during-login]
其中，命令中的during-login選項將提示用戶輸入用戶名和口令而不需要按“回車”鍵（否則，一個會話過程將自動開始而不會給出用戶名和口令的提示）。