在帧中继与 ATM 上设计与部署多链路 PPP

简介

Cisco IOS®软件版本12.1(5)T中引入了基于ATM的多链路PPP和基于帧中继的多链路PPP（MLPoATM和MLPoFR）。此功能面向具有帧中继/ATM互通(FR/ATM IW)的客户，这些客户在中低速WAN链路上部署IP语音(VoIP)。在此功能之前，ATM和具有FR/ATM IW的帧中继客户上均没有Cisco IOS支持的通用第2层分段方案被强制执行第3层分段。

先决条件

要求

本文档面向参与设计和部署VoIP网络（包括MLPoATM和帧中继网络）的网络人员。Cisco 建议您了解以下主题：

• 帧中继

• ATM

• PPP

• MLP

• 帧中继/ATM互通

• 语音服务质量(QoS)配置

本文档不旨在提供有关这些主题的技术培训。本文档末尾包含参考材料列表。思科建议您在阅读本文档之前查看并了解这些文档：

• 带有服务质量控制（分段、流量整形、LLQ/IP RTP 优先级）的 基于帧中继的VoIP

• 帧中继到 ATM 与LLQ 、PPP LFI 和cRTP 互工作的 VoIP QoS

使用的组件

本文档中的信息基于以下软件和硬件版本：

• Cisco IOS软件版本12.1(5)T或更高版本，适用于FR/ATM IW上的MLP

• 用于ATM上压缩实时传输协议(cRTP)的思科IOS软件版本12.2(2)T或更高版本

• 用于物理接口上帧中继和ATM上的低延迟队列(LLQ)的思科IOS软件版本12.0(7)T

• Cisco IOS软件版本12.1(2)T，用于帧中继上的LLQ和每永久虚电路(PVC)的ATM

本文档中包含的案例研究基于使用以下软件和硬件版本的生产网络：

• 核心Cisco 3660路由器运行Cisco IOS软件版本12.2(5.8)T。对基于ATM的cRTP的要求规定了Cisco IOS软件版本12.2T的使用。此已知问题在Cisco IOS软件版本12.2(8)T1中解决：

  Cisco Bug ID CSCdw44216（仅限注册客户） — 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)不显示任何重大问题。

规则

有关文档规则的详细信息，请参阅 Cisco 技术提示规则。

设计

本节讨论与帧中继和ATM上多链路PPP的设计和部署相关的几个设计概念。

数据链路开销

当您使用MLP设计ATM和帧中继网络时，您必须了解数据链路开销。开销会影响每个VoIP呼叫消耗的带宽量。它还有助于确定最佳MLP片段大小。优化分片大小以适应ATM信元的整数数量至关重要，特别是在低速PVC上，在信元填充上浪费了大量带宽。帧中继MLP和ATM PVC上的数据链路开销取决于以下因素：

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

• 流量的方向（ATM到帧中继或帧中继到ATM）。

• PVC腿。PVC的ATM和帧中继支路的开销不同。

• 流量类型。数据包具有MLP报头；VoIP数据包不会。

下表显示数据包的数据链路开销。它详细说明了FRF.8操作模式、流量方向和PVC支路的所有排列的各种帧中继、ATM、LLC、PPP和MLP报头中的字节数。

1 DSAP/SSAP ^{— 目标服务接入点/源服务接入点。}

2 NLPID ^{— 网络层协议标识。}

平移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数据包的数据链路开销。它详细说明了FRF.8操作模式、流量方向和PVC支路的所有排列的各种帧中继、ATM、LLC和PPP报头中的字节数。数据和VoIP数据包之间的主要区别是VoIP数据包是作为PPP数据包而不是MLP数据包发送的。所有其他方面与数据场景相同。

相比之下，端到端帧中继PVC上VoIP数据包的数据链路开销显示在最右列。

VoIP 带宽需求

为VoIP调配带宽时，数据链路开销必须包括在带宽计算中。下表显示了各种VoIP类型的每个呼叫带宽要求。它基于PVC的特性。此表中的计算假设cRTP的最佳情况（例如，没有UDP校验和，并且没有传输错误）。 然后，报头会从40个字节持续压缩到2个字节。

由于PVC的不同支路上的开销不同，因此必须针对最坏情况进行设计。例如，假设G.729采样20毫秒（毫秒），并且cRTP通过透明PVC。此场景在帧中继支路上的带宽要求一个方向为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数据包来加速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用于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多链路分段延迟和带宽的最佳值。假设目标延迟为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论坛标准附录A BISDN运营商间接口(B-ICI)规范版本2.0介绍了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 Bug 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最初支持每台路由器最多25个虚拟模板。如果每条PVC都需要具有唯一的IP地址，此限制会影响ATM分布路由器的规模。受影响版本的解决方法是使用未编号的IP或使用拨号器接口而不是虚拟模板。在思科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主流的最新维护版本。但是，如果需要可存活远程站点电话(SRST)，其他VoIP功能要求可以规定使用不同的Cisco IOS软件版本，例如12.2(2)XT。下表列出了一些已知问题。选择Cisco IOS时，应根据所选IOS评估每个Cisco Bug ID。

案例研究

简介

本节介绍MLPoATM/帧中继功能的首批客户部署之一。该客户被虚构的名称XYZ Ltd.所引用。在2001年，XYZ Ltd用IP电话解决方案替换了他们的PBX。作为本项目的一部分，我们构建了一个新的IP网络。并且为WAN选择了帧中继/ATM互通。提供WAN服务的运营商使用Newbridge交换机来提供ATM和帧中继服务。

网络概述

XYZ Ltd网络是一个中心辐射型网络，它将26个分支机构与两个核心站点连接在一起。每个核心站点都由连接Cisco 3660的E3 ATM路由器提供服务。26家分行中有18家为中型。它们有双帧中继PVC，通过ATM/帧中继IW连接回两个核心站点的3660。其余八个分支非常小。它们通过一条帧中继PVC连接回最近的中型分支。所有分支路由器都是Cisco 2620。端到端ATM PVC连接两个中心站点的两台3660路由器。此图说明了拓扑。

下表显示了帧中继接入速度和CIR。CIR从32 kbps到256 kbps不等。表中还显示了每个PVC同时承载的最大VoIP呼叫数。

帧中继流量整形由分支路由器执行。允许超出CIR的突发量。Cisco IOS流量整形设置为与接入速度整形，最小值等于CIR。如果从运营商收到后向显式拥塞通知(BECN)，则路由器将限制回最小。此方法与思科在通过帧中继进行VoIP时的建议相悖。当路由器响应拥塞通知时，语音已出现故障。但是，在这种情况下，运营商认为其网络已经过充分的调配，从而不会丢弃任何帧或信元，因此，BECN永远不应被看到。

ATM流量整形设置为在远程端以帧访问速度整形，加上信元税。例如，如果接入速度为512 Kbps，则SCR设置为512x53/48 = 565 Kbps。此整形速率用于最大化吞吐量。这是安全的，因为信元税在IW点被取消。运营商端的策略配置很宽，因此允许略微超订用。

cRTP在WAN中使用。就CPU而言，热点是核心站点1的Cisco 3660分布路由器。通过在上表中添加数字，可确定通过此路由器的VoIP呼叫的理论最大数量为102个呼叫。此图中的性能数字表明，100个cRTP会话（快速交换）的Cisco 3660 CPU负载约为50%。

虚拟模板用于IP编号的WAN链路。每条PVC需要一个虚拟模板，这是可能的，因为每条Cisco 3660上终止的PVC总数少于二十五个。

配置

本文档使用以下配置：

• 核心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

相关信息

• 带有服务质量控制（分段、流量整形、LLQ/IP RTP 优先级）的 基于帧中继的VoIP
• 帧中继到 ATM 与LLQ 、PPP LFI 和cRTP 互工作的 VoIP QoS
• 为帧中继和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