任何第3層的協議要通過撥號或者專用鏈路穿越廣域網時，都必須封裝一種數據鏈路層的協議（比如，PPP、SLIP——串行鏈路Internet協議、ARAP——AppleTalk遠程接入協議）。儘管某些公司仍然使用Novell IPX和AppleTalk協議爲主機提供遠程接入，但是TCP/IP已經成爲了今天企業網中使用的主要協議。
今天，在廣域網的數據鏈路層主要有兩種用於封裝TCP/IP的協議：SLIP和PPP
SLIP——使用TCP/IP進行點對點連接的標準協議。SLIP是PPP的前身，因其只支持IP協議和異步傳輸方式而且沒有驗證機制，所以已經很少在新設計的網絡中出現了。
PPP——點對點協議，通過異步或同步電路提供路由器到路由器或者主機到網絡的連接。這些電路可能是撥號或者租用線路。
PPP支持IP、IPX和AppleTalk等多種網絡層協議，還支持如下特性：
同步/異步傳輸方式
動態地址分配
PAP認證
CHAP認證
MLP（多鏈路捆綁）
本篇文章描述的就是這個PPP協議。
PPP的分層結構：
 |
PPP協議的運行分爲四個階段：
第一階段：建立鏈路（LCP）
第二階段：驗證（PAP/CHAP）
第三階段：網絡控制協商（NCP）
第四階段：終止PPP鏈路（LCP）
PPP協議工作的第一階段我們稱爲鏈路建立的階段，在這個階段中PPP首先使用LCP（鏈路控制協議）在鏈路兩端建立連接。在該階段中PPP不只是在數據鏈路層搭建鏈路而且還在鏈路的兩端動態協商一些參數，比如雙方使用的認證方式、是否支持壓縮和MLP（多鏈路捆綁）等。
LCP若要完成建立、配置、測試和終止數據鏈路連接的工作就需要通信兩端互相交換LCP報文。那都有哪幾類LCP報文呢？LCP報文基本上有三類：
鏈路配置報文——用來建立和配置一條鏈路
鏈路維護報文——用來維護和調試鏈路
鏈路終止報文——用來終止一條鏈路
LCP協議在鏈路兩端建立連接時還會經歷4種狀態，如果一切進行順利的話，隨着這4種狀態的結束，鏈路兩端的連接將會搭建成功。
第1種狀態機：“Initial（初始化狀態）”或“Starting（準啓動狀態）”
該狀態機發生在鏈路無效階段：該階段雙方物理連接已搭建好，但通信的兩端沒有激活（封裝）PPP，或者物理連接根本就沒有搭建好。
第2種狀態機：Request-Sent（請求發送）
第3種狀態機：Ack-Sent（確認發送）
第4種狀態機：Open（打開）
除了第1種狀態機，其餘3種狀態機都發生在第一階段(鏈路的建立階段)。
鏈路建立階段：當通信雙方的兩端都檢測到鏈路上有載波信號時，且雙方都已封裝了PPP協議就標誌着通信的兩端已進入到鏈路建立階段了。該階段的通信發生在數據鏈路層，也是PPP協議最爲關鍵和複雜的階段。在這個階段首先鏈路兩端的LCP會由鏈路無效階段的“Initial”或“Starting”狀態過渡到“Request-Sent（請求發送）”狀態。在Request-Sent（請求發送）狀態下，雙方會發送上面提到的LCP三種報文中的“鏈路配置報文”。鏈路配置報文又細分以下四種：
1、Config-Request（配置請求）
2、Config-Ack（配置確認）
3、Config-NAK（配置非確認）
4、Config-Reject（配置拒絕）
在“Request-Sent（請求發送）”狀態下，通信雙方的任何一方都會先發送Config-Request報文。Config-Request報文結構如下：
Code：Configuration Request (0x01)
Identifier：0x00
Length：17
Options：(13 bytes)
Maximum Receive Unit：1480
Magic number：0x7a9b5da2
Callback：3 bytes
Operation：Location is determined during CBCP negotiation (0x06)
報文中的Code(代碼)後面添寫的是報文的名稱，如本例中的報文是“Configuration Request (0x01) (配置請求)”報文。
“Identifier”指的是“標識”，每個鏈路配置報文都會攜帶一個“標識”，雙方在建立連接的過程中可能要發送多個Config-Request報文，這個“標識”會區別本方或對方發送的這些Config-Request報文，第一個Config-Request 報文的“標識”通常由“0x00”開始，那第二Config-Request報文的標識就變爲了“0x01”，以此類推……；
“Length”表明這個“Config-Request”報文的長度，本例爲17字節；
“Options(選項)”用於動態協商一些參數，比如本例中的Maximum Receive Unit(最大接收單元)、Magic number(魔術字)、Callback(回撥)等等；
通信兩端中的任何一方收到Config-Request報文後，各自的LCP狀態機就立即由“Request-Sent（請求發送）”狀態進入“Ack-Sent（確認發送）”狀態。處於“Ack-Sent（確認發送）”狀態中的一方會向對方發送“Config-Ack（配置確認）”報文。Config-Ack（配置確認）報文結構如下：
Code：Configuration Ack (0x02)
Identifier：0x01
Length：17
Options：(13 bytes)
Maximum Receive Unit：1480
Magic number：0x7a9b5da2
Callback：3 bytes
Operation：Location is determined during CBCP negotiation (0x06)
從以上兩個“鏈路配置報文”結構可以看出Config-Ack（配置確認）報文與Config-Request（配置請求）報文不同之處在於“Code(代碼)”這個字段後填寫的內容。從這兩個報文可以看出發送方的“Code(代碼)”是“0x00”，而接收方回覆的“Code(代碼)”是“0x01”，其他字段沒有什麼不同。無論通信雙方的哪一端接收到對端發送的Config-Ack報文，接收方的LCP的狀態機都會發生改變，LCP狀態機就從當前的“Ack-Sent（確認發送）”狀態進入到最後的opened(打開)狀態。
前面的內容中我們看到LCP協議的選項字段會協商雙方的認證方式，比如協商雙方使用PAP還是CHAP等。缺省(默認)情況下鏈路兩端的設備是不需要進行認證的，如果通信的雙方沒有配置任何認證方式，而且雙方也不需要NCP協議來協商如何分配IP地址的問題，雙方僅僅只是想通過PPP實現數據鏈路層的連接而已，那麼鏈路兩端的設備在經歷了前面提到的LCP四種狀態後就已經完成了鏈路層的連接了。可是多數情況下，鏈路兩端設備都會出於安全方面的考慮進行PPP認證，也就是進行PAP或CHAP協商。關於PAP或CHAP的協商驗證在後面還會詳細說明。除此之外雙方可能還要在LCP選項字段中協商一些其他參數，比如是否支持壓縮、多鏈路捆綁、回撥等參數。下面我們就來看看LCP選項中的這些參數是如何進行協商的。
通信兩端收到對方發送的“Config-Request（配置請求）”報文後，會查看該報文中的選項字段。比如通信兩端的設備分別爲A和B，設備A發送的“Config-Request（配置請求）”報文的選項字段需要協商認證方式(CHAP)、最大傳輸單元這兩項。設備B發送的“Config-Request（配置請求）”報文中的選項需要協商認證方式(PAP)、最大傳輸單元和回撥這三項。當A收到B發送的“Config-Request（配置請求）”報文後，由於A並不支持回撥這一屬性，所以A會向B發送“鏈路配置報文”中的第四種報文——Config-Reject（配置拒絕）報文。“Config-Reject（配置拒絕）”報文表明接收方對於發送方發送的“Config-Request（配置請求）”報文中選項提到的某個配置參數不予接受。比如本例中的A會通過“Config-Reject”報文向B通告“回撥”這個屬性是A所不能接受的。B接收到A發送的“Config-Reject”報文後，會再向A發送一個“Config-Request（配置請求）”報文，在該報文中B會將選項中的“回撥”屬性刪除。如果此時A和B雙方採用的認證方式也不同(假如A使用CHAP進行認證而B使用PAP進行認證)，那麼A或B會向對方發送“鏈路配置報文”中的第三種報文——Config-NAK（配置非確認）報文。“Config-NAK（配置非確認）”與“Config-Reject（配置拒絕）”的區別是：當接收到“Config-Request（配置請求）”報文的一端能夠識別發送方所發送過來的所有配置參數，但對某些配置參數中的具體協商內容不認可時，接收方將會給對端迴應一個“Config-Nak（配置非確認）”報文。而“Config-Reject（配置拒絕）”報文是對收到的“Config-Request（配置請求）”報文中的某些配置參數不認可（而不是參數中的具體內容不認可）而向對方發送的報文。比如前面提到的A對B發送過來的“回撥”參數不認可，所以A向B發送“Config-Reject（配置拒絕）”報文表明自己對“回撥”這一參數不予接受。再比如本例中A又向B發送了“Config-Nak（配置非確認）”報文，說明A對B發送的“Config-Request（配置請求）”報文中提到的“認證”這一參數是認可的，但對B在“認證”這一參數中使用“PAP進行認證”不予接受，所以A才向B發送“Config-Nak（配置非確認）”報文。該報文中的選項會攜帶A所支持的認證協議——CHAP這個參數。B收到該“Config-Nak（配置非確認）”報文後就會向A再發送另一個“Config-Request（配置請求）”報文，在這個“Config-Request（配置請求）”報文中B將自己原來的PAP認證方式更改爲A支持的CHAP認證方式(當然，前提是設備B已經被管理員配置爲可同時支持PAP和CHAP兩種認證方式，而A只支持CHAP認證)，最後A再向B發送一個“Config-Ack（配置確認）”報文，對雙方使用的CHAP這種認證方式表示同意和確認。經過設備A和設備B這樣地反覆協商和交互，通信雙方在LCP子層的協商最終完成。如果雙方在這個協商過程中出現了協商配置參數不匹配、不統一或協商配置參數匹配但參數中的具體內容不匹配都會導致協商失敗。從LCP協商的過程看，雙方秉承的基本原則是“求同摒異”。
待續……