1.4 廣域網
大部分的廣域網技術因為帶寬、通用性等應用上的局限,已經漸漸退出了現網應用,但在現網的部分場景中,仍然能見到少量的應用,如銀行中的幀中繼網絡。另外,部分技術,如 PPP,在現網中的應用還是比較廣泛,例如,用于寬帶撥號的PPPoE就用到了PPP技術。本節將介紹以下內容。
(1)廣域網的常見協議。
(2)HDLC協議的工作原理。
(3)PPP的工作原理。
(4)FR的工作原理。
1.4.1 廣域網技術
廣域網是一種跨地區的數據通信網絡,使用電信運營商提供的設備作為信息傳輸平臺。對照OSI參考模型,廣域網技術主要位于下面的3個層次,分別是物理層、數據鏈路層和網絡層。根據使用的通信協議不同,早期的廣域網又可以分為X.25網、ATM網、ISDN網、幀中繼網等。這里將針對HDLC、PPP、FR等廣域網的技術進行介紹。
1.4.2 HDLC工作原理
HDLC是由國際標準化組織(ISO)制定的面向比特的同步數據鏈路層協議,主要用于封裝同步串行鏈路上的數據。HDLC是在數據鏈路層中被廣泛使用的協議之一。
20世紀70年代初,IBM公司率先提出了面向比特的同步數據鏈路控制規程(Synchronous Data Link Control,SDLC)。隨后,ANSI和ISO均采納并發展了SDLC,并分別提出了自己的標準,即ANSI的高級通信控制過程(Advanced Data Communication Control Procedure,ADCCP)以及ISO的高級數據鏈路控制規程(High-level Data Link Control,HDLC)。
HDLC作為面向比特的同步數據控制協議的典型,具有以下這些特點。
(1)協議不依賴于任何一種字符編碼集。
(2)數據報文可透明傳輸,用于透明傳輸的“0比特插入法”易于硬件實現。
(3)全雙工通信,不必等待確認即可連續發送數據,有較高的數據鏈路傳輸效率。
(4)所有幀均采用CRC校驗,對信息幀進行順序編號,可防止漏收或重收,傳輸可靠性高。
(5)傳輸控制功能與處理功能分離,具有較大的靈活性和較完善的控制功能。
運行HDLC協議的數據鏈路兩端的終端,從邏輯功能的角度常被稱為站,可以分為主站、從站和復合站3種。
主站的主要功能是發送命令(包括數據信息)幀,接收響應幀,并負責對整個鏈路控制系統的初啟、流程的控制、差錯檢測或恢復等。
從站的主要功能是接收由主站發來的命令幀,向主站發送響應幀,并且配合主站參與差錯恢復等鏈路控制。
復合站的主要功能是既發送又接收命令幀和響應幀,并且負責整個鏈路的控制。
根據通信雙方的鏈路結構和傳輸響應類型,HDLC中又定義了3種基本的操作方式:正常響應方式、異步響應方式和異步平衡方式。
● 正常響應方式(Normal Responses Mode,NRM):由主站控制整個鏈路的操作,負責鏈路的初始化、數據流控制和鏈路復位等。從站的功能很簡單,它只有在得到主站的明確允許后,才能發出響應。
● 異步響應方式(Asynchronous Responses Mode,ARM):從站可以不必得到主站的允許就可以數據傳輸。傳輸效率比NRM有所提高。
● 異步平衡方式(Asynchronous Balanced Mode,ABM):鏈路兩端的復合站具有同等的能力,不管哪個復合站,均可在任意時間發送命令幀,并且不需要收到對方復合站發出的命令幀就可以發送響應幀。
HDLC具體的幀格式如圖1-37所示。

圖1-37 HDLC的幀格式
HDLC 的完整幀由標志字段(F)、地址字段(A)、控制字段(C)、信息字段(I)、幀校驗序列字段(FCS)等組成。
標志字段(F):固定為值01111110,用于標志幀的開始與結束,也可以作為幀與幀之間的填充字符。
地址字段(A):攜帶的是地址信息,在使用不平衡方式傳送數據時(采用NRM和ARM),地址字段總是寫入從站的地址;在使用平衡方式時(采用ABM),地址字段總是寫入應答站的地址。
控制字段(C):用于構成各種命令及響應,以便對鏈路進行監視與控制。發送方主節點或組合節點利用控制字段來通知被尋址的從節點或組合節點執行約定的操作。相反,從節點將該字段作為對命令的響應,報告已經完成的操作或狀態的變化。
信息字段(I):可以是任意的二進制比特串,長度未做限定,其上限由FCS字段或通信節點的緩沖容量來決定,目前國際上用得較多的是1 000~2 000 位,而下限可以是0,即無信息字段。但是監控幀中不能有信息字段。
幀校驗序列字段(FCS):可以使用16位CRC對兩個標志字段之間的整個幀的內容進行校驗。
HDLC 協議傳送的信息單位為幀。其最大的特點是不需要數據必須是規定的字符集,對任何一種比特流,均可以實現透明傳輸。幀的起始和結束由起始標志符和終止標志符進行標識,字符串值為01111110。標志碼不允許在幀的內部出現,以免引起歧義。為避免引起歧義,可以采用“0比特插入法”來解決。在發送端,一旦檢測到標志碼以外的字段有連續的5個“1”,便在其后添加一個“0”,然后繼續發送后繼的比特流。在接收端,除標志碼以外的所有字段,當連續發現5個“1”出現后,若其后的一個位為“0”,則自動刪除它,以恢復原來的比特流。若發現連續6個“1”,則可能是插入的“0”發生錯誤,也可能是收到了終止標志碼。
根據幀的不同作用,HDLC的幀可以分為信息幀(I幀)、監控幀(S幀)和無編號幀(U幀)3種不同的類型。幀的類型由控制字段決定。
信息幀用于傳送有效信息或數據,通常簡稱為I幀,以控制字段的第一位是二進制數0為標志。
監控幀用于差錯控制和流量控制,通常稱為S幀。S幀的標志是控制字段的前兩個比特位為“10”。S幀不帶信息字段,只有6個字節,即48位。
無編號幀用于提供對鏈路的建立、拆除以及多種控制功能,簡稱U幀。
HDLC 主要用于串行鏈路上的數據封裝。其基礎配置比較簡單,只需要在接口模式下封裝 HDLC,然后配置IP地址即可。典型的應用場景如圖1-38所示。

圖1-38 HDLC的典型應用
HDLC原理與配置
HDLC在配置時,通信雙方的接口必須配置相同的封裝方式。圖1-38的應用示例以華為設備的配置為例,其余廠商設備的配置會在命令上稍有區別。
1.4.3 PPP工作原理
HDLC和PPP是兩種典型的廣域網協議。在前面的內容中,已經對HDLC協議的封裝方式和基本配置進行了一定的介紹。本小節介紹另一種典型的廣域網協議,即PPP。
1.PPP的基本概念
PPP 提供了一種在點到點鏈路上傳輸多協議數據包的標準方法,是目前廣泛應用的數據鏈路層點到點通信協議。
PPP在TCP/IP協議棧中位于數據鏈路層,通常用于在串行鏈路、ATM鏈路和SDH鏈路上封裝和發送IP數據包。PPP在協議棧中的位置如圖1-39所示。

圖1-39 PPP在TCP/IP協議棧中的位置
PPP共定義了3個協議組件,分別是數據封裝方式、鏈路控制協議(Link Control Protocol,LCP)和網絡層控制協議(Network Control Protocol,NCP)。
數據封裝方式定義了如何封裝多種類型的上層協議數據包。
LCP的定義主要是為了能適應多種多樣的鏈路類型。LCP可以自動檢測鏈路環境(如是否存在環路)、協商鏈路參數(如最大數據包長度)、使用何種認證協議等。與其他數據鏈路層協議相比,PPP 的一個重要特點是可以提供認證功能,鏈路兩端可以協商使用何種認證協議并實施認證過程,只有認證成功才會建立連接。這個特點使PPP適合運營商來接入分散的用戶。
NCP包含了一組協議,主要用于協商網絡層的地址等參數,每一種協議對應一種網絡層協議,例如, IPCP用于協商控制IP,IPXCP用于協商控制IPX協議等。
PPP 的運行需要經歷多個階段的協商,而各個階段的協商需要不同的組件參與。具體的協商流程如圖1-40所示。

圖 1-40 PPP的具體協商流程
最開始建立PPP鏈路時,會從初始狀態進入到建立階段。在鏈路建立階段,PPP進行LCP的協商。協商內容包括最大接收單元MRU、驗證方式、魔術字(Magic Number)等選項。
LCP協商成功后進入Opened狀態,表示底層鏈路已經建立。此時,PPP會檢查雙方是否配置了認證,采用何種方式進行認證。如果配置了驗證,將進入認證階段,開始CHAP或PAP驗證。如果沒有配置驗證,則直接進入NCP協商階段。
對于認證階段,如果驗證失敗,則鏈路被終止拆除,LCP 狀態轉為 Down。如果驗證成功,則進入網絡協商階段,此時LCP狀態仍為Opened,而網絡協商狀態卻從Initial轉到Request。
網絡協商支持IPCP、MPLSCP、OSCICP等協商。IPCP協商主要包括雙方的IP地址。通過NCP協商來選擇和配置一個網絡層協議。只有相應的網絡層協議協商成功后,該網絡層協議才可以通過這條PPP鏈路發送報文。
PPP鏈路將一直保持通信,直至有明確的LCP或NCP幀關閉這條鏈路,或發生了某些外部事件,例如用戶干預。
在PPP協商的過程中,數據幀都是封裝在PPP報文中進行傳遞的。封裝方式相對比較簡單,主要包含了3個字段,PPP數據幀格式如圖1-41所示。

圖1-41 PPP數據幀格式
下面將介紹PPP的數據封裝中3個字段的功能。
● Protocol,協議域,長度為兩個字節,標識此PPP數據幀中封裝的協議類型,如IP數據包、LCP、NCP等。常用取值如圖1-41所示。
● Information,信息域,被PPP封裝的數據,例如LCP數據、NCP數據、網絡層數據包等。此字段的長度是可變的。
● Padding,填充域。用于填充信息域。
Padding字段和Information字段的最大總長度稱為PPP的最大接收單元(Maximum Receive Unit, MRU)。MRU默認為1 500字節。當Information字段的長度小于MRU時,可以使用Padding字段填充以方便發送和接收,也可以不進行填充,即Padding字段是可選的。
PPP數據幀無法直接在鏈路上傳輸,在不同的鏈路上傳輸PPP數據幀需要不同的額外封裝和控制機制,如在串行鏈路上傳送PPP數據幀需遵循HDLC標準。
結合之前學習的HDLC的知識,串行鏈路上的數據幀結構如圖1-42所示。

圖1-42 串行鏈路上的PPP數據幀結構
串行鏈路上的PPP基礎配置也比較簡單,只需要在接口模式下封裝PPP,然后配置IP地址即可,如圖1-43所示。

圖1-43 串行鏈路上PPP的基礎配置
PPP原理與配置——協議概述
2.鏈路控制協議(LCP)
通過前面內容的介紹,讀者已經對PPP有了一個總體的了解,包括PPP的概念、在串行鏈路上發送的PPP數據幀格式、PPP的組件以及PPP的工作過程。下面將結合前面PPP的介紹,對PPP的組件進行介紹,首先來看下PPP的鏈路控制協議LCP的工作原理。
如前面所述,LCP主要用來建立、拆除和監控PPP數據鏈路,同時進行鏈路層參數的協商,如MRU、驗證方式等。在協商過程中,PPP雙方會交互幾種常見的鏈路協商報文。下面是對幾種常見LCP協商場景的描述。
場景一:LCP協商成功。
如圖1-44所示,RTA和RTB使用串行鏈路相連,運行PPP。當物理層鏈路變為可用狀態之后,RTA和RTB使用LCP協商鏈路參數。本例中,RTA首先發送一個LCP報文。
RTA 向 RTB 發送 Configure-Request 報文,此報文包含了發送者(RTA)上配置的鏈路層參數。當RTB收到此Configure-Request報文之后,如果RTB能識別此報文中的所有鏈路層參數,并且認為每個參數的取值都是可以接受的,則向RTA回應一個Configure-Ack報文。
在沒有收到Configure-Ack報文的情況下,每隔3 s重傳一次Configure-Request報文,如果連續10次發送 Configure-Request 報文仍然沒有收到 Configure-Ack 報文,則認為對端不可用,停止發送Configure-Request報文。
需要注意的是,該過程只是表明了RTB認為RTA上的鏈路參數配置是可接受的。RTB也需要向RTA發送Configure-Request報文,使RTA檢測RTB上的鏈路參數配置是不是可接受的。

圖1-44 LCP協商成功
場景二:LCP參數協商不成功。
如圖1-45所示,當RTB收到RTA發送的Configure-Request報文之后,如果RTB能識別此報文中攜帶的所有鏈路層參數,但是認為部分或全部參數的取值不能接受,即參數的取值協商不成功,則RTB需要向RTA回應一個Configure-Nak報文。

圖1-45 LCP參數協商不成功
在這個Configure-Nak報文中,只包含不能接受的那部分鏈路層參數列表,每一個包含在此報文中鏈路層參數的取值均被修改為此報文的發送者(RTB)可以接受的取值(或取值范圍)。
在收到Configure-Nak報文之后,RTA需要根據此報文中的鏈路層參數重新選擇本地使用的相關參數,并重新發送一個Configure-Request。
連續5次協商仍然不成功的參數將被禁用,不再繼續協商。
場景三:LCP參數無法識別。
如圖1-46所示,當RTB收到RTA發送的Configure-Request報文之后,如果RTB不能識別此報文中攜帶的部分或全部鏈路層參數,則RTB需要向RTA回應一個Configure-Reject報文。
在此Configure-Reject報文中,只包含不被識別的那部分鏈路層參數列表。
在收到Configure-Reject報文之后,RTA需要向RTB重新發送一個Configure-Request報文,在新的Configure-Request報文中,不再包含不被對端(RTB)識別的參數。

圖1-46 LCP參數無法識別
場景四:LCP鏈路檢測。
如圖1-47所示,LCP建立連接之后,可以使用Echo-Request報文和Echo-RepIy報文檢測鏈路狀態,收到Echo-Request報文之后應當回應一個Echo-RepIy報文,表示鏈路狀態正常。

圖1-47 LCP鏈路檢測
場景五:LCP連接關閉。
如圖1-48所示,由于認證不成功或者管理員手工關閉等原因可以使LCP關閉已經建立的連接。
LCP關閉連接使用Terminate-Request報文和Terminate-Ack報文,Terminate-Request報文用于請求對端關閉連接,一旦收到一個Terminate-Request報文,LCP必須回應一個Terminate-Ack報文來確認連接關閉。
在沒有收到Terminate-Ack報文的情況下,每隔3 s重傳一次Terminate-Request報文,連續兩次重傳都沒有收到Terminate-Ack報文,則認為對端不可用,連接關閉。

圖1-48 LCP連接關閉
通過對上述5個場景的描述,可以總結LCP鏈路層協商常用的報文類型,如表1-9所示。
表1-9 LCP鏈路層協商常用報文

LCP鏈路的協商通過表1-9中的報文實現,LCP協商的常用鏈路參數如表1-10所示。
表1-10 LCP協商的常用鏈路參數

PPP原理與配置——鏈路控制協議(LCP)
在華為設備上,MRU參數使用接口上配置的最大傳輸單元(MTU)值來表示。
常用的PPP認證協議有PAP和CHAP(后續章節介紹),一條PPP鏈路的兩端可以使用不同的認證協議認證對端,但是被認證方必須支持認證方使用的認證協議,并正確配置用戶名和密碼等認證信息。
LCP使用魔術字(Magic-Number)檢測鏈路環路和其他異常情況。魔術字為隨機產生的一個數字,隨機機制需要保證兩端產生相同魔術字的可能性幾乎為0。
收到一個Configure-Request報文之后,其包含的魔術字需要和本地產生的魔術字做比較,如果不同,表示鏈路無環路,則使用Confugure-Ack報文確認(其他參數也協商成功),表示魔術字協商成功。在后續發送的報文中,如果報文含有魔術字字段,則該字段設置為協商成功的魔術字,LCP 不再產生新的魔術字。
如果收到的Configure-Request報文和自身產生的魔術字相同,則發送一個Configure-Nak報文,攜帶一個新的魔術字。然后,不管新收到的Configure-Nak報文中是否攜帶相同的魔術字,LCP都發送一個新的Configure-Request報文,攜帶一個新的魔術字。如果鏈路有環路,則這個過程會不停地持續下去;如果鏈路沒有環路,則報文交互會很快恢復正常。
3.PPP的認證協議
PPP工作過程中的認證,常用的方式有PAP和CHAP兩種。
(1)PAP認證。
PAP全稱為Password Authentication Protocol,密碼認證協議。要實現PAP的認證,需要配置的信息有兩部分。
● 在認證方開啟PAP認證功能,創建一個PPP用戶。
● 在被認證方配置PAP使用的用戶名和密碼信息。
PAP的認證示例如圖1-49所示,認證方配置了認證方式是PAP,創建了用戶名huawei和密碼hello,同時指定了用戶huawei的業務類型為PPP業務。被認證方指明了PAP認證的用戶名huawei和hello,保持和認證方的一致,才能保證認證通過。

圖1-49 PAP認證示例
PAP認證方式的工作原理較為簡單。LCP協商完成后,認證方要求被認證方使用PAP進行認證,具體過程如圖1-50所示。

圖1-50 PAP認證過程
被認證方將配置的用戶名和密碼信息使用Authenticate-Request報文以明文方式發送給認證方,本例中,用戶名為“huawei”,密碼為“hello”。
認證方收到被認證方發送的用戶名和密碼信息之后,根據本地配置的用戶名和密碼數據庫檢查用戶名和密碼信息是否正確匹配,如果正確,則返回 Authenticate-Ack 報文,表示認證成功。否則,返回Authenticate-Nak報文,表示認證失敗。
PAP 驗證協議包含兩次握手驗證,驗證過程僅在鏈路初始建立階段進行。當鏈路建立階段結束后,用戶名和密碼將由被驗證方重復地在鏈路上發送給驗證方,直到驗證被通過或者鏈路連接終止。PAP 不是一種安全的驗證協議。當驗證時,口令以明文方式在鏈路上發送,并且由于完成PPP鏈路建立后,被驗證方會不停地在鏈路上反復發送用戶名和口令,直到身份驗證過程結束,所以不能防止攻擊。
(2)CHAP認證。
CHAP全稱為Challenge Handshake Authentication Protocol,是一種使用加密方式發送密碼信息的認證方式,與PAP相比,可以提供更高的安全性。
CHAP 的認證示例如圖1-51所示,基本配置和 PAP 的認證方式差別不大,只是認證模式被指明為CHAP模式。

圖1-51 CHAP認證示例
CHAP的認證過程需要3次報文的交互。信息在鏈路上傳遞時,需要經過加密,因此安全性得到了極大的提升,具體過程如圖1-52所示。

圖1-52 CHAP認證過程
在LCP協商完成后,認證方發送一個Challenge報文給被認證方,報文中含有Identifier信息和一個隨機產生的Challenge字符串。此Identifier會被后續報文所使用,一次認證過程所使用的報文均使用相同的Identifier信息,用于匹配請求報文和回應報文。
被認證方收到此 Challenge 報文之后進行一次加密運算,運算公式為 MD5{Identifier+密碼+Challenge},意思是將Identifier、密碼和Challenge這3部分連成一個字符串整體,然后對此字符串做MD5運算,得到一個16字節長的摘要信息,最后將此摘要信息和端口上配置的 CHAP 用戶名一起封裝在Response報文中并發回認證方,本例中將加密運算得到的摘要信息和用戶名 “huawei”一起發回認證方。
認證方接收到被認證方發送的Response報文之后,按照其中的用戶名在本地查找相應的密碼信息。得到密碼信息之后進行一次加密運算,運算方式和被認證方的加密運算方式相同,然后將加密運算得到的摘要信息和Response報文中封裝的摘要信息做比較,相同則表示認證成功,不相同則表示認證失敗。
從CHAP認證的整個過程可以看出,驗證的密碼從未在鏈路上進行明文傳遞,傳遞的只是經過MD5計算的摘要信息,因此,相對于PAP來說,安全性得到了很大的提升。
PPP原理與配置——認證協議
4.網絡層控制協議(NCP)
目前應用最廣泛的NCP為IPCP與MPLSCP,分別用于IP和MPLS的協商與控制。
IPCP用于協商控制IP參數,使PPP可用于傳輸IP數據包。MPLSCP用于協商控制MPLSCP協議參數,使PPP可用于傳輸MPLSCP數據包。下面以IPCP的IP地址協商為例,說明一下NCP的作用。
圖1-53所示為靜態協商IP地址,RTA和RTB之間通過串行鏈路連接,封裝PPP。兩端的端口IP地址通過靜態方式部署。在雙方進行PPP的NCP協商時,需要經過以下過程。
(1)每一端都要發送Configure-Request報文,在此報文中包含本地配置的IP地址。
(2)另一端接收到此Configure-Request報文之后,檢查其中的IP地址,如果IP地址是一個合法的單播 IP 地址,而且和本地配置的 IP 地址不同(沒有 IP 沖突),則認為對端可以使用該地址,回應一個Configure-Ack報文。

圖1-53 靜態協商IP地址
除了靜態協商IP地址外,也可以通過IPCP實現IP地址的動態協商。如圖1-54所示,RTB上配置了本地端口的IP地址,同時配置一個遠端的IP地址,RTA則通過協商的方式動態獲取IP地址。具體有以下4步。
(1)RTA 向RTB 發送一個 Configure-Request 報文,此報文中的 IP 地址填充為0.0.0.0,一個含有0.0.0.0的IP地址的Configure-Request報文表示向對端請求IP地址。
(2)RTB 收到上述 Configure-Request 報文后,認為其中包含的地址(0.0.0.0)不合法,使用Configure-Nak回應一個新的IP地址10.1.1.1。
(3)RTA收到此Configure-Nak報文之后,更新本地IP地址,并重新發送一個Configure-Request報文,包含新的IP地址10.1.1.1。
(4)RTB 收到 Configure-Request 報文后,認為其中包含的 IP 地址為合法地址,回應一個Configure-Ack報文。同時,RTB也要向RTA發送Configure-Request報文來請求使用地址10.1.1.2,RTA認為此地址合法,回應Configure-Ack報文。

圖1-54 動態協商IP地址
PPP原理與配置——網絡層控制協議(NCP)
1.4.4 FR工作原理
幀中繼(Frame Relay,FR)技術是在數據鏈路層用簡化的方法傳送和交換數據單元的快速分組交換技術。由于在鏈路層的數據單元一般稱作幀,故稱為幀方式。
幀中繼采用虛電路技術,即幀中繼傳送數據使用的傳輸鏈路是邏輯連接,而不是物理連接。在一個物理連接上可以復用多個邏輯連接,實現了帶寬的復用和動態分配,有利于多用戶、多速率數據的傳輸,充分利用了網絡資源,如圖1-55中的虛線所示。采用虛電路技術,能充分利用網絡資源,因此幀中繼具有吞吐量高、時延低、適合突發性業務等特點。

圖1-55 幀中繼的虛電路技術
幀中繼工作在OSI的物理層和數據鏈路層,使用簡化的方法傳送和交換數據單元,僅完成OSI物理層和數據鏈路層核心層的功能,將流量控制、糾錯等留給智能終端完成,依賴TCP等上層協議完成糾錯控制等,大大簡化了節點機之間的協議。幀中繼可用于傳輸各種路由協議,路由協議數據包被封裝在幀中繼數據幀內,如圖1-56所示。

圖1-56 幀中繼的封裝結構
FR原理與配置——幀中繼網絡概述
在網絡發展初期,由于幀中繼能夠充分利用網絡資源,具備吞吐量高、時延低、適合突發性業務等特點,因此,對于當時的網絡組網而言,是一個重要的可選項。幀中繼技術的特點可歸納為以下幾點。
(1)幀中繼技術主要用于傳遞數據業務,數據信息以幀的形式進行傳送,是一種面向連接的快速分組交換技術。
(2)幀中繼傳送數據使用的傳輸鏈路是邏輯連接,而不是物理連接,在一個物理連接上可以復用多個邏輯連接,可以實現帶寬的復用和動態分配。
(3)幀中繼采用物理層和鏈路層的兩級結構,在鏈路層也只保留了核心子集部分,簡化了X.25的第三層功能,使網絡節點的處理大大簡化。在鏈路層可完成統計復用、幀透明傳輸和錯誤檢測,但不提供重傳操作,提高了網絡對信息的處理效率。省去了幀編號、流量控制、應答和監視等機制,大大節省了交換機的開銷,提高了網絡吞吐量、降低了通信時延。一般幀中繼用戶的接入速率在64 kbit/s~2 Mbit/s。
(4)提供了一套合理的帶寬管理和防止擁塞的機制,用戶有效地利用預約的帶寬,即承諾的信息速率(Committed Information Rate,CIR),還允許用戶的突發數據占用未預定的帶寬,以提高網絡資源的利用率。
(5)與分組交換一樣,幀中繼采用面向連接的交換技術。可以提供交換虛電路(Switched Virtual Circuit, SVC)和永久虛電路(Permanent Virtual Circuit,PVC)業務,但目前已應用幀中繼的網絡中,只采用PVC業務。
幀中繼網絡模型如圖1-57所示,由用戶側數據終端設備(Data Terminal Equipment ,DTE)和FR幀中繼交換網組成。FR 幀中繼交換網由一組數據電路終接設備(Data Circuit-terminating Equipment, DCE)組成。兩端的局域網通過FR網絡實現互聯。局域網之間數據的轉發通過PVC來實現。以下為幀中繼網絡中的一些相關術語介紹。
● 數據終端設備。通常指的是用戶側的設備等。
● 數據電路終接設備。通常是指網絡中的交換設備,如幀中繼交換機。
● 數據鏈路連接標識(Data Link Connection Identifier,DLCI)。鏈路接口的標識,幀中繼網絡的每一個連接都使用DLCI。
DTE與DCE直接連接,分組交換機之間建立若干連接,這樣,便形成了DTE與DTE之間的通路。用戶設備和網絡設備之間的接口為用戶到網絡接口(User-to-Network Interface,UNI),幀中繼交換機之間的接口為網絡到網絡接口(Network-to-Network Interface,NNI),如圖1-57所示。
幀中繼是面向連接的技術,在通信之前必須建立鏈路,DTE 之間建立的連接稱為虛電路,如圖1-57中的虛線所示。
幀中繼虛電路有兩種類型:PVC和SVC。目前在幀中繼中使用最多的方式是永久虛電路方式。

圖1-57 幀中繼網絡
PVC 是指給用戶提供的固定虛電路,該電路一旦建立,則鏈路永遠生效,除非管理員手動刪除。PVC用于兩端之間頻繁的、流量穩定的數據傳輸。
SVC 是指通過協議自動分配的虛電路。在通信結束后,該虛電路可以被本地設備或交換機取消。一般臨時性的數據傳輸多用SVC。
幀中繼技術為了能夠更加有效地利用網絡資源,采用了虛電路技術,能夠在單一物理傳輸線路上提供多條虛電路,也就是說,幀中繼是一種統計復用協議。那么如何來標識和區分這些虛鏈路呢?幀中繼中定義了數據鏈路連接標識(Data Link Connection Identifier,DLCI)。通過幀中繼幀中的地址字段,可以區分出該幀屬于哪一條虛電路。
DLCI只在本地接口和與之直接相連的對端接口有效(即用于標識連接本地和對端接口的鏈路),不具有全局有效性。在幀中繼網絡中,不同物理接口上相同的DLCI并不表示同一個虛連接。
幀中繼網絡用戶接口上最多可支持1 024條虛電路,其中用戶可用的DLCI的范圍是16~1 007。由于幀中繼虛電路是面向連接的,本地不同的DLCI連接著不同的對端設備,所以可認為本地DLCI就是對端設備的“幀中繼地址”。
幀中繼網絡作為一種公共設施,一般是由電信運營商提供的,也可以通過自己私有的交換機組成幀中繼網。對于任何一種方式,幀中繼網絡服務者都為用戶路由器使用的PVC分配了DLCI號。其中一些DLCI代表特殊的功能,如DLCI0和DLCI 1023為LMI協議專用。
幀中繼地址映射是把對端設備的協議地址與本地到達對端設備的DLCI關聯起來,以便高層協議能夠通過對端設備的協議地址尋址到對端設備。幀中繼主要用來承載IP協議,在發送IP報文時,由于路由表只知道報文的下一跳地址,所以發送前必須由該地址確定它對應的DLCI。這個過程可以通過查找幀中繼地址映射表來完成。地址映射可以手動靜態配置,也可以由協議動態維護,如圖1-58所示。

圖1-58 幀中繼地址映射
逆向地址解析協議(Inverse ARP)的主要功能是尋找每條虛電路連接的對端設備的協議地址,包括IP地址和 IPX 地址等。如果知道了某條虛電路連接的對端設備的協議地址,在本地就可以生成對端協議地址與DLCI的映射(MAP),從而避免手工配置地址映射。它的基本過程如圖1-59所示。
當RTA發現一條新的虛電路時(前提是RTA上已配置了協議地址),RTA就在該虛電路上發送Inverse ARP請求報文給RTB,該請求報文包含有RTA的協議地址。RTB收到該請求時,可以獲得RTA的協議地址,從而生成地址映射,并發送Inverse ARP響應報文進行響應,這樣RTA同樣生成地址映射。

圖1-59 Inverse ARP工作過程
對于逆向地址解析,需要留意以下幾種特殊情況。
(1)如果已經手工配置了靜態MAP或已經建立了動態MAP,則無論該靜態MAP中的對端地址正確與否,都不會在該虛電路上發送 Inverse ARP 請求報文給對端,只有在沒有 MAP 的情況下才會向對端發送Inverse ARP請求報文。
(2)如果在Inverse ARP請求報文的接收端發現對端的協議地址與本地配置的MAP中的協議地址相同,則不會生成該動態MAP。
(3)多協議地址主機回復與請求方協議地址相對應的協議地址。如果沒有則不回復。
(4)多協議地址主機會為接口的每個協議地址請求對應的協議地址。
Inverse ARP 用于尋找每條虛電路連接的對端設備的協議地址,本地管理接口(Local Management Interface,LMI)協議則通過狀態請求報文和狀態報文維護幀中繼的鏈路狀態和 PVC 狀態。涉及的功能包括增加PVC記錄、刪除已斷掉的PVC記錄、監控PVC狀態的變更、鏈路完整性驗證。
系統支持的本地管理接口協議有3種:ITU-T的Q.933 Annex A、ANSI的T1.617 Annex D和非標準兼容協議。其中,非標準兼容協議用于和其他廠商設備對接,時如表1-11所示。
表1-11 本地管理接口協議

LMI的基本工作方式:DTE設備每隔一定的時間間隔發送一個狀態請求報文(Status Enquiry報文)去查詢虛電路的狀態,DCE設備收到狀態請求報文后,立即用狀態報文(Status報文)通知DTE當前接口上所有虛電路的狀態。
對于DTE側設備,永久虛電路的狀態完全由DCE側設備決定。對于DCE側設備,永久虛電路的狀態由網絡來決定。在兩臺網絡設備直接連接的情況下,DCE側設備的虛電路狀態是由設備管理員來設置的。
惜助于DLCI、InARP、LMI等機制,幀中繼能夠實現數據的轉發,但在點到多點的網絡中部署某些應用的時候,會導致另外一些問題的出現。圖1-60所示為在網絡中部署路由協議進行路由信息的通告(路由的詳細介紹見第3章),Router A的S0口連接著3臺路由器Router B、Router C、Router D。在Router A的串口S0上分別映射3個DLCI到3臺路由器,此時,Router B的路由信息需要先傳遞給Router A,然后由Router A再傳遞給Router C。在采用距離矢量算法的路由協議中,如果路由器把從一個接口接收進來的更新信息再從這個端口轉發出去,有可能會在兩臺路由器之間形成路由環路。因此,在距離矢量算法中,不允許Router A將串口S0上的路由更新信息再從該串口轉發出去,該原則稱為水平分割。

圖1-60 水平分割與幀中繼
解決這個問題有幾個辦法:一個方法是使用多個物理接口連接多個鄰節點,這樣就需要路由器具備多個物理接口,從而增加了用戶的成本;另外一個辦法是使用子接口,如圖1-61所示,在一個物理接口上配置多個邏輯接口,每個子接口都有自己的網絡地址,就像獨立的物理接口一樣。或者是關閉水平分割功能,但這樣會增加產生路由環路的概率,同時也需要路由協議支持。

圖1-61 幀中繼子接口
配置幀中繼子接口可以解決水平分割的問題,一個物理接口可以包含多個邏輯子接口。每一個子接口使用一個或多個DLCI連接到對端的路由器。路由器之間需要經過幀中繼的網絡相連接。
在串口線路上定義這些邏輯子接口,每一個子接口使用一個或多個DLCI連接到對端的路由器。在子接口上配置了DLCI后,還需要建立目的端協議和該DLCI的映射。
圖1-61中,雖然Router A上僅有一個物理串口S0,但是在物理串口S0上定義了S0.1子接口上的DLCI到Router B,S0.2子接口上的DLCI到RouterC,S0.3子接口上的DLCI到RouterD。
幀中繼的子接口分為兩種類型。
點到點(Point-to-Point)子接口:用于連接單個遠端目標。一個子接口只配一條PVC,不用配置靜態地址映射就可唯一地確定對端設備。所以,在給子接口配置PVC時已經隱含地確定了對端地址。
點到多點(Point-to-Multipoint)子接口:用于連接多個遠端目標。一個子接口上配置多條 PVC,每條 PVC 都和它相連的遠端協議地址建立地址映射,這樣,不同的 PVC 就可以到達不同的遠端,而不會混淆。必須要通過手工配置地址映射,或者通過逆向地址解析協議來動態建立地址映射。
在創建幀中繼子接口前,應先配置主接口使用幀中繼作為鏈路層協議。幀中繼子接口的類型默認是點到多點。
幀中繼的配置實現并不復雜,如圖1-62所示,RTA和RTB通過幀中繼互聯,IP地址和DLCI通過靜態配置的方式進行映射,從而實現兩端IP地址的互通。
FR原理與配置——基本概念
FR原理與配置——基本配置

圖1-62 幀中繼的靜態解析配置實現
- Proxmox High Availability
- WordPress 5 Complete
- SSL VPN : Understanding, evaluating and planning secure, web/based remote access
- Metasploit Penetration Testing Cookbook
- C/C++串口通信:典型應用實例編程實踐
- 物聯網工程導論(第3版)
- 5G非正交多址接入技術:理論、算法與實現
- SEO攻略:搜索引擎優化策略與實戰案例詳解
- 走近奇妙的物聯網
- 物聯網技術與實踐
- 網絡信息安全工程技術與應用分析
- 物聯網導論
- 物聯網概論
- ElasticSearch Server
- Twilio Cookbook(Second Edition)