portal協(xié)議標(biāo)準(zhǔn)V20_第1頁
portal協(xié)議標(biāo)準(zhǔn)V20_第2頁
portal協(xié)議標(biāo)準(zhǔn)V20_第3頁
portal協(xié)議標(biāo)準(zhǔn)V20_第4頁
portal協(xié)議標(biāo)準(zhǔn)V20_第5頁
已閱讀5頁,還剩17頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、 Q/DKBA華為技術(shù)有限公司企業(yè)技術(shù)標(biāo)準(zhǔn)Q/DKBAXXXX-2001 華為公司寬帶產(chǎn)品Portal協(xié)議標(biāo)準(zhǔn)第2部分:Portal標(biāo)準(zhǔn)V2.0 2001-XX-XX發(fā)布 2001-XX-XX實(shí)施華 為 技 術(shù) 有 限 公 司發(fā)布 Q/DKBAXXXX-2001 密級:機(jī)密目 次1 范圍42 術(shù)語和定義43 概述44協(xié)議44.1報(bào)文格式44.2報(bào)文字段說明44.2.1Ver54.2.2Type54.2.3Pap/Chap54.2.4Rsv64.2.5SerialNo64.2.6ReqID64.2.7UserIP64.2.8UserPort64.2.9ErrCode64.2.10AttrNum6

2、4.2.11 Authenticator64.2.12報(bào)文屬性字段(Attr)的格式75流程和相關(guān)說明95.1信息詢問流程(無論成功還是失?。?5.2下線通知流程(BAS通知Portal Server)106其他說明116.1關(guān)于TextInfo屬性的使用116.2協(xié)議的兼容性116.3協(xié)議的不完善之處11前 言本標(biāo)準(zhǔn)由寬帶聯(lián)合系統(tǒng)部提出。本標(biāo)準(zhǔn)主要起草部門:寬帶聯(lián)合系統(tǒng)部,MA5200產(chǎn)品組,ESR產(chǎn)品組,iNet產(chǎn)品組本標(biāo)準(zhǔn)主要解釋部門:寬帶總體組本標(biāo)準(zhǔn)主要起草人:楊宏杰、周和秘、喬明本標(biāo)準(zhǔn)主要審核人:盧朝暉、胡鵬本標(biāo)準(zhǔn)批準(zhǔn)人:華為公司寬帶產(chǎn)品Portal協(xié)議標(biāo)準(zhǔn)V2.01 范圍本標(biāo)準(zhǔn)規(guī)定

3、了華為公司寬帶產(chǎn)品所采用的Portal協(xié)議標(biāo)準(zhǔn)。本標(biāo)準(zhǔn)適用于華為公司具備Portal特性的寬帶設(shè)備,包括服務(wù)器端設(shè)備(如:iTellin、iNet IP Hotel系統(tǒng)等)以及BAS端設(shè)備(如:ESR、MA5200等)特別的:對于服務(wù)器端設(shè)備(如:iTellin、iNet IP Hotel系統(tǒng)等)必須同時(shí)支持V1.0與V2.0協(xié)議,對于BAS端設(shè)備(如:ESR、MA5200等)以V2.0為標(biāo)準(zhǔn)。2 術(shù)語和定義Portal 門戶業(yè)務(wù)Web認(rèn)證 通過Web方式進(jìn)行用戶認(rèn)證認(rèn)證Client 本文中使用的概念,表示協(xié)議中發(fā)起認(rèn)證請求的一方,可以為Portal Server或 任何發(fā)起認(rèn)證的客戶機(jī)。在不

4、會引起混淆的情況下,簡稱為Client認(rèn)證Server 本文中使用的概念,表示協(xié)議中接受認(rèn)證請求的一方,例如BAS設(shè)備。 在不 會引起混淆的情況下,簡稱為ServerBAS Broad Access Server 寬帶接入設(shè)備3 概述本文檔主要分兩部分,一部分描述了PortalServer和BAS設(shè)備之間的通信協(xié)議,令一部分(附錄)提出了對PortalServer 的Web服務(wù)器相關(guān)配置和網(wǎng)頁設(shè)計(jì)的一些規(guī)定。PortalServer和BAS設(shè)備之間的協(xié)議規(guī)定了采用Portal認(rèn)證(或Web認(rèn)證)時(shí)PortalServer和BAS設(shè)備之間的報(bào)文格式和通信流程,協(xié)議支持PAP和CHAP兩種認(rèn)證方式

5、,對可能出現(xiàn)的各種情況的認(rèn)證流程分別做了詳細(xì)的規(guī)定。Portal V2.0協(xié)議是對原有V1.0協(xié)議存在的漏洞和不合理之處進(jìn)行部分完善,增加了用于對協(xié)議報(bào)文進(jìn)行驗(yàn)證的字段Authenticator。對于V1.0與V2.0相互沖突之處,一律以V2.0為準(zhǔn)。4 協(xié)議4.1 報(bào)文格式協(xié)議包采用固定長度頭加可變長度的屬性字段組成,屬性字段采用TLV格式。為了增加對協(xié)議報(bào)文的校驗(yàn),擴(kuò)充報(bào)文格式如下(圖 4-1):圖4-1 增加報(bào)文校驗(yàn)之后的Portal協(xié)議報(bào)文格式4.2 報(bào)文字段說明VerVer字段是協(xié)議的版本號,長度為 1 字節(jié),Ver = 0x02。之所以對Version進(jìn)行升級,是因?yàn)閷ersio

6、n 1做了如下的擴(kuò)充:þ 修改了報(bào)文格式,在AttrNum字段之后增加了16個(gè)字節(jié)的Authenticator字段。þ 增加對所有協(xié)議報(bào)文的校驗(yàn),包括上線流程、下線流程和查詢流程。þ 修改了TextInfo屬性,使其完全符合TLV格式(version 1曾經(jīng)出現(xiàn)過不完全符合TLV格式的軟件實(shí)現(xiàn)版本),不再區(qū)分其內(nèi)容的語言,并且約定:BAS本地產(chǎn)生的提示信息不上報(bào)到Portal Server。TypeType字段定義報(bào)文的類型,長度為 1 字節(jié)。該版本兼容原協(xié)議的全部命令字,同時(shí)新增類型為0x08,0x09,0x0a三個(gè)命令字:Type值方向含義REQ_CHALLE

7、NGE0x01Client -> ServerPortal Server向BAS發(fā)送的Challenge請求報(bào)文ACK_CHALLENGE0x02Server -> ClientBAS對Portal Server請求Challenge報(bào)文的響應(yīng)報(bào)文REQ_AUTH0x03Client -> ServerPortal Server向BAS發(fā)送的認(rèn)證請求報(bào)文ACK_AUTH0x04Server -> ClientBAS對Portal Server認(rèn)證請求的響應(yīng)報(bào)文REQ_LOGOUT0x05Client -> ServerPortal Server向BAS發(fā)送的下線請

8、求報(bào)文ACK_LOGOUT0x06Server -> ClientBAS對Portal Server下線請求的響應(yīng)報(bào)文AFF_ACK_AUTH0x07Client -> ServerPortal Server向BAS發(fā)送的NTF_LOGOUT0x08Server -> Client用戶被強(qiáng)制下線通知報(bào)文REQ_INFO0x09Client -> Server信息詢問報(bào)文ACK_INFO0x0aServer -> Client信息詢問的應(yīng)答報(bào)文表1 協(xié)議支持的命令字Pap/Chap與原協(xié)議一致。Pap/Chap字段定義此用戶的認(rèn)證方式,長度為 1 字節(jié),只對Type

9、值為 0x03 的認(rèn)證請求報(bào)文有意義:Chap方式認(rèn)證值為0x00;Pap 方式認(rèn)證值為0x01;þ把Pap/Chap放在協(xié)議報(bào)文的目前位置,使得整個(gè)報(bào)文不太協(xié)調(diào)。但是考慮到現(xiàn)實(shí)的原因,目前不對該字段進(jìn)行任何更改。Rsv與原協(xié)議一致。Rsv目前為保留字段,長度為 1 字節(jié),在所有報(bào)文中值為 0;SerialNo與原協(xié)議一致。(1)、SerialNo字段為報(bào)文的序列號,長度為 2 字節(jié),由PortalServer隨機(jī)生成,Portal Server必須盡量保證不同認(rèn)證流程的SerialNo在一定時(shí)間內(nèi)不得重復(fù),在同一個(gè)認(rèn)證流程中所有報(bào)文的SerialNo相同;(2)、PortalSer

10、ver發(fā)給BAS設(shè)備的報(bào)文a、由Portal Server發(fā)出的Type值為1、3的請求報(bào)文其SerialNo都是隨機(jī)生成數(shù);b、由PortalServer向BAS設(shè)備發(fā)出的Type值為5的報(bào)文其SerialNo值分兩中情況:當(dāng)ErrCode為0時(shí),SerialNo值為一個(gè)隨機(jī)生成數(shù);當(dāng)ErrCode為1時(shí),SerialNo值可能和Type值為1或3的報(bào)文相同,具體要看是請求Challenge超時(shí)還是請求認(rèn)證超時(shí);c、由PortalServer向BAS設(shè)備發(fā)出的認(rèn)證成功確認(rèn)報(bào)文(Type值為7的報(bào)文)SerialNo和其發(fā)出的相應(yīng)請求報(bào)文的SerrialNo相同;比如對于Type值為7的報(bào)文其

11、SerialNo值和Type值為3的請求認(rèn)證報(bào)文相同;(3)、每一個(gè)由BAS設(shè)備發(fā)給PortalServer的響應(yīng)報(bào)文的SerialNo必須和Portal Server發(fā)送的相應(yīng)請求報(bào)文的SerialNo一樣,否則PortalServer會丟掉從BAS設(shè)備發(fā)來的響應(yīng)報(bào)文; 比如Type值為2的報(bào)文其SerialNo值必須和Type值為1的報(bào)文相同,Type值為4的報(bào)文其SerialNo值必須和Type值為3的報(bào)文相同,Type值為6的報(bào)文其SerialNo值必須和Type值為5的報(bào)文相同。ReqID與原協(xié)議一致。(1)、ReqID字段長度為 2 個(gè)字節(jié),由BAS設(shè)備隨機(jī)生成,盡量使得在一定時(shí)間

12、內(nèi)ReqID不重復(fù)。(2)、在Chap認(rèn)證方式中:a、BAS設(shè)備在Type為2的請求Challenge響應(yīng)報(bào)文中把該ReqID的值告訴PortalServer;b、在Type值為3、4、7的報(bào)文中ReqID字段的值都和Type值為2的報(bào)文中此字段的值相同;c、在Type值為 5 的報(bào)文中,若報(bào)文表示請求Challenge超時(shí)則此字段值為0 ;若報(bào)文表示請求認(rèn)證超時(shí)則此字段值和Type值為2的報(bào)文中此字段的值相同;(3)、在Pap認(rèn)證方式中,此字段無意義,其值為0;(4)、在Type值為 5 的報(bào)文中,若報(bào)文表示請求下線時(shí)則此字段值為0 ;(5)、在Type值為1、6的報(bào)文中,該字段均無意義,值

13、都為0;UserIP與原協(xié)議一致。 UserIP字段為Portal用戶的IP地址,長度為 4 字節(jié),其值由PortalServer根據(jù)其獲得的IP地址填寫,在所有的報(bào)文中此字段都要有具體的值;UserPort與原協(xié)議一致。 UserPort字段目前沒有用到,長度為 2 字節(jié),在所有報(bào)文中其值為0;ErrCodeErrCode字段和Type字段一起表示一定的意義,長度為 1字節(jié)。對原協(xié)議支持的Type,ErrCode與原協(xié)議一致。具體如下:(1)、對于Type值為1、3、7的報(bào)文,ErrCode字段無意義,其值為0;(2)、當(dāng)Type值為 2 時(shí):ErrCode0,表示BAS設(shè)備告訴Portal

14、Server請求Challenge成功;ErrCode1,表示BAS設(shè)備告訴PortalServer請求Challenge被拒絕; ErrCode2,表示BAS設(shè)備告訴PortalServer此鏈接已建立;ErrCode3,表示BAS設(shè)備告訴PortalServer有一個(gè)用戶正在認(rèn)證過程中,請稍后再試;ErrCode4,則表示BAS設(shè)備告訴PortalServer此用戶請求Challenge失?。òl(fā)生錯(cuò)誤);(3)、當(dāng)Type值為 4 時(shí):ErrCode0,表示BAS設(shè)備告訴PortalServer此用戶認(rèn)證成功;ErrCode1,表示BAS設(shè)備告訴PortalServer此用戶認(rèn)證請求被拒絕

15、;ErrCode2,表示BAS設(shè)備告訴PortalServer此鏈接已建立; ErrCode3,表示BAS設(shè)備告訴PortalServer有一個(gè)用戶正在認(rèn)證過程中,請稍后再試;ErrCode4 ,表示BAS設(shè)備告訴PortalServer此用戶認(rèn)證失?。òl(fā)生錯(cuò)誤);(4)、當(dāng)Type值為 5 時(shí):ErrCode0,表示此報(bào)文是PortalServer發(fā)給BAS設(shè)備的請求下線報(bào)文;ErrCode1,表示此報(bào)文是在PortalServer沒有收到BAS設(shè)備發(fā)來的對各種請求的響應(yīng)報(bào)文,而定時(shí)器時(shí)間到(即超時(shí))時(shí)由PortalServer發(fā)給BAS設(shè)備的報(bào)文;(5)、當(dāng)Type值為 6 時(shí):ErrCo

16、de0,表示BAS設(shè)備告訴PortalServer此用戶下線成功;ErrCode1,表示BAS設(shè)備告訴PortalServer此用戶下線被拒絕;ErrCode2, 表示BAS設(shè)備告訴PortalServer此用戶下線失?。òl(fā)生錯(cuò)誤);對新增命令報(bào)文的ErrCode說明如下:þ對Type為REQ_INFO時(shí),ErrCode無意義,其值為0;þ對Type為NTF_LOGOUT時(shí),ErrCode含義如下:ErrCode含義0下線þ對Type為ACK_INFO時(shí),ErrCode含義如下:ErrCode含義0處理成功,但不表示全部消息都被獲取了,有多少信息被獲得應(yīng)通過屬性來

17、判斷,詳見下文1功能不支持,表示設(shè)備不支持這一功能2消息處理失敗,由于某種不可知原因,使處理失敗,例如詢問消息格式錯(cuò)誤等。AttrNum與原協(xié)議一致。 AttrNum字段表示其后邊可變長度的屬性字段屬性的個(gè)數(shù),長度為 1 字節(jié)(表示屬性字段最多可有255個(gè)屬性),其值在所有的報(bào)文中都要根據(jù)具體情況賦值;Authenticator新增字段。驗(yàn)證字的長度固定為16字節(jié),網(wǎng)絡(luò)字節(jié)順序。其內(nèi)容的計(jì)算在請求報(bào)文和響應(yīng)報(bào)文中略有區(qū)別,并且在驗(yàn)證字的計(jì)算時(shí),將類型為7(AFF_ACK_AUTH)和類型為8(NTF_LOGOUT)的報(bào)文當(dāng)作請求報(bào)文,盡管這兩種報(bào)文不是嚴(yán)格意義上的請求報(bào)文(嚴(yán)格的說,AFF_A

18、CK_AUTH更像是響應(yīng)報(bào)文)。驗(yàn)證字的計(jì)算是通過MD5算法實(shí)現(xiàn)的,其中報(bào)文的各個(gè)字段以及BAS和Portal Server之間的共享密鑰secret都參與了計(jì)算。以下分別介紹請求報(bào)文的驗(yàn)證字和響應(yīng)報(bào)文的驗(yàn)證字。1. 請求報(bào)文的驗(yàn)證字(Request Authenticator):以字節(jié)流Ver + Type + PAP/CHAP + Rsvd + SerialNo + ReqID + UserIP + UserPort + ErrCode + AttrNum + 16個(gè)字節(jié)的0 + request attributes + secret作為MD5的輸入,得到的MD5輸出就是請求報(bào)文的驗(yàn)證字R

19、equest Authenticator的內(nèi)容。2. 響應(yīng)報(bào)文的驗(yàn)證字(Response Authenticator):以字節(jié)流Ver + Type + PAP/CHAP + Rsvd + SerialNo + ReqID + UserIP + UserPort + ErrCode + AttrNum + 本響應(yīng)報(bào)文對應(yīng)的請求報(bào)文的16字節(jié)的Request Authenticator + response attributes + secret作為MD5的輸入,得到的MD5輸出就是響應(yīng)報(bào)文的驗(yàn)證字Response Authenticator的內(nèi)容。為了完成校驗(yàn)功能,需要注意如下幾點(diǎn):þ

20、;在Server和Client兩端需要配置相同的共享密鑰Secret,否則無法通過接收方的校驗(yàn);þ雙方都使用RFC1321中描述的MD5加密算法;þ接收方為了校驗(yàn)所接收到報(bào)文的正確性,必須采用和發(fā)送方完全一樣的計(jì)算過程。如果計(jì)算出來的驗(yàn)證字和接收到的報(bào)文中的驗(yàn)證字一致,則認(rèn)為報(bào)文合法;否則任務(wù)報(bào)文錯(cuò)誤,可以簡單丟棄,但是建議對丟棄報(bào)文進(jìn)行統(tǒng)計(jì)。þ請求驗(yàn)證字和響應(yīng)驗(yàn)證字的計(jì)算參照了RADIUS計(jì)費(fèi)報(bào)文的驗(yàn)證字的計(jì)算方法。þ目前支持的報(bào)文類型存在如下的請求和響應(yīng)關(guān)系: 請求響應(yīng)REQ_CHALLENGE <> ACK_CHALLENGEREQ_A

21、UTH <> ACK_AUTHREQ_LOGOUT <> ACK_LOGOUTREQ_INFO <> ACK_INFONTF_LOGOUT 無AFF_ACK_AUTH 無 報(bào)文屬性字段(Attr)的格式Attr字段(屬性字段)是一個(gè)可變長字段,由多個(gè)屬性依次鏈接而成,每個(gè)屬性的格式為TLV格式,具體如下(圖4-2):圖 4-2 報(bào)文屬性字段格式報(bào)文屬性字段說明如下:(1)、屬性類型(AttrType)表 4-2 屬 性字 段 的定義Attr(屬性字段)AttrType AttrValue自身的長度(屬性值長 度)屬性含義UserName0x01<=32

22、 (可變) 用 戶 名,具體為:“用戶名”“”+“域名”PassWord0x02<=16(可變)用戶提交的明文密 碼Challenge0x0316(固定) Chap方式加密的魔 術(shù) 字ChapPassWord0x0416(固定)經(jīng)過Chap方式加密后的密碼(2)、屬性長度(AttrLen)AttrLen字段表示屬性的長度,長度為1字節(jié),其值是整個(gè)屬性三個(gè)字段AttrType、AttrLen、AttrValue的長度之和:也就是AttrValue的長度加上2;(3)、屬性值(AttrValue)AttrValue的值為具體的屬性值,比如用戶名、口令等,長度有些可變,有些固定(具體見表4-2

23、),但最長不能超過253(255-2)字節(jié);þ支持原協(xié)議中的全部屬性字,并且對部分屬性說明如下: 1.TextInfo 格式為:類型+長度+內(nèi)容 類型為5,長度大于等于3,小于等于255,該屬性用于將RADIUS等第三方鑒權(quán)設(shè)備的提示信息透傳到Portal Server。該屬性所攜帶的內(nèi)容為字符串,但是不包括字符串結(jié)束符0。該屬性在同一個(gè)報(bào)文中允許多個(gè),建議只攜帶1個(gè)該屬性。該屬性可以存在于從BAS到Portal Server的任何報(bào)文中。 2.UpLinkFlux(暫不支持) 格式為:類型+長度(在REQ_INFO報(bào)文中)或者類型+長度+內(nèi)容(在ACK_INFO報(bào)文) 類型為6,長

24、度為2或者10:在REQ_INFO報(bào)文中,長度為2;在ACK_INFO報(bào)文中,長度為10。在ACK_INFO報(bào)文中其內(nèi)容是一個(gè)表示從該用戶終端上行(輸出)流量的8字節(jié)(64位)無符號整數(shù)(網(wǎng)絡(luò)順序),單位為kbytes。 3.DownLinkFlux(暫不支持) 格式為:類型+長度(在REQ_INFO報(bào)文中)或者類型+長度+內(nèi)容(在ACK_INFO報(bào)文) 類型為7,長度為2或者10:在REQ_INFO報(bào)文中,長度為2;在ACK_INFO報(bào)文中,長度為10。在ACK_INFO報(bào)文中,其內(nèi)容是一個(gè)表示該用戶終端下行(輸入)流量的8字節(jié)(64位)無符號整數(shù)(網(wǎng)絡(luò)順序),單位為kbytes。 4.Po

25、rt 格式為:類型+長度(在REQ_INFO報(bào)文中)或者類型+長度+內(nèi)容(在ACK_INFO報(bào)文) 類型為8,長度可以大于等于2,小于等于37:"主機(jī)名"+"-"+"2位槽號"+"1位子槽號"+“2位端口號”+("4位VPI"+"5位VCI")或("4位外層VLAN"+"0"+"4位內(nèi)層VLAN") 說明:只有一層VLAN時(shí),外層VLAN填"0"。共35個(gè)字符。Attr(屬性字段)AttrType

26、AttrLen屬性含義TextInfo0x05大于等于3,小于等于255本屬性只能在BAS到Portal Server的報(bào)文中存在,同時(shí),協(xié)議規(guī)定:BAS只是透傳從RADIUS來的錯(cuò)誤信息,屬性的內(nèi)容可以為任意字符串,不帶'0'結(jié)束符UpLinkFlux0x062或者10(暫不支持)本屬性只能在REQ_INFO和ACK_INFO報(bào)文中存在。數(shù)量不能超過1。當(dāng)Type=REQ_INFO時(shí),長度為2。當(dāng)Type=ACK_INFO時(shí),長度為10,內(nèi)容是一個(gè)表示該用戶的流量的8字節(jié)無符號整數(shù)(網(wǎng)絡(luò)順序),單位為kbytesDownLinkFlux0x072或者10(暫不支持)同上Por

27、t0x08大于等于2,小于等于37本屬性只能在REQ_INFO和ACK_INFO報(bào)文中存在。數(shù)量不能超過1。當(dāng)Type=REQ_INFO時(shí),長度為2。"主機(jī)名"+"-"+"2位槽號"+"1位子槽號"+“2位端口號”+("4位VPI"+"5位VCI")或("4位外層VLAN"+"0"+"4位內(nèi)層VLAN") 說明:只有一層VLAN時(shí),外層VLAN填"0"共35個(gè)字符 表 4-3新增屬性的定義5 流程

28、和相關(guān)說明Version 2的協(xié)議流程除了完全包含Version 1的協(xié)議流程之外,還增加了信息查詢和BAS主動通知Portal Server下線的流程。舊版本協(xié)議的流程說明如下:5.1 Chap認(rèn)證方式上線流程Chap認(rèn)證流程(每一步都正確的情況下)(圖 5-1)圖 5-1 Chap方式認(rèn)證正常流程Chap認(rèn)證流程(請求Challenge失敗或被拒絕的情況下)(圖 5-2 )圖 5-2 Chap認(rèn)證方式請求魔術(shù)字失敗流程Chap認(rèn)證流程(請求Challenge沒有響應(yīng)的情況下)(圖 5-3)圖 5-3 Chap認(rèn)證方式,請求魔術(shù)字無響應(yīng)流程Chap認(rèn)證流程(認(rèn)證結(jié)果為失敗或被拒絕的情況下)(

29、圖 5-4)圖 5-4 Chap認(rèn)證方式,認(rèn)證失敗流程Chap認(rèn)證流程(請求認(rèn)證沒有響應(yīng)的情況下)(圖5-5)圖 5-5 Chap認(rèn)證方式,請求認(rèn)證無響應(yīng)流程5.2 Pap認(rèn)證方式上線流程Pap認(rèn)證流程(每一步都正確的情況下)(圖 5-6)圖:5-6 Pap認(rèn)證方式正常流程Pap認(rèn)證流程(認(rèn)證失敗或被拒絕的情況下)(圖 5-7)圖 5-7 Pap 認(rèn)證方式,認(rèn)證失敗流程Pap認(rèn)證流程(請求認(rèn)證沒有響應(yīng)的情況下)(圖 5-8)圖 5-8 Pap認(rèn)證方式,請求認(rèn)證無響應(yīng)流程5.3 下線流程(說明:下線流程不分Chap和Pap)下線成功的流程(圖 5-9)圖 5-9 正常下線流程下線失敗或被拒絕的流

30、程(圖5-10)圖 5-10 下線失敗流程下線沒有響應(yīng)流程(圖 5-11)圖 5-11 下線報(bào)文無響應(yīng)流程þ新增流程的說明如下:5.4 信息詢問流程(無論成功還是失敗,參見圖5-12)圖5-12 信息詢問流程根據(jù)協(xié)議,REQ_INFO消息的定義如下:Ver1TypeREQ_INFOPap/Chap無意義,填0Rsv無意義,填0SerialNo任意,建議使用一個(gè)能用于區(qū)分當(dāng)前不同會話的一個(gè)數(shù)值。Server將在應(yīng)答消息中使用相同的SerialNoReqID無意義,填0UserIP被詢問的用戶IPUserPort無意義,填0ErrCode無意義,填0AttrNum根據(jù)實(shí)際情況填寫Auth

31、enticator根據(jù)Request Authenticator的計(jì)算方法進(jìn)行計(jì)算的結(jié)果<Attribution>這個(gè)消息可以帶屬性UpLinkFlux, DownLinkFlux, 和Port中的一個(gè)或多個(gè),取決于Client需要詢問何種信息。在發(fā)詢問時(shí),根據(jù)需要詢問的內(nèi)容,帶一個(gè)長度為2的相應(yīng)屬性即可。ACK_INFO的消息的定義如下:Ver1TypeACK_INFOPap/Chap無意義,填0Rsv無意義,填0SerialNo與相應(yīng)詢問消息的SerialNo一致ReqID無意義,填0UserIP被詢問的用戶IPUserPort無意義,填0ErrCode見上文的對ErrCode

32、的定義AttrNum根據(jù)實(shí)際情況填寫Authenticator根據(jù)Response Authenticator的計(jì)算方法進(jìn)行計(jì)算的結(jié)果<Attribution>這個(gè)消息可以帶屬性UpLinkFlux, DownLinkFlux, 和Port中的一個(gè)或多個(gè),取決于相應(yīng)的REQ_INFO消息帶了哪些詢問屬性。如果某屬性取不到,則不返回該屬性。所以一個(gè)屬性在本消息中存在的必要條件是:i. 詢問消息中存在ii. 能被取得5.5 下線通知流程(BAS通知Portal Server)對于從Portal Server向BAS請求用戶下線的流程此處不進(jìn)行描述。用于Server首先檢測到用戶已經(jīng)下線

33、;或者BAS主動切斷連接時(shí),用來通知Portal Server(參見圖5-13):圖5-13 下線通知流程通知消息固定向UDP端口50100發(fā)送。NTF_LOGOUT的定義如下:Ver1TypeNTF_LOGOUTPap/Chap無意義,填0Rsv無意義,填0SerialNo無意義,填0ReqID無意義,填0UserIP被下線的用戶IPUserPort無意義,填0ErrCode見上文的對ErrCode的定義AttrNum根據(jù)實(shí)際情況填寫Authenticator根據(jù)Request Authenticator的計(jì)算方法進(jìn)行計(jì)算的結(jié)果<Attribution> 無,或者Server設(shè)備

34、需要通過文字信息描述下線原因,可以帶一個(gè)或多個(gè)TextInfo屬性6 其他說明6.1 關(guān)于TextInfo屬性的使用TextInfo用于傳遞文字信息。建議使用如下慣用法:þ正常情況下,任何消息都不帶該屬性。þ如果Server通過第三方設(shè)備實(shí)現(xiàn)鑒權(quán),例如Radius Server,而該設(shè)備又包含文字信息,應(yīng)使用該信息作為文字信息。þBAS本身產(chǎn)生的錯(cuò)誤信息不傳送到Portal server。þ建議BAS能通過調(diào)試命令關(guān)閉/打開消息透傳的功能。6.2 協(xié)議的兼容性顯然,引入了報(bào)文驗(yàn)證字之后,版本Version 2與Version 1完全不兼容。如果嚴(yán)格按照擴(kuò)充后的協(xié)議,舊版本的下線流程和查詢流程報(bào)文將因?yàn)闆]有攜帶Authentic

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論