《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 通信與網(wǎng)絡(luò) > 業(yè)界動(dòng)態(tài) > 嵌入式PPPoE軟件模塊的設(shè)計(jì)與實(shí)現(xiàn)

嵌入式PPPoE軟件模塊的設(shè)計(jì)與實(shí)現(xiàn)

2008-08-25
作者:張 鋒1, 李 彤1, 黃永峰2

  摘 要: 分析了PPPoE協(xié)議的基本框架和協(xié)議過程,根據(jù)嵌入式系統(tǒng)" title="嵌入式系統(tǒng)">嵌入式系統(tǒng)資源有限和無操作系統(tǒng)支持的特點(diǎn),設(shè)計(jì)了一種適合于嵌入式系統(tǒng)的PPPoE軟件結(jié)構(gòu),提出了減少代碼長(zhǎng)度和數(shù)據(jù)存儲(chǔ)空間的優(yōu)化方法,在80D51芯片上成功實(shí)現(xiàn)了PPPoE協(xié)議軟件,并應(yīng)用在以太" title="以太">以太話機(jī)中。實(shí)際運(yùn)行證明,本PPPoE協(xié)議軟件在穩(wěn)定性、互通性和一致性等方面都具有良好的性能。
  關(guān)鍵詞: PPPoE PPP 嵌入式系統(tǒng)


  基于以太網(wǎng)的點(diǎn)對(duì)點(diǎn)通信協(xié)議PPPoE(Point to Point Protocol over Ethenet)是為了滿足越來越多的寬帶上網(wǎng)設(shè)備(如ADSL、無線、有線電視等)和越來越快的網(wǎng)絡(luò)之間的通信而指定開發(fā)的標(biāo)準(zhǔn),它給出了兩個(gè)廣泛接受的標(biāo)準(zhǔn):以太網(wǎng)和PPP撥號(hào)協(xié)議。不難看出,PPPoE就是將PPP數(shù)據(jù)承載到以太網(wǎng)上,實(shí)質(zhì)是在共享介質(zhì)的網(wǎng)絡(luò)中提供一條邏輯上的點(diǎn)到點(diǎn)鏈路" title="鏈路">鏈路。對(duì)用戶而言,在DSLAM(DSL匯聚設(shè)備)與ADSL Modem之間的ATM傳輸是透明的,如果將中間的DSLAM和ADSL Modem換成有線電視的接入設(shè)備,就是典型的HFC接入。BAS(寬帶接入服務(wù)器)對(duì)PPPoE包的處理方式不變。而對(duì)于服務(wù)商,在現(xiàn)有局域網(wǎng)基礎(chǔ)上不需要花費(fèi)巨資做大面積改造。
  目前,實(shí)現(xiàn)PPPoE協(xié)議的軟件有多種,且多數(shù)都是應(yīng)用于PC機(jī)。該類軟件的作用主要是在操作系統(tǒng)的撥號(hào)(PPP)協(xié)議與以太網(wǎng)協(xié)議建立連接,通過PPPoE協(xié)議與ISP連接,獲得Internet連接服務(wù)。而本文考慮到嵌入式系統(tǒng)的特點(diǎn),直接在網(wǎng)絡(luò)協(xié)議數(shù)據(jù)鏈路層實(shí)現(xiàn)PPPoE協(xié)議。這樣做省去了鏈路層的PPP包到PPPoE包的轉(zhuǎn)換,提高了效率,并且具有良好的可移植性。
1 PPPoE協(xié)議框架[1]
  PPPoE協(xié)議共包括兩個(gè)階段[1],即PPPoE的發(fā)現(xiàn)階段(PPPoE Discovery Stage)和PPPoE的會(huì)話階段(PPPoE Session Stage)。本文著重介紹PPPoE發(fā)現(xiàn)階段。對(duì)于PPPoE會(huì)話階段,可以看成與PPP的會(huì)話過程基本一樣,當(dāng)然兩者在數(shù)據(jù)的封裝上還是有區(qū)別的。PPPoE并不需要PPP協(xié)議中的起始位標(biāo)志、地址位、控制位和結(jié)束標(biāo)志,也不需要PPP協(xié)議中規(guī)定的數(shù)據(jù)轉(zhuǎn)譯和CRC校驗(yàn),但要在PPP的數(shù)據(jù)報(bào)文前封裝PPPoE的報(bào)文頭。無論是哪一個(gè)階段的數(shù)據(jù)報(bào)文最終會(huì)被封裝成以太網(wǎng)幀傳送。
  如果主機(jī)要開始一個(gè)PPPoE會(huì)話,它首先會(huì)在網(wǎng)絡(luò)上發(fā)送一個(gè)廣播,通過廣播尋找一個(gè)訪問集中器" title="集中器">集中器AC(Access Concentration)。當(dāng)網(wǎng)絡(luò)上存在多個(gè)訪問集中器時(shí),主機(jī)根據(jù)訪問集中器所能提供的服務(wù)或用戶預(yù)先配置的信息進(jìn)行相應(yīng)的選擇。訪問集中器選定后,主機(jī)開始與所選擇的訪問集中器建立一個(gè)PPPoE會(huì)話進(jìn)程。在這一過程中,訪問集中器會(huì)為每一個(gè)PPPoE會(huì)話分配一個(gè)惟一的進(jìn)程ID,會(huì)話建立后就開始了PPPoE的會(huì)話階段。在這個(gè)階段,已建立好點(diǎn)對(duì)點(diǎn)(邏輯點(diǎn)對(duì)點(diǎn))連接的雙方采用PPP協(xié)議交換數(shù)據(jù)報(bào)文,從而完成一系列PPP的過程,最終將在這個(gè)點(diǎn)對(duì)點(diǎn)的邏輯通道上進(jìn)行網(wǎng)絡(luò)層數(shù)據(jù)包的傳送。
  PPPoE可以理解為在以太網(wǎng)上跑PPP數(shù)據(jù),因此,其幀格式[1]與以太幀格式一致,如圖1所示。通過類型域字段的內(nèi)容,數(shù)據(jù)包的接收方可以識(shí)別以太網(wǎng)的數(shù)據(jù)域中承載的是什么協(xié)議的數(shù)據(jù)報(bào)文。PPPoE的兩大階段,也正是通過以太網(wǎng)的類型域進(jìn)行區(qū)分的。這個(gè)域的值,在發(fā)現(xiàn)階段為0x8863,而在會(huì)話階段為0x8864。


  PPPoE幀的載荷字段承載PPPoE數(shù)據(jù)報(bào)文[1],報(bào)文格式如圖2所示,其中各字段的含義如下:
  (1)版本字段(ver)標(biāo)志著協(xié)議版本信息,為4bits,目前協(xié)議規(guī)定其值為0x1。
  (2)類型字段(type),4bits,標(biāo)志類型信息,值為0x1。
  (3)編碼字段(code),單個(gè)字節(jié),在不同階段具有不同取值,本文稍候詳細(xì)分析。
  (4)會(huì)話ID字段(session id)由兩個(gè)字節(jié)組成,在發(fā)現(xiàn)階段,取值為0x0000,在后續(xù)的整個(gè)PPPoE會(huì)話過程中取值為發(fā)現(xiàn)階段所獲得的由AC分配的惟一值。
  (5)長(zhǎng)度字段(length)由兩個(gè)字節(jié)組成,指示payload字段的長(zhǎng)度,取值可以是0~1500。
  (6)凈載荷字段(payload),該字段存放PPPoE協(xié)議幀所承載的數(shù)據(jù),在發(fā)現(xiàn)階段承載零個(gè)或多個(gè)TAG結(jié)構(gòu)[1],在會(huì)話階段承載PPP協(xié)議數(shù)據(jù)。但不是簡(jiǎn)單的PPP封裝,因?yàn)椴⒉恍枰狿PP協(xié)議中的起始位標(biāo)志、地址位、控制位和結(jié)束標(biāo)志,也不需要PPP協(xié)議中規(guī)定的數(shù)據(jù)轉(zhuǎn)譯和CRC校驗(yàn)。TAG結(jié)構(gòu)如圖3所示。


2 PPPoE協(xié)議分析
  PPPoE協(xié)議分為發(fā)現(xiàn)(Discovery)階段和會(huì)話(Session)階段。發(fā)現(xiàn)階段是一個(gè)無狀態(tài)的階段,該階段主要選擇訪問集中器,確定所要建立的PPP會(huì)話標(biāo)識(shí)符Session ID,同時(shí)獲得對(duì)方點(diǎn)到點(diǎn)的連接信息;PPP會(huì)話階段執(zhí)行標(biāo)準(zhǔn)的PPP過程。
  (1) 發(fā)現(xiàn)階段
  一個(gè)典型的發(fā)現(xiàn)階段分為四個(gè)步驟,當(dāng)整個(gè)發(fā)現(xiàn)階段結(jié)束后,通信雙方分別獲得對(duì)方的MAC地址,并且共用一個(gè)Session ID,這兩個(gè)參數(shù)共同確定一個(gè)PPPoE會(huì)話。
  第一步,發(fā)送PADI(PPPoE Active Discovery Initiation)幀。在PPPoE的以太幀結(jié)構(gòu)中,編碼域的值為0x09,會(huì)話ID域的值設(shè)為0x0000。在這個(gè)步驟中,以太幀目的地址為廣播并且在包中必須包含一個(gè)確切的服務(wù)名。
  第二步,接收PADO(PPPoE Active Discovery Offer) 幀。這一過程就是當(dāng)ISP的PPPoE訪問集中器收到PADI幀后,若能夠滿足PADI提出的服務(wù)請(qǐng)求,可以發(fā)送PADO幀回應(yīng)。PADO幀中的目的地址為發(fā)送PADI幀的客戶端的MAC地址,源地址為響應(yīng)PADO幀的服務(wù)器地址。編碼域的值為0x07,會(huì)話ID域的值也設(shè)為0x0000。PADO幀還要包括PADI幀所提出的服務(wù)項(xiàng)。
  第三步,發(fā)送PADR(PPPoE Active Discovery Request) 幀。由于PADI包是廣播式的,故主機(jī)可能收到多個(gè)PADO響應(yīng)幀。主機(jī)在可能收到的多個(gè)PADO幀中根據(jù)訪問集中器的名稱標(biāo)簽或能提供的服務(wù)標(biāo)簽選擇一個(gè)合適的訪問集中器,然后向所選擇的訪問集中器發(fā)送PPPoE有效發(fā)現(xiàn)請(qǐng)求(PADR) 幀。其編碼域?yàn)?x19,Session ID域仍為0x0000,PADR幀必須包含一個(gè)服務(wù)名稱類型標(biāo)簽,確定向接入服務(wù)器請(qǐng)求的服務(wù)種類。
  第四步,接收PADS(PPPoE Active Discovery Session-confirmation ) 幀。訪問集中器收到PADR幀后開始PPP會(huì)話,它發(fā)送一個(gè)PPPoE有效發(fā)現(xiàn)會(huì)話確認(rèn)(PADS) 幀。其編碼域?yàn)?x65,會(huì)話 ID域此時(shí)為接入服務(wù)器所產(chǎn)生的惟一PPPoE會(huì)話標(biāo)識(shí)號(hào)碼。PADS幀也必須包含一個(gè)訪問集中器名稱類型的標(biāo)簽,確認(rèn)向主機(jī)提供的服務(wù)。當(dāng)主機(jī)收到PADS幀確認(rèn)后,雙方進(jìn)入PPP會(huì)話階段。若訪問集中器不能提供PADR中的服務(wù)名稱標(biāo)簽所定義的服務(wù),它必須回復(fù)PADS幀,此幀必須包含標(biāo)簽類型Sevice-Name-Error的標(biāo)簽,此時(shí)SESSION_ID必須為0x0000。
  在完成上述步驟后,雙方進(jìn)入會(huì)話階段。會(huì)話建立后,會(huì)話雙方任何一方都可以通過發(fā)送PADT(PPPoE active discover terminate)幀終止會(huì)話。PADT幀中的編碼字段值為0xA7,SESSION_ID字段為在發(fā)現(xiàn)階段結(jié)束之后得到的會(huì)話ID值,以太幀類型字段還是0x8863。發(fā)送PADT后則該次PPPoE過程結(jié)束。
  (2)會(huì)話階段
  當(dāng)PPPoE會(huì)話開始后,PPP數(shù)據(jù)就像普通的PPP數(shù)據(jù)被傳送,這時(shí)以太幀的目的地址是單播地址,類型為0x8864,編碼域必須是0x00,SESSION_ID必須是發(fā)現(xiàn)階段建立的SESSION_ID,且在會(huì)話過程中不能改變。PPPoE凈載荷是PPP幀,會(huì)話過程實(shí)際上也就是實(shí)現(xiàn)PPP協(xié)議的過程,PPP分為三個(gè)階段。首先通過LCP完成相關(guān)鏈路控制協(xié)商過程,主要是建立、配置、測(cè)試數(shù)據(jù)鏈路,根據(jù)雙方的需求,進(jìn)行鏈路的協(xié)商和配置。PAP密碼認(rèn)證后,通過NCP,針對(duì)不同的網(wǎng)絡(luò)層協(xié)議的網(wǎng)絡(luò)控制階段。最后就是IP數(shù)據(jù)的傳輸階段。
3 PPPoE模塊軟件設(shè)計(jì)
  應(yīng)用于嵌入式系統(tǒng)的PPPoE軟件模塊主要通過系統(tǒng)中的以太網(wǎng)絡(luò)驅(qū)動(dòng)在鏈路層與訪問集中器建立一個(gè)邏輯上點(diǎn)對(duì)點(diǎn)的通信鏈路,為上層TCP/IP協(xié)議棧服務(wù)。發(fā)送數(shù)據(jù)時(shí),將上層IP分組封裝成PPPoE協(xié)議幀發(fā)送出去。在接收數(shù)據(jù)時(shí),將接收到的PPPoE協(xié)議幀解析后,交由上層模塊處理,如圖4所示。與訪問集中器建立通信鏈路的過程是軟件設(shè)計(jì)的核心部分。
  PPPoE發(fā)現(xiàn)階段流程如圖5所示。發(fā)現(xiàn)階段分為四個(gè)過程完成:發(fā)送PADI、接收PADO、發(fā)送PADR和接收PADS。在發(fā)送PADI和PADR時(shí)要分別定時(shí)和計(jì)數(shù),在有限的時(shí)間內(nèi)沒有收到響應(yīng),就應(yīng)重新發(fā)送;如果在重復(fù)發(fā)送若干次之后還沒有相應(yīng),說明此時(shí)網(wǎng)絡(luò)故障或者網(wǎng)絡(luò)上沒有能夠響應(yīng)請(qǐng)求的服務(wù)器。


  PPPoE會(huì)話階段是一個(gè)標(biāo)準(zhǔn)的PPP協(xié)商過程。整個(gè)協(xié)商過程分為三部分:LCP Negotiation、PAP Negotiation、IPCP Negotiation。
  LCP階段[2]主要通過交換數(shù)據(jù)包與訪問集中器建立和配置鏈路,LCP流程如圖6所示。由于ISP提供商可能會(huì)不同,所接收到的LCP_REQ中包含的選項(xiàng)也可能不同,但其中必然包括OPTION3,表示鏈路所用的認(rèn)證協(xié)議" title="認(rèn)證協(xié)議">認(rèn)證協(xié)議(Authentication Protocol)。實(shí)踐中根據(jù)與ISP的PPPoE過程的數(shù)據(jù)包分析,多數(shù)ISP采用PAP(Password Authentication Protocol)認(rèn)證協(xié)議。也有的ISP采用CHAP(Challenge Handshake Authentication Protocol)認(rèn)證協(xié)議,雙方可以通過協(xié)商采用合適的認(rèn)證協(xié)議,本文采用PAP。
  PAP協(xié)商[3]過程比較簡(jiǎn)單,發(fā)送PAP請(qǐng)求數(shù)據(jù)包,其中包括賬號(hào)和密碼,ISP返回確認(rèn)數(shù)據(jù)包,PAP協(xié)商過程結(jié)束。
  IPCP階段[4]的目的是獲取ISP方提供的IP地址,流程如圖7所示。所以在IPCP階段的協(xié)商主要針對(duì)OPTION3進(jìn)行。PPPoE模塊首先接收服務(wù)器端一個(gè)IPCP_REQ,這個(gè)IPCP_REQ包括OPTION3(其IP地址值通常無效);接著PPPoE模塊發(fā)送一個(gè)IPCP_ACK,ISP方會(huì)響應(yīng)一個(gè)帶有有效地址的IPCP_NAK;然后PPPoE模塊就以這個(gè)地址再發(fā)一個(gè)IPCP_REQ,ISP服務(wù)器回應(yīng)IPCP_ACK,IPCP結(jié)束。此時(shí)PPPoE模塊得到了服務(wù)器分配的有效IP地址,隨后就可以在PPPoE協(xié)議之上傳送IP數(shù)據(jù)包。需要注意的是,在PPP協(xié)商過程結(jié)束后,服務(wù)器為了檢驗(yàn)接入方鏈路的活動(dòng)狀態(tài),會(huì)定期發(fā)出LCP Echo-Request請(qǐng)求,此時(shí)PPPoE模塊需要發(fā)送LCP Echo-ACK作為應(yīng)答。


  嵌入式系統(tǒng)程序設(shè)計(jì)的特點(diǎn)是面向特定應(yīng)用,由于資源有限,軟件必須去除冗余。本PPPoE模塊應(yīng)用在以太電話中,在程序模塊設(shè)計(jì)中針對(duì)性地實(shí)現(xiàn)PPPoE協(xié)議的主要功能,盡量使代碼短小精悍,如省略掉了PPPoE發(fā)現(xiàn)階段網(wǎng)絡(luò)上有多個(gè)AC的情況,還省略了在會(huì)話階段對(duì)于LCP OPTION3(認(rèn)證協(xié)議)以外選項(xiàng)的協(xié)商和IPCP PTION3(IP地址)以外的選項(xiàng)的協(xié)商等情況。這些情況,PPPoE模塊需要更多的代碼來處理,而對(duì)于以太話機(jī)這種特定的應(yīng)用,有些選項(xiàng)是不必要的。另外,在軟件結(jié)構(gòu)設(shè)計(jì)中,采用“超循環(huán)”結(jié)構(gòu)來解決無操作系統(tǒng)問題,可以很好地實(shí)現(xiàn)以太話機(jī)中的任務(wù)調(diào)度功能。在代碼編寫上,采用C與匯編相結(jié)合的方法提高程序效率,同時(shí)采用流水操作、Inline、全局變量和共享內(nèi)存等技術(shù)實(shí)現(xiàn)代碼長(zhǎng)度和數(shù)據(jù)空間的優(yōu)化。測(cè)試表明,實(shí)現(xiàn)PPPoE軟件所需的代碼空間和數(shù)據(jù)空間都比PC機(jī)環(huán)境下PPPoE軟件代碼要小得多。
  PPPoE協(xié)議是當(dāng)今ADSL寬帶接入Internet的主要技術(shù)之一,而嵌入式技術(shù)是如今IT技術(shù)發(fā)展的熱點(diǎn),廣泛應(yīng)用于信息家電和各種媒體通信終端設(shè)備。本文在對(duì)PPPoE協(xié)議深入分析的基礎(chǔ)上,結(jié)合嵌入式系統(tǒng)的特點(diǎn),提出了PPPoE在嵌入式系統(tǒng)上的具體實(shí)現(xiàn)方法,通過運(yùn)用這些優(yōu)化方法,使軟件代碼空間和數(shù)據(jù)空間大大減少。目前該軟件模塊已成功應(yīng)用在筆者自己開發(fā)的以太話機(jī)中。實(shí)際運(yùn)行表明,軟件運(yùn)行穩(wěn)定、互通性好,所實(shí)現(xiàn)的PPPoE協(xié)議軟件具有良好的應(yīng)用價(jià)值。
參考文獻(xiàn)
1 RFC2516 A Method for Transmitting PPP Over Ethernet (PPPoE). February 1999
2 RFC1661. The Point-to-Point Protocol (PPP). July 1994
3 RFC1334. PPP Authentication Protocols (PAP). October,1992
4 RFC1332. The PPP Internet Protocol Control Protocol (IPCP), July 1994
5 馬忠梅,劉 濱,戚 軍等.單片機(jī)C語言Windows環(huán)境編程寶典. 北京:北京航空航天大學(xué)出版社,2003

本站內(nèi)容除特別聲明的原創(chuàng)文章之外,轉(zhuǎn)載內(nèi)容只為傳遞更多信息,并不代表本網(wǎng)站贊同其觀點(diǎn)。轉(zhuǎn)載的所有的文章、圖片、音/視頻文件等資料的版權(quán)歸版權(quán)所有權(quán)人所有。本站采用的非本站原創(chuàng)文章及圖片等內(nèi)容無法一一聯(lián)系確認(rèn)版權(quán)者。如涉及作品內(nèi)容、版權(quán)和其它問題,請(qǐng)及時(shí)通過電子郵件或電話通知我們,以便迅速采取適當(dāng)措施,避免給雙方造成不必要的經(jīng)濟(jì)損失。聯(lián)系電話:010-82306118;郵箱:aet@chinaaet.com。