嵌入式PPPoE軟件模塊的設計與實(shí)現

基于以太網(wǎng)的點(diǎn)對點(diǎn)通信協(xié)議PPPoE(Point to Point Protocol over Ethenet)是為了滿(mǎn)足越來(lái)越多的寬帶上網(wǎng)設備(如ADSL、無(wú)線(xiàn)、有線(xiàn)電視等)和越來(lái)越快的網(wǎng)絡(luò )之間的通信而指定開(kāi)發(fā)的標準，它給出了兩個(gè)廣泛接受的標準：以太網(wǎng)和PPP撥號協(xié)議。不難看出，PPPoE就是將PPP數據承載到以太網(wǎng)上，實(shí)質(zhì)是在共享介質(zhì)的網(wǎng)絡(luò )中提供一條邏輯上的點(diǎn)到點(diǎn)鏈路。對用戶(hù)而言，在DSLAM(DSL匯聚設備)與ADSL Modem之間的ATM傳輸是透明的，如果將中間的DSLAM和ADSL Modem換成有線(xiàn)電視的接入設備，就是典型的HFC接入。BAS(寬帶接入服務(wù)器)對PPPoE包的處理方式不變。而對于服務(wù)商，在現有局域網(wǎng)基礎上不需要花費巨資做大面積改造。

目前，實(shí)現PPPoE協(xié)議的軟件有多種，且多數都是應用于PC機。該類(lèi)軟件的作用主要是在操作系統的撥號(PPP)協(xié)議與以太網(wǎng)協(xié)議建立連接，通過(guò)PPPoE協(xié)議與ISP連接，獲得Internet連接服務(wù)。而本文考慮到嵌入式系統的特點(diǎn)，直接在網(wǎng)絡(luò )協(xié)議數據鏈路層實(shí)現PPPoE協(xié)議。這樣做省去了鏈路層的PPP包到PPPoE包的轉換，提高了效率，并且具有良好的可移植性。

1 PPPoE協(xié)議框架[1]

PPPoE協(xié)議共包括兩個(gè)階段[1]，即PPPoE的發(fā)現階段(PPPoE Discovery Stage)和PPPoE的會(huì )話(huà)階段(PPPoE Session Stage)。本文著(zhù)重介紹PPPoE發(fā)現階段。對于PPPoE會(huì )話(huà)階段，可以看成與PPP的會(huì )話(huà)過(guò)程基本一樣，當然兩者在數據的封裝上還是有區別的。PPPoE并不需要PPP協(xié)議中的起始位標志、地址位、控制位和結束標志，也不需要PPP協(xié)議中規定的數據轉譯和CRC校驗，但要在PPP的數據報文前封裝PPPoE的報文頭。無(wú)論是哪一個(gè)階段的數據報文最終會(huì )被封裝成以太網(wǎng)幀傳送。

如果主機要開(kāi)始一個(gè)PPPoE會(huì )話(huà)，它首先會(huì )在網(wǎng)絡(luò )上發(fā)送一個(gè)廣播，通過(guò)廣播尋找一個(gè)訪(fǎng)問(wèn)集中器AC(Access Concentration)。當網(wǎng)絡(luò )上存在多個(gè)訪(fǎng)問(wèn)集中器時(shí)，主機根據訪(fǎng)問(wèn)集中器所能提供的服務(wù)或用戶(hù)預先配置的信息進(jìn)行相應的選擇。訪(fǎng)問(wèn)集中器選定后，主機開(kāi)始與所選擇的訪(fǎng)問(wèn)集中器建立一個(gè)PPPoE會(huì )話(huà)進(jìn)程。在這一過(guò)程中，訪(fǎng)問(wèn)集中器會(huì )為每一個(gè)PPPoE會(huì )話(huà)分配一個(gè)惟一的進(jìn)程ID，會(huì )話(huà)建立后就開(kāi)始了PPPoE的會(huì )話(huà)階段。在這個(gè)階段，已建立好點(diǎn)對點(diǎn)(邏輯點(diǎn)對點(diǎn))連接的雙方采用PPP協(xié)議交換數據報文，從而完成一系列PPP的過(guò)程，最終將在這個(gè)點(diǎn)對點(diǎn)的邏輯通道上進(jìn)行網(wǎng)絡(luò )層數據包的傳送。

PPPoE可以理解為在以太網(wǎng)上跑PPP數據，因此，其幀格式[1]與以太幀格式一致，如圖1所示。通過(guò)類(lèi)型域字段的內容，數據包的接收方可以識別以太網(wǎng)的數據域中承載的是什么協(xié)議的數據報文。PPPoE的兩大階段，也正是通過(guò)以太網(wǎng)的類(lèi)型域進(jìn)行區分的。這個(gè)域的值，在發(fā)現階段為0x8863，而在會(huì )話(huà)階段為0x8864。

PPPoE幀的載荷字段承載PPPoE數據報文[1]，報文格式如圖2所示，其中各字段的含義如下：

(1)版本字段(ver)標志著(zhù)協(xié)議版本信息，為4bits，目前協(xié)議規定其值為0x1。

(2)類(lèi)型字段(type)，4bits，標志類(lèi)型信息，值為0x1。

(3)編碼字段(code)，單個(gè)字節，在不同階段具有不同取值，本文稍候詳細分析。

　　(4)會(huì )話(huà)ID字段(session id)由兩個(gè)字節組成，在發(fā)現階段，取值為0x0000，在后續的整個(gè)PPPoE會(huì )話(huà)過(guò)程中取值為發(fā)現階段所獲得的由AC分配的惟一值。

(5)長(cháng)度字段(length)由兩個(gè)字節組成，指示payload字段的長(cháng)度，取值可以是0～1500。

(6)凈載荷字段(payload)，該字段存放PPPoE協(xié)議幀所承載的數據，在發(fā)現階段承載零個(gè)或多個(gè)TAG結構[1]，在會(huì )話(huà)階段承載PPP協(xié)議數據。但不是簡(jiǎn)單的PPP封裝，因為并不需要PPP協(xié)議中的起始位標志、地址位、控制位和結束標志，也不需要PPP協(xié)議中規定的數據轉譯和CRC校驗。TAG結構如圖3所示。


2 PPPoE協(xié)議分析

PPPoE協(xié)議分為發(fā)現(Discovery)階段和會(huì )話(huà)(Session)階段。發(fā)現階段是一個(gè)無(wú)狀態(tài)的階段，該階段主要選擇訪(fǎng)問(wèn)集中器，確定所要建立的PPP會(huì )話(huà)標識符Session ID，同時(shí)獲得對方點(diǎn)到點(diǎn)的連接信息；PPP會(huì )話(huà)階段執行標準的PPP過(guò)程。

(1) 發(fā)現階段

一個(gè)典型的發(fā)現階段分為四個(gè)步驟，當整個(gè)發(fā)現階段結束后，通信雙方分別獲得對方的MAC地址，并且共用一個(gè)Session ID，這兩個(gè)參數共同確定一個(gè)PPPoE會(huì )話(huà)。

第一步，發(fā)送PADI(PPPoE Active Discovery Initiation)幀。在PPPoE的以太幀結構中，編碼域的值為0x09，會(huì )話(huà)ID域的值設為0x0000。在這個(gè)步驟中，以太幀目的地址為廣播并且在包中必須包含一個(gè)確切的服務(wù)名。

第二步,接收PADO(PPPoE Active Discovery Offer) 幀。這一過(guò)程就是當ISP的PPPoE訪(fǎng)問(wèn)集中器收到PADI幀后，若能夠滿(mǎn)足PADI提出的服務(wù)請求，可以發(fā)送PADO幀回應。PADO幀中的目的地址為發(fā)送PADI幀的客戶(hù)端的MAC地址，源地址為響應PADO幀的服務(wù)器地址。編碼域的值為0x07，會(huì )話(huà)ID域的值也設為0x0000。PADO幀還要包括PADI幀所提出的服務(wù)項。

第三步，發(fā)送PADR(PPPoE Active Discovery Request) 幀。由于PADI包是廣播式的，故主機可能收到多個(gè)PADO響應幀。主機在可能收到的多個(gè)PADO幀中根據訪(fǎng)問(wèn)集中器的名稱(chēng)標簽或能提供的服務(wù)標簽選擇一個(gè)合適的訪(fǎng)問(wèn)集中器，然后向所選擇的訪(fǎng)問(wèn)集中器發(fā)送PPPoE有效發(fā)現請求(PADR) 幀。其編碼域為0x19，Session ID域仍為0x0000，PADR幀必須包含一個(gè)服務(wù)名稱(chēng)類(lèi)型標簽，確定向接入服務(wù)器請求的服務(wù)種類(lèi)。

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

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

(2)會(huì )話(huà)階段

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

3 PPPoE模塊軟件設計

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

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

PPPoE會(huì )話(huà)階段是一個(gè)標準的PPP協(xié)商過(guò)程。整個(gè)協(xié)商過(guò)程分為三部分：LCP Negotiation、PAP Negotiation、IPCP Negotiation。

LCP階段[2]主要通過(guò)交換數據包與訪(fǎng)問(wèn)集中器建立和配置鏈路，LCP流程如圖6所示。由于ISP提供商可能會(huì )不同，所接收到的LCP_REQ中包含的選項也可能不同，但其中必然包括OPTION3，表示鏈路所用的認證協(xié)議(Authentication Protocol)。實(shí)踐中根據與ISP的PPPoE過(guò)程的數據包分析，多數ISP采用PAP(Password Authentication Protocol)認證協(xié)議。也有的ISP采用CHAP(Challenge Handshake Authentication Protocol)認證協(xié)議，雙方可以通過(guò)協(xié)商采用合適的認證協(xié)議，本文采用PAP。

PAP協(xié)商[3]過(guò)程比較簡(jiǎn)單，發(fā)送PAP請求數據包，其中包括賬號和密碼，ISP返回確認數據包，PAP協(xié)商過(guò)程結束。

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

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

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