網(wǎng)絡工程師ppp協(xié)議技術(shù)與培訓

1、擬審審批制：核：核：準：日日日日期：期：期：期：周一帆2002-01-05修 訂市技 術(shù) 有 限 公 司日 期修訂版本作 者描 述2002/01/05v1.0周一帆資料編碼產(chǎn)品名稱使用對象用服工程師產(chǎn)品版本編寫部門交換接入產(chǎn)品技術(shù)支援管理部資料版本目 錄第一章 概 述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 PPP協(xié)議的基本概念 . . . . . . . .

2、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 PPP協(xié)議出現(xiàn)的背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1.1 SLIP協(xié)議的基本概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3、 . . . . . . . . . . . . . . . 1.1.1.2 SLIP協(xié)議的封裝格式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 PPP協(xié)議簡介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 總結(jié) . . . . . . . .

4、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 思考 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第二章 PPP協(xié)議的三組件 . . . . . . . . . . . .

5、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 PPP協(xié)議的組件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111123344467778882.1.12.1.22.1.3PPP協(xié)議的封裝 . . . . . . . . . . . . . . . . . . .

6、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LCP協(xié)議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NCP協(xié)議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7、. . . . . . . . . . . . . . . . . . . . 2.22.3總結(jié) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 思考 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8、. . . . . . . . . . . . 第三章 PPP鏈路的建立 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 PPP鏈路的建立過程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 PPP的狀態(tài)轉(zhuǎn)移圖 . . .

9、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 LCP協(xié)議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.1 LCP數(shù)據(jù)報文的封裝方式 . . . . . . . . . . . . . . . . . . . .

10、 . . . . . . . . . . . . . . . . . . . . . . . 101012121515161620202121212222LCP數(shù)據(jù)報文的分類LCP的鏈路配置報文LCP的鏈路終止報文. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.5 LCP的鏈路報文3.1.3 NCP協(xié)議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12、 . . . . . . . . . . . . . . . . . 3.1.3.1 IPCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.23.3第四章總結(jié) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13、. . . . . . . 思考 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LCP的可選配置參數(shù) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 LCP的參數(shù)配置選項 . . . . . . . . .

14、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.14.1.2魔術(shù)字（-Number） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 認證協(xié)議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15、 . . . . . . . . . . . . . . . . . 4.1.2.1 PAP認證 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2.2 CHAP認證 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 MRU（Ma

16、xium Receive Unit） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 總結(jié) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 思考 . . . . . . . . . . . . . . . . . . . . . . . .

17、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242525262727272728282929第五章PPP擴展協(xié)議. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 PPP擴展協(xié)議概述 . . . . . . . . . . . . . . . . . . . . . . . .

18、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 MP出現(xiàn)的背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 MP（Multilink Protocol）協(xié)議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19、. . . . . . 5.2 總結(jié) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 思考 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第六章 PP

20、P的狀態(tài)機 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 PPP擴展協(xié)議概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 技術(shù)第一章 概 述1.1 PPP協(xié)議的基本概念1.1.1 PPP協(xié)議出現(xiàn)的背景在提及PPP協(xié)議時，不

21、可不提及它的老SLIP（Serial Lineernet Protocol ）協(xié)議。雖然它已被淡忘在歷史的長河中，但畢竟有過輝煌的日子。它曾經(jīng)主載了 ernet半邊，人們不僅可以通過在計算機上安裝該協(xié)議實現(xiàn)瀏覽ernet的夢想，而且還可以互連許多網(wǎng)絡設備（如路由器與路由器的互連、路由器與主機的互連和主機與主機的互連）。隨著網(wǎng)絡技術(shù)的不斷日新月異，特別是計算機技術(shù)的發(fā)展，人們開始漸漸認識到使用SLIP協(xié)議已不能滿足日益增長的網(wǎng)絡需求，如何在串行點對點的鏈 封裝IPX、AppleTalk等網(wǎng)絡層的協(xié)議呢？這就給網(wǎng)絡提出了新的，也為PPP協(xié)議的出現(xiàn)提供了契機，PPP由于自身的諸多的優(yōu)點已成為目前被

22、廣泛使用的數(shù)據(jù)鏈路層協(xié)議。說明如果對SLIP不感舉趣，可直接跳到1.1.2節(jié)1.1.1.1 SLIP協(xié)議的基本概念SLIP協(xié)議出現(xiàn)在80年代中期，并被使用在BSD UNIX主機和SUN的工作站上，因為SLIP 簡單好用，所以后來被大量使用 路速率從 1200bps 到19.2Kbps的線路和撥號線互連主機和路由器，到目前為止仍有問大部分UNIX主機保留對該協(xié)議的支持。在80年代末90年代初期，被廣泛用于家庭中每臺有RS232串口的計算機和調(diào)制解調(diào)器連接到 ernet。SLIP是一種在點對點的串行鏈議。封裝IP數(shù)據(jù)報的簡單協(xié)議，它并非是 ernet的標準協(xié)1.1.1.2 SLIP協(xié)議的封裝格式S

23、LIP協(xié)議的封裝格式必需遵循以下幾條原則：通過在被發(fā)送IP數(shù)據(jù)報的尾部增加特殊的END字符（0 xC0 ）從而形成一個簡單的SLIP的數(shù)據(jù)幀，而后該幀會被傳送到物理層進行發(fā)送。為了防止線路噪聲被當成數(shù)據(jù)報的內(nèi)容傳輸，通常發(fā)送端在被傳送數(shù)1技術(shù)據(jù)報的開始處也傳一個END字符。如果線的確存在噪聲，則該數(shù)據(jù)報起始位置的END字符將結(jié)束這份錯誤的報文，這樣當前正確的數(shù)據(jù)報文就能正確的傳送了，而前一個含有無意義報文的數(shù)據(jù)幀會在對端的高層被丟棄。當被傳送的IP數(shù)據(jù)報文中含有END字符時，則需要對該字符進行轉(zhuǎn)意（就是使用其它字符來表示），可使用連續(xù)傳輸?shù)膬蓚€字節(jié)來代替它（如0 xdb和0 xdc）。如果當被

24、轉(zhuǎn)意后的字符也包含在數(shù)據(jù)報中，則也需要對其進行同樣的操作，直至不出現(xiàn)歧義為止。下圖為SLIP數(shù)據(jù)幀的封裝格式：SLIP簡單封裝方式的缺陷：從上圖可以看出SLIP幀的封裝格式非常簡單，通信雙方無需在數(shù)據(jù)報發(fā)送前協(xié)商任何配置參數(shù)選項（在PPP協(xié)議中需協(xié)商配置參數(shù)選項），所以雙方IP層通信前必需先獲知對方的IP地址，才能進行網(wǎng)絡層的通信，否則鏈路層發(fā)送的數(shù)據(jù)幀在被送到對方網(wǎng)絡層時將無法進行轉(zhuǎn)發(fā)。由于數(shù)據(jù)幀中也沒有類似于以太網(wǎng)、HDLC和PPP等數(shù)據(jù)鏈路層協(xié)議中定義的協(xié)議域字段，因此SLIP僅支持一種網(wǎng)絡層協(xié)議（IP協(xié)議）同一時刻在串行鏈發(fā)送。SLIP協(xié)議沒有在數(shù)據(jù)幀的尾部加上CRC校驗和，如果由于線

25、路噪聲的干擾影響傳送數(shù)據(jù)包的內(nèi)容是無法在對端的數(shù)據(jù)鏈路層中發(fā)現(xiàn)的，必須交由上層的應用來處理。正是由于上面的諸多缺點，導致了SLIP很快的被后面要講的PPP協(xié)議所替代。1.1.2PPP協(xié)議簡介PPP 提供了一種在點對點的鏈 封裝多協(xié)議數(shù)據(jù)報（ IP 、 IPX 和AppleTalk）的標準方法。它不僅能支持IP地址的動態(tài)分配和管理；同步（面向位的同步數(shù)據(jù)塊的傳送）或異步（起始位+數(shù)據(jù)位+奇偶校驗位+停止位）物理層的傳輸；網(wǎng)絡層協(xié)議的復用；鏈路的配置、質(zhì)量檢測和糾錯；而且還支持多種配置參數(shù)選項的協(xié)商。PPP協(xié)議主要包括三部分：LCP（ Link Control Protocol） 鏈路控制協(xié)議、N

26、CP（Network Control Protocol）和PPP的擴展協(xié)議（如Multilink Protocol，2技術(shù)詳見第五章）。隨著網(wǎng)絡技術(shù)的不斷發(fā)展，網(wǎng)絡帶寬已不在是瓶頸，所以PPP擴展協(xié)議的應用也就越來越少，因此往往人們在敘述PPP協(xié)議時經(jīng)常會忘記它的存在。而且大部分網(wǎng)絡上會將PPP的認證也作為PPP協(xié)議的一個主要部分，實際上這是一個錯誤概念的引導。PPP協(xié)議默認是不進行認證配置參數(shù)選項的協(xié)商，它只作為一個可選的參數(shù)，當點對點線路的兩端需要進行認證時才需配置。當然在實際應用中這個過程是不可忽略的，例如使用計算機上網(wǎng)時，需要通過PPP協(xié)議與NAS設備互連，在整個協(xié)議的協(xié)商過程中，需要

27、輸入用戶名和。因此當別人說PPP協(xié)議主要包括LCP、認證和NCP協(xié)議三個部分時，你不要認為他的說法有誤，而只是不夠準確罷了。1.2總結(jié)PPP協(xié)議由于自身諸多的優(yōu)點取代了SLIP協(xié)議，從而成為目前被廣泛使用的數(shù)據(jù)鏈路層協(xié)議SLIP協(xié)議歸咎其其簡單數(shù)據(jù)包的封裝方式，使其僅能在點對點的鏈封裝單一的網(wǎng)絡層協(xié)議（IP協(xié)議）PPP協(xié)議包括LCP協(xié)議、NCP協(xié)議和PPP擴展協(xié)議RFC1661文檔中說明了PPP協(xié)議缺省是不進行PAP和CHAP認證1.3思考1、當SLIP協(xié)議封裝的IP數(shù)據(jù)報文中存在END字符時，發(fā)送該數(shù)據(jù)幀的網(wǎng)絡設備會對該數(shù)據(jù)報什么樣的處理？2、SLIP協(xié)議沒有引入CRC校驗機制，那么它是如何

28、保證數(shù)據(jù)發(fā)送的正確性的？3、PPP協(xié)議不僅可以支持同步物理層傳輸，而且還支持異步物理層傳輸，請比較一下兩者的區(qū)別？4、PPP協(xié)議和SLIP協(xié)議的區(qū)別，可從封裝格式，IP地址分配等方面考慮?3技術(shù)第二章 PPP協(xié)議的三組件2.1 PPP協(xié)議的組件首先簡單介紹一下PPP協(xié)議的三組件：PPP協(xié)議的封裝方式、LCP協(xié)議的協(xié)商過程和NCP協(xié)議的協(xié)商過程，然后再結(jié)合具體的LCP和NCP數(shù)據(jù)報的封裝格式和兩個階段實際數(shù)據(jù)報文的交換過程，進一步理解PPP的LCP和NCP協(xié)商階段的具體內(nèi)容。2.1.1PPP協(xié)議的封裝知道ISO參考模型共分七層，自下而上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層和應

29、用層。通常會依據(jù)協(xié)議所完成的功能將它與這七層進行對照，PPP協(xié)議就屬于數(shù)據(jù)鏈路層協(xié)議。4技術(shù)在提及PPP協(xié)議的報文封裝格式時，不可不先提一下HDLC協(xié)議。HDLC也是最常用的數(shù)據(jù)鏈路層協(xié)議，它是從SDLC協(xié)議過來的，許多常用的數(shù)據(jù)鏈路層協(xié)議的封裝方式都是基于HDLC的封裝格式的，同樣PPP協(xié)議也不例外，它也采用了HDLC的定界幀格式。下圖為PPP數(shù)據(jù)幀的封裝格式：以下為對PPP數(shù)據(jù)幀封裝格式的一點說明：每一個PPP數(shù)據(jù)幀均是以一個標志字節(jié)起始和結(jié)束的，該字節(jié)為0 x7E。緊接在起始標志字節(jié)后的一個字節(jié)是地址域，該字節(jié)為0 xFF。熟知網(wǎng)絡是分層的，且對等層之間進行相互通信，而下層為上層提供服務

30、。當對等層進行通信時首先需獲知對方的地址，而對不同的網(wǎng)絡，在數(shù)據(jù)鏈路層則表現(xiàn)為需要知道對方的MAC地址、X.121地址、ATM地址等；在網(wǎng)絡層則表現(xiàn)為需要知道對方的IP地址、IPX地址等；而在傳輸層則需要知道對方的協(xié)議端。例如如果兩個以太網(wǎng)上的主機希望能夠通信的話，首先發(fā)送端需獲知對端的MAC地址。但由于PPP協(xié)議是被運用在點對點的鏈的特殊性，它不像廣播或多點的網(wǎng)絡一樣，因為點對點的鏈路就可以唯一標示對方，因此使用PPP協(xié)議互連的通信設備的兩端無須知道對方的數(shù)據(jù)鏈路層地址，所以該字節(jié)已無任何意義，按照協(xié)議的規(guī)定將該字節(jié)填充為全1的廣播地址。同地址域一樣，PPP數(shù)據(jù)幀的控制域也沒有實際意義，按照

31、協(xié)議的規(guī)定通信雙該字節(jié)的內(nèi)容填充為0 x03。就PPP協(xié)議本身而言，最關(guān)心的內(nèi)容應該是它的協(xié)議域和信息域。協(xié)議域可用來區(qū)分PPP數(shù)據(jù)幀中信息域所承載的數(shù)據(jù)報文的內(nèi)容。協(xié)議域的內(nèi)容必須依據(jù)ISO 3309的地址擴展機制所給出的規(guī)定。該機制規(guī)定協(xié)議域所填充的內(nèi)容必須為奇數(shù)，也即是要求低字節(jié)的最低位為”1”，高字節(jié)的最低位為”0”。如果當發(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域字段不符合上述規(guī)定，則接收端會認為此數(shù)據(jù)幀是不可識別的，那么接收端會5技術(shù)向發(fā)送端發(fā)送一個Protocol-Reject報文，在該報文尾部將完整地填充被拒絕的報文。協(xié)議域的具體取值如下表所示：說明協(xié)議域類型中的*號表示可從（0-F）中

32、任意取值信息域缺省時最大長度過1500字節(jié)，其中包括填充域的內(nèi)容（在圖2-1中并未表示，因為它屬于信息域的一部分），1500字節(jié)大小等于PPP協(xié)議中配置參數(shù)選項MRU（um Receive Unit）的缺省值，在實際應用當中可根據(jù)實際需要進行信息域最大封裝長度選項的協(xié)商。信息域如果1500字節(jié)時可被填充，但不是必須的，如果填充則需通信雙方的兩端能辨認出有用與無用的信息方可正常通信。通常在通信設備的配置過程中，遇到最多的也是MTU（umTransmit Unit ）。對于一個設備而言，它網(wǎng)絡的層次均使用MTU 和MRU兩個值，一般情況下設備的MRU會比MTU稍大幾個字節(jié)，但這需根據(jù)各廠商的設備而

33、定。CRC校驗域主要是對PPP數(shù)據(jù)幀傳輸?shù)恼_性進行檢測的，當然在數(shù)據(jù)幀中引入了一些傳輸?shù)谋ＷC機制是好的，但可以反過來說，同樣會引入使用的開銷，這樣可能會增加應用層交互的延遲，對于這個字節(jié)的可以參考一下X.25協(xié)議和FR協(xié)議就知道了。6協(xié)議域類型說明ISO標準0 x0* - 0 x3*信息域中承載的是網(wǎng)絡層的數(shù)據(jù)報文0 x4* - 0 x7*信息域中承載的是與NCP無關(guān)的低整流量0 x8* - 0 xb*信息域中承載的是網(wǎng)絡控制協(xié)議（NCP）的數(shù)據(jù)報文0 xc* - 0 xf*信息域中承載的是鏈路控制協(xié)議（LCP）的數(shù)據(jù)報文最典型的幾種取值0 xc021信息域中承載的是鏈路控制協(xié)議（LCP）的

34、數(shù)據(jù)報文0 xc023信息域中承載的是PAP協(xié)議的認證報文0 xc223信息域中承載的是CHAP協(xié)議的認證報文0 x8021信息域中承載的是網(wǎng)絡控制協(xié)議（NCP）的數(shù)據(jù)報文0 x0021信息域中承載的是IP數(shù)據(jù)報文技術(shù)2.1.2LCP協(xié)議為了能適應復雜多變的網(wǎng)絡環(huán)境，PPP協(xié)議提供了一種鏈路控制協(xié)議來配置和測試數(shù)據(jù)通信鏈路，它能用來協(xié)商PPP協(xié)議的一些配置參數(shù)選項；處理不同大小的數(shù)據(jù)幀；檢測鏈路環(huán)路、一些鏈路的錯誤；終止一條鏈路。說明詳細內(nèi)容請見3.1.2節(jié)LCP協(xié)議2.1.3NCP協(xié)議PPP的網(wǎng)絡控制協(xié)議根據(jù)不同的網(wǎng)絡層協(xié)議可提供一族網(wǎng)絡控制協(xié)議，常用的有提供給TCP/IP網(wǎng)絡使用的IPCP

35、網(wǎng)絡控制協(xié)議和提供給SPX/IPX網(wǎng)絡使用的IPXCP網(wǎng)絡控制協(xié)議等，但最為常用的是IPCP協(xié)議，當點對點的兩端進行NCP參數(shù)配置協(xié)商時，主要是用來通信雙方的網(wǎng)絡層地址。說明詳細內(nèi)容請見3.1.3節(jié)NCP協(xié)議2.2總結(jié)PPP協(xié)議的三組件包括PPP協(xié)議的封裝方式、LCP協(xié)議和NCP協(xié)議PPP協(xié)議是數(shù)據(jù)鏈路層協(xié)議，它的數(shù)據(jù)幀封裝格式非常類似于HDLCPPP協(xié)議可通過協(xié)議域來區(qū)分數(shù)據(jù)域中凈載荷的數(shù)據(jù)類型PPP協(xié)議通過LCP協(xié)議完成數(shù)據(jù)鏈路的配置和測試PPP協(xié)議通過NCP協(xié)議完成點對點通信設備之間網(wǎng)絡層通信所需參數(shù)的配置2.3思考1、PPP數(shù)據(jù)幀中的地址域被填充為0 xFF（廣播地址），在實際應用當中

36、該域已沒有任何意義，請想一下為什么使用PPP協(xié)議通信的設備不需要類似于以太網(wǎng)的數(shù)據(jù)鏈路層尋址機制？2、PPP協(xié)議數(shù)據(jù)域缺省的最大值是多少？7技術(shù)3、當發(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域不被接收方識別時，接收理這個數(shù)據(jù)幀？如何處4、IPCP協(xié)議的主要功能？8技術(shù)第三章 PPP鏈路的建立3.1 PPP鏈路的建立過程3.1.1PPP的狀態(tài)轉(zhuǎn)移圖數(shù)據(jù)通信設備（在本文中指路由器）的兩端如果希望通過PPP協(xié)議建立點對點的通信，無論哪一端的設備都需發(fā)送LCP數(shù)據(jù)報文來配置鏈路（測試鏈路）。一旦LCP的配置參數(shù)選項協(xié)商完后，通信的雙方就會根據(jù)LCP配置請求報文中所協(xié)商的認證配置參數(shù)選項來決定鏈路兩端設備所采用的

37、認證方式。協(xié)議缺省情況下雙方是不進行認證的，而直接進入到NCP配置參數(shù)選項的協(xié)商，直至所經(jīng)歷的幾個配置過程全部完成后，點對點的雙方就可以開始通過已建立好的鏈路進行網(wǎng)絡層數(shù)據(jù)報文的傳送了，整個鏈路就處于可用狀態(tài)。只有當任何一端收到LCP 或NCP的鏈路關(guān)閉報文時（一般而言協(xié)議是不要求NCP有關(guān)閉鏈路的能力的，因此通過情況下關(guān)閉鏈路的數(shù)據(jù)報文是在LCP協(xié)商階段或應用程序會話階段發(fā)出的）；物理層無法檢測到載波或管理對該鏈路進行關(guān)閉操作，都會將該條鏈路斷開，從而終止PPP會話。以下為PPP協(xié)議整個鏈路過程需經(jīng)歷階段的狀態(tài)轉(zhuǎn)移圖：在點對點鏈路的配置、和終止過程中，PPP需經(jīng)歷以下幾個階段：鏈路不可用階段

38、，有時也稱為物理層不可用階段，PPP鏈路都需從這個階段開始和結(jié)束。當通信雙方的兩端檢測到物理線路激活（通常時檢測到鏈有載波信號）時，就會從當前這個階段躍遷至下一個階段（即鏈路建立階段）。先簡單提一下鏈路建立階段，在這個階段主要是通過LCP協(xié)議進行鏈路參數(shù)的配置，LCP在此階段的狀態(tài)機也會根據(jù)不同的9技術(shù)事件發(fā)生變化。當處于在鏈路不可用階段時， LCP 的狀態(tài)機是處于 initial（初始化狀態(tài)）或starting（準備啟動狀態(tài)），一旦檢測到物理線路可用，則LCP的狀態(tài)機就要發(fā)生改變。當然鏈路被斷開后也同樣會返回到這個階段，往往在實際過程中這個階段所停留的時間是很短的，僅僅是檢測到對方設備的存在

39、。鏈路建立階段，也是PPP協(xié)議最關(guān)鍵和最復雜的階段。該階段主要是發(fā)送一些配置報文來配置數(shù)據(jù)鏈路，這些配置的參數(shù)不包括網(wǎng)絡層協(xié)議所需的參數(shù)。當完成數(shù)據(jù)報文的交換后，則會繼續(xù)向下一個階段躍遷，該下一個階段既驗證階段，也網(wǎng)絡層協(xié)議階段，下一階段的選擇是依據(jù)鏈路兩端的設備配置的（通常是由用戶來配置，但對NAS或BAS設備的PPP模塊缺省就需要支持PAP或CHAP中的一種認證方式）。在此階段LCP的狀態(tài)機會發(fā)生兩次改變，前面說了當鏈路處于不可用階段時，此時LCP的狀態(tài)機處于initial或starting，當檢測到鏈路可用時，則物理層會向鏈路層發(fā)送一個UP事件，鏈路層收到該事件后，會將LCP的狀態(tài)機從當

40、前狀態(tài)改變?yōu)镽equest（請求發(fā)送狀態(tài)），根據(jù)此時的狀態(tài)機LCP會進行相應的動作，也即是開始發(fā)送Config-Request報文來配置數(shù)據(jù)鏈路，無論哪一端接收到了Config-Ack報文時，LCP的狀態(tài)機又要發(fā)生改變，從當前狀態(tài)改變?yōu)閛pened狀態(tài)，進入Opened狀態(tài)后收到Config-Ack報文的一方則完成了當前階段，應該向下一個階段躍遷。同理可知，另一端也是一樣的，但須注意的一點是在鏈路配置階段雙方是鏈路配置操作過程是相互獨立的。如果在該階段收到了非LCP數(shù)據(jù)報文，則會的將這些報文丟棄。在實際配置當中在該階段可能會遇到很多情況，在LCP協(xié)議章節(jié)中會詳細介紹可能遇到的情況，但最好結(jié)合一

41、些troubleshooting案例能更好的幫助理解。驗證階段，多數(shù)情況下的鏈路兩端設備是需要經(jīng)過認證后才進入到網(wǎng)絡層協(xié)議階段，缺省情況下鏈路兩端的設備是不進行認證的。在該階段支持PAP和CHAP兩種認證方式，驗證方式的選擇是依據(jù)在鏈路建立階段雙方進行協(xié)商的結(jié)果。然而，鏈路質(zhì)量的檢測也會在這個階段同時發(fā)生，但協(xié)議規(guī)定不會讓鏈路質(zhì)量的檢測的延遲驗證過程。在這個階段僅支持鏈路控制協(xié)議、驗證協(xié)議和質(zhì)量檢測數(shù)據(jù)報文，其它的數(shù)據(jù)報文都會被丟棄。如果在這個階段再次收到了Config-Request報文，則又會返回到鏈路建立階段。網(wǎng)絡層協(xié)議階段，一旦PPP完成了前面幾個階段，每種網(wǎng)絡層協(xié)議（IP、IPX和A

42、ppleTalk）會通過各自相應的網(wǎng)絡控制協(xié)議進行配置，每個NCP 協(xié)議可在任何時間打開和關(guān)閉。當一個NCP 的狀態(tài)成Opened狀態(tài)時，則PPP就可以開始在鏈承載網(wǎng)絡層的數(shù)據(jù)包報文了。如果在個階段收到了Config-Request報文，則又會返回到鏈路建立階段。網(wǎng)絡終止階段，PPP能在任何時候終止鏈路。當載波丟失、失敗、鏈路質(zhì)量檢測失敗和管理員人為關(guān)閉鏈路等情況均會導致鏈路終止。鏈10技術(shù)路建立階段可能通過交換LCP的鏈路終止報文來關(guān)閉鏈路，當鏈路關(guān)閉時，鏈路層會通知網(wǎng)絡層做相應的操作，而且也會通過物理層強制關(guān)斷鏈路。對于NCP協(xié)議，它是沒有也沒有必要去關(guān)閉PPP鏈路的。3.1.2 LCP協(xié)

43、議3.1.2.1 LCP數(shù)據(jù)報文的封裝方式LCP數(shù)據(jù)報文是在鏈路建立階段被交換的，它作為PPP的凈載荷被封裝在 PPP數(shù)據(jù)幀的信息域中，此時PPP數(shù)據(jù)幀的協(xié)議域固定填充0 xC021，但在鏈路建立階段的整個過程中信息域的內(nèi)容是在變化的，它包括很多種類型的報文，所以這些報文也要通過相應的字段來區(qū)分。LCP數(shù)據(jù)報文的一般封裝方式如下圖所示：代碼域的長度為一個字節(jié)，主要是用來標識LCP數(shù)據(jù)報文的類型的。在鏈路建立階段時，接收方收到LCP數(shù)據(jù)報文的代碼域無法識別時，就會端發(fā)送一個LCP的代碼報文（Code-Reject報文）。根據(jù)RFC的規(guī)定，到目前為止LCP共包括以下幾種類型的數(shù)據(jù)報文：標識域也是一

44、個字節(jié)，其目的是用來匹配請求和響應報文。一般而言在進入鏈路建立階段時，通信雙方無論哪一端都會連續(xù)發(fā)送幾個配置請求報文（Config-Request報文），而這幾個請求報文的數(shù)據(jù)域可能是完全一11代碼值報文類型代碼報文類型0 x01Config-Request0 x07Code-Reject0 x02Config-Ack0 x08Protocol-Reject0 x03Config-Nak0 x09Echo-Request0 x04Config-Reject0 x0AEcho-Reply0 x05Terminate-Request0 x0BDiscard-Request0 x06Terminat

45、e-Ack0 x0C技術(shù)樣的，而僅僅是它們的標志域不同罷了。通常一個配置請求報文的ID是從0 x01開始逐步加1的，當對端接收到該配置請求報文后，無論使用何種報文（回應報文可能是Config-Ack、Config-Nak和Config-Reject三種報文中的一種）來回應對方，但必須要求回應報文中的ID要與接收報文中的 ID一致，當通信設備收到回應后就可以將該回應與發(fā)送時的進行比較來決定下一步的操作。說明后面中的所有例子，均可參考以下色標的含義范例中報文色標含義如下圖所示：例1：假設點對點通信的一端發(fā)送了一個Config-Request報文，報文內(nèi)容如下：從報文中可以看出這個配置請求報文包括5

46、個配置參數(shù)選項。當對端正確接收到了該報文后，應該回應一個Config-Ack報文，報文內(nèi)容如下：127EFF 03C0 21010100 1702 06 00 0A 00 0005 06 00 0B 42 CB07 0208 020D 03 067E技術(shù)該報文中唯一修改的內(nèi)容就是代碼域（02表示是Config-Ack報文），標識域與原報文中的一樣。長度域的內(nèi)容 = 總字節(jié)數(shù)據(jù)（代碼域+標志域+長度域+數(shù)據(jù)域）。長度域所指示字節(jié)數(shù)之外的字節(jié)將被當作填充字節(jié)而忽略掉，而且該域的內(nèi)過MRU的值。容數(shù)據(jù)域的內(nèi)容依據(jù)不同LCP數(shù)據(jù)報文的內(nèi)容也是不一樣的。說明數(shù)據(jù)域的詳細內(nèi)容請見3.1.2.3節(jié)3.1.2

47、.2 LCP數(shù)據(jù)報文的分類一小節(jié)可以看到，一共包括12種LCP數(shù)據(jù)報文，依據(jù)各報文的的功能又將其具體細化為以下三類：鏈路配置報文，主要用來建立和配置一條鏈路的。鏈路終止報文，主要用來終止一條鏈路的。鏈路報文，主要用來和調(diào)試鏈路的。3.1.2.3 LCP的鏈路配置報文鏈路配置報文與其它兩類報文有著明顯的區(qū)別，它主要是用來協(xié)商鏈路的配置參數(shù)選項的，因此這種報文的數(shù)據(jù)域還要攜帶許多配置參數(shù)選項的，而另外兩類報文中部分報文的格式會稍有不同（請參見RFC1661），圖3-4表明了數(shù)據(jù)配置選項的報文格式：137EFF 03C0 21020100 1702 06 00 0A 00 0005 06 00 0B

48、 42 CB07 0208 020D 03 067E技術(shù)鏈路配置報文主要包括 Config-Request 、 Config-Ack 、 Config-Nak 和Config-Reject四種報文。當通信雙方需要建立鏈路時，無論哪一方都需要發(fā)送Config-Request報文并攜帶每一端自已所希望協(xié)商的配置參數(shù)選項，下表為一些可選的配置參數(shù)選項：這個表格內(nèi)的內(nèi)容并非完全，可能還有一新定議的配置選項未列在其中，如有可參照相關(guān)的文檔說明。當接收方收到Config-Request報文時，會在剩下的三種類型的報文中選擇一種來響應對方的請求報文，到底選擇哪種報文來響應對方需依據(jù)以下兩個條件：知道一個Co

49、nfig-Request報文不能完全識別配置參數(shù)選項的類型域，中會同時攜帶多個配置參數(shù)選項，而對于一個支持PPP協(xié)議的通信設備也不一定會支持上表中所有列出的配置選項，即使支持，也可能在實際應用中關(guān)閉掉某些選項功能。（例如：當使用PPP協(xié)議通信的一端可能將一些無用的配置選項都關(guān)閉了，而僅支持0 x01和0 x03兩個配置參數(shù)選項，因此當對方發(fā)送的Config-Request報文中含有0 x04配置選項時，對于本端而言這個配置參數(shù)選項就無法識別，也即是不支持這個配置參數(shù)選項的協(xié)商）。如果能支持完全識別配置參數(shù)選項，但接收端也可能不認可 Config-Request報文中配置參數(shù)選項數(shù)據(jù)域中的內(nèi)容（

50、例如：當一端發(fā)送魔術(shù)字配置參數(shù)選項中的魔術(shù)字為全0，而對端認為應該為其它值，這種情況就屬于不支持配置參數(shù)選項中的內(nèi)容）。所以依據(jù)上面的兩個條件，用何種報文回應。就可以明確在回應對方配置請求報文時，采當接收Config-Request報文的一端能識別發(fā)送過來的所有配置參數(shù)選項且認可所有配置參數(shù)選項數(shù)據(jù)域的內(nèi)容時，接收端將會給對端回一個 Config-Ack報文并將配置請求報文中的配置參數(shù)選項原封不動的放置在Config-Ack報文的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項14類型值參數(shù)選項類型值參數(shù)選項0 x000 x05-Number0 x01um-Recieve-Unit0 x06CB

51、CP0 x02Async-Control-Character- Map0 x07press0 x03Authentication-Protocol0 x08Address-and-Control-Fielpress0 x04Quality-Protocol0 x0DMultilink-Protocol技術(shù)的順序）。當配置請求報文的發(fā)送端收到Config-Ack報后，則會從當前階段進入到下一個階段。例2：假設點對點通信的一端發(fā)送了一個Config-Request報文，報文內(nèi)容如下：唯一改變的內(nèi)容就是代碼域（02表示是Config-Ack報文），此例與例1完全一樣，但兩都說明有則重點。當接收Con

52、fig-Request報文的一端能識別發(fā)送端所發(fā)送過來的所有配置參數(shù)選項，但對部分配置參數(shù)選項數(shù)據(jù)域中的內(nèi)容不認可時，接收端將會給對端回應一個Config-Nak報文，該報文中只攜帶不認可的配置參數(shù)選項，而這些配置參數(shù)選項的數(shù)據(jù)內(nèi)容為本端希望的值。然而當接收端收到 Config-Nak 報 文后，會 重新發(fā)送 Config-Request 報 文，而 這個 Config-Request報文與上一次所發(fā)送的Config-Request報文區(qū)別在于那些被對端不認可的配置參數(shù)選項的內(nèi)容被填寫到剛剛協(xié)商完后再次發(fā)送的Config-Request報文中（Config-Nak報文發(fā)送回來的那些配置參數(shù)選項

53、）。例3：假設點對點通信的一端發(fā)送了一個Config-Request報文，報文內(nèi)容如下：該數(shù)據(jù)報文中有下劃線的配置參數(shù)選項的內(nèi)容為對端不認可的。當對端正確接收到了該報文后，發(fā)現(xiàn)類型域為0 x02的配置參數(shù)選項可識別，但該配置參數(shù)選項數(shù)據(jù)域的內(nèi)容不認可，應發(fā)送一個Config-Nak報文且該報文中將攜帶希望的配置參數(shù)選項內(nèi)容，報文內(nèi)容如下：該報文中返回的值已經(jīng)被更改，且當發(fā)端收到該報文后會重新發(fā)送一個Config-Request報文，報文內(nèi)容如下：仔細觀察是不是新的配置請求報文與老的配置請求的報文ID不一樣。當接收Config-Request報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項時

54、，此時接收端將會端回一個Config-Reject報文，該報文中的數(shù)據(jù)域只攜帶那些不能識別的配置參數(shù)選項（當配置參數(shù)選項的類型域不識別時）。當對端接收到Config-Reject報文后，同樣會再次發(fā)送一個Config-Request報文，這個配置請求報文與上一次發(fā)送的區(qū)別在于將不可識別的那些配置參數(shù)選項給刪除了。例4：假設點對點通信的一端發(fā)送了一個Config-Request報文，報文內(nèi)容如下：7EFF 03C0 21010100 1702 06 00 0A 00 0005 06 00 0B 42 CB07 0208 020D 03 067E157EFF 03C0 21010400 1702

55、06 00 0E 00 0005 06 00 0B 42 CB07 0208 020D 03 067E7EFF 03C0 21030100 0A02 06 00 0E 00 007E7EFF 03C0 21010100 1702 06 00 0A 00 0005 06 00 0B 42 CB07 0208 020D 03 067E7EFF 03C0 21010100 1702 06 00 0A 00 0005 06 00 0B 42 CB07 0208 020D 03 067E當對端正確接收到了該報文后，應該發(fā)送一個Config-Ack報文，報文內(nèi)容如下：7EFF 03C0 21020100

56、1702 06 00 0A 00 0005 06 00 0B 42 CB07 0208 020D 03 067E技術(shù)下劃線所表示的配置參數(shù)選項為對端不可識別的。當對端正確接收到了該報文后，發(fā)現(xiàn)類型域為0 x02的配置參數(shù)選項不識別，應該回應一個Config-Reject報文，報文內(nèi)容如下：該報文如果被送端接收后，又會重新發(fā)送一個Config-Request報文，報文內(nèi)容如下：這時能看到，類型域為02的配置選項在下一次的請求報文中被刪除了。所以能夠看出，鏈路配置階段也可能要經(jīng)過幾次協(xié)商后才能完成，但這與點對點兩端的設備有著密切的聯(lián)系。對于PPP的兩個端點而言，兩者是獨立完成各自的配置參數(shù)選項的協(xié)

57、商過程的。具體的配置參數(shù)選項待后續(xù)的章節(jié)中講解。3.1.2.4 LCP的鏈路終止報文鏈路終止報文分為Terminate-Request和Terminate-Reply兩種報文。LCP報文中提供了一種機制來關(guān)閉一個點對點的連接，想要關(guān)斷鏈路的一端會持續(xù)發(fā)送 Terminate-Request報文，直到收到一個Terminate-Reply為止。接收端一旦收到了一個Terminate-Request報文后，必須回應一個Terminate-Reply報時等待對端先將鏈路斷開后，再完成本端的所有斷開的操作。LCP的鏈路終止報文的數(shù)據(jù)域與鏈路配置報文的數(shù)據(jù)域不一樣，鏈路終止報文中無需攜帶各配置參數(shù)選項。

58、對于鏈路終止報文也同樣需要ID一致，當接收到Terminate-Reply報會做鏈路終止操作。3.1.2.5 LCP的鏈路報文除上述兩種報文類型以外，剩余的所有報文類型均歸屬鏈路報文。當接收端發(fā)現(xiàn)LCP報文的代碼域是一個不合法的值時，將會向發(fā)送端回應一個Code-Reject報文，在回應報文中會將所報文的內(nèi)容附加上。例5：假設點對點通信的一端發(fā)送了一個Config-Request報文，報文內(nèi)容如下：有下劃線的部分表示這個代碼域在標準中未定義，從而無法識別。當對端正確接收到了該報文后，發(fā)現(xiàn)LCP數(shù)據(jù)報文的代碼域為0 x0E時，應該發(fā)送一個Code-Reject報文，報文內(nèi)容如下：167EFF 0

59、3C0 21070100 1D0E0100 1902 06 00 0A 00 0005 06 00 0B 42 CB07 0208 020D 037EFF 03C0 210E0100 1902 06 00 0A 00 0005 06 00 0B 42 CB07 0208 020D 03 061F027E7EFF 03C0 21010400 1105 06 00 0B 42 CB07 0208 020D 03 067E7EFF 03C0 21040100 0A02 06 00 0A 00 007E技術(shù)當接收端發(fā)現(xiàn)所接收到的數(shù)據(jù)幀的協(xié)議域是一個不合法的值時，將會向發(fā)送端回應一個Protocol-R

60、eject報文，發(fā)送端收到該報文后將停止發(fā)送該種協(xié)議類型的數(shù)據(jù)報文了。Protocol-Reject報文只能在LCP的狀態(tài)機處于Opened狀態(tài)時才可被處理，而在其它狀態(tài)接收到該報被丟棄。在Protocol-Reject報文的數(shù)據(jù)域內(nèi)將攜帶所容。報文的協(xié)議類型和報文內(nèi)例6：假設點對點通信的一端發(fā)送了一個協(xié)議域未定義（無法識別）的報文，報文內(nèi)容如下：其中下劃線部分為PPP數(shù)據(jù)幀的協(xié)議域，0 x7777表示一個未定義的類型（也即對端無法識別）。當對端正確接收到了該報文后，發(fā)現(xiàn)該報文的協(xié)議域為0 x7777，該值未在RFC中未有明確定義，應該發(fā)送一個Protocol-Reject報文，報文內(nèi)容如下：