設計和部署通過幀中繼和ATM的多鏈路PPP

簡介

Cisco IOS®軟體版本12.1(5)T引入了使用ATM的多連結PPP和透過訊框中繼的多連結PPP（MLPoATM和MLPoFR）。此功能針對具有幀中繼/ATM互通(FR/ATM IW)且可在中低速廣域網鏈路上部署IP語音(VoIP)的客戶。在此功能之前，ATM和具有FR/ATM IW的訊框中繼客戶都沒有受Cisco IOS支援的通用第2層分段方案，因此被迫進行第3層分段。

必要條件

需求

本文檔面向設計和部署涉及MLPoATM和幀中繼網路的VoIP網路的網路人員。思科建議您瞭解以下主題：

• 框架轉送

• ATM

• PPP

• MLP

• 訊框中繼/ATM互通

• 語音服務品質(QoS)組態

本文檔不提供這些主題的技術培訓。本檔案的末尾包含參考資料清單。思科建議您在閱讀本檔案之前先檢視和瞭解以下檔案：

• 使用訊框中繼的VoIP與服務品質（分段、流量調節、LLQ/IP RTP優先順序）

• 適用於訊框中繼到ATM的VoIP QoS與LLQ、PPP LFI和cRTP互通

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• 用於MLP over FR/ATM IW的Cisco IOS軟體版本12.1(5)T或更高版本

• 適用於使用ATM的壓縮即時傳輸通訊協定(cRTP)的Cisco IOS軟體版本12.2(2)T或更新版本

• 適用於透過訊框中繼和實體介面上的ATM進行低延遲佇列(LLQ)的Cisco IOS軟體版本12.0(7)T

• 適用於使用訊框中繼的LLQ和每個永久虛擬電路(PVC)的ATM的Cisco IOS軟體版本12.1(2)T

本文檔中包含的案例研究基於具有以下軟體和硬體版本的生產網路：

• 核心Cisco 3660路由器運行Cisco IOS軟體版本12.2(5.8)T。使用Cisco IOS軟體版本12.2T時，必須使用cRTP over ATM。Cisco IOS軟體版本12.2(8)T1中已解決此已知問題：

  思科錯誤ID CSCdw4216(僅供註冊客戶使用)- cRTP在基於類的加權公平佇列(CBWFQ)/LLQ連結達到擁塞時導致高CPU。

• 分支Cisco 2620路由器正在從Cisco IOS軟體版本12.2(3)升級到一個2.2(6a)。 Cisco 2620還充當分支機構H.323網關。升級由網關相關問題觸發。就WAN和QoS功能而言，Cisco IOS軟體版本12.2(3)未顯示任何重大問題。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

設計

本節討論與透過訊框中繼和ATM設計和部署多重連結PPP有關的幾個設計概念。

資料鏈路開銷

使用MLP設計ATM和幀中繼網路時，必須瞭解資料鏈路開銷。開銷會影響每個VoIP呼叫佔用的頻寬量。它還有助於確定最佳MLP片段大小。最佳化片段大小以適合整數個的ATM信元，尤其是在慢速PVC中，在信元填充上浪費了大量頻寬，這是至關重要的。使用訊框中繼和ATM PVC的MLP上的資料連結額外負荷取決於以下因素：

• FRF.8 IW裝置的操作模式（透明或平移）。

• 流量的方向（ATM到框架轉送或框架轉送到ATM）。

• PVC腿。PVC的ATM和幀中繼支路上的開銷不同。

• 流量型別。資料包具有MLP報頭；VoIP資料包則不需要。

下表顯示了資料包的資料鏈路開銷。它詳細說明了各種幀中繼、ATM、LLC、PPP和MLP報頭中有關FRF.8操作模式、流量方向和PVC支路的所有置換的位元組數。

1DSAP/SSAP ^{— 目標服務接入點/源服務接入點。}

2NLPID ^{— 網路層通訊協定識別。}

平移PVC最容易理解，因為兩個方向的開銷相同。這是因為FRF.8裝置在MLPoATM和MLPoFR格式之間轉換。因此，在幀中繼支路上，兩個方向的幀格式都是MLPoFR。ATM分支上的格式在兩個方向上都是MLPoATM。

透明PVC稍顯凌亂，因為兩個方向的開銷不同。之所以會出現這種複雜性，是因為幀中繼路由器以MLPoFR格式傳送資料包。此格式由IW裝置傳送到ATM端。同樣，ATM路由器以MLPoATM格式傳送資料包。此格式由IW裝置傳送到幀中繼端。因此，每個支路上的兩個方向上的幀格式不同。

相比之下，使用FRF.12的端到端幀中繼PVC的開銷為11位元組。因此，在端到端幀中繼鏈路上，FRF.12是比MLP更有效的鏈路分段和交錯(LFI)選擇。在端到端ATM虛擬電路(VC)上，由於沒有可用的基於標準的分段，MLP是唯一選擇。但是，端到端ATM VC是中高速的。因此，不需要LFI。此規則的例外情況是在數位使用者線路(DSL)上使用慢速ATM VC。

PPP ID僅存在於第一個MLP片段中。因此，第一個片段的開銷總是比後續片段的開銷多兩個位元組。

下表顯示了VoIP資料包的資料鏈路開銷。它詳細說明了各種幀中繼、ATM、LLC和PPP報頭中有關FRF.8操作模式、流量方向和PVC支路的所有置換的位元組數。資料和VoIP資料包之間的主要區別是VoIP資料包作為PPP資料包而不是作為MLP資料包傳送。所有其他方面與資料場景相同。

相比之下，端到端幀中繼PVC上VoIP資料包的資料鏈路開銷顯示在最右一列中。

VoIP頻寬要求

為VoIP調配頻寬時，必須在頻寬計算中包括資料鏈路開銷。下表顯示了各種型別的VoIP的每呼叫頻寬要求。它基於PVC的特性。下表中的計算假設了cRTP的最佳方案（例如，沒有UDP校驗和並且沒有傳輸錯誤。） 然後將標頭從40位元組持續壓縮到2位元組。

因為PVC的不同分支上的開銷不同，所以有必要設計最壞的情況。例如，考慮具有20毫秒(msec)取樣的G.729和跨透明PVC的cRTP。此場景在幀中繼支路上的頻寬要求是：一個方向為12.4 Kbps，另一個方向為13.2 Kbps。調配需要在假設每個呼叫為13.2 Kbps的情況下完成。

相比之下，上表最右一列也顯示了端到端幀中繼PVC的VoIP頻寬要求。與本地幀中繼封裝相比，PPP的額外開銷導致每個呼叫的額外頻寬消耗介於0.5 Kbps和0.8 Kbps之間。因此，在端到端幀中繼VC上，使用FRF.12進行幀中繼封裝比使用MLP更有意義。

註：使用ATM的cRTP需要Cisco IOS軟體版本12.2(2)T或更高版本。

最佳化分段大小

在訊框中繼/ATM PVC上使用MLP是為了允許將大型資料封包分段為較小的區塊。然後，路由器通過將VoIP資料包交織到資料片段之間來加速這些資料包。在Cisco IOS中，不會直接設定分段大小。相反，所需的延遲是使用ppp multilink fragment-delay 命令配置的。然後Cisco IOS使用此公式計算適當的片段大小：

fragment size = delay x bandwidth/8

當您在ATM上執行MLP時，需要最佳化片段大小，以使其適應一個整數信元。如果不進行此最佳化，由於填充效應，所需的頻寬幾乎可以翻倍。例如，如果每個片段的長度為49位元組，則需要兩個ATM信元來承載每個片段。因此，106位元組用於承載的負載只有49位元組。

Cisco IOS在執行MLPoATM和MLPoFR時自動最佳化片段大小，以便使用整數的ATM信元。Cisco IOS會自動將計算出的片段大小舍入為下一個整數的ATM信元。未新增新的CLI命令。Cisco IOS在MLPoFR/ATM PVC的幀中繼和ATM端均執行此最佳化。MLP PVC可以是端到端幀中繼。在這種情況下，不需要針對ATM對其進行最佳化。但是，Cisco IOS會針對ATM最佳化此情境，因為它無法偵測遠端是ATM還是訊框中繼。

註：由於四捨五入，因此產生的延遲可能略高於配置的延遲。這種舍入誤差在低速PVC上更為顯著。

您也可以手動配置最佳化。由於無法直接在Cisco IOS中指定片段大小，因此請計算最佳片段大小並將其轉換為延遲。計算片段大小時，調整資料鏈路開銷，因為MLP代碼假定每個鏈路都是高級資料鏈路控制(HDLC)並有2位元組的資料鏈路開銷。除HDLC資料鏈路開銷外，MLP代碼還在計算中包括由MLP ID、MLP序列號和PPP ID構成的8個位元組，如上面的第一個表所示。

使用以下步驟計算要在Cisco IOS中設定的延遲：

1. 根據所需的延遲和PVC的頻寬計算理論片段大小：

   fragment = bandwidth * delay / 8

2. 請確保片段是48位元組的倍數，以便它適合整數的ATM信元。

   計算單元格對齊片段大小的公式為：

   fragment_aligned = (int(fragment/48)+1)*48

3. 調整MLP未考慮的資料鏈路開銷。

   如前所述，此開銷因PVC特性而異。請考慮PVC的ATM端，因為此端是您最佳化的端。此表顯示了ATM端的資料鏈路開銷位元組數。

   FRF.8模式	透明		翻譯
   流量方向	訊框中繼到ATM	ATM到框架轉送	訊框中繼到ATM	ATM到框架轉送
   PVC的訊框中繼或ATM分支	ATM	ATM	ATM	ATM
   LLC DSAP/SSAP(0xfefe)	0	2	2	2
   LLC控制(0x03)	1	1	1	1
   NLPID(0xcf for PPP)	1	1	1	1
   AAL5	8	8	8	8
   非MLP開銷（位元組）	10	12	12	12

   要得出MLP計算所依據的片段大小，請從所需的單元格對齊片段大小中減去資料鏈路開銷。後增2位元組，以補償MLP一直假設的HDLC封裝。

   用於計算MLP代碼目標的片段大小的公式：

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. 使用以下公式將得到的片段大小轉換為相應的延遲：

   delay = fragment_mlp/bandwidth x 8bits/byte

5. 在大多數情況下，計算的延遲不是整數毫秒。因為Cisco IOS只接受整數值，所以您必須向下舍入。因此，您在Cisco IOS中使用ppp multilink fragment-delay命令設定的延遲值為：

   fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)

6. 為了補償上述舍入誤差，請將MLP使用的頻寬從延遲轉換為分段。您在Cisco IOS中通過bandwidth命令的幫助配置的混合頻寬為：

   bandwidth = fragment_mlp/fragment_delay * 8

下表顯示最常見PVC速度的ppp multilink fragment-delay和bandwidth的最佳值。假定目標延遲為10毫秒。為了簡化該表，計算不會區分透明和平移PVC或流量方向。資料鏈路開銷的最大差異僅為2個位元組。因此，針對12位元組的最壞情況設計時的懲罰很小。表格中還顯示了由於增加片段大小以使片段適合成整數數量的單元格而遇到的「實際」延遲。

流量整形和策略注意事項

在訊框中繼/ATM IW環境中會特別考慮流量調節和管制。訊框中繼到ATM方向的問題與ATM到訊框中繼方向的問題不同。因此，每個主題都單獨描述。

幀中繼到ATM方向的主要問題是從幀到信元時頻寬消耗的潛在擴展。例如，幀中繼端的49位元組幀會消耗ATM端的兩個信元，即106位元組。因此，不能假設可持續信元速率(SCR)等於承諾資訊速率(CIR)。 最壞的情況發生在每個幀中繼幀包含1位元組的負載時。其中每個位元組都會在ATM端佔用一個完整的53位元組元組。例如，這種極端且不切實際的場景要求的SCR是CIR的53倍。另外兩個較為現實的例子是：

• G.729 VoIP資料包的長度為60個位元組，即69個位元組（如果包括MLP和幀中繼開銷）。 在ATM線路上，它消耗兩個基地台或106位元組。因此，如果所有傳輸流量都是VoIP，則適當的對映是SCR = 106/69 = 1.5 x CIR。

• 傳送單個擊鍵的Telnet資料包包含40位元組的TCP/IP報頭和1位元組的資料。在幀中繼端，包括開銷在內，這總計為56個位元組。但是，在ATM端，此封包將擴展到兩個基地台。在這種情況下，SCR = 106/56 = 1.9 x CIR。

ATM Forum標準BISDN Inter Carrier Interface(B-ICI)規範版本2.0的附錄A介紹了SCR和CIR之間的兩種對映方法。雖然這兩種方法都提供了從CIR推算SCR的科學方法，但無論哪種方法都比所應用的資料更準確。公式要求的數字之一是典型的幀大小，在實際網路中很難確定。此外，當在現有ATM/幀中繼網路上部署新應用時，該數字可能會發生變化。解決此問題的最佳建議是與運營商密切合作，因為他們的策略將至關重要。在承運人的幫助下，這種故障保護方法成為可能：

• 訊框中繼到ATM方向 — 在訊框中繼到ATM的方向中，電信公司僅需要管制訊框中繼輸入點處的傳入流量。例如，在連線到幀中繼連線的客戶端裝置(CPE)裝置的幀中繼交換機上，運營商根據約定的CIR控制流量。此策略如下圖所示。在入口點允許流量進入網路後，不應再執行進一步的管制。此管制策略的含義是，允許幀中繼端接收的資料擴展和使用所需的任何頻寬，以便允許使用信元稅、AAL開銷和填充，以便在網路的ATM分支中傳輸資料。在大多數情況下，所需的ATM頻寬小於所用幀中繼頻寬的兩倍。

  

• ATM到框架轉送方向 — 在ATM到框架轉送方向，體驗到的正好相反。當從ATM到幀作為信元稅、AAL開銷以及刪除填充時，頻寬使用率會降低。但是，由於ATM端的潛在傳輸速率遠高於幀中繼鏈路的傳輸速率，因此在ATM路由器上正確設定流量整形對於語音的完整性至關重要。如果整形太鬆，則ATM路由器以比另一端幀中繼鏈路的物理速度更快的速度傳輸資料。因此，資料包開始在FRF.8交換機上排隊。在某個時刻，資料包開始丟棄。而且，由於ATM/幀中繼網路不區分語音和資料，因此VoIP資料包也會被丟棄。

  同時，如果整形過於嚴格，則吞吐量會受到影響。由於ATM信元稅，FRF.8裝置刪除了AAL開銷和填充。它不佔用幀中繼鏈路上的頻寬。因此，您可以輕微超額訂閱PVC的ATM端。填充和AAL開銷的量取決於平均幀大小和分段的積極程度。由於您無法準確確定此開銷，因此最好不要嘗試對其進行最佳化。另一方面，手機稅完全是確定性的。每48位元組的負載是5位元組。您可以通過將ATM路由器上的整形目標設定為53/48 x SCR來最佳化信元稅。運營商端的策略必須設定為允許這種輕微的超訂用。

提示和警告

• MLPoATM/幀中繼當前僅通過連線到虛擬模板或撥號器介面的服務策略進行測試並受支援。忽略服務策略可能會導致功能無法正常工作。其中一個範例記錄在Cisco錯誤ID CSCdu19313(僅限註冊客戶)。

• MLPoATM/幀中繼克隆每個PVC的兩個虛擬訪問介面。其中一個表示PPP鏈路。另一個代表MLP捆綁包。show ppp multilink 命令用於指示哪個是哪個。不支援每個捆綁包有多個PPPoFR鏈路。將兩條PPPOFR電路放入一個捆綁包中的流量將不會在電路之間實現良好的負載均衡，因為PPPOFR驅動程式不提供實際串列驅動程式所具有的流量控制信令。使用ATM或幀中繼的MLPPP負載均衡可能明顯比使用物理介面的相同負載均衡效果更差。

• 每個PVC與四個不同的介面相關聯，即物理介面、子介面和兩個虛擬訪問介面。只有MLP虛擬訪問介面啟用了花式隊列。其他三個介面必須有「先進先出」(FIFO)隊列。

• 將service-policy命令應用於虛擬模板時，Cisco IOS會顯示以下正常警告消息：

  cr7200(config)#interface virtual-template 1
  cr7200(config-if)#service-policy output Gromit
  Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
  Note CBWFQ supported on MLP bundle interface only.
  

  這些消息是正常的。第一條　消息建議在PPP虛擬訪問介面上不支援服務策略。第二個消息確認服務策略已在MLP捆綁虛擬訪問介面上生效。使用show interfaces virtual-access 、show queue 和show policy-map interface 命令檢查排隊機制可以檢驗此情況。

• 由於PVC類似於租用線路，因此不嚴格要求PPP身份驗證。但是，PPP身份驗證非常方便，因為show ppp multilink命令隨後用於確定PVC另一端的路由器名稱。

• 必須在幀中繼路由器上為MLPoFR PVC啟用幀中繼流量調節。

• Cisco IOS軟體版本12.2最初最多支援每個路由器二十五個虛擬範本。如果每個PVC都需要具有唯一的IP地址，此限制可能會影響ATM分佈路由器的規模。受影響版本的解決方法是使用未編號的IP或使用撥號器介面而不是虛擬模板。在Cisco IOS軟體版本12.2(8)T中，支援增加到200個虛擬範本。

• 某些服務提供商尚未在其FRF.8裝置上支援PPP轉換。只要存在此限制，提供商就必須將其PVC配置為透明模式。

• Cisco IOS文檔中的大多數示例顯示了包括幀中繼或ATM子介面的配置。此子介面沒有任何用途。虛擬模板應只附加到物理介面。結果使配置更緊湊、更易於管理。如果存在大量的PVC，這一點尤其重要。

• 使用show ppp multilink命令作為防傻方法，可確定載波端是否有任何信元/幀丟棄。唯一可接受的片段丟失是由循環冗餘校驗(CRC)錯誤導致的。

• 雖然MLPoATM/訊框中繼是在Cisco IOS軟體版本12.1(5)T中匯入，但是此版本和後續版本中的錯誤指示您在選擇Cisco IOS軟體版本時需謹慎。思科建議使用最新維護版本的Cisco IOS 12.2主流。但是，其他VoIP功能要求可以規定使用不同的Cisco IOS軟體版本，例如，如果需要Survivable Remote Site Telephony(SRST)的12.2(2)XT。下表列出了一些已知問題。選擇Cisco IOS時，應根據所選IOS評估每個Cisco錯誤ID。

案例研究

簡介

本節介紹MLPoATM/幀中繼功能的首批客戶部署之一。該客戶使用虛構名稱XYZ Ltd.來指代。在2001年，XYZ Ltd用IP電話解決方案替換了他們的PBX。作為此專案的一部分，我們建立了新的IP網路。為WAN選擇了幀中繼/ATM互通。提供WAN服務的運營商使用Newbridge交換機提供ATM和幀中繼服務。

網路概觀

XYZ Ltd網路是一個集中星型網路，連線著26個分支機構和兩個核心站點。每個核心站點都由E3 ATM連線的Cisco 3660路由器提供服務。26個分支中的18個是中型分支機構。它們具有雙幀中繼PVC，通過ATM/幀中繼IW連線到兩個核心站點的3660。其餘8個分支非常小。它們通過單個幀中繼PVC連線回最近的中等規模分支。所有分支機構路由器都是Cisco 2620。一個端到端ATM PVC連線兩個中心站點上的兩台3660路由器。下圖說明了拓撲。

下表顯示了幀中繼接入速度和CIR。CIR從32 kbps到256 kbps不等。表中還顯示了每個PVC傳送的最大同步VoIP呼叫數。

幀中繼流量整形由分支路由器執行。允許突發超出CIR。Cisco IOS流量整形設定為以接入速度整形，最小值等於CIR。如果從運營商收到後向顯式擁塞通知(BECN)，則路由器將回退到mincir。這種方法違背了思科在通過幀中繼執行VoIP時提出的建議。當路由器響應擁塞通知時，語音已經出現問題。但是，在這種情況下，運營商會認為其網路配置過度，因此永遠不會丟棄任何幀或信元，因此，BECN將永遠不會出現。

ATM流量整形設定為在遠端以幀訪問速度進行整形，並加上信元稅。例如，如果訪問速度為512 Kbps，則SCR設定為512x53/48 = 565 Kbps。此整形速率用於最大化吞吐量。這是安全的，因為細胞稅在免疫關口被取消。運營商側的策略配置相當大，因此允許輕微超訂用。

cRTP用於整個WAN。對於CPU而言，核心站點1的Cisco 3660分佈路由器是熱點。通過新增上表中的數字，可以確定流經此路由器的VoIP呼叫的理論最大數量為102個呼叫。此圖中的效能數字表明，100 cRTP會話（快速交換）的Cisco 3660 CPU負載約為50%。

虛擬模板用於IP編號的WAN鏈路。每個PVC需要一個虛擬模板，這是可能的，因為每個Cisco 3660上終止的PVC總數不到25個。

組態

本檔案會使用以下設定：

• 核心ATM路由器

• 分支機構訊框中繼路由器

!--- Note: This section shows the parts of a core Cisco 3660 router !--- configuration that is relevant to MLPoATM.

        
class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58 
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


!--- Note: Do not configure !--- IP addresses directly on any configuration source, !--- such as a virtual template, whenever the possibility !--- exists that this information is cloned to multiple !--- active interfaces. The exception to this rule is the !--- rare case where the intent is to define multiple parallel !--- IP routes and have IP do load balancing between them. !--- If an IP address is present on the configuration source, !--- this IP address is copied to all the cloned interfaces. !--- IP installs a route to each of these interfaces.
 

!--- Note: This section shows the parts of a branch Cisco 2600 router !--- configurations that is relevant to MLPoFR.


class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000

相關資訊

• 使用訊框中繼的VoIP與服務品質（分段、流量調節、LLQ/IP RTP優先順序）
• 適用於訊框中繼到ATM的VoIP QoS與LLQ、PPP LFI和cRTP互通
• 為訊框中繼和ATM虛擬電路設定連結分散和交錯
• 使用AAL5的PPP，RFC 2364,1998年7月
• 幀中繼中的PPP，RFC1973,1996年6月
• PPP多重連結通訊協定(MP),RFC 1717,1994年11月
• 為低速串列鏈路壓縮IP/UDP/RTP報頭，RFC 2508,1999年2月
• 訊框中繼/ATM PVC服務互通實作協定FRF.8.2
• 訊框中繼分段實作協定FRF.12
• 語音技術支援
• 語音和IP通訊產品支援
• Cisco IP電話故障排除
• 技術支援與文件 - Cisco Systems