【正文】 置，會話或者控制連接必須被終止，并且要發(fā)送一個適當(dāng)?shù)慕Y(jié)果或錯誤代碼。可以列出一個給定報文的所有可能畸形格式，并給出各自的解決方案。在狀態(tài)機中有幾種情況，當(dāng)協(xié)議報文發(fā)送后，產(chǎn)生一個“clear up”。由于無論是LNS還是LAC均可作為呼叫的發(fā)起者，所以如果要求在兩個LCCE之間建立單一的連接的話，就可能同時呼叫而引起沖突?？刂七B接tiebreaker的值是一個8字節(jié)的隨機數(shù)，作用是當(dāng)兩個LCCE同時請求一個控制連接時，用來選擇一個單一的控制連接。如果只有一方SCRRQ中有tiebreaker值，則有的一方獲勝，如果雙方都沒有，則同時建立兩條連接。l idle 發(fā)起和接收都從這個狀態(tài)開始。如果認(rèn)證成功，連接則建立。(Termination of a Control Connection)任何一端發(fā)出一個StopCCN報文都可以終止一個控制連接。一個控制連接之間可以建立多個會話，每個會話負(fù)責(zé)相關(guān)的數(shù)據(jù)流。LCCE發(fā)送ICRQ后，就會等待對方的應(yīng)答。當(dāng)本地的LCCE接收到LCRP時，它將試圖建立呼叫。 LCCE A LCCE B OCRQ OCRP (執(zhí)行呼叫操作) OCCN (呼叫操作成功完成) 呼出呼叫會話連接建立過程LCCE 首先發(fā)送一個OCRQ呼出呼叫請求到LAC，LAC一旦確定存在適當(dāng)?shù)脑O(shè)備來產(chǎn)生一個呼叫，并且呼叫經(jīng)過了認(rèn)證，那么就發(fā)送一個OCRP作為響應(yīng)。 LCCE A LCCE B CDN (Clean up) (Clean up) 呼入呼叫狀態(tài)機以下分別對ICRQ發(fā)送者狀態(tài)機和ICRQ接收者狀態(tài)機作了詳細(xì)的介紹。l waitcontrolconnection 在這個狀態(tài)下，會話等待控制連接的打開或者等待控制連接已經(jīng)打開的確認(rèn)。LCCE發(fā)送一個CDN或接收到一個CDN，呼叫都可以被清除。當(dāng)接收到ICCN后，狀態(tài)變?yōu)閑stablished。 OCRQ發(fā)送者狀態(tài)機與OCRQ發(fā)送者相關(guān)的狀態(tài)如下所示。l waitconnect 如果接收到一個CDN，那么清除會話，狀態(tài)返回到idle。初始狀態(tài)事件動作新狀態(tài)idleLocal open requestInitiate local controlconnopenwaitcontrolconnReceive OCCN, OCRPClean upidleReceive CDNClean upidlewaitcontrol conncontrolconnopenSend OCRQwaitreplyLocal close requestClean upidlewaitreplyReceive OCRP, acceptablenone waitconnectReceive OCRP, not acceptableSend CDN, clean upidleReceive OCCN, OCRQSend CDN, clean upidleReceive CDNClean upidlewaitconnectReceive OCCNnoneestablishedReceive OCRQ, OCRPSend CDN, clean upidleReceive CDNClean upidleLocal close requestSend CDN, clean upidleestablishedReceive OCRQ, OCRP, OCCNSend CDN, clean upidleLocal close requestSend CDN, clean upidleReceive CDNClean upidleLocal close requestSend。l established 如果接收到一個CDN，那么清除會話，狀態(tài)返回到idle。l waitreply 如果接收到一個CDN，那么清除會話，狀態(tài)返回到idle。初始狀態(tài)事件動作新狀態(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)機 呼出呼叫狀態(tài)機以下分別對OCRQ發(fā)送者狀態(tài)機和OCRQ接收者狀態(tài)機作了詳細(xì)的介紹。l idle當(dāng)接收到一個ICRQ，如果不接受請求，則發(fā)送一個CDN，并保持idle狀態(tài)，如果接受，則發(fā)送一個ICRP,會話變?yōu)閣aitconnect 狀態(tài)。l waitreply ICRQ發(fā)送者接收到一個CDN表明對方不愿接受呼叫，那么進入idle狀態(tài)，如果接收到一個ICRP，那么就發(fā)送一個ICCN進入會話建立狀態(tài)。 ICRQ 發(fā)送者狀態(tài)機與ICRQ發(fā)送者相關(guān)的狀態(tài)如下所示。會話的拆除可以由LAC或者LNS發(fā)起，通過發(fā)送CDN控制報文來完成。呼出呼叫會話建立時，同樣由三個報文進行了交換來完成，包括OCRQ, OCRP與OCCN。對方如果沒有足夠的資源處理額外的會話，也可以選擇拒絕接受呼叫。呼入呼叫會話建立時，由三個報文進行了交換，下圖是一個呼入呼叫會話建立的典型示例。報文的接受端發(fā)送一個報文確認(rèn)后，釋放相關(guān)的控制信息。當(dāng)是由本地事件導(dǎo)致的中斷時，發(fā)起者必須發(fā)送一個StopCCN，并清除掉控制連接。l wait－ctl－reply 發(fā)起者檢查是否有另一個連接請求，如果有，則進行沖突處理。包括初始的狀態(tài)，事件，由事件而觸發(fā)的動作，動作執(zhí)行后協(xié)議的新的狀態(tài)。并發(fā)送StopCCN。協(xié)議定義了控制連接tiebreaker AVP（SCRRQ）來解決這個問題。（Control Connection States）L2TP協(xié)議在兩段的LCEE上并沒有明顯的區(qū)分，唯一的區(qū)別是誰是呼叫的發(fā)起者，誰是呼叫的接收者。由于Rx連接速度AVP是非強制性的，所以這種結(jié)果不應(yīng)該認(rèn)為是災(zāi)難性的。也就是說AVP必須忽略，并且報文必須被接受，除非是記錄一個本地的錯誤報文。 畸形控制報文舉例：（1）報文頭中有一個無效的值；（2）包含一個AVP的報文的格式不正確或者它的值越界；（3）報文中缺少所需的AVP。 收到一個無效的或者無法恢復(fù)的畸形的控制報文應(yīng)該能適當(dāng)?shù)乇挥涗?，并且控制連接清除應(yīng)確?；謴?fù)到一個知名的狀態(tài)。端用戶不允許在任何時刻都在等待Hello報文，在這里默認(rèn)為60秒沒有報文發(fā)送的情況下，當(dāng)然這個時間間隔是可以配置的。為了實現(xiàn)認(rèn)證，兩個LCCE必須擁有一個相同的共享密鑰，且經(jīng)過AVP隱藏處理。L2TP在控制連接建立時，可以采用單一的，可選擇的，類似于CHAP的認(rèn)證系統(tǒng)。在控制報文重傳時，可以采用慢啟動和擁塞避免的機制?？刂七B接采用一個滑動窗口機制。下圖是一個成為LOCKSTEP的控制連接建立過程示意。每個控制連接保存了一個等待被發(fā)送的控制報文的隊列。接收端的可靠發(fā)送機制負(fù)責(zé)控制報文的有序發(fā)送以及沒有副本傳送到協(xié)議上層。最后收到的報文接收號Nr被用于已接收到的報文的確認(rèn)，它包含下一個希望收到的報文的序列號。然而為了確保所有的報文能都被正確的確認(rèn)，尤其時在ZLB ACK報文丟失的情況下，報文的副本必須由可靠發(fā)送機制來確認(rèn)。每發(fā)送一個報文，Ns位加1，最大為65536。 LCCE A LCCE B StopCCN (Clean up) (Wait) (Clean up)有時需要關(guān)掉所有的控制連接以及與控制連接相關(guān)的所有會話，在這種情況下，當(dāng)拆掉整個控制連接時，就不需要單獨的拆除每一個控制連接。例如發(fā)送端在發(fā)送一個報文后，如果在隨后的相應(yīng)報文中沒有收到確認(rèn)報文，那么就要發(fā)送一個ZLB ACKs確認(rèn)包。 控制報文類型下表是定義的文本定義的控制報文類型。然后再按照上面介紹的處理過程的逆過程來獲得原始的值。把值域分成16字節(jié)的數(shù)據(jù)塊pp2等，最后的塊用隨機數(shù)填充到16字節(jié)。如果子格式大于16字節(jié)，下一個單向的MD5哈希值是通過共享密鑰組成的字節(jié)流以及其后所跟的第一次異或的結(jié)果計算得到的。如果不同的隨機向量應(yīng)用于并發(fā)AVP的隱藏時，那么在第一個AVP應(yīng)用前，必須在命令報文中設(shè)置一個新的隨機向量AVP。第二步，對如下的串進行MD5哈希算法。Padding并不改變Length of Original Attribute Value域，但是改變了合成的AVP的長度。當(dāng)增加了Padding后，有必要知道原始數(shù)據(jù)的長度。如果在一個給定的控制報文中的任何AVP的H位被設(shè)定，一個隨機向量AVP必須出現(xiàn)在報文中并且在第一個帶有H位為1的AVP之前。H位在以下兩種情況下必須采用：（1）兩個LCCE之間存在一個共享密鑰；（2）LCCE認(rèn)證已經(jīng)完成。在接收端，當(dāng)收到的控制報文中的AVP不可識別或是畸形時，應(yīng)當(dāng)只檢查這個AVP的M位，反之則不用檢查。在定義這種AVP時應(yīng)該要考慮到這個問題。屬性值（Attribute Type）用以表明具體的AVP屬性。本文中采用的是0。長度字段（Length）表示這個AVP中的字節(jié)長度，一般為屬性值加6。如果一個與特殊會話或者控制連接相關(guān)的控制報文AVP無法識別或者是畸形，且M位被設(shè)定，則這個會話或連接以及綁定到這個連接上的所有會話必須被終止。01234567890123456789012345678901MHrsvdLengthVendor IDAttribute TypeAttribute Value ...(until Length is reached) AVP格式前六位描述了AVP的一般屬性，其中前兩位被定義，而后四位作為保留位以為將來擴展用。01234567890123456789012345678901Session IDCookie (optional, maximum 64 bits)... L2TPv3 Over IP 會話頭同樣控制頭也有所不同，當(dāng)發(fā)送控制報文時，它使報文頭前四個字節(jié)設(shè)為全0，這樣處理將使得區(qū)分?jǐn)?shù)據(jù)報文和控制報文以及報文的校驗更加有效。01234567890123456789012345678901TXXXXXXXXXXXVerLengthSession IDCookie (optional, maximum 64 bits)... L2TPv3 over UDP會話頭T為必須設(shè)置為0，表明為數(shù)據(jù)報文。L2特殊子層位于L2TP會話頭和入隧起始幀之間，其中控制域用來使每個幀可以方便的入隧。Cookie：這個域是可選的，長度可變，最大為8個字節(jié)，其值用于檢驗所接收的報文與會話的關(guān)系。所有的會話頭中都包括Session ID與Cookie兩個域，以下分別做說明。L2TP Session HeaderL2Specific SublayerTunneled Frame 數(shù)據(jù)報文的頭格式L2TP會話頭專應(yīng)用穿過PSN的數(shù)據(jù)流。