本文將提及Cisco設備的訊框中繼網路相關知識，也會介紹Local Management Interface（LMI）。LMI負責路由器以及使用訊框中繼網路協定的交換機之間的狀態資訊收集和管理。
訊框中繼（Frame Relay），有人也稱之為「幀中繼」，此一網路協定是一個效能相當高的廣域網路協定，運作於OSI網路模型中的實體層（第一層）和資料連結層（第二層）。訊框中繼網路協定是由International Telecommunication Union Telecommunication Standardization（ITU-T）組織所訂立的網路協定，但是在美國，訊框中繼網路協定則是American National Standards Institute（ANSI）標準。
廣域網路簡介
訊框中繼網路協定是網路協定中位於第二層的封裝協定，用於廣域網路。因此，在介紹訊框中繼網路技術之前，先簡單介紹一下廣域網路（Wide Area Network，WAN）。廣域網路和一般所謂的區域網路（Local Area Network，LAN）不一樣。區域網路一般是指比較小範圍的網路區段，可能是同一棟大樓、同一層樓，或是一個比較小區域的地理位置。而廣域網路則是指範圍比較廣的網路區段，例如一般跨國型的企業都會使用廣域網路將各個不同國家的分部連結起來，好讓資訊能在各個國家的分部之間流通。
訊框中繼網路協定簡介
訊框中繼網路協定是連線導向的網路協定，也因此，訊框中繼網路協定可以提供高效率而且品質很好的網路連線。而在網路傳輸資料的錯誤偵測與保護方面，訊框中繼網路協定依靠高階層的網路協定。訊框中繼網路協定定義了介於路由器和網路服務供應商的交換機設備之間的互動連線。要注意的是，訊框中繼網路協定並沒有定義網路封包如何被傳送。
訊框中繼網路協定的硬體設備
下圖是使用訊框中繼網路協定的網路架構範例圖。其中，訊框中繼網路協定主要運作在路由器A到中間的DCE或是訊框中繼交換機之間。而使用訊框中繼網路協定的硬體設備主要分成資料終端設備（Data Terminal Equipment，DTE）和資料線路終端設備（Data Circuit-terminating Equipment，DCE）兩種類型。
 |
| ▲使用訊框中繼網路協定的網路架構 |
DTE主要代表特定網路之中的端節點，一般而言，DTE常常代表著用戶端，例如訊框中繼存取設備（Frame Relay Access Devices，FRADs）、路由器或是橋接器等等。而DCE設備主要的用途是在網路之中提供Clocking和Switching服務，並負責在廣域網路之中傳遞資料。
訊框中繼的封裝與欄位
如同前面所提到的，訊框中繼網路協定運作在OSI網路模型的最底下兩個層級，所有支援點對點（Point-to-point）的實體Serial連線，也支援連到服務供應商的訊框中繼連線。Cisco的路由器支援以下這幾種Serial連線：
訊框中繼運作於資料連結層，會將上層的資料封裝起來。舉例來說，IP網路封包會被封裝成訊框的格式，這樣才能在訊框中繼網路上傳輸。一個訊框格式的封包包含以下的欄位：
訊框中繼網路協定用語
接著，為各位解釋一些用於訊框中繼網路協定的用語。也許這裡所提及的訊框中繼網路協定用語可能與讀者的網路服務供應商所提供的用語不盡相同，不過大同小異，主要是讓讀者瞭解訊框中繼網路中有哪些東西和用途。先用下面這個訊框中繼網路架構圖來解釋：
 |
| ▲訊框中繼網路架構圖 |
本地端存取速率
本地端存取速率（Local access rate）其實指的就是Local Loop連到訊框中繼網路區段的頻寬（Port Speed / Clock Speed），這個頻寬單純只是指進出這個訊框中繼網路的資料傳輸速率。以上面這個訊框中繼網路架構圖來說，路由器A與中間這個網路雲所連接的網路速度就是指本地端存取速度，這個本地端存取速率就是T1，而路由器B和路由器C的本地端存取速率是64kbps。
資料連結連線辨識值
資料連結連線辨識值（DLCI）是訊框中繼網路封包之中位於表頭（Header）中位址欄位的10個位元的資料。剛剛提到，在訊框中繼網路封包中位址欄位長度為兩個位元組，而兩個位元組之中有10個位元用來儲存線路ID，另外6個位元則用來儲存網路壅塞控制。這10個位元就是DLCI。簡單來說，而DLCI是用來辨識本地端的訊框中繼路由器和交換機，DLCI只能用來辨識本地端的訊框中繼網路設備，所以一段虛擬線路的兩端所使用的DLCI並不相同。
以上頁訊框中繼網路架構圖為例，這裡有三個路由器，彼此之間用永久性虛擬線路來連接，每一段永久性虛擬線路的兩端都可以擁有獨特的DLCI。舉例來說，在路由器A和路由器B之間的永久性虛擬線路中，路由器A的DLCI可能是500，而路由器B的DLCI可能是200。而路由器A與路由器C也有永久性虛擬線路，此時，路由器A對於路由器C而言的DLCI值，和路由器A與路由器B之間的DLCI值是沒有關係的。也就是說，對於路由器A與路由器C之間的永久性虛擬線路而言，路由器A的DLCI值可能是400，而路由器C的DLCI值可能是300。
虛擬線路
虛擬線路（Virtual Circuit），是由資料連結連線辨識元（Data-link Connection Identifier，DLCI）所辨識出來的，是邏輯性線路。虛擬線路用來保證兩台資料終端設備（DTE）之間的雙向通路。多條虛擬線路可以集結成單一條實體線路。這種特性主要是為了降低多台資料終端設備（DTE）之間的複雜度。而單一條虛擬線路可以通過任何數量之中繼的資料線路終端設備（DCE），也就是用於訊框中繼網路的交換機。虛擬線路有兩種型態，一種是永久性虛擬線路（Permanent Virtual Circuit），另一種則是交換式虛擬線路（Switched Virtual Circuit）。單一條虛擬線路可以是這兩種類型的其中一種，如果不是永久性虛擬線路，就一定是交換式虛擬線路。
交換式虛擬線路
在訊框中繼網路之中，交換式虛擬線路（Switched Virtual Circuit，SVC）主要是針對偶爾才需要傳遞資料的連線，提供網路連線。當然，提供服務的對象是位於訊框中繼網路之中的資料終端設備（DTE）。在使用交換式虛擬線路之前，必須建立連線，而這種建立的動作是依據需求才產生的（On Demand），而連線結束時，必須關閉連線。Cisco IOS在11.2以後的版本就支援交換式虛擬線路。
永久性虛擬線路
在訊框中繼網路之中，有些網路連線需要非常頻繁的流通，甚至是永久性的流通，此時，永久性虛擬線路（Permanent Virtual Circuit，PVC）就可以針對這種需求，對資料終端設備（DTE）之間的訊框中繼網路提供這樣的永久性連線。藉由永久性虛擬線路產生的連線並不需要像交換式虛擬線路一樣必須有建立連線（Setup）和關閉連線（Teardown）等等的過程。
資料約定速率
資料約定速率（Committed Information Rate，CIR）是指在一般的情況之下，ISP業者所保證能在虛擬線路上使用的平均頻寬，不過，這也代表在任何的情況之下，所使用的速率不應該低於這個約定的速率，而這個速率的單位是kbit/s。所以當用戶去申請訊框中繼網路服務的時候，都會指定一個特定速率，例如56kbps或是T1（這裡指的是本地端存取速率，也就是Local Access Rate），一般而言，用戶也會被詢問每一段的DLCI所需要的資料約定速率（CIR）要多少。如果傳送資料的速度比DLCI上指定的資料約定速率（CIR）還要快的話，這些網路封包就會被貼上DE（Discard Eligible）的位元標籤，這個DE標籤是位於訊框中繼網路封包表頭（Header）的位址欄位中。
在一般情況下，當然訊框中繼網路會盡力去傳送每一個網路封包，不過，一旦網路發生壅塞，訊框中繼網路就會先把標示為DE的網路封包給丟棄。很多比較便宜的訊框中繼網路服務的資料約定速率都是0。資料約定速率如果是0，那麼所有的網路封包所運行的速率都比較快，也就是說，所有的網路封包都會被貼上DE的標籤，同時也代表當這樣的訊框中繼網路承受不了的時候，將會丟棄所有的網路封包。所以，在得到便宜費用的同時也要注意所可能帶來的風險。
Inverse ARP
Inverse ARP的全稱為Inverse Address Resolution Protocol，這是一個可以找尋DLCI和遠端路由器在網路層的位址，也就是可以讓路由器自動去搜尋虛擬線路另一端的資料終端設備的位址。
LMI
LMI的全名是Local Management Interface，是一種訊號標準，用於路由器等資料終端設備（DTE設備）和訊框中繼交換機（DCE設備）之間，而LMI負責這兩者之間的連線管理與維護的功能。
FECN
Forward Explicit Congestion Notification（FECN）是位於訊框中繼網路封包表頭內位址欄位中的一個位元。當路由器等資料終端設備（DTE設備）發送訊框中繼網路封包到網路時，FECN的機制就會被初始化，當網路發生壅塞的情況，訊框中繼交換機（DCE設備）就會把這個FECN的值設定成1。因此，如果這些訊框中繼網路封包到達目的端的DTE設備，目的端設備看到這個FECN的值是1時，就可以知道這個訊框中繼網路封包從發送端到目的端的這段網路過程中曾經經歷網路壅塞的情況。這樣一來，DTE設備就可以把這樣的資訊呈報到上層的網路協定以便針對網路壅塞做出一些回應。
BECN
Backward Explicit Congestion Notification（BECN）也是位於訊框中繼網路封包表頭內位址欄位中的一個位元。當訊框中繼網路封包從訊框中繼交換機（DCE設備）以反方向發送回給路由器等資料終端設備（DTE設備）而FECN的值為1的時候，訊框中繼交換機（DCE設備）就會把BECN的值也設定為1，這個把BECN設定為1的目的，在於告訴來源端的DTE設備，剛剛這段訊框中繼網路路徑曾發生網路壅塞的狀況，來源端的DTE設備就可以把這樣的訊息通知上層的網路協定，以便於做出相對應的策略或是處理等等。
訊框中繼網路協定的網路架構
訊框中繼網路基本上有星狀拓撲（Star Topology）、全狀拓撲（Full Mesh Topology）和部分拓撲（Partial Topology）三種網路拓撲（Topology）結構。以下針對這三種拓撲結構做一些簡單的介紹。
星狀拓撲
在這個星狀拓撲（Star Topology）中，所有的遠端設備都連到同一個中央控制的設備，而這個中央控制的設備會提供一定的服務給各個遠端設備。星狀拓撲也是Hub-and-spoke的設定方式，下圖為星狀拓撲的網路架構範例。
從範例圖中可以看出，路由器A就是中央控制的設備，整個網路架構圖之中，永久性虛擬線路（PVC）連線的數目並不高，也因為這樣，成本相對就比較低，所以星狀拓撲網路結構是最受歡迎，也是最常被使用於訊框中繼網路的架設。
 |
| ▲星狀拓撲 |
全狀拓撲
全狀拓撲（Full Mesh Topology）這種網路拓撲架構，顧名思義就是每一台路由器與其他各個路由器都有永久性虛擬線路（PVC）的連線，如下圖。
 |
| ▲全狀拓撲 |
由圖中可以看出，這種網路拓撲架構須要架設的永久性虛擬線路數目是最高的，因此，成本也最高。但是，也因為由一個路由器到另一個路由器的路徑不只一條，所以一旦某條網路路徑發生問題，路由器依然可以透過其他路徑傳送網路封包給目的端的路由器。這種網路拓撲所要注意的是，若增加一台新的路由器設備，則要額外建立N-1條永久性虛擬線路（N是全部的路由器數目），而總共的永久性虛擬線路的數目將會變成n ( n - 1) / 2個。舉例來說，如果有20台路由器設備要使用這種網路拓撲結構，則必須架構190條永久性虛擬線路。相對地，若使用剛剛的星狀網路拓撲結構，則只需要N–1條，也就是19條永久性虛擬線路就可以了。兩者之間的成本就相差了十倍。
部分拓撲
至於部分拓撲（Partial Topology），就是指全狀拓撲中少掉幾條永久性虛擬線路的樣子，但又不是星狀拓撲，下圖就是其中一種部分拓撲的範例圖。
 |
| ▲部分拓撲 |
在這種網路拓撲架構之中，雖然成本比星狀拓撲高，比全狀拓撲低，但是無疑是一種權宜方案，依照網路環境的需求，選擇性地讓某幾條網路路徑做到重複（Redundant Path），以便提升網路路徑發生問題的容忍程度，選擇性地降低風險。
Distance Vector路由協定的問題
接下來要講解的是Distance Vector路由協定的問題，因為在後面筆者將會說明訊框中繼網路的缺點，但是在此之前，筆者必須先講解一些相關的背景知識——Distance Vector路由協定所可能造成的問題和解決方案。
Distance Vector路由演算法是將整份路由表（Routing Table）只與鄰近Router設備分享，而且會每隔一段時間就與其他Router設備分享Routing Table的資料，所以當更新動作不夠快的時候，最可能造成的狀況就是資料不一致的問題。以下面的範例來說明Distance Vector路由演算法是在怎樣的情況下讓Routing Table的資料產生不一致。
 |
| ▲連接Router設備的網路架構圖 |
假設有以上三台Router設備，Router A的左邊為E0介面，右邊為S0介面，Router B的左邊為S0介面，右邊為S1介面，Router C的左邊為S0介面，右邊為E0介面。與之前的範例相同，所以上圖顯示出這三台Router設備目前的Routing Table資料。現在假設10.4.0.0的網路區段連線發生問題，如下圖所示。
 |
| ▲10.4.0.0網段開始發生問題 |
因為Router C設備與10.4.0.0的網路區段是直接連接的，所以Router C設備能夠在第一時間內先發現無法到達10.4.0.0網路區段，因此，Router C設備會更新自己的Routing Table，標示10.4.0.0網段為無法到達，並不再發送任何網路封包透過E0介面前往10.4.0.0的網路區段，但是，這個時候Router A和Router B兩台設備都還不知道10.4.0.0網段發生問題，所以還是相信10.4.0.0網段是可以到達的。接著，當Router B設備準備要發送它的定期對外更新資料時，會發送自己的Routing Table資料給Router C設備，如下圖所示。
 |
| ▲Router C收到關於10.4.0.0的錯誤資料 |
這個時候，因為Router C會從自己的S0介面收到由Router B設備所送過來的Routing Table資料，而且資料中顯示10.4.0.0網段是可以到達的，所以Router C設備會以為原來可以透過自己的S0介面出去，經過Router B設備可以到達10.4.0.0網段，而且必須經過兩台網路設備（直接把Router B設備的Routing Table中針對10.4.0.0網段的距離加1），於是Router C就會更新自己的Routing Table。此時Routing Table中就有錯誤資料的事情發生了，但是更慘的還在後頭。若此時，Router C設備也到了應該對其他設備做Routing Table同步的動作，如下圖所示。
 |
| ▲Router C把錯誤資料發送出去 |
Router C設備會先發送自己的Routing Table給Router B設備，此時，與上面的情況類似，Router B設備會以為原來可以從自己的S1介面出去，透過Router C設備而到達10.4.0.0網段，所以Router B設備就會乖乖地更新自己的Routing Table，並記錄前往10.4.0.0網段的Hops Count為3。同樣地，Router A設備也會更新10.4.0.0網段的Hops Count為4。這個時候錯誤已經到了難以彌補的地步了，因為現在所有的網路設備對於10.4.0.0網段的資訊全部都是錯誤的。事實上，10.4.0.0網段根本就沒有辦法到達。
接著，Router A設備會一直傳送這個錯誤訊息給全部的設備，所以各個Router設備對於10.4.0.0網段的Hops Count值可能會趨近於無限大（Count to infinity），這就是第二個可能造成的問題。而且，此刻若有任何封包要送往10.4.0.0網段的話，那麼這個封包是根本不可能成功送達目的地，而會在各個Router之間傳遞，也就是Routing Loop問題。接著來看看如何解決Count to infinity和Routing Loop問題。
Count to infinity解決方案
Count to infinity所指的問題是，Router設備嘗試不斷地增加Hops Count，而其所要到達的網段根本就無法到達。這個問題的解決方案比較簡單，就是去定義一個Hops Count的最大值，RIP協定預設的最大值為16，所以當Hops Count增加到16之後，就不會再繼續增加了。同時也代表，當發現Routing Table中有Hops Count到達16這樣的最大值，就表示這條路徑無法到達，因此也就不會繼續把這樣的資料分送給其他Router設備。所以像剛剛的這個範例，若套用這樣的解決方案，其各個Router設備的Routing Table就會變成下面這個樣子：
 |
| ▲Count to infinity解決方案 |
Routing Loop解決方案
Routing Loop問題的詳細情況，前面都已經提過了。而解決Routing Loop問題有很多種方法，其中包含Split Horizon、Route Poisoning、Poison Reverse、Hold-Down Timer和Triggered Update。這些都相當重要，準備CCNA認證的讀者必須完全了解。下面一一來了解這五種Routing Loop的解決方案，要注意的是，這五種解決方案必須一起使用，並不是其中一種就可以完整地解決Routing Loop問題。不過由於篇幅有限，筆者在這裡只介紹與訊框中繼網路有關的Split Horizon的解決方案。
Split Horizon
這個解決方案的精神就是，絕對不向這筆資訊的來源端發送與這筆資料有關的更新動作。這個方法可以有效避免發生Routing Loop問題，也可以加速Routing Table的資料收斂過程。所謂的收斂過程代表的是當網路發生變化，網路上各個網路設備的Routing Table從發生變化開始到真正把變化反應到Routing Table的過程，就叫做Routing Table的收斂過程。繼續使用上述的範例來說明，如下圖所示。
 |
| ▲Split Horizon解決方案 |
以上面的網路圖為例，對Router B設備而言，10.4.0.0網段可以從S1介面出去，透過Router C設備而到達，而這樣的訊息是Router C設備告訴Router B設備的，所以Router B設備才知道可以透過Router C設備到達，之後根本不必透過Router B設備來告知Router C設備，Router B設備可以到達10.4.0.0網段。因為事實上Router C設備應該比Router B設備還要了解10.4.0.0網段。同樣的道理，Router B設備也不應該發送有關10.1.0.0網段的更新資料從S0介面給Router A設備，S0介面對Router B設備而言，就是這筆資料的來源端，除了這個來源端之外，這筆資料可以從其他的介面和Router設備做更新的動作。
訊框中繼網路的問題
這裡要告訴各位讀者的是，訊框中繼網路雖然看起來都還不錯，也都很廣泛地被使用於廣域網路，但是，訊框中繼網路卻還是有一定的缺點，那就是路由更新（Routing Update）的可到達性問題（Reachability Issue）以及重複發送廣播封包問題（Broadcast Replication）。
非廣播式多重存取連線
預設上，訊框中繼網路在遠端設備之間提供「非廣播式多重存取（Non-broadcast Multi-access，NBMA）」的連線類型，非廣播式多重存取連線類型其實和一般的廣播網路環境（例如乙太網路）類似，差別只在於所有的路由器都位於相同的子網路中。然而，因為成本的考量，非廣播式多重存取連線網路通常位於Hub-and-spoke的網路拓撲中。但是在這樣的Hub-and-spoke的網路拓撲中，實體拓撲並沒有提供像乙太網路一樣的多重存取功能，也因此，在同一個子網路中每一個路由器並沒有專門的永久性虛擬線路分別連線到不同的遠端路由器。
由於訊框中繼網路的非廣播式多重存取連線架構，讓訊框中繼網路面臨兩個問題：第一是路由更新的到達性問題，第二是當一個實體介面接上多個永久性虛擬線路時，必須重複發送廣播封包。
路由更新問題
在Distance Vector路由協定中，為了減少路由迴圈（Routing Loop）的問題，衍生出Split Horizon的解決方案，但是在訊框中繼網路中，Split Horizon卻衍生出其他的問題，這也就是為什麼剛剛要介紹Distance Vector路由協定的Split Horizon解決方案的原因。
在訊框中繼網路的Hub-and-spoke網路架構中，遠端的路由器（Spoke端路由器）會發送路由更新給主要的路由器（Headquarter端路由器），而這個主要的Headquarter端路由器會透過同一個實體的介面來建立出很多不同條的永久性虛擬線路，在這樣的環境之中，一旦這台Headquarter端路由器由這個實體介面收到廣播封包（路由更新），卻不能轉發這個路由更新封包透過同一個介面轉發給其他不同的遠端路由器（Spoke路由器），因此造成無法傳送路由更新出去的問題。當然，如果Headquarter端路由器的每一個實體介面都只有建立一個永久性虛擬線路的話，就不會有這種路由更新的問題。
重複發送廣播封包問題
這個問題的發生環境和上一個問題相同，但是不同的是，如果要解決上面這個問題，就會衍生出現在這個問題。就是因為主要的Headquarter端路由器會透過同一個實體的介面來建立許多不同的永久性虛擬線路，所以若收到廣播封包時打算把這樣的廣播封包真的傳送到不同的永久性虛擬線路，那麼這些廣播封就會耗盡大量的網路頻寬，而造成網路嚴重延遲的問題。
結語
訊框中繼目前已經成為已經產業界的標準，它可以處理多個虛擬線路。訊框中繼不僅可以用於資料傳輸，也可以用於語音傳輸，而且訊框中繼不僅用於廣域網路，也可以應用在區域網路。雖然訊框中繼是個蠻好用的協定，不過訊框中繼協定正逐漸被ATM協定所取代。在這篇文章之中，筆者花費不少心力講解了訊框中繼網路的專有名詞解釋、訊框中繼網路的網路架構和訊框中繼網路所可能造成的問題，不過篇幅有限，所以筆者打算在下一篇的文章，詳細介紹訊框中繼網路這些問題的解決方案。