【正文】 端系統(tǒng)與L2TP隧道間的連接點(diǎn)。值得注意的是：如果一個(gè)LNS由于事件驅(qū)動(dòng)而建立一個(gè)會(huì)話，那么則把LNS作為L(zhǎng)AC客戶來(lái)看待。 論文結(jié)構(gòu)論文總體上對(duì)L2TP協(xié)議的概念，一個(gè)典型實(shí)現(xiàn)以及對(duì)該實(shí)現(xiàn)的測(cè)試進(jìn)行了描述。第五章是對(duì)系統(tǒng)的測(cè)試，重點(diǎn)在作者所負(fù)責(zé)的模塊方面的測(cè)試。Circuit－電路 2層連接的總稱。 Outgoing Call Request －呼出呼叫請(qǐng)求（OCRQ）是指向LAC發(fā)出的一個(gè)請(qǐng)求，以發(fā)起一個(gè)呼出呼叫。Session－會(huì)話 當(dāng)一個(gè)電路成功建立后，兩個(gè)LCCE之間通過(guò)一個(gè)特殊的控制連接建立起一個(gè)L2TP會(huì)話。這類的報(bào)文采用可靠的控制信道來(lái)發(fā)送。控制報(bào)文在一個(gè)可靠的信道上發(fā)送，穿過(guò)同樣的PSN。 L2TP over IP在L2TPv3中對(duì)over IP專門作了定義，L2TPv3 over IP采用了IANA分配的IP協(xié)議ID為115。Remote SystemPSTNLACLNS分組交換網(wǎng)主機(jī)主機(jī)隧道服務(wù)二層連接本地網(wǎng)DATAIPPPPUDP/IPDATAIPPPPL2TPDATAIP L2TP協(xié)議幀的封裝 TCP/IP協(xié)議棧內(nèi)部的數(shù)據(jù)流向分析正常情況下，數(shù)據(jù)鏈路層協(xié)議（以下簡(jiǎn)稱L2P）的功能是為網(wǎng)絡(luò)層提供服務(wù)。LNS在收到幀后，根據(jù)協(xié)議的標(biāo)識(shí)，對(duì)二層幀頭部作相應(yīng)的處理。 控制和數(shù)據(jù)報(bào)文L2TP頭的格式包括控制報(bào)文和數(shù)據(jù)報(bào)文兩種格式，報(bào)文發(fā)送時(shí)采用高字節(jié)在前的發(fā)送順序。Length域表示報(bào)文的字節(jié)長(zhǎng)度，計(jì)算的方式從報(bào)文的頭部開始。L2TP Session HeaderL2Specific SublayerTunneled Frame 數(shù)據(jù)報(bào)文的頭格式L2TP會(huì)話頭專應(yīng)用穿過(guò)PSN的數(shù)據(jù)流。Cookie：這個(gè)域是可選的，長(zhǎng)度可變，最大為8個(gè)字節(jié)，其值用于檢驗(yàn)所接收的報(bào)文與會(huì)話的關(guān)系。01234567890123456789012345678901TXXXXXXXXXXXVerLengthSession IDCookie (optional, maximum 64 bits)... L2TPv3 over UDP會(huì)話頭T為必須設(shè)置為0，表明為數(shù)據(jù)報(bào)文。01234567890123456789012345678901MHrsvdLengthVendor IDAttribute TypeAttribute Value ...(until Length is reached) AVP格式前六位描述了AVP的一般屬性，其中前兩位被定義，而后四位作為保留位以為將來(lái)擴(kuò)展用。長(zhǎng)度字段（Length）表示這個(gè)AVP中的字節(jié)長(zhǎng)度，一般為屬性值加6。屬性值（Attribute Type）用以表明具體的AVP屬性。在接收端，當(dāng)收到的控制報(bào)文中的AVP不可識(shí)別或是畸形時(shí)，應(yīng)當(dāng)只檢查這個(gè)AVP的M位，反之則不用檢查。如果在一個(gè)給定的控制報(bào)文中的任何AVP的H位被設(shè)定，一個(gè)隨機(jī)向量AVP必須出現(xiàn)在報(bào)文中并且在第一個(gè)帶有H位為1的AVP之前。Padding并不改變Length of Original Attribute Value域，但是改變了合成的AVP的長(zhǎng)度。如果不同的隨機(jī)向量應(yīng)用于并發(fā)AVP的隱藏時(shí)，那么在第一個(gè)AVP應(yīng)用前，必須在命令報(bào)文中設(shè)置一個(gè)新的隨機(jī)向量AVP。把值域分成16字節(jié)的數(shù)據(jù)塊pp2等，最后的塊用隨機(jī)數(shù)填充到16字節(jié)。 控制報(bào)文類型下表是定義的文本定義的控制報(bào)文類型。 LCCE A LCCE B StopCCN (Clean up) (Wait) (Clean up)有時(shí)需要關(guān)掉所有的控制連接以及與控制連接相關(guān)的所有會(huì)話，在這種情況下，當(dāng)拆掉整個(gè)控制連接時(shí)，就不需要單獨(dú)的拆除每一個(gè)控制連接。然而為了確保所有的報(bào)文能都被正確的確認(rèn)，尤其時(shí)在ZLB ACK報(bào)文丟失的情況下，報(bào)文的副本必須由可靠發(fā)送機(jī)制來(lái)確認(rèn)。接收端的可靠發(fā)送機(jī)制負(fù)責(zé)控制報(bào)文的有序發(fā)送以及沒(méi)有副本傳送到協(xié)議上層。下圖是一個(gè)成為L(zhǎng)OCKSTEP的控制連接建立過(guò)程示意。在控制報(bào)文重傳時(shí)，可以采用慢啟動(dòng)和擁塞避免的機(jī)制。為了實(shí)現(xiàn)認(rèn)證，兩個(gè)LCCE必須擁有一個(gè)相同的共享密鑰，且經(jīng)過(guò)AVP隱藏處理。 收到一個(gè)無(wú)效的或者無(wú)法恢復(fù)的畸形的控制報(bào)文應(yīng)該能適當(dāng)?shù)乇挥涗洠⑶铱刂七B接清除應(yīng)確?；謴?fù)到一個(gè)知名的狀態(tài)。也就是說(shuō)AVP必須忽略，并且報(bào)文必須被接受，除非是記錄一個(gè)本地的錯(cuò)誤報(bào)文。（Control Connection States）L2TP協(xié)議在兩段的LCEE上并沒(méi)有明顯的區(qū)分，唯一的區(qū)別是誰(shuí)是呼叫的發(fā)起者，誰(shuí)是呼叫的接收者。并發(fā)送StopCCN。l wait－ctl－reply 發(fā)起者檢查是否有另一個(gè)連接請(qǐng)求，如果有，則進(jìn)行沖突處理。報(bào)文的接受端發(fā)送一個(gè)報(bào)文確認(rèn)后，釋放相關(guān)的控制信息。對(duì)方如果沒(méi)有足夠的資源處理額外的會(huì)話，也可以選擇拒絕接受呼叫。會(huì)話的拆除可以由LAC或者LNS發(fā)起，通過(guò)發(fā)送CDN控制報(bào)文來(lái)完成。l waitreply ICRQ發(fā)送者接收到一個(gè)CDN表明對(duì)方不愿接受呼叫，那么進(jìn)入idle狀態(tài)，如果接收到一個(gè)ICRP，那么就發(fā)送一個(gè)ICCN進(jìn)入會(huì)話建立狀態(tài)。初始狀態(tài)事件動(dòng)作新狀態(tài)idleReceive ICRQ, acceptableSend ICRPwaitconnectReceive ICRQ, not acceptableSend CDN,clean upidleReceive ICRPSend CDN，clean upidleReceive ICCNClean upidleReceive CDNClean upidlewaitconnectReceive ICCN acceptablePrepare for dataestablishedReceive ICCN not acceptableSend CDN, clean upidleReceive ICRQ, ICRPSend CDN, clean upidleReceive CDNClean upidleLocal close requestSend CDN, clean upidleestablishedReceive CDNClean upidleLocal close requestSend CDN, clean upidleReceive ICRQ, ICRP, ICCNSend CDN, clean upidle ICRQ接收者狀態(tài)機(jī) 呼出呼叫狀態(tài)機(jī)以下分別對(duì)OCRQ發(fā)送者狀態(tài)機(jī)和OCRQ接收者狀態(tài)機(jī)作了詳細(xì)的介紹。l established 如果接收到一個(gè)CDN，那么清除會(huì)話，狀態(tài)返回到idle。l waitconnect 如果接收到一個(gè)CDN，那么清除會(huì)話，狀態(tài)返回到idle。當(dāng)接收到ICCN后，狀態(tài)變?yōu)閑stablished。l waitcontrolconnection 在這個(gè)狀態(tài)下，會(huì)話等待控制連接的打開或者等待控制連接已經(jīng)打開的確認(rèn)。 LCCE A LCCE B OCRQ OCRP (執(zhí)行呼叫操作) OCCN (呼叫操作成功完成) 呼出呼叫會(huì)話連接建立過(guò)程LCCE 首先發(fā)送一個(gè)OCRQ呼出呼叫請(qǐng)求到LAC，LAC一旦確定存在適當(dāng)?shù)脑O(shè)備來(lái)產(chǎn)生一個(gè)呼叫，并且呼叫經(jīng)過(guò)了認(rèn)證，那么就發(fā)送一個(gè)OCRP作為響應(yīng)。LCCE發(fā)送ICRQ后，就會(huì)等待對(duì)方的應(yīng)答。(Termination of a Control Connection)任何一端發(fā)出一個(gè)StopCCN報(bào)文都可以終止一個(gè)控制連接。l idle 發(fā)起和接收都從這個(gè)狀態(tài)開始?？刂七B接tiebreaker的值是一個(gè)8字節(jié)的隨機(jī)數(shù)，作用是當(dāng)兩個(gè)LCCE同時(shí)請(qǐng)求一個(gè)控制連接時(shí)，用來(lái)選擇一個(gè)單一的控制連接。在狀態(tài)機(jī)中有幾種情況，當(dāng)協(xié)議報(bào)文發(fā)送后，產(chǎn)生一個(gè)“clear up”。 如果一個(gè)接收到的畸形的AVP強(qiáng)制位（M位）被設(shè)置，會(huì)話或者控制連接必須被終止，并且要發(fā)送一個(gè)適當(dāng)?shù)慕Y(jié)果或錯(cuò)誤代碼。其中定義了呼入和呼出的情況，以及控制連接本身的初始狀態(tài)。如果接收到SCCRQ或者SCCRP報(bào)文中挑戰(zhàn)AVP，那么就緊接著在SCCRP或SCCCN的響應(yīng)報(bào)文中發(fā)送一個(gè)挑戰(zhàn)應(yīng)答AVP。一旦N個(gè)報(bào)文被發(fā)送，B就必須等待A的確認(rèn)，以確保在發(fā)送新的報(bào)文前，A的窗口向前移動(dòng)。如果一段時(shí)間沒(méi)有確認(rèn)，則報(bào)文進(jìn)行重傳。作為預(yù)防措施，在清除重傳報(bào)文之前應(yīng)該檢查Nr位。例如，如果收到的序列號(hào)為15，那么15前的32767個(gè)序列為：0～15以及32784～65535。LCCE A LCCE B SCCRQ SCCRPSCCCN 控制連接建立過(guò)程控制連接的拆除可以由任何一個(gè)LCCE發(fā)起，通過(guò)發(fā)送一個(gè)StopCCN控制報(bào)文來(lái)完成。這種報(bào)文類型AVP的屬性值域是一個(gè)兩字節(jié)的無(wú)符號(hào)整數(shù)。如果需要，可以重復(fù)這種操作，通過(guò)使用共享密鑰和每次異或的結(jié)果來(lái)產(chǎn)生下一個(gè)哈希值，以與下一個(gè)字節(jié)段進(jìn)行異或。發(fā)送者在進(jìn)行AVP隱藏操作前，必須把這個(gè)隨機(jī)向量AVP放在報(bào)文中。Padding：隨機(jī)附加的字節(jié)用于加密被隱藏的屬性值的長(zhǎng)度。在LCCE認(rèn)證成功完成以后，隱藏值不可以公開（也許需要隱藏值保存直到附加配置報(bào)文接收到）。例如，僅僅發(fā)送一個(gè)設(shè)定了M位的AVP來(lái)確定一個(gè)特殊的擴(kuò)展是否存在，不如采用通過(guò)在請(qǐng)求報(bào)文里發(fā)送一個(gè)AVP，以期待在應(yīng)答報(bào)文里是否存在一個(gè)相應(yīng)的AVP這種方法來(lái)的要好。這里Vendor ID分配了16位，那么限制了企業(yè)數(shù)為前65535個(gè)。隱藏（H）位用于識(shí)別AVP中屬性值域中的隱藏?cái)?shù)據(jù)。 AVP定義在確保互用性的情況下，為了最大化報(bào)文的可擴(kuò)展性，在L2TP中采用報(bào)文類型和內(nèi)容統(tǒng)一編碼的方法。數(shù)據(jù)報(bào)文頭后緊跟著所要入隧的二層幀。會(huì)話標(biāo)識(shí)符只具有本地的意義，也就是說(shuō)在會(huì)話的生命期內(nèi)，控制連接的兩端可以具有不同的會(huì)話ID。Nr表示下一個(gè)收到的控制報(bào)文所期望的序列號(hào)，也就是說(shuō)Nr的值被設(shè)定為Ns加1。X域是保留位作為將來(lái)的擴(kuò)展用，如果是呼出報(bào)文的話，保留位則設(shè)定為0，如果是呼入報(bào)文則忽略。目的是為了本章最后所作的系統(tǒng)設(shè)計(jì)的需要，包括系統(tǒng)的框架設(shè)計(jì)以及模塊的劃分等。數(shù)據(jù)包也就是二層的數(shù)據(jù)，如PPP的幀，在隧道建立完成后，通過(guò)L2TP的內(nèi)核來(lái)完成封裝，再通過(guò)TCP/IP的內(nèi)核路由到目的端。封裝完成后，通過(guò)隧道發(fā)送到LNS，LNS則完成解封裝的過(guò)程，獲得原始的數(shù)據(jù)。隧道的發(fā)起者選擇一個(gè)空閑的源UDP端口（如：1701或者其他端口），然后將UDP包發(fā)送到接收者的1701端口上，接收者選擇一個(gè)空閑端口（如：1701或者其他端口），并把它作為源端口，把發(fā)起者的IP地址和UDP端口作為目標(biāo)地址和端口，發(fā)送一個(gè)響應(yīng)。它相對(duì)于L2TPv2發(fā)生了一些變化，L2TPv2中控制和數(shù)據(jù)報(bào)文的頭格式定義了一個(gè)統(tǒng)一的形式，而L2TPv3中將控制報(bào)文頭和數(shù)據(jù)報(bào)文頭區(qū)分開，以滿足在通過(guò)UDP或者IP不同應(yīng)用時(shí)的需要。L2TP協(xié)議有兩種類型的報(bào)文，控制報(bào)文和數(shù)據(jù)報(bào)文。每一個(gè)L2TP會(huì)話都有一個(gè)偽線。呼人呼叫如果決定要求使用隧道，那么LAC將產(chǎn)生一個(gè)L2TP的ICRQ報(bào)文。呼叫由呼叫的類型，被呼叫數(shù)等屬性以及呼叫的數(shù)據(jù)量來(lái)定義。并在此分析的基礎(chǔ)上提出了實(shí)現(xiàn)的總體框架。工作完成后，筆者將自己的研究工作轉(zhuǎn)向了網(wǎng)絡(luò)技術(shù)方面，因此與同屆的李杰和任挺同學(xué)一道，開展了二層隧道協(xié)議方面研究與開發(fā)工作。一個(gè)會(huì)話可以通過(guò)用戶來(lái)建立，或者由某些信號(hào)所觸發(fā)的事件來(lái)驅(qū)動(dòng)使其建立。PSTN:公共電話網(wǎng)絡(luò) LACLNS參考模型②LACLAC組合每個(gè)LAC使用L2TP協(xié)議把遠(yuǎn)程系統(tǒng)（Remote System）數(shù)據(jù)流發(fā)送到對(duì)等端的 LAC，反之亦然。與非自建隧道的處理過(guò)程基本類似，只不過(guò)PPP幀的生成與封裝全部在LAC Client中完成。非自建隧道的創(chuàng)建不需要用戶來(lái)操作，也不允許用戶進(jìn)行任何選擇。對(duì)隧道功能的形象表達(dá)可以用“過(guò)渡”（Ferrying）來(lái)描述，公用數(shù)據(jù)網(wǎng)可以看作是河流，隧道視為“渡船”（Ferry），而過(guò)渡的乘客或車輛則是用戶期望過(guò)河的數(shù)據(jù)?！八淼纻鬏敗被蛘摺斑^(guò)渡”的思想[5]實(shí)際上有更廣泛的應(yīng)用前景。在隧道內(nèi)建立PPP連接時(shí)，PPTP需要對(duì)訪問(wèn)者的身份進(jìn)行認(rèn)證（如用戶名，口令和域名等）。Internet環(huán)境提供了兩種典型的VPN技術(shù)：安全I(xiàn)P協(xié)議（IPSec）[2]和二層隧道協(xié)議[7