《GPRS工作原理以及其通信協(xié)議.doc》由會(huì)員分享，可在線閱讀，更多相關(guān)《GPRS工作原理以及其通信協(xié)議.doc（47頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

關(guān)于GPRS通信協(xié)議 簡(jiǎn)介：首先介紹了GPRS的工作原理和工作特點(diǎn)，然后介紹GPRS的協(xié)議模型和應(yīng)用范圍，接著介紹了GPRS在傳輸中所需要用的3種協(xié)議，最后介紹了一種基于單片機(jī)的GPRS的無(wú)線數(shù)據(jù)傳送系統(tǒng) GPRS的工作原理簡(jiǎn)介 GPRS工作時(shí)，是通過(guò)路由管理來(lái)進(jìn)行尋址和建立數(shù)據(jù)連接的，而GPRS的路由管理表現(xiàn)在以下3個(gè)方面：移動(dòng)終端發(fā)送數(shù)據(jù)的路由建立；移動(dòng)終端接收數(shù)據(jù)的路由建立；以及移動(dòng)終端處于漫游時(shí)數(shù)據(jù)路由的建立。 對(duì)于第一種情況，當(dāng)移動(dòng)終端產(chǎn)生了一個(gè)PDU（分組數(shù)據(jù)單元），這個(gè)PDU經(jīng)過(guò)SNDC層處理，稱為SNDC數(shù)據(jù)單元。然后經(jīng)過(guò)LLC層處理為L(zhǎng)LC幀，通過(guò)空中接口（空中接口（Air Interface）是指用戶終端（UT）和無(wú)線接入網(wǎng)絡(luò)（RAN）之間的接口）送到GSM網(wǎng)絡(luò)中移動(dòng)終端所處的SGSN。SGSN把數(shù)據(jù)送到GGSN。GGSN把收到的消息進(jìn)行解裝處理，轉(zhuǎn)換為可在公用數(shù)據(jù)網(wǎng)中傳送的格式（如PSPDN的PDU），最終送給公用數(shù)據(jù)網(wǎng)的用戶。為了提高傳輸效率，并保證數(shù)據(jù)傳輸?shù)陌踩梢詫?duì)空中接口上的數(shù)據(jù)做壓縮和加密處理。 在第二種情況中，一個(gè)公用數(shù)據(jù)網(wǎng)用戶傳送數(shù)據(jù)到移動(dòng)終端時(shí)，首先通過(guò)數(shù)據(jù)網(wǎng)的標(biāo)準(zhǔn)協(xié)議建立數(shù)據(jù)網(wǎng)和GGSN之間的路由。數(shù)據(jù)網(wǎng)用戶發(fā)出的數(shù)據(jù)單元（如PSPDN中的PDU），通過(guò)建立好的路由把數(shù)據(jù)單元PDU送給GGSN。而GGSN再把PDU送給移動(dòng)終端所在的SGSN上，GSN把PDU封裝成SNDC數(shù)據(jù)單元，再經(jīng)過(guò)LLC層處理為L(zhǎng)LC幀單元，最終通過(guò)空中接口送給移動(dòng)終端。 第三種情況是一個(gè)數(shù)據(jù)網(wǎng)用戶傳送數(shù)據(jù)給一個(gè)正在漫游的移動(dòng)用戶。這種情況下的數(shù)據(jù)傳送必須要經(jīng)過(guò)歸屬地的GGSN，然后送到移動(dòng)用戶A。 GPRS的英文全稱是：“General Packet Radio Service”（譯作“通用分組無(wú)線服務(wù)”），它是利用“包交換”（Packet－Switched）的概念發(fā)展起來(lái)的一套無(wú)線傳輸方式。所謂“包交換 ”就是將Data封裝成許多獨(dú)立的封包，再將這些封包一一傳送出去，形式上有點(diǎn)類似郵局中的寄包裹。其作用在于只有當(dāng)有資料需要傳送時(shí)才會(huì)占用頻寬，而且可以以傳輸?shù)馁Y料量計(jì)價(jià)，這對(duì)廣大用戶來(lái)說(shuō)是較合理的計(jì)費(fèi)方式，因?yàn)橄馡nternet這類的數(shù)據(jù)傳輸大多數(shù)的時(shí)間頻寬是閑置的。 GPRS網(wǎng)絡(luò)是基于現(xiàn)有的GSM網(wǎng)絡(luò)來(lái)實(shí)現(xiàn)的。在現(xiàn)有的GSM網(wǎng)絡(luò)中需增加一些節(jié)點(diǎn)，如GGSN（Gateway GPRS Supporting Node，GPRS網(wǎng)關(guān)支持節(jié)點(diǎn)）和SGSN（ Serving GSN，GPRS服務(wù)支持節(jié)點(diǎn)），GSN是GPRS網(wǎng)絡(luò)中最重要的網(wǎng)絡(luò)節(jié)點(diǎn)。GSN具有移動(dòng)路由管理功能，它可以連接各種類型的數(shù)據(jù)網(wǎng)絡(luò)，并可以連到 GPRS寄存器。GSN可以完成移動(dòng)終端（即手機(jī)）和各種數(shù)據(jù)網(wǎng)絡(luò)之間的數(shù)據(jù)傳送和格式轉(zhuǎn)換。GSN可以是一種類似于路由器的獨(dú)立設(shè)備，也可以與GSM中的MSC（Mobile Switching Center，移動(dòng)交換中心，將本網(wǎng)和其它網(wǎng)絡(luò)連接起來(lái)）集成在一起。GSN有兩種類型：一種為SGSN（ Serving GSN，服務(wù)GSN），另一種為GGSN（Gateway GSN，網(wǎng)關(guān)GSN），SGSN的主要作用是記錄移動(dòng)終端的當(dāng)前位置信息，并且在移動(dòng)終端和GGSN之間完成移動(dòng)分組數(shù)據(jù)的發(fā)送和接收。GGSN主要是起網(wǎng)關(guān)作用，它可以和多種不同的數(shù)據(jù)網(wǎng)絡(luò)連接，如ISDN（綜合業(yè)務(wù)數(shù)字網(wǎng)）、PSPDN(分組交換公用數(shù)據(jù)網(wǎng))和LAN（局域網(wǎng)）等。國(guó)外有些資料甚至將GGSN稱為GPRS路由器。GGSN可以把GSM網(wǎng)中的GPRS 分組數(shù)據(jù)包進(jìn)行協(xié)議轉(zhuǎn)換，從而可以把這些分組數(shù)據(jù)包傳送到遠(yuǎn)端的TCP／IP或X.25網(wǎng)絡(luò)。 　 GPRS網(wǎng)不但具有覆蓋范圍廣、數(shù)據(jù)傳輸速度快、通信質(zhì)量高、永遠(yuǎn)在線和按流量計(jì)費(fèi)等優(yōu)點(diǎn)，而且其本身就是一個(gè)分組型數(shù)據(jù)網(wǎng)，支持TCP/IP協(xié)議，可以直接與Internet互通。因此，GPRS在無(wú)線上網(wǎng)、環(huán)境監(jiān)測(cè)便攜型、交通監(jiān)控、移動(dòng)辦公等行業(yè)中具有無(wú)可比擬的性價(jià)比優(yōu)勢(shì)。 GPRS的主要特點(diǎn) 相對(duì)原來(lái)GSM的電路交換數(shù)據(jù)傳送方式，GPRS采用分組交換技術(shù)。由于使用“分組”技術(shù)，用戶上網(wǎng)可以免受掉線的麻煩。此外，使用GPRS上網(wǎng)的方法與 WAP不同， 用WAP上網(wǎng)就如在家中上網(wǎng)，先“撥號(hào)連接”，而上網(wǎng)后便不能同時(shí)使用該電話線，但GPRS則較優(yōu)越，下載資料和通話可以同時(shí)進(jìn)行。 從技術(shù)上來(lái)說(shuō)，聲音的傳送（即通話）繼續(xù)使用GSM，而數(shù)據(jù)的傳送則使用GPRS，就把移動(dòng)電話的應(yīng)用提升到一個(gè)更高層次，而且不需重新組網(wǎng)，十分經(jīng)濟(jì)。 GPRS的用途十分廣泛，包括通過(guò)手機(jī)發(fā)送及接收電子郵件、在Internet上瀏覽等。使用GPRS，數(shù)據(jù)可實(shí)現(xiàn)分組發(fā)送和接受，這意味著用戶總是在線且按流量計(jì)費(fèi)，降低了服務(wù)成本。 GPRS的最大優(yōu)勢(shì)在于數(shù)據(jù)傳輸速度不是WAP所能比擬的。目前的GSM移動(dòng)通信網(wǎng)的傳輸速度為每秒9.6K字節(jié)，GPRS手機(jī)在今年初推出時(shí)已達(dá)到 56Kbps的傳輸速度，到現(xiàn)在更是達(dá)到了115Kbps（此速度是常用56k modem理想速率的兩倍）。除了速度上的優(yōu)勢(shì)，GPRS還有“永遠(yuǎn)在線”的特點(diǎn)，即用戶隨時(shí)與網(wǎng)絡(luò)保持聯(lián)系。舉個(gè)例子，用戶訪問(wèn)Internet時(shí)，點(diǎn)擊一個(gè)超級(jí)鏈接，手機(jī)就在無(wú)線信道上發(fā)送和接受數(shù)據(jù)，主頁(yè)下載到本地后，沒(méi)有數(shù)據(jù)傳送，手機(jī)就進(jìn)入一種“準(zhǔn)休眠”狀態(tài)，手機(jī)釋放所用的無(wú)線頻道給其它用戶使用，這時(shí)網(wǎng)絡(luò)與用戶之間還保持一種邏輯上的連接，當(dāng)用戶再次點(diǎn)擊，手機(jī)立即向網(wǎng)絡(luò)請(qǐng)求無(wú)線頻道用來(lái)傳送數(shù)據(jù)，而不像普通撥號(hào)上網(wǎng)那樣斷線后還得重新?lián)芴?hào)才能上網(wǎng)。 GPRS的協(xié)議模型 Um接口是GSM的空中接口。Um接口上的通信協(xié)議有5層，自下而上依次為物理層、MAC（Media Access Control)層、LLG（Logical Link Control）層、SNDC層和網(wǎng)絡(luò)層。Um接口的物理層為射頻接口部分，而物理鏈路層則負(fù)責(zé)提供空中接口的各種邏輯信道。GSM空中接口的載頻帶寬為 200KHZ，一個(gè)載頻分為8個(gè)物理信道。如果8個(gè)物理信道都分配為傳送GPRS數(shù)據(jù)，則原始數(shù)據(jù)速率可達(dá)200Kbps。考慮前向糾錯(cuò)碼的開(kāi)銷，則最終的數(shù)據(jù)速率可達(dá)164kbps左右；MAC為媒質(zhì)訪問(wèn)控制層。MAC的主要作用是定義和分配空中接口的GPRS邏輯信道，使得這些信道能被不同的移動(dòng)終端共享；LLG層為邏輯鏈路控制層。它是一種基于高速數(shù)據(jù)鏈路規(guī)程HDLG的無(wú)線鏈路協(xié)議；SNDC被稱為子網(wǎng)依賴結(jié)合層。它的主要作用是完成傳送數(shù)據(jù)的分組、打包，確定TCP／IP地址和加密方式；網(wǎng)絡(luò)層的協(xié)議目前主要是Phasel階段提供的 TCP／IP和L25協(xié)議。TCP／IP和X.25協(xié)議對(duì)于傳統(tǒng)的GSM網(wǎng)絡(luò)設(shè)備（如：BSS、NSS等設(shè)備）是透明的。 GPRS的應(yīng)用范圍 GPRS是在現(xiàn)有GSM網(wǎng)絡(luò)上開(kāi)通的一種新型的分組數(shù)據(jù)傳輸業(yè)務(wù)，在有GPRS承載業(yè)務(wù)支持的標(biāo)準(zhǔn)化網(wǎng)絡(luò)協(xié)議的基礎(chǔ)上，GPRS可以提供系列交互式業(yè)務(wù)服務(wù)： 1、點(diǎn)對(duì)點(diǎn)面向連接的數(shù)據(jù)業(yè)務(wù)。為兩個(gè)用戶或者多個(gè)用戶之間發(fā)送多分組的業(yè)務(wù)，該業(yè)務(wù)要求有建立連接、數(shù)據(jù)傳送以及連接釋放等工作程序。 2、單點(diǎn)對(duì)多點(diǎn)業(yè)務(wù)。根據(jù)某個(gè)業(yè)務(wù)請(qǐng)求者的要求，把單一信息傳送給多個(gè)用戶。該業(yè)務(wù)又可以分為點(diǎn)對(duì)多點(diǎn)多信道廣播業(yè)務(wù)、點(diǎn)對(duì)多點(diǎn)群呼業(yè)務(wù)和IP多點(diǎn)傳播業(yè)務(wù)。 3、點(diǎn)對(duì)點(diǎn)無(wú)連接型網(wǎng)絡(luò)業(yè)務(wù)。各個(gè)數(shù)據(jù)分組彼此互相獨(dú)立，用戶之間的信息傳輸不需要端到端的呼叫建立程序，分組的傳送沒(méi)有邏輯連接，分組的交付沒(méi)有確認(rèn)保護(hù)，是由IP協(xié)議支持的業(yè)務(wù)。 GPRS除了提供點(diǎn)對(duì)點(diǎn)、點(diǎn)對(duì)多點(diǎn)的數(shù)據(jù)業(yè)務(wù)外，還能支持用戶終端業(yè)務(wù)、補(bǔ)充業(yè)務(wù)、 GSM短消息業(yè)務(wù)和各種GPRS電信業(yè)務(wù)。 GPRS DTU(數(shù)據(jù)傳輸終端)的INERNET接入技術(shù) GPRS DTU(數(shù)據(jù)傳輸終端)的INERNET接入技術(shù)，通過(guò)點(diǎn)對(duì)點(diǎn)協(xié)議建立通信鏈路，將集成有GPPS模塊的DTU采集處理后的數(shù)據(jù)經(jīng)UDP／IP封包，采用TCP／IP協(xié)議進(jìn)行遠(yuǎn)程無(wú)線數(shù)據(jù)傳輸。所以我們必須了解ppp協(xié)議 和UDP/IP、TCP/IP協(xié)議，下面介紹了3種協(xié)議 （一）ppp協(xié)議 1.1PPP協(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é)議、NCP（Network Control Protocol）和PPP的擴(kuò)展協(xié)議（如Multilink Protocol，）。隨著網(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ò)程中，我們需要輸入用戶名和密碼。因此當(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)證 第二章 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.1 PPP協(xié)議的封裝 我們知道ISO參考模型共分七層，自下而上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng) 絡(luò)層、傳輸層、會(huì)話層、表示層和應(yīng)用層。通常我們會(huì)依據(jù)協(xié)議所完成的 功能將它與這七層進(jìn)行對(duì)照，PPP協(xié)議就屬于數(shù)據(jù)鏈路層協(xié)議。 4 我們?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ù)幀的 封裝格式： 以下為對(duì)PPP數(shù)據(jù)幀封裝格式的一點(diǎn)說(shuō)明： ?? 每一個(gè)PPP數(shù)據(jù)幀均是以一個(gè)標(biāo)志字節(jié)起始和結(jié)束的，該字節(jié)為0x7E。 ?? 緊接在起始標(biāo)志字節(jié)后的一個(gè)字節(jié)是地址域，該字節(jié)為0xFF。我們熟知網(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ī)希望能夠通信的話，首先發(fā)送端需獲知對(duì)端的MAC地址。但由于PPP協(xié)議是被運(yùn)用在點(diǎn)對(duì)點(diǎn)的鏈路上的特殊性，它不像廣播或多點(diǎn)訪問(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)容填充為0x03。 ?? 就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ì)向發(fā)送端發(fā)送一個(gè)Protocol-Reject報(bào)文，在該報(bào)文尾部將完整地填充被拒絕的報(bào)文。協(xié)議域的具體取值如下表所示： ????說(shuō)明 協(xié)議域類型中的*號(hào)表示可從（0-F）中任意取值 ?? 信息域缺省時(shí)最大長(zhǎng)度不能超過(guò)1500字節(jié)，其中包括填充域的內(nèi)容（在圖2-1中并未表示，因?yàn)樗鼘儆谛畔⒂虻囊徊糠郑?500字節(jié)大小等于PPP協(xié)議中配置參數(shù)選項(xiàng)MRU（Maximum 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（MaximumTransmit Unit）。對(duì)于一個(gè)設(shè)備而言，它網(wǎng)絡(luò)的層次均使用MTU和MRU兩個(gè)值，一般情況下設(shè)備的MRU會(huì)比MTU稍大幾個(gè)字節(jié)，但這需根據(jù)各廠商的設(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)銷，這樣可能會(huì)增加應(yīng)用層交互的延遲，對(duì)于這個(gè)字節(jié)的使用我們可以參考一下X.25協(xié)議和FR協(xié)議就知道 2.1.2 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é)議 2.1.3 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ò)層地址。 ????說(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ù)幀封裝格式非常類似于HDLC ?? PPP協(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ù)的配置 第三章 PPP鏈路的建立 3.1 PPP鏈路的建立過(guò)程 3.1.1 PPP的狀態(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è)備所采用的認(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)鏈路的配置、維護(hù)和終止過(guò)程中，PPP需經(jīng)歷以下幾個(gè)階段： ?? 鏈路不可用階段，有時(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ù)不同的 事件發(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è)備的存在。 ?? 鏈路建立階段，也是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)前狀態(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ú)立的。如果在該階段收到了非LCP數(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、IPX和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ī)變成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)載波丟失、授權(quán)失敗、鏈路質(zhì)量檢測(cè)失敗和管理員人為關(guān)閉鏈路等情況均會(huì)導(dǎo)致鏈路終止。鏈路建立階段可能通過(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é)議 3.1.2.1 LCP數(shù)據(jù)報(bào)文的封裝方式 LCP數(shù)據(jù)報(bào)文是在鏈路建立階段被交換的，它作為PPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中，此時(shí)PPP數(shù)據(jù)幀的協(xié)議域固定填充0xC021，但在鏈路建立階段的整個(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ì)向?qū)Χ税l(fā)送一個(gè)LCP的代碼拒絕報(bào)文（Code-Reject報(bào)文）。根據(jù)RFC的規(guī)定，到目前為止LCP共包括以下幾種類型的數(shù)據(jù)報(bào)文： ?? 標(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)含義如下圖所示： 例1：假設(shè)點(diǎn)對(duì)點(diǎn)通信的一端發(fā)送了一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 從報(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)容如下： 7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 該報(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.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)終止一條鏈路的。 ?? 鏈路維護(hù)報(bào)文，主要用來(lái)維護(hù)和調(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)文格式： 鏈路配置報(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è)條件： ?? 不能完全識(shí)別配置參數(shù)選項(xiàng)的類型域，我們知道一個(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ù)字為全0，而對(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)容如下： 7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該發(fā)送一個(gè)Config-Ack報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 C0 21 02 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 唯一改變的內(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é)商完后再次發(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)容如下： 7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 該數(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)容如下： 7E FF 03 C0 21 03 01 00 0A 02 06 00 0E 00 00 7E 該報(bào)文中返回的值已經(jīng)被更改，且當(dāng)發(fā)端收到該報(bào)文后會(huì)重新發(fā)送一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 C0 21 01 04 00 17 02 06 00 0E 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 仔細(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)的類型域不識(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)容如下： 7E FF 03 C0 21 01 01 00 17 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 下劃線所表示的配置參數(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)容如下： 7E FF 03 C0 21 04 01 00 0A 02 06 00 0A 00 00 7E 該報(bào)文如果被原發(fā)送端接收后，又會(huì)重新發(fā)送一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 C0 21 01 04 00 11 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 7E 這時(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é)商過(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)。對(duì)于鏈路終止報(bào)文也同樣需要ID一致，當(dāng)接收到Terminate-Reply報(bào)文才會(huì)做鏈路終止操作。 3.1.2.5 LCP的鏈路維護(hù)報(bào)文 除上述兩種報(bào)文類型以外，剩余的所有報(bào)文類型均歸屬鏈路維護(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)容如下： 7E FF 03 C0 21 0E 01 00 19 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 1F02 7E 有下劃線的部分表示這個(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)容如下： 7E FF 03 C0 21 07 01 00 1D 0E 01 00 19 02 06 00 0A 00 00 05 06 00 0B 42 CB 07 02 08 02 0D 03 06 1F 02 7E ?? 當(dāng)接收端發(fā)現(xiàn)所接收到的數(shù)據(jù)幀的協(xié)議域是一個(gè)不合法的值時(shí)，將會(huì)向發(fā)送端回應(yīng)一個(gè)Protocol-Reject報(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)容如 下： 7E FF 03 77 77 01 01 00 19 02 06 00 0D 00 00 05 07 03 09 02 0D 04 06 2F 02 7E 其中下劃線部分為PPP數(shù)據(jù)幀的協(xié)議域，0x7777表示一個(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)容如下： 7E FF 03 C0 21 08 01 00 18 77 77 01 00 00 19 02 06 00 0D 00 00 05 07 03 09 02 0D 04 06 2F 02 7E ?? Echo-Request報(bào)文和Echo-Reply報(bào)文主要用來(lái)檢測(cè)雙向鏈路上自環(huán)的問(wèn)題， 除此之外還可附帶做一些鏈路質(zhì)量的測(cè)試和其它功能。當(dāng)LCP狀態(tài)機(jī)處于Opened狀態(tài)時(shí)，如果接收到了Echo-Request，就需向?qū)Χ嘶厮鸵粋€(gè)Echo-Reply報(bào)文。否則在其它LCP狀態(tài)下，該類型的報(bào)文會(huì)被丟棄。這種類型數(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)容如下： 7E FF 03 C0 21 09 01 00 08 02 06 00 0D 7E 有下劃線的部分表示魔術(shù)字。 當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該發(fā)送一個(gè)Echo-Reply報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 C0 21 0A 01 00 08 02 06 00 0D 7E 3.1.3 NCP協(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。 3.1.3.1 IPCP IPCP控制協(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)可將IPCP的協(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ò)程。IPCP的數(shù)據(jù)的文同LCP的數(shù)據(jù)報(bào)文非常類似，只不過(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)文類型只是LCP數(shù)據(jù)報(bào)文的一個(gè)子集（只 有LCP代碼域從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)類似于LCP配置參數(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)中只含有各自的IP地址。當(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è)IPCP在網(wǎng)絡(luò)層協(xié)議階段開(kāi)始協(xié)商配置參數(shù)選項(xiàng)（這里只舉協(xié)商IP地址的配置參 數(shù)選項(xiàng)地的過(guò)程），發(fā)送方設(shè)置IP地址為192.168.0.1，接收方設(shè)置IP地址為192.168.0.2， 發(fā)送方發(fā)送給Config-Request報(bào)文內(nèi)容如下： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 01 7E 在這個(gè)例子中我們能看見(jiàn)明顯的改變之處再于PPP協(xié)議域字段由原先的0xC021改變?yōu)?x8021，下劃線的部分表示本端的IP地址。 當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該回應(yīng)一個(gè)Config-Ack報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 01 7E 同樣的接收方給發(fā)送方也發(fā)送一個(gè)Config-Request報(bào)文內(nèi)容如下，但此時(shí)報(bào)文中IP地址配置參數(shù)選項(xiàng)的值為本端的IP地址（192.168.0.2）： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E 發(fā)送方回應(yīng)一個(gè)Config-Ack報(bào)文給接收方，報(bào)文內(nèi)容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E ?? 動(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)文中只攜帶IP地址的配置參數(shù)選項(xiàng)。如果是配置參數(shù)選項(xiàng)中含有其它配置參數(shù)選項(xiàng)，則可能會(huì)遇到其它的一些情況（如不識(shí)別配置參數(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地址填充全0（也即是0.0.0.0），這樣當(dāng)對(duì)端收到這個(gè)Config-Request報(bào)文時(shí)，當(dāng)接收方收到該配置請(qǐng)求報(bào)文后會(huì)迅檢測(cè)IP地址的內(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)文中所提供的。接收方IP 地址的配置過(guò)程與靜態(tài)時(shí)的一樣， 只需發(fā)送一個(gè)Config-Request報(bào)文即可，當(dāng)收到發(fā)送方的Config-Ack報(bào)文，就表示接收方的IP地址配置完成。 例9： 假設(shè)IPCP在網(wǎng)絡(luò)層協(xié)議階段開(kāi)始協(xié)商配置參數(shù)選項(xiàng)（這里只舉協(xié)商IP地址的配置參數(shù)選項(xiàng)地的過(guò)程），發(fā)送方?jīng)]有配置IP地址，而接收方配置了IP地址為192.168.0.2，接收方可給發(fā)送方分配IP地址（192.168.0.1），發(fā)送方發(fā)送給接收方的Config-Request報(bào)文內(nèi) 容如下： 7E FF 03 80 21 01 01 00 0A 03 06 00 00 00 00 7E 有下劃線的部分表示本端的IP地址。 當(dāng)對(duì)端正確接收到了該報(bào)文后，應(yīng)該回應(yīng)一個(gè)Config-Nak報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 80 21 03 01 00 0A 03 06 C0 A8 00 01 7E 當(dāng)接收方收到該報(bào)文后，重新發(fā)送一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 80 21 01 02 00 0A 03 06 C0 A8 00 01 7E 接收方再次收到發(fā)送方的一個(gè)Config-Request報(bào)文，此時(shí)將回應(yīng)一個(gè)Config-Ack報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 80 21 02 02 00 0A 03 06 C0 A8 00 01 7E 請(qǐng)仔細(xì)觀察一下這些報(bào)文在交互過(guò)程中，PPP數(shù)據(jù)幀凈載荷內(nèi)的數(shù)據(jù)報(bào)文的類型域和報(bào)文 ID。同樣的接收方給發(fā)送方也發(fā)送一個(gè)Config-Request報(bào)文，報(bào)文內(nèi)容如下： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E 發(fā)送方應(yīng)回送一個(gè)Config-Ack給接收方，報(bào)文內(nèi)容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E 本章節(jié)的一些內(nèi)容可能沒(méi)有明確寫出，只是將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)文和鏈路維 ?? 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é)商 第四章 LCP的可選配置參數(shù) 4.1 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）。 4.1.1 魔術(shù)字（Magic-Number） 魔術(shù)字是在LCP的Config-Request報(bào)文中被協(xié)商的，并且可被其它一些其它類型的LCP數(shù)據(jù)報(bào)文所使用，如前面已經(jīng)說(shuō)過(guò)的Echo-Request、Echo-Reply報(bào)文和Quality-Protocol報(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)在相同廠商的設(shè)備進(jìn)行互連時(shí)，因?yàn)橐粋€(gè)廠商所生產(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án)路。但如果一致的話，接收端認(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)一端收到了一個(gè)Config-Nak報(bào)文時(shí)，又會(huì)發(fā)送一個(gè)Config-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ì)使LCP的狀態(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ò)程。 4.1.2 認(rèn)證協(xié)議 PPP協(xié)議也提供了可選的認(rèn)證配置參數(shù)選項(xiàng)，缺省情況下點(diǎn)對(duì)點(diǎn)通信的兩端是不進(jìn)行認(rèn)證的。在LCP的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)的