PPP協(xié)議技術(shù)與標(biāo)準(zhǔn)培訓(xùn)教材

資料編碼產(chǎn)品名稱(chēng)使用對(duì)象用服工程師產(chǎn)品版本編寫(xiě)部n交換接入產(chǎn)品技術(shù)支援管理部資料版本ppp專(zhuān)題擬制:周ー帆日期:2002-01-05審核:日期:審核:日期:批準(zhǔn)：日期:華為技術(shù)有限公司版權(quán)所有侵權(quán)必究

修訂記錄日期修訂版本描述作者2002/01/05vl.0周ー帆錄(TOCHeading)第1章概述（標(biāo)題1） 錯(cuò)誤!未定義書(shū)簽。移動(dòng)智能網(wǎng)的概念和特點(diǎn)（標(biāo)題2）錯(cuò)誤!未定義書(shū)簽。.!移動(dòng)智能網(wǎng)概念（標(biāo)題3）.錯(cuò)誤!未定義書(shū)簽。.2移動(dòng)智能網(wǎng)特點(diǎn)（標(biāo)題3）.錯(cuò)誤!未定義書(shū)簽。移動(dòng)智能網(wǎng)的體系結(jié)構(gòu)（標(biāo)題2）錯(cuò)誤!未定義書(shū)簽。業(yè)務(wù)交換點(diǎn)（SSP）（標(biāo)題3）錯(cuò)誤!未定義書(shū)簽。業(yè)務(wù)控制點(diǎn)（SCP）（標(biāo)題3）錯(cuò)誤!未定義書(shū)簽。第2章移動(dòng)智能網(wǎng)的概念模型（標(biāo)題1）錯(cuò)誤!未定義書(shū)簽。概述（標(biāo)題2） 錯(cuò)誤!未定義書(shū)簽。業(yè)務(wù)平面（標(biāo)題2） 錯(cuò)誤!未定義書(shū)簽。2.1業(yè)務(wù)及業(yè)務(wù)特征（標(biāo)題3）.錯(cuò)誤!未定義書(shū)簽。第3章本模板新增兩個(gè)樣式 錯(cuò)誤!未定義書(shū)簽。1命令行關(guān)鍵字commandkeywords.錯(cuò)誤!未定義書(shū)簽。2命令行參數(shù)commandparameter..錯(cuò)誤!未定義書(shū)簽。3樣例如下 錯(cuò)誤!未定義書(shū)簽。第4章TerminalDisplay樣式 錯(cuò)誤!未定義書(shū)簽。關(guān)鍵詞:摘要:縮略語(yǔ)清單:參考資料清單:第1章概述PPP協(xié)議的基本概念PPP協(xié)議出現(xiàn)的背景在提及PPP協(xié)議時(shí),不可不提及它的老祖宗SLIP(SerialLineInternetProtocol)協(xié)議。雖然它已被淡忘在歷史的長(zhǎng)河中,但畢竟有過(guò)輝煌的日子。它曾經(jīng)主載了Internet半邊江山,人們不僅可以通過(guò)在計(jì)算機(jī)上安裝該協(xié)議實(shí)現(xiàn)瀏覽Internet的夢(mèng)想,而且還可以互連許多網(wǎng)絡(luò)設(shè)備(如路由器與路由器的互連、路由器與主機(jī)的互連和主機(jī)與主機(jī)的互連)。隨著網(wǎng)絡(luò)技術(shù)的不斷日新月異,特別是計(jì)算機(jī)技術(shù)的發(fā)展,人們開(kāi)始漸漸認(rèn)識(shí)到使用SLIP協(xié)議已不能滿(mǎn)足日益增長(zhǎng)的網(wǎng)絡(luò)需求,如何在串行點(diǎn)對(duì)點(diǎn)的鏈路上封裝IPX、AppleTalk等網(wǎng)絡(luò)層的協(xié)議呢?這就給我們網(wǎng)絡(luò)專(zhuān)家提出了新的挑戰(zhàn),也為PPP協(xié)議的出現(xiàn)提供了契機(jī),PPP由于自身的諸多的優(yōu)點(diǎn)已成為目前被廣泛使用的數(shù)據(jù)鏈路層協(xié)議。說(shuō)明如果對(duì)SLIP不感舉趣,可直接跳到L1.2節(jié)1.1.1.1SLIP協(xié)議的基本概念SLIP協(xié)議出現(xiàn)在80年代中期,并被使用在BSDUNIX主機(jī)和SUN的工作站上,因?yàn)镾LIP簡(jiǎn)單好用,所以后來(lái)被大量使用在線(xiàn)路速率從1200bps到19.2Kbps的專(zhuān)用線(xiàn)路和撥號(hào)線(xiàn)路上互連主機(jī)和路由器,到目前為止仍有問(wèn)大部分UNIX主機(jī)保留對(duì)該協(xié)議的支持。在80年代末90年代初期,被廣泛用于家庭中每臺(tái)有RS232串口的計(jì)算機(jī)和調(diào)制解調(diào)器連接到Internet。SLIP是ー種在點(diǎn)對(duì)點(diǎn)的串行鏈路上封裝!P數(shù)據(jù)報(bào)的簡(jiǎn)單協(xié)議,它并非是Internet的標(biāo)準(zhǔn)協(xié)議。1.1.1.2SLIP協(xié)議的封裝格式SLIP協(xié)議的封裝格式必需遵循以下幾條原則:?通過(guò)在被發(fā)送IP數(shù)據(jù)報(bào)的尾部增加特殊的END字符（OxCO）從而形成一個(gè)簡(jiǎn)單的SLIP的數(shù)據(jù)幀,而后該幀會(huì)被傳送到物理層進(jìn)行發(fā)送。為了防止線(xiàn)路噪聲被當(dāng)成數(shù)據(jù)報(bào)的內(nèi)容在線(xiàn)路上傳輸,通常發(fā)送端在被傳送數(shù)據(jù)報(bào)的開(kāi)始處也傳ー個(gè)END字符。如果線(xiàn)路上的確存在噪聲,則該數(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)代替它（如Oxdb和Oxdc）。如果當(dāng)被轉(zhuǎn)意后的字符也包含在數(shù)據(jù)報(bào)中,則也需要對(duì)其進(jìn)行同樣的操作,直至不出現(xiàn)歧義為止。下圖為SLIP數(shù)據(jù)幀的封裝格式:End Endq IP數(shù)據(jù)報(bào)文 險(xiǎn)1B 1B圖1-1SUP數(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)有類(lè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)和,如果由于線(xiàn)路噪聲的干擾影響傳送數(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、!PX和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(LinkControlProtocol)鏈路控制協(xié)議、NCP(NetworkControlProtocol)和PPP的擴(kuò)展協(xié)議(如MultilinkProtocol,詳見(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)線(xià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ò)程中,我們需要輸入用戶(hù)名和密碼。因此當(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é)議RFC166I文檔中說(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ī)制,那么它是如何保證數(shù)據(jù)發(fā)送的正確性的?3、PPP協(xié)議不僅可以支持同步物理層傳輸,而且還支持異步物理層傳輸,請(qǐng)比較一下兩者的區(qū)別?4、PPP協(xié)議和SLIP協(xié)議的區(qū)別,可從封裝格式,IP地址分配等方面考慮?第2章PPP協(xié)議的三組件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)容。PPP協(xié)議的封裝我們知道ISO參考模型共分七層,自下而上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話(huà)層、表示層和應(yīng)用層。通常我們會(huì)依據(jù)協(xié)議所完成的功能將它與這七層進(jìn)行對(duì)照,PPP協(xié)議就屬于數(shù)據(jù)鏈路層協(xié)議。我們?cè)谔峒癙PP協(xié)議的報(bào)文封裝格式時(shí),不可不先提ー下HDLC協(xié)議。HDLC也是最常用的數(shù)據(jù)鏈路層協(xié)議,它是從SDLC協(xié)議衍進(jìn)過(guò)來(lái)的,許多常用的數(shù)據(jù)鏈路層協(xié)議的封裝方式都是基于HDLC的封裝格式的,同樣PPP協(xié)議也不例外,它也采用了HDLC的定界幀格式。下圖為PPP數(shù)據(jù)幀的封裝格式:FlagAddCtrl Flag讀FF03協(xié)議域 信息域，數(shù)據(jù)域Crcミ圖2-2PPP數(shù)據(jù)幀格式以下為對(duì)PPP數(shù)據(jù)幀封裝格式的一點(diǎn)說(shuō)明:每ー個(gè)PPP數(shù)據(jù)幀均是以一個(gè)標(biāo)志字節(jié)起始和結(jié)束的,該字節(jié)為0x7E。?緊接在起始標(biāo)志字節(jié)后的ー個(gè)字節(jié)是地址域,該字節(jié)為OxFF。我們熟知網(wǎng)絡(luò)是分層的,且對(duì)等層之間進(jìn)行相互通信,而下層為上層提供服務(wù)。當(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é)議端口號(hào)。例如如果兩個(gè)以太網(wǎng)上的主機(jī)希望能夠通信的話(huà),首先發(fā)送端需獲知對(duì)端的MAC地址。但由于PPP協(xié)議是被運(yùn)用在點(diǎn)對(duì)點(diǎn)的鏈路上的特殊性,它不像廣播或多點(diǎn)訪(fǎng)問(wè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í)際意義,按照協(xié)議的規(guī)定通信雙方將該字節(jié)的內(nèi)容填充為0x03o就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ù)ISO3309的地址擴(kuò)展機(jī)制所給出的規(guī)定。該機(jī)制規(guī)定協(xié)議域所填充的內(nèi)容必須為奇數(shù),也即是要求低字節(jié)的最低位為〃1〃,高字節(jié)的最低位為〃?！?。如果當(dāng)發(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域字段不符合上述規(guī)定,則接收端會(huì)認(rèn)為此數(shù)據(jù)幀是不可識(shí)別的,那么接收端會(huì)向發(fā)送端發(fā)送ー個(gè)Protocol-Reject報(bào)文,在該報(bào)文尾部將完整地填充被拒絕的報(bào)文。協(xié)議域的具體取值如下表所示:協(xié)議域類(lèi)型說(shuō)明ISO標(biāo)準(zhǔn)0x0***-0x3***信息域中承載的是網(wǎng)絡(luò)層的數(shù)據(jù)報(bào)文0x4***-0x7***信息域中承載的是與NCP無(wú)關(guān)的低整流量0x8***-Oxb***信息域中承載的是網(wǎng)絡(luò)控制協(xié)議(NCP)的數(shù)據(jù)報(bào)文

Oxc***-Oxf***信息域中承載的是鏈路控制協(xié)議（LCP）的數(shù)據(jù)報(bào)文最典型的幾種取值0xc021信息域中承載的是鏈路控制協(xié)議（LCP）的數(shù)據(jù)報(bào)文0xc023信息域中承載的是PAP協(xié)議的認(rèn)證報(bào)文0xc223信息域中承載的是CHAP協(xié)議的認(rèn)證報(bào)文0x8021信息域中承載的是網(wǎng)絡(luò)控制協(xié)議（NCP）的數(shù)據(jù)報(bào)文0x0021信息域中承載的是IP數(shù)據(jù)報(bào)文說(shuō)明協(xié)議域類(lèi)型中的?號(hào)表示可從(0-F)中任意取值?信息域缺省時(shí)最大長(zhǎng)度不能超過(guò)1500字節(jié),其中包括填充域的內(nèi)容(在圖2-1中并未表示,因?yàn)樗鼘儆谛畔⒂虻囊徊糠?，1500字節(jié)大小等于PPP協(xié)議中配置參數(shù)選項(xiàng)MRU(MaximumReceiveUnit)的缺省值,在實(shí)際應(yīng)用當(dāng)中可根據(jù)實(shí)際需要進(jìn)行信息域最大封裝長(zhǎng)度選項(xiàng)的協(xié)商。信息域如果不足1500字節(jié)時(shí)可被填充,但不是必須的,如果填充則需通信雙方的兩端能辨認(rèn)出有用與無(wú)用的信息方可正常通信。我們通常在通信設(shè)備的配置過(guò)程中,遇到最多的也是MTU(MaximumTransmitUnit)〇對(duì)于ー個(gè)設(shè)備而言,它網(wǎng)絡(luò)的層次均使用MTU和MRU兩個(gè)值,一般情況下設(shè)備的MRU會(huì)比MTU稍大幾個(gè)字節(jié),但這需根據(jù)各廠(chǎng)商的設(shè)備而定。?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)銷(xiāo),這樣可能會(huì)增加應(yīng)用層交互的延遲,對(duì)于這個(gè)字節(jié)的使用我們可以參考一下X.25協(xié)議和FR協(xié)議就知道了。LCP協(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é)議NCP協(xié)議PPP的網(wǎng)絡(luò)控制協(xié)議根據(jù)不同的網(wǎng)絡(luò)層協(xié)議可提供一族網(wǎng)絡(luò)控制協(xié)議,常用的有提供給TCP/IP網(wǎng)絡(luò)使用的IPCP網(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ò)層地址。詳細(xì)內(nèi)容請(qǐng)見(jiàn)3.1.3節(jié)NCP協(xié)議總結(jié)?PPP協(xié)議的三組件包括PPP協(xié)議的封裝方式、LCP協(xié)議和NCP協(xié)議?PPP協(xié)議是數(shù)據(jù)鏈路層協(xié)議,它的數(shù)據(jù)幀封裝格式非常類(lèi)似于HDLC.PPP協(xié)議可通過(guò)協(xié)議域來(lái)區(qū)分?jǐn)?shù)據(jù)域中凈載荷的數(shù)據(jù)類(lèi)型?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ù)幀中的地址域被填充為OxFF（廣播地址）,在實(shí)際應(yīng)用當(dāng)中該域已沒(méi)有任何意義,請(qǐng)想ー下為什么使用PPP協(xié)議通信的設(shè)備不需要類(lèi)似于以太網(wǎng)的數(shù)據(jù)鏈路層尋址機(jī)制?2、PPP協(xié)議數(shù)據(jù)域缺省的最大值是多少?3、當(dāng)發(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域不被接收方識(shí)別時(shí),接收方將如何處理這個(gè)數(shù)據(jù)幀?4、IPCP協(xié)議的主要功能?第3章PPP鏈路的建立PPP鏈路的建立過(guò)程PPP的狀態(tài)轉(zhuǎn)移圖數(shù)據(jù)通信設(shè)備（在本文中指路由器）的兩端如果希望通過(guò)PPP協(xié)議建立點(diǎn)對(duì)點(diǎn)的通信,無(wú)論哪一端的設(shè)備都需發(fā)送しCP數(shù)據(jù)報(bào)文來(lái)配置鏈路（測(cè)試鏈路）。一旦LCP的配置參數(shù)選項(xiàng)協(xié)商完后,通信的雙方就會(huì)根據(jù)しCP配置請(qǐng)求報(bào)文中所協(xié)商的認(rèn)證配置參數(shù)選項(xiàng)來(lái)決定鏈路兩端設(shè)備所采用的認(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)文是在しCP協(xié)商階段或應(yīng)用程序會(huì)話(huà)階段發(fā)出的）;物理層無(wú)法檢測(cè)到載波或管理人員對(duì)該鏈路進(jìn)行關(guān)閉操作,都會(huì)將該條鏈路斷開(kāi),從而終止PPP會(huì)話(huà)。以下為PPP協(xié)議整個(gè)鏈路過(guò)程需經(jīng)歷階段的狀態(tài)轉(zhuǎn)移圖:鏈路不可用階段 ?鏈路建立階段一?I!犠路終止階段 驗(yàn)證階段I1?—網(wǎng)絡(luò)層協(xié)議階段?—圖3-1PPP的狀態(tài)轉(zhuǎn)移圖在點(diǎn)對(duì)點(diǎn)鏈路的配置、維護(hù)和終止過(guò)程中,PPP需經(jīng)歷以下幾個(gè)階段:?鏈路不可用階段,有時(shí)也稱(chēng)為物理層不可用階段,PPP鏈路都需從這個(gè)階段開(kāi)始和結(jié)束。當(dāng)通信雙方的兩端檢測(cè)到物理線(xiàn)路激活（通常時(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ù)不同的事件發(fā)生變化。當(dāng)處于在鏈路不可用階段時(shí),LCP的狀態(tài)機(jī)是處于initial（初始化狀態(tài)）或starting（準(zhǔn)備啟動(dòng)狀態(tài)），一旦檢測(cè)到物理線(xiàn)路可用,則LCP的狀態(tài)機(jī)就要發(fā)生改變。當(dāng)然鏈路被斷開(kāi)后也同樣會(huì)返回到這個(gè)階段,往往在實(shí)際過(guò)程中這個(gè)階段所停留的時(shí)間是很短的,僅僅是檢測(cè)到對(duì)方設(shè)備的存在。?鏈路建立階段,也是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è)備配置的（通常是由用戶(hù)來(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)前狀態(tài)改變?yōu)镽equest-Sent（請(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ú)立的。如果在該階段收到了非しCP數(shù)據(jù)報(bào)文,則會(huì)的將這些報(bào)文丟棄。在實(shí)際配置當(dāng)中在該階段可能會(huì)遇到很多情況,在LCP協(xié)議章節(jié)中會(huì)詳細(xì)介紹可能遇到的情況,但最好結(jié)合一些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è)無(wú)限制的延遲驗(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、!PX和AppleTalk）會(huì)通過(guò)各自相應(yīng)的網(wǎng)絡(luò)控制協(xié)議進(jìn)行配置,每個(gè)NCP協(xié)議可在任何時(shí)間打開(kāi)和關(guān)閉。當(dāng)ー個(gè)NCP的狀態(tài)機(jī)變成。pened狀態(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)載波丟失、授權(quán)失敗、鏈路質(zhì)量檢測(cè)失敗和管理員人為關(guān)閉鏈路等情況均會(huì)導(dǎo)致鏈路終止。鏈路建立階段可能通過(guò)交換しCP的鏈路終止報(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.2LCP協(xié)議3.1.2.1LCP數(shù)據(jù)報(bào)文的封裝方式LCP數(shù)據(jù)報(bào)文是在鏈路建立階段被交換的,它作為PPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中,此時(shí)PPP數(shù)據(jù)幀的協(xié)議域固定填充0xC021,但在鏈路建立階段的整個(gè)過(guò)程中信息域的內(nèi)容是在變化的,它包括很多種類(lèi)型的報(bào)文,所以這些報(bào)文也要通過(guò)相應(yīng)的字段來(lái)區(qū)分。LCP數(shù)據(jù)報(bào)文的一般封裝方式如下圖所示:代碼域標(biāo)識(shí)域長(zhǎng)度域數(shù)據(jù)域圖3-2LCP報(bào)文的封裝格式?代碼域的長(zhǎng)度為ー個(gè)字節(jié),主要是用來(lái)標(biāo)識(shí)LCP數(shù)據(jù)報(bào)文的類(lèi)型的。在鏈路建立階段時(shí),接收方收到LCP數(shù)據(jù)報(bào)文的代碼域無(wú)法識(shí)別時(shí),就會(huì)向?qū)Χ税l(fā)送ー個(gè)LCP的代碼拒絕報(bào)文（Code-Reject報(bào)文）。根據(jù)RFC的規(guī)定,到目前為止LCP共包括以下幾種類(lèi)型的數(shù)據(jù)報(bào)文:代碼值報(bào)文類(lèi)型代碼報(bào)文類(lèi)型0x01Config-Request0x07Code-Reject0x02Config-Ack0x08Protocol-Reject0x03Config-Nak0x09Echo-Request0x04Config-RejectOxOAEcho-Reply0x05Terminate-RequestOxOBDiscard-Request0x06Terminate-AckOxOCReserved?標(biāo)識(shí)域也是一個(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ù)域可能是完全ー樣的,而僅僅是它們的標(biāo)志域不同罷了。通常一個(gè)配置請(qǐng)求報(bào)文的ID是從0x01開(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)含義如下圖所示:ppp數(shù)據(jù)幀的起始像束標(biāo)志字節(jié)ppp數(shù)據(jù)幀的地址域和控制域ppp數(shù)據(jù)幀的協(xié)議域LCP數(shù)據(jù)報(bào)文的類(lèi)型域LCP數(shù)據(jù)報(bào)文的配置參數(shù)選項(xiàng)或報(bào)文內(nèi)容LCP數(shù)據(jù)報(bào)文標(biāo)識(shí)域LCP數(shù)據(jù)報(bào)文的長(zhǎng)度域圖3-3報(bào)文色標(biāo)含義定義例1:假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)Config-Request報(bào)文,報(bào)文內(nèi)容如下:

Config-Request報(bào)文,報(bào)文內(nèi)容如下:從報(bào)文中可以看出這個(gè)配置請(qǐng)求報(bào)文包括5個(gè)配置參數(shù)選項(xiàng)。當(dāng)對(duì)端正確接收到了該報(bào)文后,應(yīng)該回應(yīng)ー個(gè)Config-Ack從報(bào)文中可以看出這個(gè)配置請(qǐng)求報(bào)文包括5個(gè)配置參數(shù)選項(xiàng)。當(dāng)對(duì)端正確接收到了該報(bào)文后,應(yīng)該回應(yīng)ー個(gè)Config-Ack報(bào)文,報(bào)文內(nèi)容如下:該報(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é)1.2.2LCP數(shù)據(jù)報(bào)文的分類(lèi)在前ー小節(jié)我們可以看到,ー共包括!2種LCP數(shù)據(jù)報(bào)文,我們依據(jù)各報(bào)文的的功能又將其具體細(xì)化為以下三類(lèi):?鏈路配置報(bào)文,主要用來(lái)建立和配置一條鏈路的。?鏈路終止報(bào)文,主要用來(lái)終止一條鏈路的。?鏈路維護(hù)報(bào)文,主要用來(lái)維護(hù)和調(diào)試鏈路的。3.1.2.3LCP的鏈路配置報(bào)文圖3-4配置報(bào)文中配置選項(xiàng)的數(shù)據(jù)格式鏈路配置報(bào)文與其它兩類(lèi)報(bào)文有著明顯的區(qū)別,它主要是用來(lái)協(xié)商鏈路的配置參數(shù)選項(xiàng)的,因此這種報(bào)文的數(shù)據(jù)域還要攜帶許多配置參數(shù)選項(xiàng)的,而另外兩類(lèi)報(bào)文中部分報(bào)文的格式會(huì)稍有不同（請(qǐng)參見(jiàn)RFC1661),圖3-4表明了數(shù)據(jù)配置選項(xiàng)的報(bào)文格式:鏈路配置報(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):類(lèi)型值參數(shù)選項(xiàng)類(lèi)型值參數(shù)選項(xiàng)0x00Reserved0x05Magic-Number0x01Maximum-Recieve-Un0x06CBCP

it0x0Async-0x07Protocol-F2Controield-Compr1-Charessacter-Map0x0Authen0x08Address-an3ticatid-Control-on-ProField-Comptocolress0x0QualitOxODMultilink-4y-ProtProtocolocol這個(gè)表格內(nèi)的內(nèi)容并非完全,可能還有一新定議的配置選項(xiàng)未列在其中,如有興趣可參照相關(guān)的文檔說(shuō)明。當(dāng)接收方收到Config-Request報(bào)文時(shí),會(huì)在剩下的三種類(lèi)型的報(bào)文中選擇ー種來(lái)響應(yīng)對(duì)方的請(qǐng)求報(bào)文,到底選擇哪種報(bào)文來(lái)響應(yīng)對(duì)方需依據(jù)以下兩個(gè)條件:?不能完全識(shí)別配置參數(shù)選項(xiàng)的類(lèi)型域,我們知道ー個(gè)Config-Request報(bào)文中會(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)閉了,而僅支持0x01和0x03兩個(gè)配置參數(shù)選項(xiàng),因此當(dāng)對(duì)方發(fā)送的Config-Request報(bào)文中含有0x04配置選項(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)容（例如:當(dāng)一端發(fā)送魔術(shù)字配置參數(shù)選項(xiàng)中的魔術(shù)字為全〇,而對(duì)端認(rèn)為應(yīng)該為其它值,這種情況就屬于不支持配置參數(shù)選項(xiàng)中的內(nèi)容）。所以依據(jù)上面的兩個(gè)條件,我們就可以明確在回應(yīng)對(duì)方配置請(qǐng)求報(bào)文時(shí),采用何種報(bào)文回應(yīng)。?當(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)的順序）。當(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)容如下:當(dāng)對(duì)端正確接收到了該報(bào)文后,應(yīng)該發(fā)送ー個(gè)Config-Ack報(bào)文,報(bào)文內(nèi)容如下:FF03唯一改變的內(nèi)容就是代碼域（02表示是Config-Ack報(bào)文）,此例與例1完全ー樣,但兩都說(shuō)明的問(wèn)題有則重點(diǎn)。?當(dāng)接收Config-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)）。例3：假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)Config-Request報(bào)文,報(bào)文內(nèi)容如下:該數(shù)據(jù)報(bào)文中有下劃線(xiàn)的配置參數(shù)選項(xiàng)的內(nèi)容為對(duì)端不認(rèn)可的。當(dāng)對(duì)端正確接收到了該報(bào)文后,發(fā)現(xiàn)類(lèi)型域?yàn)樵摂?shù)據(jù)報(bào)文中有下劃線(xiàn)的配置參數(shù)選項(xiàng)的內(nèi)容為對(duì)端不認(rèn)可的。當(dāng)對(duì)端正確接收到了該報(bào)文后,發(fā)現(xiàn)類(lèi)型域?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)容如下:HFF03HFF03該報(bào)文中返回的值已經(jīng)被更改,且當(dāng)發(fā)端收到該報(bào)文后會(huì)重新發(fā)送ー個(gè)Config-Request報(bào)文,報(bào)文內(nèi)容如下:7EFF03仔細(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í),此時(shí)接收端將會(huì)向?qū)Χ嘶丞`個(gè)Config-Reject報(bào)文,該報(bào)文中的數(shù)據(jù)域只攜帶那些不能識(shí)別的配置參數(shù)選項(xiàng)（當(dāng)配置參數(shù)選項(xiàng)的類(lèi)型域不識(shí)別時(shí)）。該報(bào)文中返回的值已經(jīng)被更改,且當(dāng)發(fā)端收到該報(bào)文后會(huì)重新發(fā)送ー個(gè)Config-Request報(bào)文,報(bào)文內(nèi)容如下:7EFF03仔細(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í),此時(shí)接收端將會(huì)向?qū)Χ嘶丞`個(gè)Config-Reject報(bào)文,該報(bào)文中的數(shù)據(jù)域只攜帶那些不能識(shí)別的配置參數(shù)選項(xiàng)（當(dāng)配置參數(shù)選項(xiàng)的類(lèi)型域不識(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)容如下:FF03UI力下劃線(xiàn)所表示的配置參數(shù)選項(xiàng)為對(duì)端不可識(shí)別的。當(dāng)對(duì)端正確接收到了該報(bào)文后,發(fā)現(xiàn)類(lèi)型域?yàn)?x02的配置參數(shù)選項(xiàng)不識(shí)別,應(yīng)該回應(yīng)ー個(gè)Config-Reject報(bào)文,報(bào)文內(nèi)容如下:該報(bào)文如果被原發(fā)送端接收后,又會(huì)重新發(fā)送ー個(gè)Config-Request報(bào)文,報(bào)文內(nèi)容如下:FF03FF03這時(shí)我們能看到,類(lèi)型域?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é)商過(guò)程的。具體的配置參數(shù)選項(xiàng)待后續(xù)的章節(jié)中講解。3.1.2.4LCP的鏈路終止報(bào)文鏈路終止報(bào)文分為T(mén)erminate-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為止。接收端一旦收到了一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)。對(duì)于鏈路終止報(bào)文也同樣需要ID一致,當(dāng)接收到Terminate-Reply報(bào)文才會(huì)做鏈路終止操作。3.1.2.5LCP的鏈路維護(hù)報(bào)文除上述兩種報(bào)文類(lèi)型以外,剩余的所有報(bào)文類(lèi)型均歸屬鏈路維護(hù)報(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)容如下:

有下劃線(xiàn)的部分表示這個(gè)代碼域在標(biāo)準(zhǔn)中未定義,從而無(wú)法識(shí)別。當(dāng)對(duì)端正確接收到了該報(bào)文后,發(fā)現(xiàn)LCP數(shù)據(jù)報(bào)文的代碼域?yàn)镺xOE時(shí),應(yīng)該發(fā)送ー個(gè)Code-Reject報(bào)文,報(bào)文內(nèi)容如下:?當(dāng)接收端發(fā)現(xiàn)所接收到的數(shù)據(jù)幀的協(xié)議域是ー個(gè)不合法的值時(shí),將會(huì)向發(fā)送端回應(yīng)ー個(gè)Protocol-Reject報(bào)文,發(fā)送端收到該拒絕報(bào)文后將停止發(fā)送該種協(xié)議類(lèi)型的數(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é)議類(lèi)型和報(bào)文內(nèi)容。例6：假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)協(xié)議域未定義（無(wú)法識(shí)別）的報(bào)文,報(bào)文內(nèi)容如下:FF03FF03其中下劃線(xiàn)部分為PPP數(shù)據(jù)幀的協(xié)議域,0x7777表示ー個(gè)未定義的類(lèi)型（也即對(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)容如下:?Echo-Request報(bào)文和Echo-Reply報(bào)文主要用來(lái)檢測(cè)雙向鏈路上自環(huán)的問(wèn)題,除此之外還可附帶做ー些鏈路質(zhì)量的測(cè)試和其它功能。當(dāng)しCP狀態(tài)機(jī)處于Opened狀態(tài)時(shí),如果接收到了Echo-Request,就需向?qū)Χ嘶厮桐`個(gè)Echo-Reply報(bào)文。否則在其它LCP狀態(tài)下,該類(lèi)型的報(bào)文會(huì)被丟棄。這種類(lèi)型數(shù)據(jù)報(bào)文的長(zhǎng)度域后不是直接跟數(shù)據(jù)域,而是要插入4個(gè)字節(jié)的Magic-Number（魔術(shù)字）,該魔術(shù)字是在LCP的Config-Request的配置參數(shù)選項(xiàng)協(xié)商時(shí)獲得的〇例7:假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端接收到了一個(gè)Echo-Request報(bào)文，報(bào)文內(nèi)容如下:FF03有下劃線(xiàn)的部分表示魔術(shù)字。當(dāng)對(duì)端正確接收到了該報(bào)文后,應(yīng)該發(fā)送ー個(gè)Echo-Reply報(bào)文,報(bào)文內(nèi)容如下:3.1.3NCP協(xié)議NCP協(xié)議的數(shù)據(jù)報(bào)文是在網(wǎng)絡(luò)層協(xié)議階段被交換的,在這個(gè)階段所需的ー些配置參數(shù)選項(xiàng)協(xié)商完后,就可以進(jìn)行網(wǎng)絡(luò)層的通信,也即是在點(diǎn)對(duì)點(diǎn)的鏈路上可以開(kāi)始傳送網(wǎng)絡(luò)層的數(shù)據(jù)報(bào)文了。NCP協(xié)議主要包括IPCP、IPXCP等,但我們?cè)趯?shí)際當(dāng)中最常遇見(jiàn)的也只有IPCP協(xié)議了,如果對(duì)IPXCP或其它的一些網(wǎng)絡(luò)控制協(xié)議有興趣,則可參見(jiàn)RFC1552。1.3.1IPCPIPCP控制協(xié)議主要是負(fù)責(zé)完成IP網(wǎng)絡(luò)層協(xié)議通信所需配置參數(shù)的選項(xiàng)協(xié)商的。IPCP在運(yùn)行的過(guò)程當(dāng)中,主要是完成點(diǎn)對(duì)點(diǎn)通信設(shè)備的兩端動(dòng)態(tài)的協(xié)商IP地址。我們依據(jù)兩端設(shè)備的配置選項(xiàng)可將!PCP的協(xié)商過(guò)程分為〃靜態(tài)〃和〃動(dòng)態(tài)〃。何為靜態(tài),何為動(dòng)態(tài),這是ー個(gè)相對(duì)的概念,也是自己總結(jié)出來(lái)的,可能不太準(zhǔn)確,只作為參考使用。我們?cè)谙旅鏁?huì)具體描述這兩個(gè)過(guò)程。!PCP的數(shù)據(jù)的文同LCP的數(shù)據(jù)報(bào)文非常類(lèi)似,只不過(guò)ー個(gè)是在網(wǎng)絡(luò)層協(xié)議階段協(xié)商配置參數(shù)選項(xiàng),而LCP協(xié)議則是在鏈路建立階段協(xié)商配置參數(shù)選項(xiàng)的。除此之外是兩者在所使用報(bào)文上的相似之處,我們知道LCP共包括十幾種報(bào)文,而IPCP也包括多種報(bào)文,但它的報(bào)文類(lèi)型只是LCP數(shù)據(jù)報(bào)文的ー個(gè)子集（只有しCP代碼域從1到7這七種報(bào)文）,而且實(shí)際的數(shù)據(jù)報(bào)文交換過(guò)程中也僅涉及以下兒種:Config-Request>Config-Ack>Config-Nak和Config-Reject（代碼域從1到4,而鏈路終止報(bào)文一般而言是不在網(wǎng)絡(luò)協(xié)議階段使用的,而且也是不需要的）。以下就具體介紹一下IPCP控制協(xié)議的靜態(tài)和動(dòng)態(tài)的兩個(gè)過(guò)程,實(shí)際上兩者的區(qū)分是在于互連設(shè)備IP地址的獲取過(guò)程。?靜態(tài)協(xié)商,也即是不協(xié)商。點(diǎn)對(duì)點(diǎn)的通信設(shè)備兩端在PPP協(xié)商之前已配置好了IP地址,所以就無(wú)須在網(wǎng)絡(luò)層協(xié)議階段協(xié)商IP地址,而雙方唯ー要做的就是告訴對(duì)方自身的IP地址。在IPCP控制協(xié)議完成整個(gè)配置的過(guò)程時(shí),最理想的情況將會(huì)看到如圖所示的四種報(bào)文,而無(wú)其它報(bào)文再被發(fā)送。如果當(dāng)配置請(qǐng)求中所攜帶的網(wǎng)絡(luò)層配置參數(shù)選項(xiàng)類(lèi)似于しCP配置參數(shù)選項(xiàng)協(xié)商過(guò)程一樣,可能會(huì)有對(duì)方不識(shí)別的配置參數(shù)選項(xiàng)或不被對(duì)方所認(rèn)可的配置參數(shù)選項(xiàng)的內(nèi)容。這樣在這個(gè)階段的協(xié)商過(guò)程中可能還會(huì)看到其它的ー些報(bào)文。在靜態(tài)協(xié)商時(shí),如果IPCP的Config-Request報(bào)文中只含有地址配置參數(shù)選項(xiàng)時(shí)（實(shí)際中可能還會(huì)附帶其它配置參數(shù)選項(xiàng),這些配置參數(shù)選項(xiàng)的協(xié)商與LCP階段的ー樣,而我這里只提到了IP地址配置參數(shù)選項(xiàng)）,無(wú)論是發(fā)送方還是接收方都同時(shí)發(fā)送Config-Request報(bào)文,其中配置選項(xiàng)中只含有各自的!P地址。當(dāng)對(duì)端收到該報(bào)文后,會(huì)發(fā)送ー個(gè)Config-Ack報(bào)文,這個(gè)目的是告訴對(duì)端我已經(jīng)知道了你的IP地址,對(duì)路由器而言會(huì)增加一條到對(duì)端接口的主機(jī)路由。剛進(jìn)入網(wǎng)絡(luò)層協(xié)議階段時(shí),IPCP的狀態(tài)機(jī)是initial的,但當(dāng)完成了上述的整個(gè)過(guò)程后,IPCP的狀態(tài)機(jī)改變?yōu)镺pened,雙方也就可以開(kāi)始網(wǎng)絡(luò)層數(shù)據(jù)網(wǎng)的傳送了。IPCP協(xié)議中并未規(guī)定,當(dāng)一端接收到Config-Request報(bào)文后,它從報(bào)文的配置參數(shù)選項(xiàng)中可獲知對(duì)端的IP地址,但并不與本端的IP地址進(jìn)行比較.我們也知道,一般而言點(diǎn)對(duì)點(diǎn)的兩端應(yīng)該是在ー個(gè)網(wǎng)段。但如果雙方的地址不在ー個(gè)網(wǎng)段,就不給對(duì)方回應(yīng)Config-Ack報(bào)文,而是無(wú)條件的回送一個(gè)回應(yīng)報(bào)文因此說(shuō)點(diǎn)對(duì)點(diǎn)通信的兩端如果是手動(dòng)設(shè)置每ー端的IP地址時(shí),無(wú)須雙方地址在同一網(wǎng)段。例8：假設(shè)!PCP在網(wǎng)絡(luò)層協(xié)議階段開(kāi)始協(xié)商配置參數(shù)選項(xiàng)（這里只舉協(xié)商!P地址的配置參數(shù)選項(xiàng)地的過(guò)程）,發(fā)送方設(shè)置!P地址為192.168.0.1,接

收方設(shè)置IP地址為192.168.0.2,發(fā)送方發(fā)送給Config-Request報(bào)文內(nèi)容如下:FF03在這個(gè)例子中我們能看見(jiàn)明顯的改變之處再于PPP協(xié)議域字段由原先的0xC021改變?yōu)?x8021,下劃線(xiàn)的部分表示本端的IP地址。當(dāng)對(duì)端正確接收到了該報(bào)文后,應(yīng)該回應(yīng)ー個(gè)Config-Ack報(bào)文,報(bào)文內(nèi)容如下:同樣的接收方給發(fā)送方也發(fā)送ー個(gè)同樣的接收方給發(fā)送方也發(fā)送ー個(gè)Config-Request報(bào)文內(nèi)容如下,但此時(shí)報(bào)文中IP地址配置參數(shù)選項(xiàng)的值為本端的IP地址(192.168.0.2)：.FF03.FF03發(fā)送方回應(yīng)ーConfig-Ack報(bào)文給接收方,報(bào)文內(nèi)容如下:

?動(dòng)態(tài)協(xié)商,也即是一端配置為動(dòng)態(tài)獲取IP地址,另一端通過(guò)手動(dòng)方式配置IP地址,且允許給對(duì)端分配IP地址,這個(gè)過(guò)程實(shí)際上可與窄帶撥號(hào)上網(wǎng)的過(guò)程相一致,如果我們想用計(jì)算機(jī)上網(wǎng),均會(huì)安裝ー個(gè)撥號(hào)適配器,而?且計(jì)算機(jī)中的撥號(hào)網(wǎng)絡(luò)適配器是采用動(dòng)態(tài)獲取IP地址的方式。這個(gè)例子與一個(gè)例子相似,也就是在IPCP的Config-Request報(bào)文中只攜帶!P地址的配置參數(shù)選項(xiàng)。如果是配置參數(shù)選項(xiàng)中含有其它配置參數(shù)選項(xiàng),則可能會(huì)遇到其它的ー些情況（如不識(shí)SenderReceiver圖3-6SenderReceiver圖3-6動(dòng)態(tài)協(xié)商別配置參數(shù)選項(xiàng)的代碼域或不認(rèn)可配置參數(shù)選項(xiàng)的內(nèi)容,但對(duì)于這些情況的處理方法和LCP配置參數(shù)選項(xiàng)的處理方法一致）。圖3-6中我們可以看出發(fā)送方連續(xù)發(fā)送了兩次Config-Request報(bào)文,才能完成發(fā)送方的協(xié)商過(guò)程。而接收方仍然只需要發(fā)送一次Config-Request即可完成本端的協(xié)商過(guò)程。由于發(fā)送方?jīng)]有配置IP地址（而是動(dòng)態(tài)獲取IP地址）,所以在IPCP的Config-Request報(bào)文的IP地址配置參數(shù)配置選項(xiàng)中的IP地址填充全。（也即是。.〇?〇.〇）,這樣當(dāng)對(duì)端收到這個(gè)Config-Request報(bào)文時(shí),當(dāng)接收方收到該配置請(qǐng)求報(bào)文后會(huì)迅檢測(cè)!P地址的內(nèi)容,如果發(fā)送為全0,則認(rèn)為對(duì)端的這個(gè)IP地址不是我所希望的值,這樣就回應(yīng)ー個(gè)Config-Nak報(bào)文,并將希望分配給對(duì)方的IP地址填充到Config-Nak報(bào)文內(nèi)。這時(shí)當(dāng)接收方收到Config-Nak報(bào)文后,就會(huì)重新發(fā)送ー個(gè)Config-Request報(bào)文,這個(gè)報(bào)文中的IP地址配置選項(xiàng)為對(duì)方在Nak報(bào)文中所提供的。Sender圖Sender圖3-6動(dòng)態(tài)協(xié)商接收方!P地址的配置過(guò)程與靜態(tài)時(shí)的ー樣,只需發(fā)送ー個(gè)Config-Request報(bào)文即可,當(dāng)收到發(fā)送方的Config-Ack報(bào)文,就表示接收方的IP地址配置完成。例9：假設(shè)!PCP在網(wǎng)絡(luò)層協(xié)議階段開(kāi)始協(xié)商配置參數(shù)選項(xiàng)(這里只舉協(xié)商!P地址的配置參數(shù)選項(xiàng)地的過(guò)程),發(fā)送方?jīng)]有配置IP地址,而接收方配置了!P地址為192.168.0.2,接收方可給發(fā)送方分配IP地址(192.168.0.1),發(fā)送方發(fā)送給接收方的Config-Request報(bào)文內(nèi)容如下:有下劃線(xiàn)的部分表示本端的ip地址。當(dāng)對(duì)端正確接收到了該報(bào)文后,應(yīng)該回應(yīng)ー個(gè)Config-Nak報(bào)文,報(bào)文內(nèi)容如下:.師03當(dāng)接收方收到該報(bào)文后,重新發(fā)送ー個(gè)Config-Request報(bào)文,報(bào)文內(nèi)容如下:IffIff03接收方再次收到發(fā)送方的ー個(gè)Config-Request報(bào)文,此時(shí)將回應(yīng)ー個(gè)Config-Ack報(bào)文,報(bào)文內(nèi)容如下:7E7EFF03請(qǐng)仔細(xì)觀察一下這些報(bào)文在交互過(guò)程中,PPP數(shù)據(jù)幀凈載荷內(nèi)的數(shù)據(jù)報(bào)文的類(lèi)型域和報(bào)文IDo同樣的接收方給發(fā)送方也發(fā)送ー個(gè)Config-Request報(bào)文,報(bào)文內(nèi)容如下:發(fā)送方應(yīng)回送一個(gè)Config-Ack給接收方,報(bào)文內(nèi)容如下:FF03FF03本章節(jié)的ー些內(nèi)容可能沒(méi)有明確寫(xiě)出,只是將IPCP配置參數(shù)選項(xiàng)配置過(guò)程中最關(guān)鍵的部分做了一些說(shuō)明,如果想深入了解決IPCP或IPXCP,可參見(jiàn)相關(guān)的RFC文檔。3.2總結(jié)PPP協(xié)議的狀態(tài)轉(zhuǎn)移圖包括鏈路不可用階段、鏈路建立階段、認(rèn)證階段、網(wǎng)絡(luò)層協(xié)議階段和鏈路終止階段LCP協(xié)議依據(jù)報(bào)文的功能可分為鏈路配置報(bào)文、鏈路終止報(bào)文和鏈路維護(hù)報(bào)文LCP協(xié)議的鏈路配置報(bào)文主要是用來(lái)協(xié)商ー些可選的配置參數(shù)選項(xiàng)LCP協(xié)議的鏈路終止報(bào)文主要是用來(lái)終止一條PPP鏈路LCP協(xié)議的鏈路維護(hù)報(bào)文主要是用來(lái)測(cè)試和調(diào)試PPP鏈路NCP協(xié)議主要負(fù)責(zé)網(wǎng)絡(luò)層配置參數(shù)選項(xiàng)的協(xié)商,它包括〃靜態(tài)協(xié)商〃和〃動(dòng)態(tài)協(xié)商〃3.3思考1、當(dāng)發(fā)送端在鏈路建立階段開(kāi)始時(shí),發(fā)送ー個(gè)Config-Request報(bào)文,那么當(dāng)接收端接收到該數(shù)據(jù)報(bào)文后,什么情況下回應(yīng)Config-Ack報(bào)文,什么情況下回應(yīng)Config-Nak報(bào)文,而什么情況下又回應(yīng)Config-Reject報(bào)文?2、按功能分,Echo-Request報(bào)文和Echo-Reply報(bào)文屬于LCP協(xié)議哪種類(lèi)型報(bào)文,在這種報(bào)文中需要攜帶鏈路配置報(bào)文中協(xié)商何種配置參數(shù)選項(xiàng)?3、IPCP協(xié)議在進(jìn)行網(wǎng)絡(luò)層配置參數(shù)選項(xiàng)協(xié)商時(shí)可能會(huì)遇到哪兩種協(xié)商,當(dāng)只協(xié)商!P地址選項(xiàng)時(shí),請(qǐng)對(duì)比ー下這兩種配置參數(shù)選項(xiàng)的區(qū)別?當(dāng)需要進(jìn)行多種參數(shù)配置參數(shù)選項(xiàng)時(shí)（請(qǐng)回憶一下LCP配置參數(shù)選項(xiàng)協(xié)商的情況）,可能會(huì)出現(xiàn)哪幾種情況 ?第4章LCP的可選配置參數(shù)LCP的參數(shù)配置選項(xiàng)LCP協(xié)議在對(duì)鏈路配置過(guò)程中需要進(jìn)行一些可選配置參數(shù)選項(xiàng)的協(xié)商,我們?cè)谇懊嬷v述的過(guò)程中已列舉了許多配置參數(shù)選項(xiàng),但我們只挑選其中較為重要的幾個(gè)參數(shù)做相應(yīng)的擴(kuò)展說(shuō)明（魔術(shù)字和認(rèn)證協(xié)議選項(xiàng)）。關(guān)于ー些更具體的細(xì)節(jié)和未涉及到的配置參數(shù)選項(xiàng),請(qǐng)參數(shù)PPP的RFC文檔（RFC1661）。魔術(shù)字（Magic-Number）魔術(shù)字是在LCP的Config-Request報(bào)文中被協(xié)商的,并且可被其它ー些其它類(lèi)型的LCP數(shù)據(jù)報(bào)文所使用,如前面已經(jīng)說(shuō)過(guò)的Echo-RequestヽEcho-Reply報(bào)文和Quality-Protoco!報(bào)文等。對(duì)于PPP協(xié)議本身它是不要求協(xié)商魔術(shù)字的,如果在雙方不協(xié)商魔術(shù)字的情況下,某些LCP的數(shù)據(jù)報(bào)文需要使用魔術(shù)字時(shí),那么只能是將魔術(shù)字的內(nèi)容填充為全0:反之,則填充為配置參數(shù)選項(xiàng)協(xié)商后的結(jié)果。魔術(shù)字在目前所有的設(shè)備當(dāng)中都是需要進(jìn)行協(xié)商的,它被放在Config-Request的配置選項(xiàng)參數(shù)中進(jìn)行發(fā)送,而且需要由自身的通信設(shè)備獨(dú)立產(chǎn)生,協(xié)議為了避免雙方可能產(chǎn)生同樣的魔術(shù)字,從而導(dǎo)致通信出現(xiàn)不必要的麻煩,因此要求由設(shè)備采用ー些隨機(jī)方法產(chǎn)生一個(gè)獨(dú)一無(wú)二的魔術(shù)字。一般來(lái)說(shuō)魔術(shù)字的選擇會(huì)采用設(shè)備的系列號(hào)、網(wǎng)絡(luò)硬件地址或時(shí)鐘。雙方產(chǎn)生相同魔術(shù)字的可能性不能說(shuō)是沒(méi)有的,但應(yīng)盡量避免,通常這種情況是發(fā)產(chǎn)在相同廠(chǎng)商的設(shè)備進(jìn)行互連時(shí),因?yàn)橐粋€(gè)廠(chǎng)商所生產(chǎn)的設(shè)備產(chǎn)生魔術(shù)字的方法是ー樣的。我們知道魔術(shù)字產(chǎn)生的作用是用來(lái)幫助檢測(cè)鏈路是否存在環(huán)路,當(dāng)接收端收到ー個(gè)Config-Request報(bào)文時(shí),會(huì)將此報(bào)文與上一次所接收到的Config-Request進(jìn)行比較,如果兩個(gè)報(bào)文中所含的魔術(shù)字不一致的話(huà),表明鏈路不存在環(huán)路。但如果一致的話(huà),接收端認(rèn)為鏈路可能存在環(huán)路,但不ー定存在環(huán)路,還需進(jìn)ー步確認(rèn)。此時(shí)接收端將發(fā)送ー個(gè)Config-Nak報(bào)文,并在該報(bào)文中攜帶ー個(gè)重新產(chǎn)生的魔術(shù)字,而且此時(shí)在未接收到任何Config-Request或Config-Nak報(bào)文之前,接收端也不會(huì)發(fā)送任何的Config-Request報(bào)文。這時(shí)我們假設(shè)可能會(huì)有以下兩種情況發(fā)生:?鏈路實(shí)際不存在環(huán)路,而是由于對(duì)方在產(chǎn)生魔術(shù)字時(shí)與接收端產(chǎn)生的一致,但實(shí)際這種情況出現(xiàn)的概率是很小的。當(dāng)Config-Nak被對(duì)端接收到后,應(yīng)該發(fā)送ー個(gè)Config-Request報(bào)文（此報(bào)文中的魔術(shù)字為Nak報(bào)文中的）,當(dāng)對(duì)端接收到后,與上次比較,由于接收端已經(jīng)在Nak報(bào)文中產(chǎn)生了一個(gè)不同的魔術(shù)字,此時(shí)接收端收到的Config-Request報(bào)文中的魔術(shù)字與上次配置請(qǐng)求報(bào)文中不一樣,所以接收端可斷定鏈路不存在環(huán)路。?鏈路實(shí)際上確實(shí)存在環(huán)路,一段時(shí)間后Config-Nak報(bào)文會(huì)返回到發(fā)送該報(bào)文的同一端。這時(shí)接收端比較這個(gè)Config-Nak報(bào)文與上一次發(fā)出去的ー樣,因此鏈路存在環(huán)路的可能性又增大了。我們知道當(dāng)一端收到了一Config-Nak報(bào)文時(shí),又會(huì)發(fā)送ーVConfig-Request報(bào)文（該報(bào)文中的魔術(shù)字與Config-Nak中的一致）,這樣又回到了最初的狀態(tài),在這條鏈路上就會(huì)不斷的出現(xiàn)Config-Request>Config-Nak報(bào)文,因此這樣周而復(fù)始下去,接收端就會(huì)認(rèn)為PPP鏈路存在環(huán)路的可能性在不斷增加,當(dāng)達(dá)到ー定數(shù)量級(jí)時(shí),就可認(rèn)為此鏈路存在環(huán)路。但在實(shí)際應(yīng)用中根據(jù)不同設(shè)備實(shí)現(xiàn)PPP協(xié)議的方法,我們?cè)阪溌翻h(huán)路檢測(cè)時(shí)可采用兩種方法。第ー種機(jī)制就是如上面所述的,這個(gè)過(guò)程不斷地重復(fù),最終可能會(huì)給LCP狀態(tài)機(jī)發(fā)ー個(gè)Down事件,這時(shí)可能會(huì)使しCP的狀態(tài)機(jī)又回到初始化階段,又開(kāi)始新一輪的協(xié)商。當(dāng)然對(duì)于某些設(shè)備還會(huì)采用第二種機(jī)制,就是不產(chǎn)生任何事件去影響當(dāng)前LCP的狀態(tài)機(jī),而是停留在請(qǐng)求發(fā)送狀態(tài)。但這時(shí)認(rèn)為鏈路有環(huán)路的一端設(shè)備需要不斷的向鏈路上發(fā)送Echo-Request報(bào)文來(lái)檢測(cè)鏈路環(huán)路是否被解除,當(dāng)接收端收到Echo-Reply報(bào)文時(shí),就認(rèn)為鏈路環(huán)路被解除,從而就可能進(jìn)行后續(xù)的PPP的過(guò)程。認(rèn)證協(xié)議PPP協(xié)議也提供了可選的認(rèn)證配置參數(shù)選項(xiàng),缺省情況下點(diǎn)對(duì)點(diǎn)通信的兩端是不進(jìn)行認(rèn)證的。在eCP的Config-Request報(bào)文中不可一次攜帶多種認(rèn)證配置選項(xiàng),必須二者擇其ー(PAP/CHAP),選擇最希望的那ー種,一般是在PPP設(shè)備互連的設(shè)備上進(jìn)行配置的,但一般設(shè)備會(huì)默認(rèn)支持ー個(gè)缺省的認(rèn)證方式(PAP是大部分設(shè)備所默認(rèn)的認(rèn)證方式)。當(dāng)對(duì)端收到該配置請(qǐng)求報(bào)文后,如果支持配置參數(shù)選項(xiàng)中的認(rèn)證方式,則回應(yīng)ー個(gè)Config-Ack報(bào)文;否則回應(yīng)ー個(gè)Config-Nak報(bào)文,并附帶上自希望雙方采用的認(rèn)證方式。當(dāng)對(duì)方接收到Config-Ack報(bào)文后就可以開(kāi)始進(jìn)行認(rèn)證了,而如果收到得是Config-Nak報(bào)文,則根據(jù)自身是否支持Config-Nak報(bào)文中的認(rèn)證方式來(lái)回應(yīng)對(duì)方,如果支持則回應(yīng)ー個(gè)新的Config-Request(并攜帶上Config-Nak報(bào)文中所希望使用的認(rèn)證協(xié)議),否則將回應(yīng)ー個(gè)Config-Reject報(bào)文,那么雙方就無(wú)法通過(guò)認(rèn)證,從而不可能建立起PPP鏈路。PPP支持兩種授權(quán)協(xié)議:PAP(PasswordAuthenticationProtocol)和CHAP(ChallengeHandAuthenticationProtocol)〇4.1.2.1PAP認(rèn)證我們所知兩個(gè)設(shè)備在使用PAP進(jìn)行認(rèn)證之前,應(yīng)該確認(rèn)那一方是驗(yàn)證方,那一方是被驗(yàn)證方。實(shí)際上對(duì)于使用PPP協(xié)議互連的兩端來(lái)說(shuō),既可作為認(rèn)證方,也可作為被認(rèn)證方。但通常情況下,PAP只使用一個(gè)方向上的認(rèn)證。一般在兩端設(shè)備使用PAP協(xié)議之前,均會(huì)設(shè)備上進(jìn)行一些相應(yīng)的配置,對(duì)于寬帶工程師而言MA5200可謂是大家最熟悉的產(chǎn)品了,它默認(rèn)就作為驗(yàn)證方,但可通過(guò)使用命令PAPAuthenticationPAP/CHAP來(lái)更改認(rèn)證方式,而對(duì)于被驗(yàn)證方而言只需設(shè)置用戶(hù)名和密碼即可。PAP認(rèn)證是兩次握手,在鏈路建立階段,依據(jù)設(shè)備上的配置情況,如果是使用PAP認(rèn)證,則驗(yàn)證方在發(fā)送Config-Request報(bào)文時(shí)會(huì)攜帶認(rèn)證配置參數(shù)選項(xiàng),而對(duì)于被驗(yàn)證方而言則是不需要,它只需要收到該配置請(qǐng)求報(bào)文后根據(jù)自身的情況給對(duì)端返回相應(yīng)的報(bào)文。如果點(diǎn)對(duì)點(diǎn)的兩端設(shè)備采用的是PAP雙向認(rèn)證時(shí),也即是它同時(shí)也作為驗(yàn)證方,則此時(shí)需要在配置請(qǐng)求報(bào)文中攜帶認(rèn)證配置參數(shù)選項(xiàng)。因此,我們可以總結(jié)一下,如果對(duì)于點(diǎn)對(duì)點(diǎn)的兩個(gè)設(shè)備在PPP鏈路建立的過(guò)程中使用的認(rèn)證方式為PAP的話(huà),那么驗(yàn)證方在其Config-Request報(bào)文中必須含有認(rèn)證配置參數(shù)選項(xiàng),且該認(rèn)證配置參數(shù)選項(xiàng)的數(shù)據(jù)域?yàn)?xC023,下圖為PAP認(rèn)證的過(guò)程:用戶(hù)名ノ密碼被瞼證方 >驗(yàn)證方RouterA ppp封裝 RouterB< 圖4-1PAPiA證過(guò)程當(dāng)通信設(shè)備的兩端在收到對(duì)方返回的Config-Ack報(bào)文時(shí),就從各自的鏈路建立階段進(jìn)入到認(rèn)證階段,那么作為被驗(yàn)證方此時(shí)需要向驗(yàn)證方發(fā)送PAP認(rèn)證的請(qǐng)求報(bào)文,該請(qǐng)求報(bào)文攜帶了用戶(hù)名和密碼,當(dāng)驗(yàn)證方收到該認(rèn)證請(qǐng)求報(bào)文后,則會(huì)根據(jù)報(bào)文中的實(shí)際內(nèi)容查找本地的數(shù)據(jù)庫(kù),如果該數(shù)據(jù)庫(kù)中有與用戶(hù)名和密碼一致的選項(xiàng)時(shí),則回向?qū)Ψ椒祷丞`個(gè)認(rèn)證請(qǐng)求響應(yīng),告訴對(duì)方認(rèn)證已通過(guò)。反之,如果用戶(hù)名與密碼不符,則向?qū)Ψ椒祷仳?yàn)證不通過(guò)的響應(yīng)報(bào)文。如果雙方都配置為驗(yàn)證方,則需要雙方的兩個(gè)單向驗(yàn)證過(guò)程都完成后,方可進(jìn)入到網(wǎng)絡(luò)

層協(xié)議階段,否則在一定次的認(rèn)證失敗后,則會(huì)從當(dāng)前狀態(tài)返回鏈路不可用狀態(tài)。例1。:如圖4-1所示,當(dāng)路由器A（被驗(yàn)證方）收到了路由器B的Config-Ack報(bào)文后,因?yàn)槭鞘褂肞AP認(rèn)證,所以作為被驗(yàn)證方的路由器A應(yīng)主動(dòng)向驗(yàn)證方（路由器B）發(fā)送認(rèn)證請(qǐng)求報(bào)文（PAPAuthenticate）,用戶(hù)名和密碼均為!63?報(bào)文的內(nèi)容如下:FF03FF03下劃線(xiàn)的前四個(gè)字節(jié)是用戶(hù)名,后四個(gè)字節(jié)是密碼。當(dāng)路由器B收到了該報(bào)文后,會(huì)向路由器A回應(yīng)一個(gè)PAPAuthenticateAck報(bào)文,報(bào)文內(nèi)容如下:小?№?11此時(shí)所回應(yīng)的報(bào)文中,并未攜帶任何數(shù)據(jù),如果是認(rèn)證不通過(guò),則會(huì)在返回的報(bào)文中指是因何原因無(wú)法認(rèn)證通過(guò),可能是無(wú)此用戶(hù)名或密碼不匹配。4.1.2.2CHAP認(rèn)證與PAP認(rèn)證比起來(lái),CHAP認(rèn)證更具有安全性,從前面認(rèn)證過(guò)程的數(shù)據(jù)包交換過(guò)程中不然發(fā)現(xiàn),采用PAP認(rèn)證時(shí),被驗(yàn)證是采用明文的方式直接將用戶(hù)名和密碼發(fā)送給驗(yàn)證方的,而對(duì)于PAP認(rèn)證則不ー樣。CHAP為三次握手協(xié)議,它只在網(wǎng)絡(luò)上傳送用戶(hù)名而不傳送口令,因此安全性比PAP高。在驗(yàn)證ー開(kāi)始,不像PAPー樣是由被驗(yàn)證方發(fā)送認(rèn)證請(qǐng)求報(bào)文了,而是由驗(yàn)證方向被驗(yàn)證方發(fā)送一段隨機(jī)的報(bào)文,并加上自己的主機(jī)名,我們通稱(chēng)這個(gè)過(guò)程叫做挑戰(zhàn)。當(dāng)被驗(yàn)證方收到驗(yàn)證方的驗(yàn)證請(qǐng)求,從中提取出驗(yàn)證方所發(fā)送過(guò)來(lái)的主機(jī)名,然后根據(jù)該主機(jī)名在被驗(yàn)證方設(shè)備的后臺(tái)數(shù)據(jù)庫(kù)中去查找相同的用戶(hù)名的記錄,當(dāng)查找到后就使用該用戶(hù)名所對(duì)應(yīng)的密鑰,然后根據(jù)這個(gè)密鑰、報(bào)文ID和驗(yàn)證方發(fā)送的隨機(jī)報(bào)文用Md5加密算法生成應(yīng)答,隨后將應(yīng)答和自己的主機(jī)名送回,同樣驗(yàn)證方收到被驗(yàn)證方發(fā)送回應(yīng)后,提取被驗(yàn)證方的用戶(hù)名,然后去查找本地的數(shù)據(jù)庫(kù),當(dāng)找到與被驗(yàn)證方一致用戶(hù)名后,根據(jù)該用戶(hù)名所對(duì)應(yīng)的密鑰、保留報(bào)文!D和隨機(jī)報(bào)文用Md5加密算法生成結(jié)果,和剛剛被驗(yàn)證方所返回的應(yīng)答進(jìn)行比較,相同則返回Ack,否則返回Nak,下圖為CHAP的認(rèn)證過(guò)程:例11:如圖4-2所示,當(dāng)路由器A（被驗(yàn)證方）收到了路由器B的Challenge報(bào)文后,報(bào)文內(nèi)容如下:下劃線(xiàn)的前16個(gè)字節(jié)是驗(yàn)證方隨機(jī)產(chǎn)生的一段報(bào)文,后7個(gè)字節(jié)是驗(yàn)證方的主機(jī)名（MA5200A）,而且單個(gè)字節(jié)10表示隨機(jī)報(bào)文的長(zhǎng)度。而此時(shí)路由器A會(huì)根據(jù)用戶(hù)名所對(duì)應(yīng)的密鑰使用報(bào)文的ID和該報(bào)文的內(nèi)容生成一個(gè)回應(yīng)報(bào)文,報(bào)文內(nèi)容如下:被瞼證方 主機(jī)名，應(yīng)答 驗(yàn)證方RouterA ppp封裝 RouterB接收，拒絕圖4-2CHAP認(rèn)證過(guò)程我們將這個(gè)回應(yīng)報(bào)文與驗(yàn)證方發(fā)送的挑戰(zhàn)報(bào)文進(jìn)行比較,報(bào)文的代碼域已由原01改為02,總報(bào)文的長(zhǎng)度有變化,主要后而一個(gè)下劃線(xiàn)的內(nèi)容是被驗(yàn)證方的主機(jī)名(ppkiss@hua),而且此時(shí)回應(yīng)的16個(gè)字節(jié)的報(bào)文已經(jīng)是經(jīng)過(guò)MD5算法加密過(guò)的。當(dāng)驗(yàn)證方收到了這個(gè)回應(yīng)報(bào)文后,會(huì)根據(jù)報(bào)文中被驗(yàn)證方的主機(jī)名(ppkiss@hua)在本地的數(shù)據(jù)庫(kù)中去查找密鑰,然后再對(duì)原發(fā)先發(fā)送的那段挑戰(zhàn)報(bào)文進(jìn)行MD5的算法加密,如果所得的結(jié)果與對(duì)方剛發(fā)過(guò)來(lái)的16個(gè)字節(jié)的加密值ー樣的話(huà),則就會(huì)發(fā)送ー個(gè)報(bào)文通知被驗(yàn)證方,你的認(rèn)證已經(jīng)通過(guò),我們可以進(jìn)入到下ー個(gè)階段了。在實(shí)際應(yīng)用當(dāng)中,我們很多都是使用PC機(jī)來(lái)進(jìn)行撥號(hào)這個(gè)過(guò)程,實(shí)際中當(dāng)驗(yàn)證方發(fā)送挑戰(zhàn)后,PC機(jī)只接收而并不去查本地?cái)?shù)據(jù)庫(kù),而直接使用在撥號(hào)對(duì)話(huà)框中所輸入的密碼和報(bào)文的ID及報(bào)報(bào)文的內(nèi)容進(jìn)行MD5算法加密（這個(gè)在PC機(jī)采用PPPOE軟件撥入到MA5200時(shí)就是這樣的）。下面來(lái)看一下驗(yàn)證通過(guò)時(shí),驗(yàn)證方給被驗(yàn)證方所發(fā)送的一段報(bào)文內(nèi)容:此時(shí)所回應(yīng)的報(bào)文的代碼域?yàn)?3,且報(bào)文的實(shí)際內(nèi)容是,WelcomtoMA5200Ao4.1.3MRU（MaxiumReceiveUnit）這個(gè)配置參數(shù)選項(xiàng)主要是Config-Request報(bào)文的發(fā)送端告訴接收端,本端接收到的PPP數(shù)據(jù)幀的數(shù)據(jù)域的最大值。通常情況下這個(gè)參數(shù)選項(xiàng)使用默認(rèn)值（1500字節(jié)）,因此在Config-Request報(bào)文中雙方都不會(huì)攜帶這個(gè)配置參數(shù)選項(xiàng)。當(dāng)在某些特殊應(yīng)用中,可能會(huì)使用到小于1500字節(jié)或大于1500字節(jié)的情況,這時(shí)在Config-Request報(bào)文就會(huì)攜帶要協(xié)商的MRU配置參數(shù)選項(xiàng)值。4.2總結(jié)魔術(shù)字可以在鏈路配置階段被協(xié)商,數(shù)據(jù)報(bào)文可借助魔術(shù)字來(lái)檢PP?鏈路是否存在環(huán)路PAP（密碼認(rèn)證協(xié)議）認(rèn)證是二次握手,它是直接在網(wǎng)絡(luò)上傳送明文的用戶(hù)名和密碼,因此這種協(xié)議安全性不高CHAP（挑戰(zhàn)性握手認(rèn)證協(xié)議）認(rèn)證是三次握手,它只在網(wǎng)絡(luò)上傳送驗(yàn)證方和被驗(yàn)證方的主機(jī)名,而并不傳送密碼,因此相比之處CHAP比PAP更安全PPP協(xié)議缺省的MRU是!500,而對(duì)于通信的雙方可根據(jù)實(shí)際需要對(duì)MRU進(jìn)行協(xié)商4.3思考1、PPP協(xié)議可通過(guò)幾種方式來(lái)檢測(cè)PPP鏈路是否存在環(huán)路?2、請(qǐng)比較PAP認(rèn)證和CHAP認(rèn)證?第5章PPP擴(kuò)展協(xié)議PPP擴(kuò)展協(xié)議概述MP出現(xiàn)的背景我們知道ISDN可以在兩個(gè)系統(tǒng)之間提供2B+D和30B+D多通道捆綁能務(wù),從而為用戶(hù)能夠提供更多可用的帶寬。諸如上述的許多鏈路捆綁功能需要軟件和硬件的協(xié)同工作,而且更多的基于硬件來(lái)實(shí)現(xiàn)的。然而我們是否考慮過(guò)僅僅通過(guò)軟件的實(shí)現(xiàn)來(lái)完成鏈路捆綁的功能,同時(shí)還考慮到很多實(shí)際鏈路的情況,對(duì)于軟件在實(shí)現(xiàn)過(guò)程中還要能對(duì)不同速率的鏈路進(jìn)行捆綁。我們可以通過(guò)在發(fā)送數(shù)據(jù)之前增加ー定數(shù)據(jù)的字節(jié)頭,其中含有為重組數(shù)據(jù)而所需的ー些字段。隨著PPP的廣泛應(yīng)用,MP作為PPP功能擴(kuò)展協(xié)議應(yīng)運(yùn)而生。它可為用戶(hù)提供更大的帶寬,實(shí)現(xiàn)數(shù)據(jù)的快速轉(zhuǎn)發(fā)。同時(shí),還可實(shí)現(xiàn)對(duì)鏈路資源進(jìn)行動(dòng)態(tài)分配,有效的利用寶貴的資源。但隨著網(wǎng)絡(luò)技術(shù)的發(fā)展,網(wǎng)絡(luò)的帶寬已不再是瓶頸,所以對(duì)于使用PPP擴(kuò)展協(xié)議已沒(méi)有實(shí)際意義,只在本章中簡(jiǎn)單做一下介紹,如果想進(jìn)ー步了解該協(xié)議,可參考相應(yīng)的RFC1717或提供的參考書(shū)目。MP(MultilinkProtocol)協(xié)議MP的協(xié)商較為特殊。MP配置參數(shù)選項(xiàng)的協(xié)商是在LCP協(xié)商過(guò)程中完成的,協(xié)商MP配置參數(shù)選項(xiàng)的目的完成以下幾個(gè)過(guò)程:?表明系統(tǒng)是否支持將多個(gè)物理鏈路捆綁成一個(gè)邏輯鏈路?系統(tǒng)在多鏈路上接收到了對(duì)端發(fā)送的數(shù)據(jù)單元后,能夠通過(guò)附加在這些數(shù)據(jù)之前的重組字段對(duì)這些分段的數(shù)據(jù)單元進(jìn)行重組.邏輯鏈路為了能夠提高傳輸?shù)男?可以不使用單ーPPP物理鏈路上的最大接收單元,可以重新協(xié)商新的邏輯鏈路上使用的最大接收單元進(jìn)行數(shù)據(jù)報(bào)文的發(fā)送和接收。MP協(xié)議可以用來(lái)靈活的調(diào)整點(diǎn)對(duì)點(diǎn)系統(tǒng)之間的多條獨(dú)立物理鏈路,它可為整個(gè)系統(tǒng)提供一個(gè)虛擬鏈路,虛擬鏈路的帶寬是N個(gè)鏈路的捆綁之和(N21)〇而對(duì)于被捆綁的鏈路并未做出特殊要求,可以將同步鏈路和異步鏈路進(jìn)行捆綁,同樣也可將低速鏈路和高速鏈路進(jìn)行捆綁。使用該協(xié)商可將多個(gè)PPP的鏈路捆綁成一條使用,而決定不同通道是否需進(jìn)行多鏈路捆綁有兩個(gè)條件:只有兩個(gè)鏈路的Discriminator和驗(yàn)證方式、用戶(hù)完全相符時(shí),才能對(duì)兩個(gè)鏈路進(jìn)行捆綁。這就意味著只有當(dāng)驗(yàn)證完成后,才能真正完成MP的協(xié)商過(guò)程。MP不會(huì)導(dǎo)致鏈路的拆除。如果配置了MP,兩個(gè)鏈路不符合MP條件,則會(huì)建立一條新的MP通道,這同時(shí)也表明允許MP為單鏈路。MP的捆綁是完全依照用戶(hù)進(jìn)行的,只有相同用戶(hù)才能進(jìn)行捆綁。如一端配置了MP,另ー端不支持或未配MP,則建立起來(lái)的鏈路為非MP鏈路?？偨Y(jié)?MP協(xié)議屬于PPP協(xié)議的擴(kuò)展協(xié)議?MP協(xié)議可依據(jù)終端指示符和驗(yàn)證方式對(duì)不同的物理鏈路進(jìn)行捆綁5.3思考如下圖所示,設(shè)備1與設(shè)備2通過(guò)兩條物理鏈路互連（使用鏈路1和鏈路2）,而設(shè)備1與設(shè)備3也通過(guò)兩條物理鏈路互連（使用鏈路3和鏈路4）,我們知道設(shè)備鏈路的捆綁是依據(jù)終端指示符和驗(yàn)證方式的組合進(jìn)行的,試想一下使用這兩項(xiàng)的4種組合設(shè)備1在進(jìn)行鏈路捆綁中會(huì)出現(xiàn)哪些情況。第6章PPP的狀態(tài)機(jī)6.1PPP擴(kuò)展協(xié)議概述由于PPP的狀態(tài)機(jī),對(duì)于我們實(shí)際使用當(dāng)中沒(méi)有太大的意義,如果想進(jìn)ー步深入了解PPP協(xié)議的話(huà),請(qǐng)參見(jiàn)PPP的RFC文檔。資料編碼產(chǎn)品名稱(chēng)使用對(duì)象用服工程師產(chǎn)品版本編寫(xiě)部門(mén)交換接入產(chǎn)品技術(shù)支援管理部資料版本

PPP0E專(zhuān)題擬制周ー帆日期：2002-01-05審核:日期:審核:日期:批準(zhǔn)：日期：華為技術(shù)有限公司

版權(quán)所有侵權(quán)必究修訂記錄日期修訂版本描述作者2002/01/05vl.0周ー帆

目錄(TOCHeading)TOC\o"1-5"\h\z第1章概述 571.1PPP0E協(xié)議的基本概念 571.1.1 PPP0E協(xié)議出現(xiàn)的背景 571.1.2 PPP0E協(xié)議簡(jiǎn)介 582總結(jié) 601.3思考 60第2章PPP0E的發(fā)現(xiàn)階段 611PPP0E的初始化過(guò)程 612.1.1以太網(wǎng)的幀格式 612.1.2PPP0E的數(shù)據(jù)報(bào)文格式 632.1.3PPP0E發(fā)現(xiàn)階段的數(shù)據(jù)報(bào)文 652.1.3.1 PPP0E數(shù)據(jù)報(bào)文中Tag(標(biāo)記)的格式672.1.3.2PADI(PPPOEActiveDiscoveryInitiation)報(bào)文 692.1.3.3PADO(PPPOEActiveDiscoveryOffer)報(bào)文712.1.3.4PADR(PPPOE ActiveDiscoveryRequest)報(bào)文 72TOC\o"1-5"\h\z2.1.3.5PADS(PPPOEActiveDiscoverySession-confirmation)報(bào)文 731.3.6PADT(PPPOE ActiveDiscoveryTerminate)報(bào)742總結(jié) 753思考 76第3章PPPOE的會(huì)話(huà)階段 771PPPOE的會(huì)話(huà)過(guò)程 772總結(jié) 783思考 78第1章概述PPP0E協(xié)議的基本概念PPP0E協(xié)議出現(xiàn)的背景隨著寬帶網(wǎng)絡(luò)技術(shù)的不斷發(fā)展,以xDSL、Cab1eModem和以太網(wǎng)為主的幾種主流寬帶接入技術(shù)的應(yīng)用已開(kāi)展的如火如荼。同時(shí)又給各大網(wǎng)絡(luò)運(yùn)營(yíng)商們帶來(lái)了種種困惑,無(wú)論使用哪種接入技術(shù),對(duì)于他們而言可盼和可求的是如何有效的管理用戶(hù),如何從網(wǎng)絡(luò)的投資中收取回報(bào),因此對(duì)于各種寬帶接入技術(shù)的收費(fèi)的問(wèn)題就變得更加敏感。在傳統(tǒng)的以太網(wǎng)模型中,我們是不存在所謂的用戶(hù)計(jì)費(fèi)的概念,要么用戶(hù)能設(shè)置/獲取IP地址上網(wǎng),要么用戶(hù)就無(wú)法上網(wǎng)。IETF的工程師們?cè)诒姓瓗芴?hào)上網(wǎng)的運(yùn)營(yíng)思路(使用NAS設(shè)備終結(jié)用戶(hù)的PPP數(shù)據(jù)包),制定出了在以太網(wǎng)上傳送PPP數(shù)據(jù)包的協(xié)議(PointToPointProtocolOverEthernet),這個(gè)協(xié)議出臺(tái)后,各網(wǎng)絡(luò)設(shè)備制造商也相繼推出自已品牌的寬帶接入服務(wù)器（BAS）,它不僅能支持PPP0E協(xié)議數(shù)據(jù)報(bào)文的終結(jié),而且還能支持其它許多協(xié)議。如華為公司的MA5200（小BAS）和ISN8850（大BAS）〇PPPOE協(xié)議簡(jiǎn)介PPPOE協(xié)議提供了在廣播式的網(wǎng)絡(luò)（如以太網(wǎng)）中多臺(tái)主機(jī)連接到遠(yuǎn)端的訪(fǎng)問(wèn)集中器（我們對(duì)目前能完成上述功能的設(shè)備為寬帶接入服務(wù)器）上的ー種標(biāo)準(zhǔn)。在這種網(wǎng)絡(luò)模型中,我們不難看出所有用戶(hù)的主機(jī)都需要能獨(dú)立的初始化自已的PPP協(xié)議棧,而且通過(guò)PPP協(xié)議本身所具有的一些特點(diǎn),能實(shí)現(xiàn)在廣播式網(wǎng)絡(luò)上對(duì)用戶(hù)進(jìn)行計(jì)費(fèi)和管理。為了能在廣播式的網(wǎng)絡(luò)上建立、維持各主機(jī)與訪(fǎng)問(wèn)集中器之間點(diǎn)對(duì)點(diǎn)的關(guān)系,那么就需要每個(gè)主機(jī)與訪(fǎng)問(wèn)集中器之間能建立唯一的點(diǎn)到點(diǎn)的會(huì)話(huà)。PPPOE協(xié)議共包括兩個(gè)階段,即PPPOE的發(fā)現(xiàn)階段（PPPOEDiscoveryStage）和PPPOE的會(huì)話(huà)階段（PPPOESessionStage）〇在這篇培訓(xùn)教材中更注重是PPPOE發(fā)現(xiàn)階段的介紹,因?yàn)閷?duì)于PPPOE的會(huì)話(huà)階段,可以看成和PPP的會(huì)話(huà)過(guò)程是ー樣的（可直接參照PPP協(xié)議培訓(xùn)教材）,而兩者的主要區(qū)別在于只是在PPP的數(shù)據(jù)報(bào)文前封裝了PPP0E的報(bào)文頭。無(wú)論是哪ー個(gè)階段的數(shù)據(jù)報(bào)文最終會(huì)被封裝成以太網(wǎng)的幀進(jìn)行傳送。當(dāng)一個(gè)主機(jī)希望能夠開(kāi)始ー個(gè)PPP0E會(huì)話(huà)時(shí),它首先會(huì)在廣播式的網(wǎng)絡(luò)（協(xié)議中是這樣說(shuō)的,但在實(shí)際應(yīng)用中,可能還要跨躍多點(diǎn)訪(fǎng)問(wèn)的網(wǎng)絡(luò),如ATM等,從而就形成了PPP0E0A的數(shù)據(jù)包）上尋找ー個(gè)訪(fǎng)問(wèn)集中器,當(dāng)然可能網(wǎng)絡(luò)上會(huì)存在多個(gè)訪(fǎng)問(wèn)集中器時(shí),對(duì)于主機(jī)而言則會(huì)根據(jù)各訪(fǎng)問(wèn)集中器（AC,AccessConcentration）所能提供的服務(wù)或用戶(hù)的預(yù)先的ー些配置來(lái)進(jìn)行相應(yīng)的選擇。當(dāng)主機(jī)選擇完了所需要的訪(fǎng)問(wèn)集中器后,就開(kāi)始和訪(fǎng)問(wèn)集中器建立一個(gè)PPP0E會(huì)話(huà)進(jìn)程。在這個(gè)過(guò)程中訪(fǎng)問(wèn)集中器會(huì)為每ー個(gè)PPPOE會(huì)話(huà)分配ー個(gè)唯一的進(jìn)程ID,會(huì)話(huà)建立起來(lái)后就開(kāi)始了PPPOE的會(huì)話(huà)階段,在這個(gè)階段中已建立好點(diǎn)對(duì)點(diǎn)連接的雙方（這種點(diǎn)對(duì)點(diǎn)的結(jié)構(gòu)與PPP不一樣,它是一種邏輯上的點(diǎn)對(duì)點(diǎn)關(guān)系）就采用PPP協(xié)議來(lái)交換數(shù)據(jù)報(bào)文,從而完成一系列PPP的過(guò)程,最終將在這點(diǎn)對(duì)點(diǎn)的邏輯通道上進(jìn)行網(wǎng)絡(luò)層數(shù)據(jù)報(bào)的傳送?？偨Y(jié)?PPP0E協(xié)議包括PPP0E的發(fā)現(xiàn)階段和PPP0E的會(huì)話(huà)階段?大多數(shù)的BAS（寬帶接入服務(wù)器）都支持PPP0E協(xié)議1.3思考1、PPP0E的客戶(hù)端是依據(jù)什么條件來(lái)選項(xiàng)訪(fǎng)問(wèn)集中器的?第2章PPPOE的發(fā)現(xiàn)階段PPPOE的初始化過(guò)程PPPOE的初始化過(guò)程是至關(guān)重要的,它不僅要在廣播式的網(wǎng)絡(luò)上確定一對(duì)一的邏輯關(guān)系,而且還要為PPPOE的會(huì)話(huà)階段準(zhǔn)備ー些必要條件,如訪(fǎng)問(wèn)集中器唯一分配的會(huì)話(huà)!D(SessionID)〇在介紹PPPOE的發(fā)現(xiàn)階段之前,首先讓我們重溫一下以太網(wǎng)幀的封裝格式,前面也介紹過(guò)了,所有的PPPOE的數(shù)據(jù)報(bào)文均是被封裝在以太網(wǎng)的數(shù)據(jù)域(凈載荷區(qū))中傳送的。以太網(wǎng)的幀格式以太網(wǎng)的幀格式對(duì)于大多數(shù)人來(lái)說(shuō)是并不陌生,而且目前大多數(shù)的網(wǎng)絡(luò)中都在使用以太網(wǎng)2.。版,因此EthernetH就被作為ー種事實(shí)上的工業(yè)標(biāo)準(zhǔn)而廣泛使用,如果對(duì)以太網(wǎng)不太熟悉或想深入了解的讀者,可參考相關(guān)局域網(wǎng)技術(shù)方面的書(shū)籍。下圖為以太網(wǎng)的幀格式:以太網(wǎng)目的地址（目的MAC地址）和以太網(wǎng)源地址（源MAC地址）,是我們大家最為熟悉的數(shù)據(jù)鏈路層地址。它包括單播地址、多播地址和廣播地址,而對(duì)于PPPOE協(xié)議中要使用到單播地址和廣播地址。在PPP的培訓(xùn)教材中也提到了,對(duì)于PPP這樣的數(shù)據(jù)鏈路層協(xié)議而言,二層地址通信雙方之間已失去了原有的意義。以太網(wǎng)的類(lèi)型域也是我們最關(guān)心的一個(gè)字段,它在199?年以前還一直由施樂(lè)公司維護(hù),但后來(lái)就交由IEEE802小組維護(hù)了。通過(guò)這個(gè)字段的內(nèi)容,數(shù)據(jù)包的接收方可以識(shí)別以太網(wǎng)的數(shù)據(jù)域中承載的是什么協(xié)議的數(shù)據(jù)報(bào)文。對(duì)于PPPOE的兩大階段,也正是通過(guò)以太網(wǎng)的類(lèi)型域進(jìn)行區(qū)分的。在PPPOE的發(fā)現(xiàn)階段時(shí),以太網(wǎng)的類(lèi)型域填充0x8863;而在PPPOE的會(huì)話(huà)階段時(shí),以太網(wǎng)的類(lèi)型域填充為0x8864。數(shù)據(jù)域（凈載荷）主要是用來(lái)承載類(lèi)型域中所指示的數(shù)據(jù)報(bào)文,在PPPOE協(xié)議中所有的PPPOE數(shù)據(jù)報(bào)文就是被封裝在這個(gè)域中被傳送。校驗(yàn)域,主要用來(lái)保證鏈路層數(shù)據(jù)幀傳送的正確性。PPPOE的數(shù)據(jù)報(bào)文格式描述完了以太網(wǎng)的幀格式后,我們簡(jiǎn)要介紹一下PPPOE的數(shù)據(jù)報(bào)文格式。PPPOE的數(shù)據(jù)報(bào)文是被封裝在以太網(wǎng)幀的數(shù)據(jù)域內(nèi)的。簡(jiǎn)單來(lái)說(shuō)我們可能把PPPOE報(bào)文分成兩大塊,（雖然這樣比較籠統(tǒng),但還是比較好助于理解）,一大塊是PPPOE的數(shù)據(jù)報(bào)頭,另ー塊則是PPPOE的凈載荷（數(shù)據(jù)域）,對(duì)于PPPOE報(bào)文數(shù)據(jù)域中的內(nèi)容會(huì)隨著會(huì)話(huà)過(guò)程的進(jìn)行而不斷改變。下圖為PPPOE的報(bào)文的格式:01234567890123456789012345678901版本類(lèi)型代碼 金話(huà)ID長(zhǎng)度域 浄我荷圖2-2PPPOE數(shù)據(jù)報(bào)文的格式?PPPOE數(shù)據(jù)報(bào)文最開(kāi)始的4位為版本域,協(xié)議中

給出了明確的