點對點通信協(xié)議PPPoE模塊的設(shè)計

　　第四步，接收PADS(PPPoE Active Discovery Sessionconfirmation)幀。訪問集中器收到PADR幀后開始PPP會話，它發(fā)送一個PPPoE有效發(fā)現(xiàn)會話確認(PADS)幀。其編碼域為0x65，會話ID域此時為接入服務(wù)器所產(chǎn)生的惟一PPPoE會話標(biāo)識號碼。PADS幀也必須包含一個訪問集中器名稱類型的標(biāo)簽，確認向主機提供的服務(wù)。當(dāng)主機收到PADS幀確認后，雙方進入PPP會話階段。若訪問集中器不能提供PADR中的服務(wù)名稱標(biāo)簽所定義的服務(wù)，它必須回復(fù)PADS幀，此幀必須包含標(biāo)簽類型Sevice-Name-Error的標(biāo)簽，此時SESSION_ID必須為0x0000。

　　在完成上述步驟后，雙方進入會話階段。會話建立后，會話雙方任何一方都可以通過發(fā)送PADT(PPPoE active discover terminate)幀終止會話。PADT幀中的編碼字段值為0xA7,SEEION_ID字幀為在發(fā)現(xiàn)階段結(jié)束之后得到的會話ID值，以太幀類型字段還是0x8863。發(fā)送PADT后則該次PPPoE過程結(jié)束。

　　2)會話階段

　　當(dāng)PPPoE會話開始后，PPP數(shù)據(jù)就像普通的PPP數(shù)據(jù)被傳送，這時以太幀的目的地址是單播地址，類型為0x8864，編碼域必須是0x00，SESSION_ID必須是發(fā)現(xiàn)階段建立的SESSION_ID，且在會話過程中不能改變。PPPoE凈載荷是PPP幀，會話過程實際上也就是實現(xiàn)PPP協(xié)議的過程，PPP分為三個階段。首先通過LCP完成相關(guān)鏈路控制協(xié)商過程，主要是建立、配置、測試數(shù)據(jù)鏈路，根據(jù)雙方的需求，進行鏈路的協(xié)商和配置。PAP密碼認證后，通過NCP，針對不同的網(wǎng)絡(luò)層協(xié)議的網(wǎng)絡(luò)控制階段。最后就是IP數(shù)據(jù)的傳輸階段。

　　3 PPPoE模塊軟件設(shè)計

　　應(yīng)用于嵌入式系統(tǒng)的PPPoE軟件模塊主要通過系統(tǒng)中的以太網(wǎng)絡(luò)驅(qū)動在鏈路層與訪問集中器建立一個邏輯上點對點的通信鏈路，為上層TCP/IP協(xié)議棧服務(wù)。發(fā)送數(shù)據(jù)時，將上層IP分組封裝成PPPoE協(xié)議幀發(fā)送出去。在接收數(shù)據(jù)時，將接收到的PPPoE協(xié)議幀解析后，交由上層模塊處理，如圖4所示。與訪問集中器建立通信鏈路的過程是軟件設(shè)計的核心部分。

　　PPPoE發(fā)現(xiàn)階段流程如圖5所示。發(fā)現(xiàn)階段分為四個過程完成：發(fā)送PADI、接收PADO、發(fā)送PADR和接收PADS。在發(fā)送PADI和PADR時要分別定時和計數(shù)，在有限的時間內(nèi)沒有收到響應(yīng)，就應(yīng)重新發(fā)送;如果在重復(fù)發(fā)送若干次之后還沒有相應(yīng)，說明此時網(wǎng)絡(luò)故障或者網(wǎng)絡(luò)上沒有能夠響應(yīng)請示的服務(wù)器。

　　PPPoE會話階段是一個標(biāo)準的PPP協(xié)商過程。整個協(xié)商過程為三部分：LCP Negotiation、PAP Negotiation、IPCP Negotiation。 LCP階段主要通過交換數(shù)據(jù)包與訪問集中器建立和配置鏈路，LCP流程如圖6所示。由于ISP提供商可能會不同，所接收到的LCP_REQ中包含的選項也可能不同，但其中必然包括OPTION3，表示鏈路所用的認證協(xié)議(Authentication Protocol)。實踐中根據(jù)與ISP的PPPoE過程的數(shù)據(jù)包分析，多數(shù)ISP采用PAP(Password Authentication Protocol)認證協(xié)議。也有的ISP采用CHAP(Challenge Handshake Authentication Protocol)認證協(xié)議，雙方可以通過協(xié)商采用合適的認證協(xié)議，本文采用PAP。

　　PAP協(xié)商過程比較簡單，發(fā)送PAP請求數(shù)據(jù)包，其中包括幀號和密碼，ISP返回確認數(shù)據(jù)包，PAP協(xié)商過程結(jié)束。

　　IPCP階段的目的是獲取ISP方提供的IP地址，流程如圖7所示。所以在IPCP階段的協(xié)商主要針對OPTION3進行。PPPoE模塊首先接收服務(wù)器端一個IPCP_REQ，這個IPCP_REQ包括OPTION3(其IP地址值通常無效);接著PPPoE模塊發(fā)送一個IPCP_ACK,ISP方會響應(yīng)一個帶有有效地址的IPCP_NAK;然后PPPoE模塊就以這個地址再發(fā)一個IPCP_REQ，ISP服務(wù)器回應(yīng)IPCP_ACK，IPCP結(jié)束。此時PPPoE模塊得到限服務(wù)器分配的有效I守址，隨后就可以在PPPoE協(xié)議之上傳送IP數(shù)據(jù)包。需要注意的是，在PPP協(xié)商過程結(jié)束后，服務(wù)器為了檢驗接入方鏈路的活動狀態(tài)，會定期發(fā)出LCP EchoRequest請求，此時PPPoE模塊需要發(fā)送LCP Echo-ACK作為應(yīng)答。

　　嵌入式系統(tǒng)程序設(shè)計的特點是面向特定應(yīng)用，由于資源有限，軟件必須去除冗余。本PPPoE模塊應(yīng)用在以太電話中，在程序模塊設(shè)計中針對性地實現(xiàn)PPPoE協(xié)議的主要功能，盡量使代碼短小精悍，如省略掉了PPPoE發(fā)現(xiàn)階段網(wǎng)絡(luò)上有多個AC的情況，還省略了在會話階段對于LCP OPTION3(認證協(xié)議)以外選項的協(xié)商和IPCP PTION3(IP地址)以外的選項的協(xié)商等情況。它些情況，PPPoE模塊需要更多的代碼來處理，而對于以太話機這種特定的應(yīng)用，有些選項是不必要的。另外，在軟件結(jié)構(gòu)設(shè)計中，采用“超循環(huán)”結(jié)構(gòu)來解決無操作系統(tǒng)問題，可以很好地實現(xiàn)以太話機中的任務(wù)調(diào)度功能。在代碼編寫上，采用C和匯編相結(jié)合的方法提高程序效率，同時采用流水操作、Inline、全局變量和共享內(nèi)存等技術(shù)實現(xiàn)代碼長度和數(shù)據(jù)空間的優(yōu)化。測試表明，實現(xiàn)PPPoE軟件所需的代碼空間和數(shù)據(jù)空間都比PC機環(huán)境下PPPoE軟件代碼要小得多。

　　PPPoE協(xié)議是當(dāng)今ADSL寬帶接入Internet的主要技術(shù)之一，而嵌入式技術(shù)是如今IT技術(shù)發(fā)展的熱點，廣泛應(yīng)用于信息家電和各種媒體通信終端設(shè)備。本文在對PPPoE協(xié)議深入分析的基礎(chǔ)上，結(jié)合嵌入式系統(tǒng)的特點，提出了PPPoE在嵌入式系統(tǒng)上的具體實現(xiàn)方法，通過運用這些優(yōu)化方法，使軟件代碼空間和數(shù)據(jù)空間大大減少。目前該軟件模塊已成功應(yīng)用在筆者自己開發(fā)的以太話機中。實際運行表明，軟件運行穩(wěn)定、互通性好，所實現(xiàn)的PPPoE協(xié)議軟件具有良好的應(yīng)用價值。