專利名稱：一種802.1x接入會話保活的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，特別涉及一種基于802.1X協(xié)議的接入會話保活的方法及其相關(guān)系統(tǒng)。
背景技術(shù)：
隨著互聯(lián)網(wǎng)應(yīng)用和智能終端的快速發(fā)展，無線局域網(wǎng)WLAN應(yīng)用已經(jīng)非常普遍，很多公共場所部署了 WLAN，例如工廠、學(xué)校、咖啡廳等。通過WLAN接入網(wǎng)絡(luò)已成為用戶訪問網(wǎng)絡(luò)資源最重要的手段之一，用戶可以通過手機、電腦等各種終端設(shè)備，隨時隨地訪問互聯(lián)網(wǎng)，進行網(wǎng)上辦公、娛樂等活動。隨著公眾對隨時隨地通過WLAN訪問互聯(lián)網(wǎng)的需求不斷增力口，政府和運營商紛紛出臺了公眾WLAN網(wǎng)絡(luò)熱點和熱區(qū)的建設(shè)計劃，部分城市已經(jīng)完成了包括商業(yè)中心、大中院校等地區(qū)的WLAN網(wǎng)絡(luò)大范圍覆蓋，這也進一步刺激了終端用戶使用WLAN網(wǎng)絡(luò)的頻率，使得同時在線的WLAN終端數(shù)量飛速增長。當前對WLAN用戶訪問網(wǎng)絡(luò)的接入控制方法主要有802.1X方式和DHCP用戶的0ption60和Web認證等幾種方式，由于這幾種方式在設(shè)計初期都沒有考慮到超大規(guī)模用戶同時訪問WLAN的場景，在這種場景下這些接入方式有個共同的缺陷就是無法及時感知在線用戶是否異常離開網(wǎng)絡(luò)，即沒有提供用戶狀態(tài)?；畹臋C制。用戶經(jīng)常因為各種原因異常下線，沒有發(fā)送下線報文給接入控制設(shè)備。對于WLAN熱區(qū)網(wǎng)絡(luò)而言，隨著大量用戶不斷接入WLAN網(wǎng)絡(luò)并“悄悄的離開”，WLAN控制層面網(wǎng)絡(luò)設(shè)備需要管理的“在線”用戶數(shù)量不斷增力口，導(dǎo)致WLAN控制層面的網(wǎng)絡(luò)設(shè)備、尤其是用戶認證和管理設(shè)備(即網(wǎng)關(guān)設(shè)備)的負擔逐步加重，存在資源浪費和一定的安全隱患。802.1X+EAP在WLAN用戶接入中使用越來越普遍，尤其是在WLAN接入場景中被作為用戶無感知認證的主要方式。用戶通常可以采用802.1X+EAP+DHCPv4/DHCPv6、802.ΙΧ+ΕΑΡ+Static IP/無狀態(tài)地址自動配置SLAAC的方式接入認證并獲取三層地址。用戶和認證點/網(wǎng)關(guān)設(shè)備之間的接入?yún)f(xié)議沒有?；顧C制，一旦鏈路異?；蛴脩舢惓ｋx線，認證點/網(wǎng)關(guān)設(shè)備不能及時偵測到用戶離線，從而影響用戶的計費精度并耗費認證點/網(wǎng)關(guān)設(shè)備的內(nèi)存資源。盡管認證點/網(wǎng)關(guān)設(shè)備可以通過用戶在線檢測(例如單播ARP請求)或用戶空閑流量檢測這些輔助手段來檢測用戶是否異常離線，但是這些方法與接入?yún)f(xié)議802.1X無關(guān)，需要額外的協(xié)議支持，一般比較耗費資源，影響認證點/網(wǎng)關(guān)設(shè)備性能?？傮w來看，擴展現(xiàn)有的802.1X機制實現(xiàn)類似PPP LCP類型的鏈路層保活機制將是一種很好的替代方案。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種接入會話?；畹姆椒跋到y(tǒng)，通過擴展現(xiàn)有的802.1X協(xié)議，對在線用戶的狀態(tài)進行確認和維持，解決了大量用戶不發(fā)送離線消息直接離開網(wǎng)絡(luò)造成的認證點的資源浪費問題、安全隱患和計費錯誤等問題。根據(jù)本發(fā)明的一個方面，提供了一種802.1X接入會話?；畹姆椒?，包括:802.1X客戶端接入網(wǎng)絡(luò)期間，用于接入認證的認證點按照認證點實際?；钪芷冢?02.1X客戶端發(fā)送用于確定所述802.1X客戶端是否異常離網(wǎng)的?；钫埱笙?；在認證點預(yù)定時間內(nèi)，若所述認證點未收到所述802.1X客戶端響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則所述認證點確定所述802.1X客戶端異常離網(wǎng)，否則所述認證點確定所述802.1X客戶端正常在網(wǎng)。優(yōu)選地，還包括:802.1X客戶端接入網(wǎng)絡(luò)期間，802.1X客戶端按照客戶端實際?；钪芷?，向認證點發(fā)送用于確定所述認證點是否狀態(tài)異常的?；钫埱笙?；在客戶端預(yù)定時間內(nèi)，若所述802.1X客戶端未收到所述認證點響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則所述802.1X客戶端確定所述認證點狀態(tài)異常，否則，所述802.1X客戶端確定認證點狀態(tài)正常。優(yōu)選地，在所述認證點/802.1X客戶端向?qū)Χ税l(fā)送保活請求消息前，還包括802.1X客戶端接入認證步驟，包括:所述認證點接收所述802.1X客戶端發(fā)送的開始通告請求消息，并向802.1X客戶端發(fā)送身份請求消息；所述認證點接收所述802.1X客戶端響應(yīng)所述身份請求消息的身份響應(yīng)消息，并將所述身份響應(yīng)消息封裝到認證請求消息中，發(fā)送至認證服務(wù)器；所述認證服務(wù)器根據(jù)所述認證請求消息，經(jīng)由認證點與所述802.1X客戶端確定鑒權(quán)方式，并按照所述鑒權(quán)方式，對802.1X客戶端進行鑒權(quán)處理；所述認證服務(wù)器將鑒權(quán)成功/失敗的處理結(jié)果封裝到接入接受/拒絕消息中，發(fā)送至認證點。優(yōu)選地，所述802.1X客戶端接入認證期間，當所述802.1X客戶端發(fā)送的所述開始通告請求消息中未攜帶建議?；钪芷跁r，所述802.1X客戶端將所述建議保活周期封裝到通告請求消息中，發(fā)送至所述認證點，以供所述認證點確定認證點實際保活周期。優(yōu)選地，所述認證點解析收到的所述接入接受消息，得到其中的用于開啟?；罟δ艿氖跈?quán)屬性，并根據(jù)所述用于開啟?；罟δ艿氖跈?quán)屬性，開啟指定身份標識或業(yè)務(wù)管理域標識所對應(yīng)的802.1X客戶端的?；罟δ?，以便進行802.1X接入會話?；睢?yōu)選地，所述認證點通過以下步驟確定認證點實際保活周期:所述認證點解析收到的所述開始通告請求消息或所述通告請求消息，得到其中的建議保活周期；所述認證點解析收到的所述接入接受消息，得到其中的授權(quán)?；钪芷?；所述認證點利用所述建議?；钪芷诤?或所述授權(quán)?；钪芷诤?或認證點本地配置的本地保活周期，確定所述認證點實際保活周期。優(yōu)選地，所述客戶端實際?；钪芷谑?02.1X客戶端本地的默認?；钪芷?。優(yōu)選地，所述802.1X客戶端解析收到的所述?；铐憫?yīng)消息，得到其中的強制?；钪芷?，并按照所述強制保活周期，調(diào)整客戶端實際?；钪芷?。根據(jù)本發(fā)明的另一方面，提供了一種802.1X接入會話?；畹南到y(tǒng)，包括802.1客戶端、用于接入認證的認證點和認證服務(wù)器，其中，所述認證點包括:認證點消息發(fā)送模塊，用于在802.1X客戶端接入網(wǎng)絡(luò)期間，按照認證點實際?；钪芷?，向802.1X客戶端發(fā)送用于確定所述802.1X客戶端是否異常離網(wǎng)的?；钫埱笙ⅲ?br> 客戶端狀態(tài)確定模塊，用于在認證點預(yù)定時間內(nèi)，若未收到所述802.1X客戶端響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則確定所述802.1X客戶端異常離網(wǎng)，否則確定所述802.1X客戶端正常在網(wǎng)。優(yōu)選地，所述802.1客戶端包括:客戶端消息發(fā)送模塊，用于在802.1X客戶端接入網(wǎng)絡(luò)期間，按照客戶端實際?；钪芷冢蛘J證點發(fā)送用于確定所述認證點是否狀態(tài)異常的?；钫埱笙ⅲ徽J證點狀態(tài)確定模塊，用于在客戶端預(yù)定時間內(nèi)，若未收到所述認證點響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則確定所述認證點狀態(tài)異常，否則，確定認證點狀態(tài)正常。與現(xiàn)有技術(shù)相比較，本發(fā)明的有益效果在于:1、本發(fā)明通過認證點對802.1X客戶端保活，使認證點能夠及時感知用戶是否異常離開網(wǎng)絡(luò)，從而提升了網(wǎng)絡(luò)資源利用率，尤其是WLAN接入網(wǎng)絡(luò)，實現(xiàn)簡便，擴展靈活；2、本發(fā)明降低了用于認證接入的認證點出現(xiàn)負擔過重的安全性問題和按時計費錯誤的風(fēng)險；3、本發(fā)明通過802.1X客戶端對認證點?；?，使802.1X客戶端能夠及時感知認證點的狀態(tài)，并在認證點狀態(tài)異常時，及時選擇其它有效節(jié)點，從而提升用戶體驗。


圖1是本發(fā)明提供的802.1X接入會話保活的方法原理框圖；圖2是本發(fā)明提供的802.1X接入會話保活的方法流程圖；圖3是本發(fā)明提供的802.1X接入會話?；畹南到y(tǒng)框圖；圖4是本發(fā)明第一實施例提供的802.1X接入會話?；畹南到y(tǒng)拓撲示意圖；圖5是本發(fā)明第一實施例提供的802.1X接入會話?；畹姆椒鞒虉D；圖6是本發(fā)明提供的擴展的開始通告消息示意圖；圖7是本發(fā)明提供的EAPOL?；钕⑹疽鈭D；圖8是本發(fā)明第二實施例提供的802.1X接入會話保活的系統(tǒng)拓撲示意圖；圖9是本發(fā)明的第二實施例提供的802.1X接入會話?；畹姆椒鞒虉D；圖10是本發(fā)明第三實施例提供的802.1X接入會話?；畹南到y(tǒng)拓撲示意圖；圖11是本發(fā)明第三實施例提供的802.1X接入會話?；畹姆椒鞒虉D。
具體實施例方式以下結(jié)合附圖對本發(fā)明的優(yōu)選實施例進行詳細說明，應(yīng)當理解，以下所說明的優(yōu)選實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。本發(fā)明考慮到當前WLAN網(wǎng)絡(luò)中直接與客戶端進行802.1X消息交互的設(shè)備是802.1X認證點，且認證流程通過EAPOL消息觸發(fā)，因此本發(fā)明擴展EAPOL消息，實現(xiàn)客戶端與認證點之間的雙向?；顧C制。該機制同樣適用于有線接入網(wǎng)絡(luò)中用戶使用802.1X客戶端認證接入的場景。所述EAPOL指EAP承載于局域網(wǎng)，即802.1X協(xié)議。圖1是本發(fā)明提供的802.1X接入會話?；畹姆椒ㄔ砜驁D，如圖1所示，步驟包括:步驟101:802.1X客戶端接入網(wǎng)絡(luò)期間，用于接入認證的認證點按照認證點實際?；钪芷?，向802.1X客戶端發(fā)送用于確定所述802.1X客戶端是否異常離網(wǎng)的?；钫埱笙?br> 肩、O步驟102:在認證點預(yù)定時間內(nèi)，若所述認證點未收到所述802.1X客戶端響應(yīng)所述保活請求消息的?；铐憫?yīng)消息，則所述認證點確定所述802.1X客戶端異常離網(wǎng)，否則所述認證點確定所述802.1X客戶端正常在網(wǎng)。除上述步驟101和步驟102外，還包括802.1X客戶端接入網(wǎng)絡(luò)期間，802.1X客戶端按照客戶端實際保活周期，向認證點發(fā)送用于確定所述認證點是否狀態(tài)異常的保活請求消息；在客戶端預(yù)定時間內(nèi)，若所述802.1X客戶端未收到所述認證點響應(yīng)所述保活請求消息的?；铐憫?yīng)消息，則所述802.1X客戶端確定所述認證點狀態(tài)異常，否則，所述802.1X客戶端確定認證點狀態(tài)正常。也就是說，在802.1X客戶端和認證點之間可以建立?；顧C制，使802.1X協(xié)議會話交互的任何一方能及時有效地感知對方是否異常，例如上述步驟101和步驟102中，認證點利用保活機制感知802.1X客戶端異常離線。圖2是本發(fā)明提供的802.1X接入會話保活的方法流程圖，如圖2所示，步驟包括:步驟1:802.1X站點STA發(fā)送開始通告請求消息EAPOL-StartAnnouncement給用于接入認證的認證點，并在EAPOL-Start-Announcement消息的擴展TLV選項中攜帶保活支持標識信息和建議?；钪芷谛畔ⅰＫ鰯U展TLV選項格式如圖6所示。步驟2:認證點保存STA的建議保活周期信息，并發(fā)送身份請求消息EAPOL-EAP-Request-1dentity給STA，索要身份認證信息。STA收到所述消息后，向所述認證點返回身份響應(yīng)消息EAPOL-EAP-Response-1dentity。步驟3:認證點將EAPOL-EAP-Response-1dentity消息攜帶在認證請求消息Access-Request中發(fā)送給認證服務(wù)器，即AAA服務(wù)器。步驟4 =AAA服務(wù)器通過認證點與STA協(xié)商具體的鑒權(quán)方式，并對STA進行鑒權(quán)，鑒權(quán)結(jié)果用EAP-Success或EAP-Failure消息發(fā)送給認證點。進一步地,所述EAP-Success或EAP-Failure消息封裝到接入接受/拒絕消息中，發(fā)送至認證點。進一步地，STA與AAA服務(wù)器之間的EAP鑒權(quán)協(xié)議包括EAP-PEAP、EAP-SIM,EAP-AKA、EAP-TLS、EAP-TTLS。進一步地,認證點與AAA服務(wù)器之間的認證協(xié)議包括Radius、Diameter等。步驟5:認證點根據(jù)STA的建議?；钪芷?、認證點本地配置的本地?；钪芷谝约癆AA服務(wù)器授權(quán)給STA的授權(quán)?；钪芷冢C合確定針對該STA的認證點實際?；钪芷?。進一步地，默認情況下AAA服務(wù)器的授權(quán)?；钪芷趦?yōu)先級最高，認證點本地配置的本地?；钪芷趦?yōu)先級次之，STA的建議?；钪芷趦?yōu)先級最低。該優(yōu)先級順序允許根據(jù)配置的策略調(diào)整。也就是說，對于認證點對802.1X客戶端的?；?，允許802.1X認證模型的三方角色(即802.1X客戶端、認證點和認證服務(wù)器)參與協(xié)商802.1X協(xié)議會話的具體保活周期，并由認證點根據(jù)配置的選擇策略最終確定有效的認證點實際?；钪芷冢凑账稣J證點實際?；钪芷谶M行802.1X協(xié)議會話的?；睿⒃?02.1X認證模型的三方角色協(xié)商允許的前提下，允許認證點根據(jù)自身負載等情況對802.1X會話的保活周期進行動態(tài)調(diào)整。
步驟6:認證點按照該STA的認證點實際?；钪芷冢騍TA發(fā)送?；钫埱笙ⅲ琒TA收到該消息之后返回?；铐憫?yīng)消息。進一步地，所述?；钫埱笙⒑退霰；铐憫?yīng)消息統(tǒng)稱為EAPOL?；钕APOL-Keepalive，消息內(nèi)容包括以下字段:Protocol Version:協(xié)議類型(EAP0L),長度為I字節(jié)，目前最新的版本號中長度為3 ；Packet Type =EAPOL消息類型，EAPoL-Ke印alive消息建議采用Oxf，長度為I字節(jié);Packet Body Length:消息長度,長度為2字節(jié)；Message Type:EAP0L_Keepalive消息類型，長度為I字節(jié)，O代表?；钫埱笙cho request, I代表?；铐憫?yīng)消息Echo reply ；Forced Flag:1字節(jié)，表示是否強制要求對端修改其?；钪芷跒樽约航ㄗh的有效?；钪芷冢J為不強制。Timer Period:?；钪芷冢L度為2字節(jié)，O表示無效，65535表示不?；?，其它值為有效值，建議值180s。Sequence number:序列號，長度為4字節(jié),標識一組保活請求和應(yīng)答,初始值隨機，?；钫埱笠驗閼?yīng)答超時重傳時，序列號維持不變，發(fā)送新的保活請求時，序列號遞增。在這個流程中,EAPOL-Start-Announcement可以不攜帶STA是否支持保活及建議?；钪芷诘刃畔⒔o認證點，STA可以在認證時單獨向認證點發(fā)送攜帶這些信息的EAPOL通告消息EAPOL-Announcement-Req,認證點只要在STA認證完成前及時獲悉STA是否支持?；詈徒ㄗh保活周期即可。也就是說，在802.1X客戶端接入認證期間，802.1X客戶端可以在EAPOL-StartAnnouncement或EAPOLAnnouncement-Req中攜帶對應(yīng)的擴展選項，將其建議保活周期等信息告知給認證點；認證服務(wù)器在802.1X客戶端認證成功時將其授權(quán)保活周期等信息用擴展的授權(quán)屬性在接入接受消息中下發(fā)給認證點，認證點也可以針對指定的管理域或指定身份標識的用戶本地配置的本地?；钪芷?。認證點在收到認證服務(wù)器的接入接受報文后，根據(jù)本地配置的選擇策略，從這些?；钪芷谥羞x擇一個?；钪芷谧鳛檎J證點實際?；钪芷?，開始執(zhí)行802.1X協(xié)議會話的?；钕⒔换?。上述步驟是認證點對STA的保活，同樣地,STA也可以對認證點?；?STA對認證點保活為可選功能，一般不建議開啟，但是認證點需要能夠響應(yīng)STA的保活請求。具體地說，所述STA也可以采用客戶端默認的客戶端實際?；钪芷冢蛘J證點發(fā)起?；钫埱?，并接收來自認證點的保活響應(yīng)消息中新的強制?；钪芷?。也就是說，對于802.1X客戶端對認證點的?；睿试S認證點根據(jù)802.1X認證模型的三方角色協(xié)商結(jié)果建議或強制802.1X客戶端進行調(diào)整，用作客戶端實際?；钪芷诘膹娭票；钪芷谠诒；铐憫?yīng)消息中攜帶給802.1X客戶端。由此可見，在802.1X客戶端接入認證成功后，802.1X客戶端和/或認證點都可以向802.1X協(xié)議會話的對端設(shè)備發(fā)送?；钫埱笙?，802.1X協(xié)議會話的對端設(shè)備回應(yīng)?；铐憫?yīng)消息，相同的流程以一定的客戶端和/或認證點實際?；钪芷谥貜?fù)進行。該?；顧C制是雙向的，可以單向開啟或關(guān)閉，例如可以僅開啟認證點對802.1X客戶端的?；钚袨椋凑J證點發(fā)送?；钫埱笙?，對應(yīng)的802.1X客戶端回應(yīng)保活響應(yīng)消息。
進一步地，開啟或關(guān)閉?；顧C制，獨立于802.1X的接入認證流程，僅在802.1X客戶端認證成功后執(zhí)行。具體地，認證點可以對指定身份標識或域標識的802.1X客戶端開啟或關(guān)閉?；罟δ埽撋矸輼俗R可以是用戶MAC、用戶賬號或國際移動用戶識別號等信息，該域標識可以是認證點或認證服務(wù)器針對一組用戶的業(yè)務(wù)管理域的域名，由認證點執(zhí)行針對這些指定用戶開啟或關(guān)閉?；罟δ艿膭幼鳌?02.1X客戶端聲明自身是否支持?；罟δ?在開始通告請求報文或通告請求報文中攜帶對應(yīng)的擴展選項，將是否支持?；罟δ芨嬷J證點，認證點默認802.1X客戶端不支持?；罟δ?，如果支持，可選擇是否開啟?；罟δ堋ＵJ證服務(wù)器可以根據(jù)其配置的策略決定針對哪些用戶進行?；睿⒃?02.1X客戶端接入認證成功時，通過接入接受消息攜帶對應(yīng)的用于開啟?；罟δ艿氖跈?quán)屬性給認證點，由認證點執(zhí)行具體的開啟或關(guān)閉?；罟δ艿膭幼鳌Ｉ鲜?02.1X STA指802.1X客戶端，可以是裝有無線網(wǎng)卡的計算機，也可以是有無線保真WiFi模塊的智能手機。STA可以是移動的，也可以是固定的，是WLAN的最基本組成單元。圖3是本發(fā)明提供的802.1X接入會話?；畹南到y(tǒng)框圖，如圖3所示，包括:認證點:在802.1X客戶端接入認證過程中，負責(zé)選定認證服務(wù)器并轉(zhuǎn)換中繼802.1X客戶端和認證服務(wù)器的認證報文交互，接收802.1X客戶端的?；罱ㄗh和認證服務(wù)器的授權(quán)屬性(包括針對802.1X客戶端?；畹南嚓P(guān)參數(shù)授權(quán))，并在802.1X客戶端認證成功時最終選擇合適的保活周期，開始執(zhí)行對802.1X客戶端的?；畈僮?；802.1X客戶端:負責(zé)進行802.1X協(xié)議的接入認證交互，根據(jù)設(shè)置主動上報?；罟δ芟嚓P(guān)的參數(shù)(包括是否支持?；?，建議的?；钪芷诘?，在認證成功后響應(yīng)認證點的?；钫埱笙?。必要時，根據(jù)設(shè)置也可以主動針對認證點進行保活，發(fā)送保活請求消息并接受認證點的?；铐憫?yīng)消息；認證服務(wù)器:負責(zé)對802.1X客戶端進行EAP認證交互和授權(quán)屬性下發(fā)，鑒權(quán)成功時，根據(jù)其所知的策略下發(fā)針對802.1X客戶端進行?；钕嚓P(guān)的參數(shù)給認證點。其中，所述認證點包括:認證點消息發(fā)送模塊，用于在802.1X客戶端接入網(wǎng)絡(luò)期間，按照認證點實際?；钪芷?，向802.1X客戶端發(fā)送用于確定所述802.1X客戶端是否異常離網(wǎng)的保活請求消息；客戶端狀態(tài)確定模塊，用于在認證點預(yù)定時間內(nèi)，若未收到所述802.1X客戶端響應(yīng)所述保活請求消息的?；铐憫?yīng)消息，則確定所述802.1X客戶端異常離網(wǎng)，否則確定所述802.1X客戶端正常在網(wǎng)。所述802.1客戶端包括:客戶端消息發(fā)送模塊，用于在802.1X客戶端接入網(wǎng)絡(luò)期間，按照客戶端實際?；钪芷冢蛘J證點發(fā)送用于確定所述認證點是否狀態(tài)異常的?；钫埱笙ⅲ徽J證點狀態(tài)確定模塊，用于在客戶端預(yù)定時間內(nèi)，若未收到所述認證點響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則確定所述認證點狀態(tài)異常，否則，確定認證點狀態(tài)正常。以下結(jié)合圖4至圖11，針對認證點對802.1X客戶端的?；钸M行著重說明。圖4是本發(fā)明第一實施例提供的802.1X接入會話?；畹南到y(tǒng)拓撲示意圖，如圖4所示，寬帶網(wǎng)絡(luò)網(wǎng)關(guān)BNG用作認證點的場景，無線接入點AP處于本地轉(zhuǎn)發(fā)模式，BNG和AAA服務(wù)器之間使用遠程用戶撥號認證系統(tǒng)Radius協(xié)議通訊，該場景可以是無線接入控制器AC和BNG融合，也可以是AC和BNG分離。圖5是本發(fā)明第一實施例提供的802.1X接入會話?；畹姆椒鞒虉D，即圖4所述系統(tǒng)的流程圖，步驟包括:步驟1:STA 關(guān)聯(lián) AP 后，擴展的 EAPOL-Start-Announcement 消息攜帶?；钪С謽俗R信息和建議?；钪芷谛畔?，并將該消息經(jīng)AP發(fā)送到BNG。擴展的EAPOL-Start-Announcement消息不意圖如圖6所不。所述?；钪С謽俗R信息用于指示是否支持?；罟δ?。步驟2:BNG接收到STA發(fā)送的EAPOL-Start-Announcement消息后，從中提取出STA的建議?；钪芷谛畔⒉⒈４妫⑼ㄟ^AP向STA發(fā)送EAPOL-EAP-Request-1dentity消息；STA 收到 EAPOL-EAP-Request-1dentity 消息后，經(jīng) AP 向 BNG 發(fā)送EAPOL-EAP-Response-1dentity 消息。步驟3:BNG把EAPOL-EAP-Response消息封裝在RADIUS協(xié)議的認證請求消息Access-Request中，發(fā)送給AAA服務(wù)器。步驟4 =AAA服務(wù)器和STA協(xié)商具體的鑒權(quán)方式，并由AAA服務(wù)器對STA進行鑒權(quán)。步驟5 =AAA服務(wù)器發(fā)送鑒權(quán)成功的EAP-SUCCESS消息或者鑒權(quán)失敗的EAP-FAILURE消息，并將所述消息封裝在RADIUS協(xié)議報文的允許/拒絕接入消息Access-Accept/Reject 中發(fā)送 BNG。進一步地，如果該用戶的簽約信息中有授權(quán)?；钪芷谛畔ⅲ瑒tAAA服務(wù)器在Access-Accept消息中攜帶該信息發(fā)送給BNG。步驟6 =BNG根據(jù)STA的建議保活周期信息、本地配置的本地?；钪芷谛畔⒁约癆AA服務(wù)器的授權(quán)?；钪芷谛畔?，確定認證點對該STA保活的認證點實際?；钪芷凇２襟E7 =BNG根據(jù)所述認證點實際?；钪芷谙騍TA發(fā)送?；钫埱笙?，STA收到該消息之后返回保活響應(yīng)消息。?；钫埱笙⒑捅；铐憫?yīng)消息的建議格式如圖7所示。步驟8 =STA發(fā)出動態(tài)主機設(shè)置協(xié)議發(fā)現(xiàn)消息DHCP Discover請求IP地址，經(jīng)AP發(fā)送給BNG，BNG與STA之間通過DHCP協(xié)議完成STA的IP地址分配，也允許BNG作為DHCPRelay/Proxy代理DHCP Server完成該地址分配流程。特別地，所述步驟8與步驟I至步驟7沒有時間上的先后順序。步驟9 =BNG判斷該STA已經(jīng)過認證，允許轉(zhuǎn)發(fā)STA訪問網(wǎng)絡(luò)側(cè)設(shè)備的上下行數(shù)據(jù)。圖8是本發(fā)明第二實施例提供的802.1X接入會話?；畹南到y(tǒng)拓撲示意圖，如圖8所示，與第一實施例對比，本實施例是將AC作為認證點的場景，AC與AAA服務(wù)器之間通過BNG相連，其具體流程如圖9所示，步驟包括:步驟1:STA關(guān)聯(lián)AP后，擴展的EAPOL-Start-Announcement消息攜帶是?；钪С謽俗R信息和建議?；钪芷谛畔?，并將該消息經(jīng)AP發(fā)送到AC。擴展后的EAPOL-Start-Announcement消息不意圖如圖6所不。步驟2:AC收到STA發(fā)送的EAPOL-Start-Announcement消息后，從中提取出STA的建議?；钪芷谛畔⒉⒈４?，并通過AP向STA發(fā)送EAPOL-EAP-Request-1dentity消息，STA 收到 EAPOL-EAP-Request-1dentity 消息后，經(jīng) AP 向 AC 發(fā)送EAPOL-EAP-Response-1dentity 消息。
步驟3:AC把EAPOL-EAP-Response-1dentity消息封裝在RADIUS協(xié)議的認證請求消息Access-Request中，發(fā)送給AAA服務(wù)器。進一步地，當BNG作為AC與AAA之間的Radius Proxy網(wǎng)元時，BNG需要對Radius協(xié)議報文進行重新封裝。步驟4 =AAA服務(wù)器和STA協(xié)商具體的鑒權(quán)方式，并由AAA服務(wù)器對STA進行鑒權(quán)。步驟5 =AAA服務(wù)器發(fā)送鑒權(quán)成功的EAP-SUCCESS消息或者鑒權(quán)失敗的EAP-FAILURE消息，將所述消息封裝在RADIUS協(xié)議報文的Access-Accept/Re ject消息中發(fā)送AC。進一步地，如果該用戶的簽約信息中有授權(quán)?；钪芷谛畔?，則AAA服務(wù)器在Access-Accept消息中攜帶該信息發(fā)送給AC。步驟6:AC根據(jù)STA的建議保活周期信息、本地配置的默本地保活周期信息以及AAA服務(wù)器授權(quán)的授權(quán)?；钪芷谛畔?，確定認證點對該STA?；畹恼J證點實際?；钪芷凇２襟E7:AC根據(jù)所述認證點實際?；钪芷谙騍TA發(fā)送?；钫埱笙?，STA收到該消息之后返回?；铐憫?yīng)消息，所述?；钫埱笙⒑捅；铐憫?yīng)消息的建議格式如圖7所示。步驟8:STA發(fā)出DHCP Discover消息請求IP地址，經(jīng)AP發(fā)送給AC，AC與STA之間通過DHCP協(xié)議完成STA的IP地址分配。特別地，所述步驟8與所述步驟I至步驟7沒有時間上的先后順序。步驟9:AC判斷該STA已經(jīng)過認證且地址分配成功，則向BNG發(fā)送用戶上線通告消
肩、O進一步地，當BNG作為AC與AAA服務(wù)器之間的Radius Proxy網(wǎng)元時,該消息可以是計費開始消息。步驟10:BNG收到用戶上線通告消息之后，允許轉(zhuǎn)發(fā)STA訪問網(wǎng)絡(luò)側(cè)設(shè)備的上下行數(shù)據(jù)。圖10是本發(fā)明第三實施例提供的802.1X接入會話?；畹南到y(tǒng)拓撲示意圖，如圖10所示，本實施例是將家庭網(wǎng)關(guān)RG (Residential Gateway)或固定終端作為802.1X客戶端，將接入設(shè)備或BNG作為認證點的場景，其具體流程如圖11所示，步驟包括:步驟1:RG或固定終端在擴展的EAPOL-Start-Announcement消息中攜帶是?；钪С謽俗R信息和建議保活周期信息，并將該消息發(fā)送給接入設(shè)備或BNG。擴展的EAPOL-Start-Announcement消息格式不意圖如圖6所不。步驟2:接入設(shè)備或BNG接收到RG或固定終端發(fā)送的EAPOL-Start-Announcement消息后，從中提取出RG或固定終端的建議?；钪芷诓⒈４?，并向RG或固定終端發(fā)送EAPOL-EAP-Request-1dentity 消息，RG 或固定終端收到 EAPOL-EAP-Request-1dentity 消息后，向接入設(shè)備或BNG發(fā)送EAP0L-EAP - Response-1dentity消息。步驟3:接入設(shè)備或 BNG 把 EAPOL-EAP-Response-1dentity 消息封裝在 RADIUS 協(xié)議的認證請求消息Access-Request中，發(fā)送給AAA服務(wù)器。步驟4 =AAA服務(wù)器和RG或固定終端協(xié)商具體的鑒權(quán)方式，并由AAA服務(wù)器對RG或固定終端進行鑒權(quán)。步驟5 =AAA服務(wù)器發(fā)送鑒權(quán)成功的EAP-SUCCESS消息或者鑒權(quán)失敗的EAP-FAILURE消息，并將所述消息封裝在RADIUS協(xié)議報文AccessAccept/Re ject消息中發(fā)送接入設(shè)備或BNG。進一步地，如果該用戶的簽約信息中有授權(quán)?；钪芷谛畔ⅲ珹AA服務(wù)器在Access-Accept消息中攜帶該信息發(fā)送給接入設(shè)備或BNG。步驟6:接入設(shè)備或BNG根據(jù)RG或固定終端的建議?；钪芷?、接入設(shè)備或BNG本地配置的本地?；钪芷谝约癆AA服務(wù)器授權(quán)給RG或固定終端的授權(quán)保活周期，確定接入設(shè)備或BNG對該RG或固定終端?；畹恼J證點實際保活周期。步驟7:接入設(shè)備或BNG根據(jù)所述認證點實際?；钪芷谙騌G或固定終端發(fā)送保活請求消息，RG或固定終端收到該消息之后返回保活響應(yīng)消息。保活請求消息和?；铐憫?yīng)消息的格式如圖7所示。步驟8:RG或固定終端發(fā)出DHCP Discover消息請求IP地址，發(fā)送給BNG，BNG與RG或固定終端之間通過DHCP協(xié)議完成RG或固定終端的IP地址分配。特別地，所述步驟8與所述步驟I至步驟7沒有時間上的先后順序。步驟9:接入設(shè)備或BNG判斷該RG或固定終端已經(jīng)過認證，允許轉(zhuǎn)發(fā)RG或固定終端訪問網(wǎng)絡(luò)側(cè)設(shè)備的上下行數(shù)據(jù)。 本發(fā)明的各步驟或各部件可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個步驟或部件制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。 盡管上文對本發(fā)明進行了詳細說明，但是本發(fā)明不限于此，本技術(shù)領(lǐng)域技術(shù)人員可以根據(jù)本發(fā)明的原理進行各種修改。因此，凡按照本發(fā)明原理所作的修改，都應(yīng)當理解為落入本發(fā)明的保護范圍。
權(quán)利要求
1.一種802.1X接入會話保活的方法，其特征在于，包括: 802.1X客戶端接入網(wǎng)絡(luò)期間，用于接入認證的認證點按照認證點實際?；钪芷?，向802.1X客戶端發(fā)送用于確定所述802.1X客戶端是否異常離網(wǎng)的?；钫埱笙ⅲ? 在認證點預(yù)定時間內(nèi)，若所述認證點未收到所述802.1X客戶端響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則所述認證點確定所述802.1X客戶端異常離網(wǎng)，否則所述認證點確定所述802.1X客戶端正常在網(wǎng)。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括: 802.1X客戶端接入網(wǎng)絡(luò)期間，802.1X客戶端按照客戶端實際?；钪芷?，向認證點發(fā)送用于確定所述認證點是否狀態(tài)異常的?；钫埱笙?； 在客戶端預(yù)定時間內(nèi)，若所述802.1X客戶端未收到所述認證點響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則所述802.1X客戶端確定所述認證點狀態(tài)異常，否則，所述802.1X客戶端確定認證點狀態(tài)正常。
3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，在所述認證點/802.1X客戶端向?qū)Χ税l(fā)送保活請求消息前，還包括802.1X客戶端接入認證步驟,包括: 所述認證點接收所述802.1X客戶端發(fā)送的開始通告請求消息，并向802.1X客戶端發(fā)送身份請求消息； 所述認證點接收所述802.1X客戶端響應(yīng)所述身份請求消息的身份響應(yīng)消息，并將所述身份響應(yīng)消息封裝到認證請求消息中，發(fā)送至認證服務(wù)器； 所述認證服務(wù)器根據(jù)所述認證請求消息，經(jīng)由認證點與所述802.1X客戶端確定鑒權(quán)方式，并按照所述鑒 權(quán)方式，對802.1X客戶端進行鑒權(quán)處理； 所述認證服務(wù)器將鑒權(quán)成功/失敗的處理結(jié)果封裝到接入接受/拒絕消息中，發(fā)送至認證點。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述802.1X客戶端接入認證期間，當所述802.1X客戶端發(fā)送的所述開始通告請求消息中未攜帶建議?；钪芷跁r，所述802.1X客戶端將所述建議?；钪芷诜庋b到通告請求消息中，發(fā)送至所述認證點，以供所述認證點確定認證點實際?；钪芷凇?br> 5.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述認證點解析收到的所述接入接受消息，得到其中的用于開啟?；罟δ艿氖跈?quán)屬性，并根據(jù)所述用于開啟?；罟δ艿氖跈?quán)屬性，開啟指定身份標識或業(yè)務(wù)管理域標識所對應(yīng)的802.1X客戶端的?；罟δ埽员氵M行802.1X接入會話?；睢?br> 6.根據(jù)權(quán)利要求5所述的方法，其特征在于，所述認證點通過以下步驟確定認證點實際?；钪芷? 所述認證點解析收到的所述開始通告請求消息或所述通告請求消息，得到其中的建議保活周期； 所述認證點解析收到的所述接入接受消息，得到其中的授權(quán)?；钪芷冢? 所述認證點利用所述建議?；钪芷诤?或所述授權(quán)保活周期和/或認證點本地配置的本地?；钪芷冢_定所述認證點實際?；钪芷?。
7.根據(jù)權(quán)利要求5所述的方法，其特征在于，所述客戶端實際保活周期是802.1X客戶端本地的默認?；钪芷凇?br> 8.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述802.1X客戶端解析收到的所述?；铐憫?yīng)消息，得到其中的強制?；钪芷?，并按照所述強制?；钪芷冢{(diào)整客戶端實際?；钪芷凇?br> 9.一種802.1X接入會話?；畹南到y(tǒng)，包括802.1客戶端、用于接入認證的認證點和認證服務(wù)器，其特征在于，所述認證點包括: 認證點消息發(fā)送模塊，用于在802.1X客戶端接入網(wǎng)絡(luò)期間，按照認證點實際保活周期，向802.1X客戶端發(fā)送用于確定所述802.1X客戶端是否異常離網(wǎng)的保活請求消息； 客戶端狀態(tài)確定模塊，用于在認證點預(yù)定時間內(nèi)，若未收到所述802.1X客戶端響應(yīng)所述?；钫埱笙⒌谋；铐憫?yīng)消息，則確定所述802.1X客戶端異常離網(wǎng)，否則確定所述802.1X客戶端正常在網(wǎng)。
10.根據(jù)權(quán)利要求9所述的系統(tǒng)，其特征在于，所述802.1客戶端包括: 客戶端消息發(fā)送模塊，用于在802.1X客戶端接入網(wǎng)絡(luò)期間，按照客戶端實際?；钪芷?，向認證點發(fā)送用于確定所述認證點是否狀態(tài)異常的?；钫埱笙?； 認證點狀態(tài)確定模塊，用于在客戶端預(yù)定時間內(nèi)，若未收到所述認證點響應(yīng)所述?；钫埱笙⒌谋；铐?應(yīng)消息，則確定所述認證點狀態(tài)異常，否則，確定認證點狀態(tài)正常。
全文摘要
本發(fā)明公開了一種802.1X接入會話保活的方法及系統(tǒng)，涉及通信領(lǐng)域，所述方法包括802.1X客戶端接入網(wǎng)絡(luò)期間，用于接入認證的認證點按照認證點實際?；钪芷?，向802.1X客戶端發(fā)送用于確定所述802.1X客戶端是否異常離網(wǎng)的保活請求消息；在認證點預(yù)定時間內(nèi)，若所述認證點未收到所述802.1X客戶端響應(yīng)所述保活請求消息的?；铐憫?yīng)消息，則所述認證點確定所述802.1X客戶端異常離網(wǎng)，否則所述認證點確定所述802.1X客戶端正常在網(wǎng)。本發(fā)明通過擴展現(xiàn)有的802.1X協(xié)議，提升了網(wǎng)絡(luò)資源利用率，降低了認證點出現(xiàn)負擔過重的安全性問題和按時計費錯誤的風(fēng)險。
文檔編號H04L29/06GK103200172SQ20131005306
公開日2013年7月10日 申請日期2013年2月19日 優(yōu)先權(quán)日2013年2月19日
發(fā)明者梁乾燈, 范亮 申請人:中興通訊股份有限公司