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

關(guān)于GPRS通信協(xié)議 簡介：首先介紹了GPRS的工作原理和工作特點，然后介紹GPRS的協(xié)議模型和應(yīng)用范圍，接著介紹了GPRS在傳輸中所需要用的3種協(xié)議，最后介紹了一種基于單片機的GPRS的無線數(shù)據(jù)傳送系統(tǒng) GPRS的工作原理簡介 GPRS工作時，是通過路由管理來進行尋址和建立數(shù)據(jù)連接的，而GPRS的路由管理表現(xiàn)在以下3個方面：移動終端發(fā)送數(shù)據(jù)的路由建立；移動終端接收數(shù)據(jù)的路由建立；以及移動終端處于漫游時數(shù)據(jù)路由的建立。 對于第一種情況，當(dāng)移動終端產(chǎn)生了一個PDU（分組數(shù)據(jù)單元），這個PDU經(jīng)過SNDC層處理，稱為SNDC數(shù)據(jù)單元。然后經(jīng)過LLC層處理為LLC幀，通過空中接口（空中接口（Air Interface）是指用戶終端（UT）和無線接入網(wǎng)絡(luò)（RAN）之間的接口）送到GSM網(wǎng)絡(luò)中移動終端所處的SGSN。SGSN把數(shù)據(jù)送到GGSN。GGSN把收到的消息進行解裝處理，轉(zhuǎn)換為可在公用數(shù)據(jù)網(wǎng)中傳送的格式（如PSPDN的PDU），最終送給公用數(shù)據(jù)網(wǎng)的用戶。為了提高傳輸效率，并保證數(shù)據(jù)傳輸?shù)陌踩梢詫罩薪涌谏系臄?shù)據(jù)做壓縮和加密處理。 在第二種情況中，一個公用數(shù)據(jù)網(wǎng)用戶傳送數(shù)據(jù)到移動終端時，首先通過數(shù)據(jù)網(wǎng)的標(biāo)準(zhǔn)協(xié)議建立數(shù)據(jù)網(wǎng)和GGSN之間的路由。數(shù)據(jù)網(wǎng)用戶發(fā)出的數(shù)據(jù)單元（如PSPDN中的PDU），通過建立好的路由把數(shù)據(jù)單元PDU送給GGSN。而GGSN再把PDU送給移動終端所在的SGSN上，GSN把PDU封裝成SNDC數(shù)據(jù)單元，再經(jīng)過LLC層處理為LLC幀單元，最終通過空中接口送給移動終端。 第三種情況是一個數(shù)據(jù)網(wǎng)用戶傳送數(shù)據(jù)給一個正在漫游的移動用戶。這種情況下的數(shù)據(jù)傳送必須要經(jīng)過歸屬地的GGSN，然后送到移動用戶A。 GPRS的英文全稱是：“General Packet Radio Service”（譯作“通用分組無線服務(wù)”），它是利用“包交換”（Packet－Switched）的概念發(fā)展起來的一套無線傳輸方式。所謂“包交換 ”就是將Data封裝成許多獨立的封包，再將這些封包一一傳送出去，形式上有點類似郵局中的寄包裹。其作用在于只有當(dāng)有資料需要傳送時才會占用頻寬，而且可以以傳輸?shù)馁Y料量計價，這對廣大用戶來說是較合理的計費方式，因為像Internet這類的數(shù)據(jù)傳輸大多數(shù)的時間頻寬是閑置的。 GPRS網(wǎng)絡(luò)是基于現(xiàn)有的GSM網(wǎng)絡(luò)來實現(xiàn)的。在現(xiàn)有的GSM網(wǎng)絡(luò)中需增加一些節(jié)點，如GGSN（Gateway GPRS Supporting Node，GPRS網(wǎng)關(guān)支持節(jié)點）和SGSN（ Serving GSN，GPRS服務(wù)支持節(jié)點），GSN是GPRS網(wǎng)絡(luò)中最重要的網(wǎng)絡(luò)節(jié)點。GSN具有移動路由管理功能，它可以連接各種類型的數(shù)據(jù)網(wǎng)絡(luò)，并可以連到 GPRS寄存器。GSN可以完成移動終端（即手機）和各種數(shù)據(jù)網(wǎng)絡(luò)之間的數(shù)據(jù)傳送和格式轉(zhuǎn)換。GSN可以是一種類似于路由器的獨立設(shè)備，也可以與GSM中的MSC（Mobile Switching Center，移動交換中心，將本網(wǎng)和其它網(wǎng)絡(luò)連接起來）集成在一起。GSN有兩種類型：一種為SGSN（ Serving GSN，服務(wù)GSN），另一種為GGSN（Gateway GSN，網(wǎng)關(guān)GSN），SGSN的主要作用是記錄移動終端的當(dāng)前位置信息，并且在移動終端和GGSN之間完成移動分組數(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)）等。國外有些資料甚至將GGSN稱為GPRS路由器。GGSN可以把GSM網(wǎng)中的GPRS 分組數(shù)據(jù)包進行協(xié)議轉(zhuǎn)換，從而可以把這些分組數(shù)據(jù)包傳送到遠(yuǎn)端的TCP／IP或X.25網(wǎng)絡(luò)。 　 GPRS網(wǎng)不但具有覆蓋范圍廣、數(shù)據(jù)傳輸速度快、通信質(zhì)量高、永遠(yuǎn)在線和按流量計費等優(yōu)點，而且其本身就是一個分組型數(shù)據(jù)網(wǎng)，支持TCP/IP協(xié)議，可以直接與Internet互通。因此，GPRS在無線上網(wǎng)、環(huán)境監(jiān)測便攜型、交通監(jiān)控、移動辦公等行業(yè)中具有無可比擬的性價比優(yōu)勢。 GPRS的主要特點 相對原來GSM的電路交換數(shù)據(jù)傳送方式，GPRS采用分組交換技術(shù)。由于使用“分組”技術(shù)，用戶上網(wǎng)可以免受掉線的麻煩。此外，使用GPRS上網(wǎng)的方法與 WAP不同， 用WAP上網(wǎng)就如在家中上網(wǎng)，先“撥號連接”，而上網(wǎng)后便不能同時使用該電話線，但GPRS則較優(yōu)越，下載資料和通話可以同時進行。 從技術(shù)上來說，聲音的傳送（即通話）繼續(xù)使用GSM，而數(shù)據(jù)的傳送則使用GPRS，就把移動電話的應(yīng)用提升到一個更高層次，而且不需重新組網(wǎng)，十分經(jīng)濟。 GPRS的用途十分廣泛，包括通過手機發(fā)送及接收電子郵件、在Internet上瀏覽等。使用GPRS，數(shù)據(jù)可實現(xiàn)分組發(fā)送和接受，這意味著用戶總是在線且按流量計費，降低了服務(wù)成本。 GPRS的最大優(yōu)勢在于數(shù)據(jù)傳輸速度不是WAP所能比擬的。目前的GSM移動通信網(wǎng)的傳輸速度為每秒9.6K字節(jié)，GPRS手機在今年初推出時已達(dá)到 56Kbps的傳輸速度，到現(xiàn)在更是達(dá)到了115Kbps（此速度是常用56k modem理想速率的兩倍）。除了速度上的優(yōu)勢，GPRS還有“永遠(yuǎn)在線”的特點，即用戶隨時與網(wǎng)絡(luò)保持聯(lián)系。舉個例子，用戶訪問Internet時，點擊一個超級鏈接，手機就在無線信道上發(fā)送和接受數(shù)據(jù)，主頁下載到本地后，沒有數(shù)據(jù)傳送，手機就進入一種“準(zhǔn)休眠”狀態(tài)，手機釋放所用的無線頻道給其它用戶使用，這時網(wǎng)絡(luò)與用戶之間還保持一種邏輯上的連接，當(dāng)用戶再次點擊，手機立即向網(wǎng)絡(luò)請求無線頻道用來傳送數(shù)據(jù)，而不像普通撥號上網(wǎng)那樣斷線后還得重新?lián)芴柌拍苌暇W(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，一個載頻分為8個物理信道。如果8個物理信道都分配為傳送GPRS數(shù)據(jù)，則原始數(shù)據(jù)速率可達(dá)200Kbps?？紤]前向糾錯碼的開銷，則最終的數(shù)據(jù)速率可達(dá)164kbps左右；MAC為媒質(zhì)訪問控制層。MAC的主要作用是定義和分配空中接口的GPRS邏輯信道，使得這些信道能被不同的移動終端共享；LLG層為邏輯鏈路控制層。它是一種基于高速數(shù)據(jù)鏈路規(guī)程HDLG的無線鏈路協(xié)議；SNDC被稱為子網(wǎng)依賴結(jié)合層。它的主要作用是完成傳送數(shù)據(jù)的分組、打包，確定TCP／IP地址和加密方式；網(wǎng)絡(luò)層的協(xié)議目前主要是Phasel階段提供的 TCP／IP和L25協(xié)議。TCP／IP和X.25協(xié)議對于傳統(tǒng)的GSM網(wǎng)絡(luò)設(shè)備（如：BSS、NSS等設(shè)備）是透明的。 GPRS的應(yīng)用范圍 GPRS是在現(xiàn)有GSM網(wǎng)絡(luò)上開通的一種新型的分組數(shù)據(jù)傳輸業(yè)務(wù)，在有GPRS承載業(yè)務(wù)支持的標(biāo)準(zhǔn)化網(wǎng)絡(luò)協(xié)議的基礎(chǔ)上，GPRS可以提供系列交互式業(yè)務(wù)服務(wù)： 1、點對點面向連接的數(shù)據(jù)業(yè)務(wù)。為兩個用戶或者多個用戶之間發(fā)送多分組的業(yè)務(wù)，該業(yè)務(wù)要求有建立連接、數(shù)據(jù)傳送以及連接釋放等工作程序。 2、單點對多點業(yè)務(wù)。根據(jù)某個業(yè)務(wù)請求者的要求，把單一信息傳送給多個用戶。該業(yè)務(wù)又可以分為點對多點多信道廣播業(yè)務(wù)、點對多點群呼業(yè)務(wù)和IP多點傳播業(yè)務(wù)。 3、點對點無連接型網(wǎng)絡(luò)業(yè)務(wù)。各個數(shù)據(jù)分組彼此互相獨立，用戶之間的信息傳輸不需要端到端的呼叫建立程序，分組的傳送沒有邏輯連接，分組的交付沒有確認(rèn)保護，是由IP協(xié)議支持的業(yè)務(wù)。 GPRS除了提供點對點、點對多點的數(shù)據(jù)業(yè)務(wù)外，還能支持用戶終端業(yè)務(wù)、補充業(yè)務(wù)、 GSM短消息業(yè)務(wù)和各種GPRS電信業(yè)務(wù)。 GPRS DTU(數(shù)據(jù)傳輸終端)的INERNET接入技術(shù) GPRS DTU(數(shù)據(jù)傳輸終端)的INERNET接入技術(shù)，通過點對點協(xié)議建立通信鏈路，將集成有GPPS模塊的DTU采集處理后的數(shù)據(jù)經(jīng)UDP／IP封包，采用TCP／IP協(xié)議進行遠(yuǎn)程無線數(shù)據(jù)傳輸。所以我們必須了解ppp協(xié)議 和UDP/IP、TCP/IP協(xié)議，下面介紹了3種協(xié)議 （一）ppp協(xié)議 1.1PPP協(xié)議簡介 PPP 提供了一種在點對點的鏈路上封裝多協(xié)議數(shù)據(jù)報（ IP 、IPX和AppleTalk）的標(biāo)準(zhǔn)方法。它不僅能支持IP地址的動態(tài)分配和管理；同步（面向位的同步數(shù)據(jù)塊的傳送）或異步（起始位+數(shù)據(jù)位+奇偶校驗位+停止位）物理層的傳輸；網(wǎng)絡(luò)層協(xié)議的復(fù)用；鏈路的配置、質(zhì)量檢測和糾錯；而且還支持多種配置參數(shù)選項的協(xié)商。 PPP協(xié)議主要包括三部分：LCP（Link Control Protocol）鏈路控制協(xié)議、NCP（Network Control Protocol）和PPP的擴展協(xié)議（如Multilink Protocol，）。隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)帶寬已不在是瓶頸，所以PPP擴展協(xié)議的應(yīng)用也就越來越少，因此往往人們在敘述PPP協(xié)議時經(jīng)常會忘記它的存在。而且大部分網(wǎng)絡(luò)教材上會將PPP的認(rèn)證也作為PPP協(xié)議的一個主要部分，實際上這是一個錯誤概念的引導(dǎo)。PPP協(xié)議默認(rèn)是不進行認(rèn)證配置參數(shù)選項的協(xié)商，它只作為一個可選的參數(shù)，當(dāng)點對點線路的兩端需要進行認(rèn)證時才需配置。當(dāng)然在實際應(yīng)用中這個過程是不可忽略的，例如我們使用計算機上網(wǎng)時，需要通過PPP協(xié)議與NAS設(shè)備互連，在整個協(xié)議的協(xié)商過程中，我們需要輸入用戶名和密碼。因此當(dāng)別人說PPP協(xié)議主要包括LCP、認(rèn)證和NCP協(xié)議三個部分時，你不要認(rèn)為他的說法有誤，而只是不夠準(zhǔn)確罷了。 1.2 總結(jié) ?? PPP協(xié)議由于自身諸多的優(yōu)點取代了SLIP協(xié)議，從而成為目前被廣泛使用的數(shù)據(jù)鏈路層協(xié)議 ?? SLIP協(xié)議歸咎其其簡單數(shù)據(jù)包的封裝方式，使其僅能在點對點的鏈路上封裝單一的網(wǎng)絡(luò)層協(xié)議（IP協(xié)議） ?? PPP協(xié)議包括LCP協(xié)議、NCP協(xié)議和PPP擴展協(xié)議 ?? RFC1661文檔中說明了PPP協(xié)議缺省是不進行PAP和CHAP認(rèn)證 第二章 PPP協(xié)議的三組件 2.1 PPP協(xié)議的組件 首先簡單介紹一下PPP協(xié)議的三組件：PPP協(xié)議的封裝方式、LCP協(xié)議的協(xié)商過程和NCP協(xié)議的協(xié)商過程，然后再結(jié)合具體的LCP和NCP數(shù)據(jù)報的封裝格式和兩個階段實際數(shù)據(jù)報文的交換過程，進一步理解PPP的LCP和NCP協(xié)商階段的具體內(nèi)容。 2.1.1 PPP協(xié)議的封裝 我們知道ISO參考模型共分七層，自下而上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng) 絡(luò)層、傳輸層、會話層、表示層和應(yīng)用層。通常我們會依據(jù)協(xié)議所完成的 功能將它與這七層進行對照，PPP協(xié)議就屬于數(shù)據(jù)鏈路層協(xié)議。 4 我們在提及PPP協(xié)議的報文封裝格式時，不可不先提一下HDLC協(xié)議。HDLC也是最常用的數(shù)據(jù)鏈路層協(xié)議，它是從SDLC協(xié)議衍進過來的，許多常用的數(shù)據(jù)鏈路層協(xié)議的封裝方式都是基于HDLC的封裝格式的，同樣PPP協(xié)議也不例外，它也采用了HDLC的定界幀格式。下圖為PPP數(shù)據(jù)幀的 封裝格式： 以下為對PPP數(shù)據(jù)幀封裝格式的一點說明： ?? 每一個PPP數(shù)據(jù)幀均是以一個標(biāo)志字節(jié)起始和結(jié)束的，該字節(jié)為0x7E。 ?? 緊接在起始標(biāo)志字節(jié)后的一個字節(jié)是地址域，該字節(jié)為0xFF。我們熟知網(wǎng)絡(luò)是分層的，且對等層之間進行相互通信，而下層為上層提供服務(wù)。當(dāng)對等層進行通信時首先需獲知對方的地址，而對不同的網(wǎng)絡(luò)，在數(shù)據(jù)鏈路層則表現(xiàn)為需要知道對方的MAC地址、X.121地址、ATM地址等；在網(wǎng)絡(luò)層則表現(xiàn)為需要知道對方的IP地址、IPX地址等；而在傳輸層則需要道對方的協(xié)議端口號。例如如果兩個以太網(wǎng)上的主機希望能夠通信的話，首先發(fā)送端需獲知對端的MAC地址。但由于PPP協(xié)議是被運用在點對點的鏈路上的特殊性，它不像廣播或多點訪問的網(wǎng)絡(luò)一樣，因為點對點的鏈路就可以唯一標(biāo)示對方，因此使用PPP協(xié)議互連的通信設(shè)備 的兩端無須知道對方的數(shù)據(jù)鏈路層地址，所以該字節(jié)已無任何意義，按照協(xié)議的規(guī)定將該字節(jié)填充為全1的廣播地址。 ?? 同地址域一樣，PPP數(shù)據(jù)幀的控制域也沒有實際意義，按照協(xié)議的規(guī)定通信雙方將該字節(jié)的內(nèi)容填充為0x03。 ?? 就PPP協(xié)議本身而言，我們最關(guān)心的內(nèi)容應(yīng)該是它的協(xié)議域和信息域。 協(xié)議域可用來區(qū)分PPP數(shù)據(jù)幀中信息域所承載的數(shù)據(jù)報文的內(nèi)容。協(xié)議域的內(nèi)容必須依據(jù)ISO 3309的地址擴展機制所給出的規(guī)定。該機制規(guī)定協(xié)議域所填充的內(nèi)容必須為奇數(shù)，也即是要求低字節(jié)的最低位為”1”，高字節(jié)的最低位為”0”。如果當(dāng)發(fā)送端發(fā)送的PPP數(shù)據(jù)幀的協(xié)議域字段不符合上述規(guī)定，則接收端會認(rèn)為此數(shù)據(jù)幀是不可識別的，那么接收端會向發(fā)送端發(fā)送一個Protocol-Reject報文，在該報文尾部將完整地填充被拒絕的報文。協(xié)議域的具體取值如下表所示： ????說明 協(xié)議域類型中的*號表示可從（0-F）中任意取值 ?? 信息域缺省時最大長度不能超過1500字節(jié)，其中包括填充域的內(nèi)容（在圖2-1中并未表示，因為它屬于信息域的一部分），1500字節(jié)大小等于PPP協(xié)議中配置參數(shù)選項MRU（Maximum Receive Unit）的缺省值，在實際應(yīng)用當(dāng)中可根據(jù)實際需要進行信息域最大封裝長度選項的協(xié)商。信息域如果不足1500字節(jié)時可被填充，但不是必須的，如果填充則需通信 雙方的兩端能辨認(rèn)出有用與無用的信息方可正常通信。我們通常在通信設(shè)備的配置過程中，遇到最多的也是MTU（MaximumTransmit Unit）。對于一個設(shè)備而言，它網(wǎng)絡(luò)的層次均使用MTU和MRU兩個值，一般情況下設(shè)備的MRU會比MTU稍大幾個字節(jié)，但這需根據(jù)各廠商的設(shè)備而定。 ?? CRC校驗域主要是對PPP數(shù)據(jù)幀傳輸?shù)恼_性進行檢測的，當(dāng)然在數(shù)據(jù)幀中引入了一些傳輸?shù)谋ＷC機制是好的，但可以反過來說，同樣我們會引入更多的開銷，這樣可能會增加應(yīng)用層交互的延遲，對于這個字節(jié)的使用我們可以參考一下X.25協(xié)議和FR協(xié)議就知道 2.1.2 LCP協(xié)議 為了能適應(yīng)復(fù)雜多變的網(wǎng)絡(luò)環(huán)境，PPP協(xié)議提供了一種鏈路控制協(xié)議來配置和測試數(shù)據(jù)通信鏈路，它能用來協(xié)商PPP協(xié)議的一些配置參數(shù)選項；處理不同大小的數(shù)據(jù)幀；檢測鏈路環(huán)路、一些鏈路的錯誤；終止一條鏈路。 ????說明 詳細(xì)內(nèi)容請見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)點對點的兩端進行NCP參數(shù)配置協(xié)商時，主要是用來通信雙方的網(wǎng)絡(luò)層地址。 ????說明 詳細(xì)內(nèi)容請見3.1.3節(jié)NCP協(xié)議 2.2 總結(jié) ?? PPP協(xié)議的三組件包括PPP協(xié)議的封裝方式、LCP協(xié)議和NCP協(xié)議 ?? PPP協(xié)議是數(shù)據(jù)鏈路層協(xié)議，它的數(shù)據(jù)幀封裝格式非常類似于HDLC ?? PPP協(xié)議可通過協(xié)議域來區(qū)分?jǐn)?shù)據(jù)域中凈載荷的數(shù)據(jù)類型 ?? PPP協(xié)議通過LCP協(xié)議完成數(shù)據(jù)鏈路的配置和測試 ?? PPP協(xié)議通過NCP協(xié)議完成點對點通信設(shè)備之間網(wǎng)絡(luò)層通信所需參數(shù)的配置 第三章 PPP鏈路的建立 3.1 PPP鏈路的建立過程 3.1.1 PPP的狀態(tài)轉(zhuǎn)移圖 數(shù)據(jù)通信設(shè)備（在本文中指路由器）的兩端如果希望通過PPP協(xié)議建立點對點的通信，無論哪一端的設(shè)備都需發(fā)送LCP數(shù)據(jù)報文來配置鏈路（測試鏈路）。一旦LCP的配置參數(shù)選項協(xié)商完后，通信的雙方就會根據(jù)LCP配置請求報文中所協(xié)商的認(rèn)證配置參數(shù)選項來決定鏈路兩端設(shè)備所采用的認(rèn)證方式。協(xié)議缺省情況下雙方是不進行認(rèn)證的，而直接進入到NCP配置參數(shù)選項的協(xié)商，直至所經(jīng)歷的幾個配置過程全部完成后，點對點的雙方就可以開始通過已建 立好的鏈路進行網(wǎng)絡(luò)層數(shù)據(jù)報文的傳送了，整個鏈路就處于可用狀態(tài)。只有當(dāng)任何一端收到LCP或NCP的鏈路關(guān)閉報文時（一般而言協(xié)議是不要求NCP有關(guān)閉鏈路的能力的，因此通過情況下關(guān)閉鏈路的數(shù)據(jù)報文是在LCP協(xié)商階段或應(yīng)用程序會話階段發(fā)出的）；物理層無法檢測到載波或管理人員對該鏈路進行關(guān)閉操作，都會將該條鏈路斷開，從而終止PPP會話。以下為PPP協(xié)議整個鏈路過程需經(jīng)歷階段的狀態(tài)轉(zhuǎn)移圖： 在點對點鏈路的配置、維護和終止過程中，PPP需經(jīng)歷以下幾個階段： ?? 鏈路不可用階段，有時也稱為物理層不可用階段，PPP鏈路都需從這個階段開始和結(jié)束。當(dāng)通信雙方的兩端檢測到物理線路激活（通常時檢測到鏈路上有載波信號）時，就會從當(dāng)前這個階段躍遷至下一個階段（即鏈路建立階段）。先簡單提一下鏈路建立階段，在這個階段主要是通過LCP協(xié)議進行鏈路參數(shù)的配置，LCP在此階段的狀態(tài)機也會根據(jù)不同的 事件發(fā)生變化。當(dāng)處于在鏈路不可用階段時，LCP的狀態(tài)機是處于initial（初始化狀態(tài)）或starting（準(zhǔn)備啟動狀態(tài)），一旦檢測到物理線路可用，則LCP的狀態(tài)機就要發(fā)生改變。當(dāng)然鏈路被斷開后也同樣會返回到這個階段，往往在實際過程中這個階段所停留的時間是很短的，僅僅是檢測到對方設(shè)備的存在。 ?? 鏈路建立階段，也是PPP協(xié)議最關(guān)鍵和最復(fù)雜的階段。該階段主要是發(fā)送一些配置報文來配置數(shù)據(jù)鏈路，這些配置的參數(shù)不包括網(wǎng)絡(luò)層協(xié)議所需的參數(shù)。當(dāng)完成數(shù)據(jù)報文的交換后，則會繼續(xù)向下一個階段躍遷，該下一個階段既可是驗證階段，也可是網(wǎng)絡(luò)層協(xié)議階段，下一階段的選擇是依據(jù)鏈路兩端的設(shè)備配置的（通常是由用戶來配置，但對NAS或BAS設(shè)備的PPP模塊缺省就需要支持PAP或CHAP中的一種認(rèn)證方式）。在此階段LCP的狀態(tài)機會發(fā)生兩次改變，前面我們說了當(dāng)鏈路處于不可用階段時，此時LCP的狀態(tài)機處于initial或starting，當(dāng)檢測到鏈路可用時，則物理層會向鏈路層發(fā)送一個UP事件，鏈路層收到該事件后，會將 LCP的狀態(tài)機從當(dāng)前狀態(tài)改變?yōu)镽equest-Sent（請求發(fā)送狀態(tài)），根據(jù)此時的狀態(tài)機LCP會進行相應(yīng)的動作，也即是開始發(fā)送Config-Request報文 來配置數(shù)據(jù)鏈路，無論哪一端接收到了Config-Ack報文時，LCP的狀態(tài)機又要發(fā)生改變，從當(dāng)前狀態(tài)改變?yōu)閛pened狀態(tài)，進入Opened狀態(tài)后收到Config-Ack報文的一方則完成了當(dāng)前階段，應(yīng)該向下一個階段躍遷。同理可知，另一端也是一樣的，但須注意的一點是在鏈路配置階段雙方是鏈路配置操作過程是相互獨立的。如果在該階段收到了非LCP數(shù)據(jù)報文，則會的將這些報文丟棄。在實際配置當(dāng)中在該階段可能會遇到很多情況，在LCP協(xié)議章節(jié)中會詳細(xì)介紹可能遇到的情況，但最好結(jié)合一些troubleshooting案例能更好的幫助理解。 ?? 驗證階段，多數(shù)情況下的鏈路兩端設(shè)備是需要經(jīng)過認(rèn)證后才進入到網(wǎng)絡(luò)層協(xié)議階段，缺省情況下鏈路兩端的設(shè)備是不進行認(rèn)證的。在該階段支持PAP和CHAP兩種認(rèn)證方式，驗證方式的選擇是依據(jù)在鏈路建立階段雙方進行協(xié)商的結(jié)果。然而，鏈路質(zhì)量的檢測也會在這個階段同時發(fā)生，但協(xié)議規(guī)定不會讓鏈路質(zhì)量的檢測無限制的延遲驗證過程。在這個階段僅支持鏈路控制協(xié)議、驗證協(xié)議和質(zhì)量檢測數(shù)據(jù)報文，其它的數(shù)據(jù)報文都會被丟棄。如果在這個階段再次收到了Config-Request報文，則又會返回到鏈路建立階段。 ?? 網(wǎng)絡(luò)層協(xié)議階段，一旦PPP完成了前面幾個階段，每種網(wǎng)絡(luò)層協(xié)議（IP、IPX和AppleTalk）會通過各自相應(yīng)的網(wǎng)絡(luò)控制協(xié)議進行配置，每個NCP協(xié)議可在任何時間打開和關(guān)閉。當(dāng)一個NCP的狀態(tài)機變成Opened狀態(tài)時，則PPP就可以開始在鏈路上承載網(wǎng)絡(luò)層的數(shù)據(jù)包報文了。如果在個階段收到了Config-Request報文，則又會返回到鏈路建立階段。?? 網(wǎng)絡(luò)終止階段，PPP能在任何時候終止鏈路。當(dāng)載波丟失、授權(quán)失敗、鏈路質(zhì)量檢測失敗和管理員人為關(guān)閉鏈路等情況均會導(dǎo)致鏈路終止。鏈路建立階段可能通過交換LCP的鏈路終止報文來關(guān)閉鏈路，當(dāng)鏈路關(guān)閉時，鏈路層會通知網(wǎng)絡(luò)層做相應(yīng)的操作，而且也會通過物理層強制關(guān)斷鏈路。對于NCP協(xié)議，它是沒有也沒有必要去關(guān)閉PPP鏈路的。 3.1.2 LCP協(xié)議 3.1.2.1 LCP數(shù)據(jù)報文的封裝方式 LCP數(shù)據(jù)報文是在鏈路建立階段被交換的，它作為PPP的凈載荷被封裝在PPP數(shù)據(jù)幀的信息域中，此時PPP數(shù)據(jù)幀的協(xié)議域固定填充0xC021，但在鏈路建立階段的整個過程中信息域的內(nèi)容是在變化的，它包括很多種類型的報文，所以這些報文也要通過相應(yīng)的字段來區(qū)分。LCP數(shù)據(jù)報文的一般封裝方式如下圖所示： ?? 代碼域的長度為一個字節(jié)，主要是用來標(biāo)識LCP數(shù)據(jù)報文的類型的。在鏈路建立階段時，接收方收到LCP數(shù)據(jù)報文的代碼域無法識別時，就會向?qū)Χ税l(fā)送一個LCP的代碼拒絕報文（Code-Reject報文）。根據(jù)RFC的規(guī)定，到目前為止LCP共包括以下幾種類型的數(shù)據(jù)報文： ?? 標(biāo)識域也是一個字節(jié)，其目的是用來匹配請求和響應(yīng)報文。一般而言在進入鏈路建立階段時，通信雙方無論哪一端都會連續(xù)發(fā)送幾個配置請求報文（Config-Request報文），而這幾個請求報文的數(shù)據(jù)域可能是完全一樣的，而僅僅是它們的標(biāo)志域不同罷了。通常一個配置請求報文的ID是從0x01開始逐步加1的，當(dāng)對端接收到該配置請求報文后，無論使用何種 報文（回應(yīng)報文可能是Config-Ack、Config-Nak和Config-Reject三種報文中的一種）來回應(yīng)對方，但必須要求回應(yīng)報文中的ID要與接收報文中的ID一致，當(dāng)通信設(shè)備收到回應(yīng)后就可以將該回應(yīng)與發(fā)送時的進行比較來決定下一步的操作。 ????說明 后面教材中的所有例子，均可參考以下色標(biāo)的含義 范例中報文色標(biāo)含義如下圖所示： 例1：假設(shè)點對點通信的一端發(fā)送了一個Config-Request報文，報文內(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 從報文中可以看出這個配置請求報文包括5個配置參數(shù)選項。 當(dāng)對端正確接收到了該報文后，應(yīng)該回應(yīng)一個Config-Ack報文，報文內(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報文），標(biāo)識域與原報文中的一樣。 ?? 長度域的內(nèi)容 = 總字節(jié)數(shù)據(jù)（代碼域+標(biāo)志域+長度域+數(shù)據(jù)域）。長度 域所指示字節(jié)數(shù)之外的字節(jié)將被當(dāng)作填充字節(jié)而忽略掉，而且該域的內(nèi)容不能超過MRU的值。 ?? 數(shù)據(jù)域的內(nèi)容依據(jù)不同LCP數(shù)據(jù)報文的內(nèi)容也是不一樣的。 ????說明 數(shù)據(jù)域的詳細(xì)內(nèi)容請見3.1.2.3節(jié) 3.1.2.2 LCP數(shù)據(jù)報文的分類 在前一小節(jié)我們可以看到，一共包括12種LCP數(shù)據(jù)報文，我們依據(jù)各報文的 的功能又將其具體細(xì)化為以下三類： ?? 鏈路配置報文，主要用來建立和配置一條鏈路的。 ?? 鏈路終止報文，主要用來終止一條鏈路的。 ?? 鏈路維護報文，主要用來維護和調(diào)試鏈路的。 3.1.2.3 LCP的鏈路配置報文 鏈路配置報文與其它兩類報文有著明顯的區(qū)別，它主要是用來協(xié)商鏈路的配置參數(shù)選項的，因此這種報文的數(shù)據(jù)域還要攜帶許多配置參數(shù)選項的，而另外兩類報文中部分報文的格式會稍有不同（請參見RFC1661），圖3-4表明了數(shù)據(jù)配置選項的報文格式： 鏈路配置報文主要包括Config-Request 、Config-Ack 、Config-Nak 和Config-Reject四種報文。當(dāng)通信雙方需要建立鏈路時，無論哪一方都需要發(fā)送Config-Request報文并攜帶每一端自已所希望協(xié)商的配置參數(shù)選項，下表為一些可選的配置參數(shù)選項： 這個表格內(nèi)的內(nèi)容并非完全，可能還有一新定議的配置選項未列在其中，如有興趣可參照相關(guān)的文檔說明。當(dāng)接收方收到Config-Request報文時，會在剩下的三種類型的報文中選擇一 種來響應(yīng)對方的請求報文，到底選擇哪種報文來響應(yīng)對方需依據(jù)以下兩個條件： ?? 不能完全識別配置參數(shù)選項的類型域，我們知道一個Config-Request報文中會同時攜帶多個配置參數(shù)選項，而對于一個支持PPP協(xié)議的通信設(shè)備也不一定會支持上表中所有列出的配置選項，即使支持，也可能在實際應(yīng)用中關(guān)閉掉某些選項功能。（例如：當(dāng)使用PPP協(xié)議通信的一端可能將一些無用的配置選項都關(guān)閉了，而僅支持0x01和0x03兩個配置參數(shù)選 項，因此當(dāng)對方發(fā)送的Config-Request報文中含有0x04配置選項時，對于本端而言這個配置參數(shù)選項就無法識別，也即是不支持這個配置參數(shù)選項的協(xié)商）。 ?? 如果能支持完全識別配置參數(shù)選項， 但接收端也可能不認(rèn)可 Config-Request報文中配置參數(shù)選項數(shù)據(jù)域中的內(nèi)容（例如：當(dāng)一端發(fā)送魔術(shù)字配置參數(shù)選項中的魔術(shù)字為全0，而對端認(rèn)為應(yīng)該為其它值，這種情況就屬于不支持配置參數(shù)選項中的內(nèi)容）。所以依據(jù)上面的兩個條件，我們就可以明確在回應(yīng)對方配置請求報文時，采用何種報文回應(yīng)。 ?? 當(dāng)接收Config-Request報文的一端能識別發(fā)送過來的所有配置參數(shù)選項且 認(rèn)可所有配置參數(shù)選項數(shù)據(jù)域的內(nèi)容時，接收端將會給對端回一個Config-Ack報文并將配置請求報文中的配置參數(shù)選項原封不動的放置在Config-Ack報文的數(shù)據(jù)域內(nèi)（根據(jù)協(xié)議的規(guī)定是不可改變配置參數(shù)選項的順序）。當(dāng)配置請求報文的發(fā)送端收到Config-Ack報后，則會從當(dāng)前階段進入到下一個階段。 例2：假設(shè)點對點通信的一端發(fā)送了一個Config-Request報文，報文內(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)對端正確接收到了該報文后，應(yīng)該發(fā)送一個Config-Ack報文，報文內(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報文），此例與例1完全一樣，但兩都說明的問題有則重點。 ?? 當(dāng)接收Config-Request報文的一端能識別發(fā)送端所發(fā)送過來的所有配置參數(shù)選項，但對部分配置參數(shù)選項數(shù)據(jù)域中的內(nèi)容不認(rèn)可時，接收端將會給對端回應(yīng)一個Config-Nak報文，該報文中只攜帶不認(rèn)可的配置參數(shù)選項，而這些配置參數(shù)選項的數(shù)據(jù)內(nèi)容為本端希望的值。然而當(dāng)接收端收到Config-Nak 報文后， 會重新發(fā)送Config-Request 報文， 而這個Config-Request報文與上一次所發(fā)送的Config-Request報文區(qū)別在于那些被對端不認(rèn)可的配置參數(shù)選項的內(nèi)容被填寫到剛剛協(xié)商完后再次發(fā)送的Config-Request報文中（Config-Nak報文發(fā)送回來的那些配置參數(shù)選項）。 例3：假設(shè)點對點通信的一端發(fā)送了一個Config-Request報文，報文內(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ù)報文中有下劃線的配置參數(shù)選項的內(nèi)容為對端不認(rèn)可的。 當(dāng)對端正確接收到了該報文后，發(fā)現(xiàn)類型域為0x02的配置參數(shù)選項可識別，但該配置參數(shù)選項數(shù)據(jù)域的內(nèi)容不認(rèn)可，應(yīng)發(fā)送一個Config-Nak報文且該報文中將攜帶希望的配置參數(shù)選項內(nèi)容，報文內(nèi)容如下： 7E FF 03 C0 21 03 01 00 0A 02 06 00 0E 00 00 7E 該報文中返回的值已經(jīng)被更改，且當(dāng)發(fā)端收到該報文后會重新發(fā)送一個Config-Request報文，報文內(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ì)觀察是不是新的配置請求報文與老的配置請求的報文ID不一樣。 ?? 當(dāng)接收Config-Request報文的一端不能識別所有的發(fā)送端發(fā)送過來的配置參數(shù)選項時，此時接收端將會向?qū)Χ嘶匾粋€Config-Reject報文，該報文中的數(shù)據(jù)域只攜帶那些不能識別的配置參數(shù)選項（當(dāng)配置參數(shù)選項的類型域不識別時）。當(dāng)對端接收到Config-Reject報文后，同樣會再次發(fā)送一個Config-Request報文，這個配置請求報文與上一次發(fā)送的區(qū)別在于將 不可識別的那些配置參數(shù)選項給刪除了。 例4：假設(shè)點對點通信的一端發(fā)送了一個Config-Request報文，報文內(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ù)選項為對端不可識別的。 當(dāng)對端正確接收到了該報文后，發(fā)現(xiàn)類型域為0x02的配置參數(shù)選項不識別，應(yīng)該回應(yīng)一個Config-Reject報文，報文內(nèi)容如下： 7E FF 03 C0 21 04 01 00 0A 02 06 00 0A 00 00 7E 該報文如果被原發(fā)送端接收后，又會重新發(fā)送一個Config-Request報文，報文內(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 這時我們能看到，類型域為02的配置選項在下一次的請求報文中被刪除了。所以我們能夠看出，鏈路配置階段也可能要經(jīng)過幾次協(xié)商后才能完成，但這與點對點兩端的設(shè)備有著密切的聯(lián)系。對于PPP的兩個端點而言，兩者是獨立完成各自的配置參數(shù)選項的協(xié)商過程的。具體的配置參數(shù)選項待后續(xù)的章節(jié)中講解。 3.1.2.4 LCP的鏈路終止報文 鏈路終止報文分為Terminate-Request和Terminate-Reply兩種報文。LCP報文中提供了一種機制來關(guān)閉一個點對點的連接，想要關(guān)斷鏈路的一端會持續(xù)發(fā)送Terminate-Request報文，直到收到一個Terminate-Reply為止。接收端一旦收到了一個Terminate-Request報文后，必須回應(yīng)一個Terminate-Reply報文，同時等待對端先將鏈路斷開后，再完成本端的所有斷開的操作。 LCP的鏈路終止報文的數(shù)據(jù)域與鏈路配置報文的數(shù)據(jù)域不一樣，鏈路終止報文中無需攜帶各配置參數(shù)選項。對于鏈路終止報文也同樣需要ID一致，當(dāng)接收到Terminate-Reply報文才會做鏈路終止操作。 3.1.2.5 LCP的鏈路維護報文 除上述兩種報文類型以外，剩余的所有報文類型均歸屬鏈路維護報文。 ?? 當(dāng)接收端發(fā)現(xiàn)LCP報文的代碼域是一個不合法的值時，將會向發(fā)送端回應(yīng)一個Code-Reject報文，在回應(yīng)報文中會將所拒絕報文的內(nèi)容附加上。 例5：假設(shè)點對點通信的一端發(fā)送了一個Config-Request報文，報文內(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 有下劃線的部分表示這個代碼域在標(biāo)準(zhǔn)中未定義，從而無法識別。 當(dāng)對端正確接收到了該報文后，發(fā)現(xiàn)LCP數(shù)據(jù)報文的代碼域為0x0E時，應(yīng)該發(fā)送一個 Code-Reject報文，報文內(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é)議域是一個不合法的值時，將會向發(fā)送端回應(yīng)一個Protocol-Reject報文，發(fā)送端收到該拒絕報文后將停止發(fā)送該種協(xié)議類型的數(shù)據(jù)報文了。Protocol-Reject報文只能在LCP的狀態(tài)機處于Opened狀態(tài)時才可被處理，而在其它狀態(tài)接收到該報文將被丟棄。在Protocol-Reject報文的數(shù)據(jù)域內(nèi)將攜帶所拒絕報文的協(xié)議類型和報文內(nèi)容。 例6：假設(shè)點對點通信的一端發(fā)送了一個協(xié)議域未定義（無法識別）的報文，報文內(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表示一個未定義的類型（也即對端無法識別）。當(dāng)對端正確接收到了該報文后，發(fā)現(xiàn)該報文的協(xié)議域為0x7777，該值未在RFC中未有明確定義，應(yīng)該發(fā)送一個Protocol-Reject報文，報文內(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報文和Echo-Reply報文主要用來檢測雙向鏈路上自環(huán)的問題， 除此之外還可附帶做一些鏈路質(zhì)量的測試和其它功能。當(dāng)LCP狀態(tài)機處于Opened狀態(tài)時，如果接收到了Echo-Request，就需向?qū)Χ嘶厮鸵粋€Echo-Reply報文。否則在其它LCP狀態(tài)下，該類型的報文會被丟棄。這種類型數(shù)據(jù)報文的長度域后不是直接跟數(shù)據(jù)域，而是要插入4個字節(jié)的Magic-Number（魔術(shù)字），該魔術(shù)字是在LCP的Config-Request的配置參 數(shù)選項協(xié)商時獲得的。 例7：假設(shè)點對點通信的一端接收到了一個Echo-Request報文，報文內(nèi)容如下： 7E FF 03 C0 21 09 01 00 08 02 06 00 0D 7E 有下劃線的部分表示魔術(shù)字。 當(dāng)對端正確接收到了該報文后，應(yīng)該發(fā)送一個Echo-Reply報文，報文內(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ù)報文是在網(wǎng)絡(luò)層協(xié)議階段被交換的，在這個階段所需的一些配置參數(shù)選項協(xié)商完后，就可以進行網(wǎng)絡(luò)層的通信，也即是在點對點的鏈路上可以開始傳送網(wǎng)絡(luò)層的數(shù)據(jù)報文了。NCP協(xié)議主要包括IPCP、IPXCP等，但我們在實際當(dāng)中最常遇見的也只有IPCP協(xié)議了，如果對IPXCP或其它的一些網(wǎng)絡(luò)控制協(xié)議有興趣，則可參見RFC1552。 3.1.3.1 IPCP IPCP控制協(xié)議主要是負(fù)責(zé)完成IP網(wǎng)絡(luò)層協(xié)議通信所需配置參數(shù)的選項協(xié)商的。IPCP在運行的過程當(dāng)中，主要是完成點對點通信設(shè)備的兩端動態(tài)的協(xié)商IP地址。我們依據(jù)兩端設(shè)備的配置選項可將IPCP的協(xié)商過程分為”靜態(tài)”和”動態(tài)”。何為靜態(tài)，何為動態(tài)，這是一個相對的概念，也是自已總結(jié)出來的，可能不太準(zhǔn)確，只作為參考使用。我們在下面會具體描述這兩個過程。IPCP的數(shù)據(jù)的文同LCP的數(shù)據(jù)報文非常類似，只不過一個是在網(wǎng)絡(luò)層協(xié)議階段協(xié)商 配置參數(shù)選項，而LCP協(xié)議則是在鏈路建立階段協(xié)商配置參數(shù)選項的。除此之外是兩者在所使用報文上的相似之處，我們知道LCP共包括十幾種報文，而IPCP也包括多種報文，但它的報文類型只是LCP數(shù)據(jù)報文的一個子集（只 有LCP代碼域從1到7這七種報文），而且實際的數(shù)據(jù)報文交換過程中也僅涉及以下幾種：Config-Request、Config-Ack、Config-Nak和Config-Reject（代碼域從1到4，而鏈路終止報文一般而言是不在網(wǎng)絡(luò)協(xié)議階段使用的，而且也是不需要的）。以下就具體介紹一下IPCP控制協(xié)議的靜態(tài)和動態(tài)的兩個過程， 實際上兩者的區(qū)分是在于互連設(shè)備IP地址的獲取過程。 ?? 靜態(tài)協(xié)商，也即是不協(xié)商。點對點的通信設(shè)備兩端在PPP協(xié)商之前已配 置好了IP地址，所以就無須在網(wǎng)絡(luò)層協(xié)議階段協(xié)商IP地址，而雙方唯一要做的就是告訴對方自身的IP地址。在IPCP控制協(xié)議完成整個配置的過程時，最理想的情況將會看到如圖所示的四種報文，而無其它報文再被發(fā)送。如果當(dāng)配置請求中所攜帶的網(wǎng)絡(luò)層配置參數(shù)選項類似于LCP配置參數(shù)選項協(xié)商過程一樣，可能會有對方不識別的配置參數(shù)選項或不被對 方所認(rèn)可的配置參數(shù)選項的內(nèi)容。這樣在這個階段的協(xié)商過程中可能還會看到其它的一些報文。 在靜態(tài)協(xié)商時，如果IPCP的Config-Request報文中只含有地址配置參數(shù)選項時（實際中可能還會附帶其它配置參數(shù)選項，這些配置參數(shù)選項的協(xié)商與LCP階段的一樣，而我這里只提到了IP地址配置參數(shù)選項），無論是發(fā)送方還是接收方都同時發(fā)送Config-Request報文，其中配置選項中只含有各自的IP地址。當(dāng)對端收到該報文后，會發(fā)送一個Config-Ack報文， 這個目的是告訴對端我已經(jīng)知道了你的IP地址，對路由器而言會增加一條到對端接口的主機路由。剛進入網(wǎng)絡(luò)層協(xié)議階段時，IPCP的狀態(tài)機是initial的，但當(dāng)完成了上述的整個過程后，IPCP的狀態(tài)機改變?yōu)镺pened，雙方也就可以開始網(wǎng)絡(luò)層數(shù)據(jù)網(wǎng)的傳送了。IPCP協(xié)議中并未規(guī)定，當(dāng)一端接收到Config-Request報文后，它從報文的配置參數(shù)選項中可獲知對端的IP地址，但并不與本端的IP地址進行比較.我們也知道，一般而言點對點的兩端應(yīng)該是在一個網(wǎng)段。但如果雙方的地址不在一個網(wǎng)段，就不給對方回應(yīng)Config-Ack報文，而是無條件的回送一個回應(yīng)報文。因此說點對點通信的兩端如果是手動設(shè)置每一端的IP地址時，無須雙方地址在同一網(wǎng)段。 例8：假設(shè)IPCP在網(wǎng)絡(luò)層協(xié)議階段開始協(xié)商配置參數(shù)選項（這里只舉協(xié)商IP地址的配置參 數(shù)選項地的過程），發(fā)送方設(shè)置IP地址為192.168.0.1，接收方設(shè)置IP地址為192.168.0.2， 發(fā)送方發(fā)送給Config-Request報文內(nèi)容如下： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 01 7E 在這個例子中我們能看見明顯的改變之處再于PPP協(xié)議域字段由原先的0xC021改變?yōu)?x8021，下劃線的部分表示本端的IP地址。 當(dāng)對端正確接收到了該報文后，應(yīng)該回應(yīng)一個Config-Ack報文，報文內(nèi)容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 01 7E 同樣的接收方給發(fā)送方也發(fā)送一個Config-Request報文內(nèi)容如下，但此時報文中IP地址配置參數(shù)選項的值為本端的IP地址（192.168.0.2）： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E 發(fā)送方回應(yīng)一個Config-Ack報文給接收方，報文內(nèi)容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E ?? 動態(tài)協(xié)商，也即是一端配置為動態(tài)獲取IP地址，另一端通過手動方式配置IP地址，且允許給對端分配IP地址，這個過程實際上可與窄帶撥號上網(wǎng)的過程相一致，如果我們想用計算機上網(wǎng)，均會安裝一個撥號適配器，而 且計算機中的撥號網(wǎng)絡(luò)適配器是采用動態(tài)獲取IP地址的方式。這個例子與一個例子相似，也就是在IPCP的Config-Request報文中只攜帶IP地址的配置參數(shù)選項。如果是配置參數(shù)選項中含有其它配置參數(shù)選項，則可能會遇到其它的一些情況（如不識別配置參數(shù)選項的代碼域或不認(rèn)可配置參數(shù)選項的內(nèi)容，但對于這些情況的處理方法和LCP配置參數(shù)選項的處理方法一致）。圖3-6中我們可以看出發(fā)送方連續(xù)發(fā)送了兩次Config-Request報文，才能完成發(fā)送方的協(xié)商過程。而接收方仍然只需要發(fā)送一次Config-Request即可完成本端的協(xié)商過程。 由于發(fā)送方?jīng)]有配置IP地址（而是動態(tài)獲取IP地址），所以在IPCP的Config-Request報文的IP地址配置參數(shù)配置選項中的IP地址填充全0（也即是0.0.0.0），這樣當(dāng)對端收到這個Config-Request報文時，當(dāng)接收方收到該配置請求報文后會迅檢測IP地址的內(nèi)容，如果發(fā)送為全0，則認(rèn)為對端的這個IP地址不是我所希望的值，這樣就回應(yīng)一個Config-Nak報文，并將希望分配給對方的IP地址填充到Config-Nak報文內(nèi)。這時當(dāng)接收方收到Config-Nak報文后，就會重新發(fā)送一個Config-Request報文，這個報文中的IP地址配置選項為對方在Nak報文中所提供的。接收方IP 地址的配置過程與靜態(tài)時的一樣， 只需發(fā)送一個Config-Request報文即可，當(dāng)收到發(fā)送方的Config-Ack報文，就表示接收方的IP地址配置完成。 例9： 假設(shè)IPCP在網(wǎng)絡(luò)層協(xié)議階段開始協(xié)商配置參數(shù)選項（這里只舉協(xié)商IP地址的配置參數(shù)選項地的過程），發(fā)送方?jīng)]有配置IP地址，而接收方配置了IP地址為192.168.0.2，接收方可給發(fā)送方分配IP地址（192.168.0.1），發(fā)送方發(fā)送給接收方的Config-Request報文內(nèi) 容如下： 7E FF 03 80 21 01 01 00 0A 03 06 00 00 00 00 7E 有下劃線的部分表示本端的IP地址。 當(dāng)對端正確接收到了該報文后，應(yīng)該回應(yīng)一個Config-Nak報文，報文內(nèi)容如下： 7E FF 03 80 21 03 01 00 0A 03 06 C0 A8 00 01 7E 當(dāng)接收方收到該報文后，重新發(fā)送一個Config-Request報文，報文內(nèi)容如下： 7E FF 03 80 21 01 02 00 0A 03 06 C0 A8 00 01 7E 接收方再次收到發(fā)送方的一個Config-Request報文，此時將回應(yīng)一個Config-Ack報文，報文內(nèi)容如下： 7E FF 03 80 21 02 02 00 0A 03 06 C0 A8 00 01 7E 請仔細(xì)觀察一下這些報文在交互過程中，PPP數(shù)據(jù)幀凈載荷內(nèi)的數(shù)據(jù)報文的類型域和報文 ID。同樣的接收方給發(fā)送方也發(fā)送一個Config-Request報文，報文內(nèi)容如下： 7E FF 03 80 21 01 01 00 0A 03 06 C0 A8 00 02 7E 發(fā)送方應(yīng)回送一個Config-Ack給接收方，報文內(nèi)容如下： 7E FF 03 80 21 02 01 00 0A 03 06 C0 A8 00 02 7E 本章節(jié)的一些內(nèi)容可能沒有明確寫出，只是將IPCP配置參數(shù)選項配置過程中最關(guān)鍵的部分做了一些說明，如果想深入了解決IPCP或IPXCP，可參見相關(guān)的RFC文檔。 3.2 總結(jié) ?? PPP協(xié)議的狀態(tài)轉(zhuǎn)移圖包括鏈路不可用階段、鏈路建立階段、認(rèn)證階段、 網(wǎng)絡(luò)層協(xié)議階段和鏈路終止階段 ?? LCP協(xié)議依據(jù)報文的功能可分為鏈路配置報文、鏈路終止報文和鏈路維 ?? LCP協(xié)議的鏈路配置報文主要是用來協(xié)商一些可選的配置參數(shù)選項 ?? LCP協(xié)議的鏈路終止報文主要是用來終止一條PPP鏈路 ?? LCP協(xié)議的鏈路維護報文主要是用來測試和調(diào)試PPP鏈路 ?? NCP協(xié)議主要負(fù)責(zé)網(wǎng)絡(luò)層配置參數(shù)選項的協(xié)商，它包括”靜態(tài)協(xié)商”和”動態(tài)協(xié)商 第四章 LCP的可選配置參數(shù) 4.1 LCP的參數(shù)配置選項 LCP協(xié)議在對鏈路配置過程中需要進行一些可選配置參數(shù)選項的協(xié)商，我們在前面講述的過程中已列舉了許多配置參數(shù)選項，但我們只挑選其中較為重要的幾個參數(shù)做相應(yīng)的擴展說明（魔術(shù)字和認(rèn)證協(xié)議選項）。關(guān)于一些更具體的細(xì)節(jié)和未涉及到的配置參數(shù)選項，請參數(shù)PPP的RFC文檔（RFC1661）。 4.1.1 魔術(shù)字（Magic-Number） 魔術(shù)字是在LCP的Config-Request報文中被協(xié)商的，并且可被其它一些其它類型的LCP數(shù)據(jù)報文所使用，如前面已經(jīng)說過的Echo-Request、Echo-Reply報文和Quality-Protocol報文等。對于PPP協(xié)議本身它是不要求協(xié)商魔術(shù)字的，如果在雙方不協(xié)商魔術(shù)字的情況下，某些LCP的數(shù)據(jù)報文需要使用魔術(shù)字時，那么只能是將魔術(shù)字的內(nèi)容填充為全0；反之，則填充為配置參數(shù)選項協(xié)商后的結(jié)果。魔術(shù)字在目前所有的設(shè)備當(dāng)中都是需要進行協(xié)商的， 它被放在Config-Request的配置選項參數(shù)中進行發(fā)送，而且需要由自身的通信設(shè)備獨立產(chǎn)生，協(xié)議為了避免雙方可能產(chǎn)生同樣的魔術(shù)字，從而導(dǎo)致通信出現(xiàn)不必要的麻煩，因此要求由設(shè)備采用一些隨機方法產(chǎn)生一個獨一無二的魔術(shù)字。一般來說魔術(shù)字的選擇會采用設(shè)備的系列號、網(wǎng)絡(luò)硬件地址或時鐘。雙方產(chǎn)生相同魔術(shù)字的可能性不能說是沒有的，但應(yīng)盡量避免，通常這種情況是發(fā)產(chǎn)在相同廠商的設(shè)備進行互連時，因為一個廠商所生產(chǎn)的設(shè)備產(chǎn)生魔術(shù)字的 方法是一樣的。 我們知道魔術(shù)字產(chǎn)生的作用是用來幫助檢測鏈路是否存在環(huán)路，當(dāng)接收端收到一個Config-Request 報文時， 會將此報文與上一次所接收到的Config-Request進行比較，如果兩個報文中所含的魔術(shù)字不一致的話，表明鏈路不存在環(huán)路。但如果一致的話，接收端認(rèn)為鏈路可能存在環(huán)路，但不一定存在環(huán)路，還需進一步確認(rèn)。此時接收端將發(fā)送一個Config-Nak報文，并在該報文中攜帶一個重新產(chǎn)生的魔術(shù)字， 而且此時在未接收到任何 Config-Request 或Config-Nak 報文之前， 接收端也不會發(fā)送任何的Config-Request報文。這時我們假設(shè)可能會有以下兩種情況發(fā)生： ?? 鏈路實際不存在環(huán)路，而是由于對方在產(chǎn)生魔術(shù)字時與接收端產(chǎn)生的一致，但實際這種情況出現(xiàn)的概率是很小的。當(dāng)Config-Nak被對端接收到后，應(yīng)該發(fā)送一個Config-Request報文（此報文中的魔術(shù)字為Nak報文中的），當(dāng)對端接收到后，與上次比較，由于接收端已經(jīng)在Nak報文中產(chǎn)生了一個不同的魔術(shù)字，此時接收端收到的Config-Request報文中的魔術(shù)字與上次配置請求報文中不一樣，所以接收端可斷定鏈路不存在環(huán)路。 ?? 鏈路實際上確實存在環(huán)路，一段時間后Config-Nak報文會返回到發(fā)送該報文的同一端。這時接收端比較這個Config-Nak報文與上一次發(fā)出去的一樣，因此鏈路存在環(huán)路的可能性又增大了。我們知道當(dāng)一端收到了一個Config-Nak報文時，又會發(fā)送一個Config-Request報文（該報文中的魔術(shù)字與Config-Nak中的一致），這樣又回到了最初的狀態(tài)，在這條鏈路 上就會不斷的出現(xiàn)Config-Request、Config-Nak報文，因此這樣周而復(fù)始下去，接收端就會認(rèn)為PPP鏈路存在環(huán)路的可能性在不斷增加，當(dāng)達(dá)到一定數(shù)量級時，就可認(rèn)為此鏈路存在環(huán)路。但在實際應(yīng)用中根據(jù)不同設(shè)備實現(xiàn)PPP協(xié)議的方法，我們在鏈路環(huán)路檢測時可采用兩種方法。第一種機制就是如上面所述的，這個過程不斷地重復(fù)，最終可能會給LCP狀態(tài)機發(fā)一個Down事件，這時可能會使LCP的狀態(tài)機又回到初始化階段，又開始新一輪的協(xié)商。當(dāng)然對于某些設(shè)備還會采用第二種機制，就是不產(chǎn)生任何事件去影響當(dāng)前LCP的狀態(tài)機，而 是停留在請求發(fā)送狀態(tài)。但這時認(rèn)為鏈路有環(huán)路的一端設(shè)備需要不斷的向鏈路上發(fā)送Echo-Request報文來檢測鏈路環(huán)路是否被解除，當(dāng)接收端收到Echo-Reply報文時，就認(rèn)為鏈路環(huán)路被解除，從而就可能進行后續(xù)的PPP的過程。 4.1.2 認(rèn)證協(xié)議 PPP協(xié)議也提供了可選的認(rèn)證配置參數(shù)選項，缺省情況下點對點通信的兩端是不進行認(rèn)證的。在LCP的Config-Request報文中不可一次攜帶多種認(rèn)證配置選項，必須二者擇其一（PAP/CHAP），選擇最希望的那一種，一般是在PPP設(shè)備互連的設(shè)備上進行配置的，但一般設(shè)備會默認(rèn)支持一個缺省的認(rèn)證方式（PAP是大部分設(shè)備所默認(rèn)的