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

1、擬審審批制：核：核：準(zhǔn)：日日日日期：期：期：期：周一帆2002-01-05修 訂市技 術(shù) 有 限 公 司日 期修訂版本作 者描 述2002/01/05v1.0周一帆資料編碼產(chǎn)品名稱使用對(duì)象用服工程師產(chǎn)品版本編寫(xiě)部門交換接入產(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é)議簡(jiǎn)介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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鏈路的建立過(guò)程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 PPP的狀態(tài)轉(zhuǎn)移圖 . . .

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

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

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

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

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

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

15、 . . . . . . . . . . . . . . . . . 4.1.2.1 PAP認(rèn)證 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2.2 CHAP認(rèn)證 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 MRU（Ma

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

17、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242525262727272728282929第五章PPP擴(kuò)展協(xié)議. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 PPP擴(kuò)展協(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)機(jī) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 PPP擴(kuò)展協(xié)議概述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 技術(shù)第一章 概 述1.1 PPP協(xié)議的基本概念1.1.1 PPP協(xié)議出現(xiàn)的背景在提及PPP協(xié)議時(shí)，不

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35、網(wǎng)絡(luò)控制協(xié)議和提供給SPX/IPX網(wǎng)絡(luò)使用的IPXCP網(wǎng)絡(luò)控制協(xié)議等，但最為常用的是IPCP協(xié)議，當(dāng)點(diǎn)對(duì)點(diǎn)的兩端進(jìn)行NCP參數(shù)配置協(xié)商時(shí)，主要是用來(lái)通信雙方的網(wǎng)絡(luò)層地址。說(shuō)明詳細(xì)內(nèi)容請(qǐng)見(jiàn)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é)議可通過(guò)協(xié)議域來(lái)區(qū)分?jǐn)?shù)據(jù)域中凈載荷的數(shù)據(jù)類型PPP協(xié)議通過(guò)LCP協(xié)議完成數(shù)據(jù)鏈路的配置和測(cè)試PPP協(xié)議通過(guò)NCP協(xié)議完成點(diǎn)對(duì)點(diǎn)通信設(shè)備之間網(wǎng)絡(luò)層通信所需參數(shù)的配置2.3思考1、PPP數(shù)據(jù)幀中的地址域被填充為0 xFF（廣播地址），在實(shí)際應(yīng)用當(dāng)中

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

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

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

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

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

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

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

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

44、個(gè)字節(jié)，其目的是用來(lái)匹配請(qǐng)求和響應(yīng)報(bào)文。一般而言在進(jìn)入鏈路建立階段時(shí)，通信雙方無(wú)論哪一端都會(huì)連續(xù)發(fā)送幾個(gè)配置請(qǐng)求報(bào)文（Config-Request報(bào)文），而這幾個(gè)請(qǐng)求報(bào)文的數(shù)據(jù)域可能是完全一11代碼值報(bào)文類型代碼報(bào)文類型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ù)樣的，而僅僅是它們的標(biāo)志域不同罷了。通常一個(gè)配置請(qǐng)求報(bào)文的ID是從0 x01開(kāi)始逐步加1的，當(dāng)對(duì)端接收到該配置請(qǐng)求報(bào)文后，無(wú)論使用何種報(bào)文（回應(yīng)報(bào)文可能是Config-Ack、Config-Nak和Config-Reject三種報(bào)文中的一種）來(lái)回應(yīng)對(duì)方，但必須要求回應(yīng)報(bào)文中的ID要與接收?qǐng)?bào)文中的 ID一致，當(dāng)通信設(shè)備收到回應(yīng)后就可以將該回應(yīng)與發(fā)送時(shí)的進(jìn)行比較來(lái)決定下一步的操作。說(shuō)明后面中的所有例子，均可參考以下色標(biāo)的含義范例中報(bào)文色標(biāo)含義如下圖所示：例1：假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下：從報(bào)文中可以看出這個(gè)配置請(qǐng)求報(bào)文包括5

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

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

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

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

50、例如：當(dāng)一端發(fā)送魔術(shù)字配置參數(shù)選項(xiàng)中的魔術(shù)字為全0，而對(duì)端認(rèn)為應(yīng)該為其它值，這種情況就屬于不支持配置參數(shù)選項(xiàng)中的內(nèi)容）。所以依據(jù)上面的兩個(gè)條件，用何種報(bào)文回應(yīng)。就可以明確在回應(yīng)對(duì)方配置請(qǐng)求報(bào)文時(shí)，采當(dāng)接收Config-Request報(bào)文的一端能識(shí)別發(fā)送過(guò)來(lái)的所有配置參數(shù)選項(xiàng)且認(rèn)可所有配置參數(shù)選項(xiàng)數(shù)據(jù)域的內(nèi)容時(shí)，接收端將會(huì)給對(duì)端回一個(gè) Config-Ack報(bào)文并將配置請(qǐng)求報(bào)文中的配置參數(shù)選項(xiàng)原封不動(dòng)的放置在Config-Ack報(bào)文的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項(xiàng)14類型值參數(shù)選項(xiàng)類型值參數(shù)選項(xiàng)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ù)的順序）。當(dāng)配置請(qǐng)求報(bào)文的發(fā)送端收到Config-Ack報(bào)后，則會(huì)從當(dāng)前階段進(jìn)入到下一個(gè)階段。例2：假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下：唯一改變的內(nèi)容就是代碼域（02表示是Config-Ack報(bào)文），此例與例1完全一樣，但兩都說(shuō)明有則重點(diǎn)。當(dāng)接收Con

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

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

54、，此時(shí)接收端將會(huì)端回一個(gè)Config-Reject報(bào)文，該報(bào)文中的數(shù)據(jù)域只攜帶那些不能識(shí)別的配置參數(shù)選項(xiàng)（當(dāng)配置參數(shù)選項(xiàng)的類型域不識(shí)別時(shí)）。當(dāng)對(duì)端接收到Config-Reject報(bào)文后，同樣會(huì)再次發(fā)送一個(gè)Config-Request報(bào)文，這個(gè)配置請(qǐng)求報(bào)文與上一次發(fā)送的區(qū)別在于將不可識(shí)別的那些配置參數(shù)選項(xiàng)給刪除了。例4：假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)Config-Request報(bào)文，報(bào)文內(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當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該發(fā)送一個(gè)Config-Ack報(bào)文，報(bào)文內(nèi)容如下：7EFF 03C0 21020100

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

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

58、對(duì)于鏈路終止報(bào)文也同樣需要ID一致，當(dāng)接收到Terminate-Reply報(bào)會(huì)做鏈路終止操作。3.1.2.5 LCP的鏈路報(bào)文除上述兩種報(bào)文類型以外，剩余的所有報(bào)文類型均歸屬鏈路報(bào)文。當(dāng)接收端發(fā)現(xiàn)LCP報(bào)文的代碼域是一個(gè)不合法的值時(shí)，將會(huì)向發(fā)送端回應(yīng)一個(gè)Code-Reject報(bào)文，在回應(yīng)報(bào)文中會(huì)將所報(bào)文的內(nèi)容附加上。例5：假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下：有下劃線的部分表示這個(gè)代碼域在標(biāo)準(zhǔn)中未定義，從而無(wú)法識(shí)別。當(dāng)對(duì)端正確接收到了該報(bào)文后，發(fā)現(xiàn)LCP數(shù)據(jù)報(bào)文的代碼域?yàn)? x0E時(shí)，應(yīng)該發(fā)送一個(gè)Code-Reject報(bào)文，報(bào)文內(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ù)當(dāng)接收端發(fā)現(xiàn)所接收到的數(shù)據(jù)幀的協(xié)議域是一個(gè)不合法的值時(shí)，將會(huì)向發(fā)送端回應(yīng)一個(gè)Protocol-R

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