Cisco 3825 Mobile Wireless Edge Router Software Configuration Guide
Overview of the Cisco 3825 Mobile Wireless Edge Router
Downloads: This chapterpdf (PDF - 720.0KB) The complete bookPDF (PDF - 8.36MB) | Feedback

Overview of the Cisco 3825 Mobile Wireless Edge Router

Table Of Contents

Overview of the Cisco 3825 Mobile Wireless Edge Router

Introduction

RAN-Optimization Implementation

Cisco Abis and Iub Optimization over IP Implementation

Cisco GSM Abis Optimization over IP

Cisco Pseudowire Emulation Edge-to-Edge (PWE3)

Cisco Iub Optimization over IP

Intelligent Cell Site IP Services

Cell Site Points-of-Presence (POPs)

Cisco IOS Software Features

Software features for the RAN-O Implementation

Software Features

Redundancy Support

Configuration Statements for CISCO-IP-RAN-BACKHAUL-MIB

MIB Support

Limitations and Restrictions

RAN-O Implementation Limitations and Restrictions

Hardware not Supported on the Cisco 3825 Router

UMTS Iub and GSM Abis Implementation Limitations and Restrictions

Hardware not Supported for UMTS Iub

Hardware not Supported for GSM Abis

New Features in Cisco IOS Release 12.4(16)MR2

Keyword ignore-vpi-vci Added to xconnect Command

New Features in Cisco IOS Release 12.4(16)MR1

Emulation of TDM Circuit via MPLS/IP (PWE3/TDM)

Structure-agnostic TDM over Packet (SAToP)

Structure-aware TDM CESoPSN

Transportation of ATM Service via MPLS/IP (PWE3/ATM)

Transparent Cell Transport Service/ATM Port Mode

ATM N-to-One VCC Cell Mode

ATM AAL5 CPCS-SDU Mode

ATM One-to-One VCC Cell Mode

Transportation of ATM Service via L2TPv3

ATM Port Cell Relay Service

ATM VCC Cell Relay Service

ATM AAL5-SDU Mode

Asymmetric PWE3

Ethernet over MPLS

VLAN Mode

Port Mode

PWE3 over MLPPP

PWE3 Redundancy

TDM PWE3 Redundancy

ATM PWE3 Redundancy

Ethernet PWE3 Redundancy

Maximum Number of Supported ATM Ports

ATM Cell Switching

New Features in Cisco IOS Release 12.4(16)MR

GSMmux—Global System for Mobile Communication (GSM) Abis Optimization over IP

UMTSmux—Universal Mobile Telecommunication System (UMTS) Iub Optimization over IP

UMTS Congestion Management Control

Inverse Multiplexing over ATM (IMA)

Permanent Virtual Circuit (PVC) Routing

Behavior Changes

UMTS QoS


Overview of the Cisco 3825 Mobile Wireless Edge Router


The Cisco 3825 Mobile Wireless Edge Router is a networking platform optimized for use in mobile wireless networks; specifically designed to be used at the cell site edge as a part of a 2G, 3G or 4G Radio Access Network (RAN). The Cisco 3825 Mobile Wireless Edge Router is a general purpose router platform specializing in 2/2.5G Global System for Mobile Communication (GSM) and 3G Universal Mobile Telecommunication System (UMTS) RAN backhaul transport and optimization.

The Cisco 3825 router offers high performance at a low cost while meeting the critical requirements for deployment in cell sites, including small size, high availability, and

DC input power flexibility.

This chapter includes the following sections:

Introduction

Cisco IOS Software Features

MIB Support

Limitations and Restrictions

New Features in Cisco IOS Release 12.4(16)MR2

New Features in Cisco IOS Release 12.4(16)MR1

New Features in Cisco IOS Release 12.4(16)MR

Introduction

A typical RAN is composed of thousands of Base Transceiver Stations (BTSs)/Node Bs, hundreds of Base Station Controllers/Radio Network Controllers (BSCs/RNCs), and several Mobile Switching Centers (MSCs). The BTSs/Node Bs and BSCs/RNCs are often separated by large geographic distances, with the BTSs/Node Bs located in cell sites uniformly distributed throughout a region, and the BSCs, RNCs, and MSCs located at suitably chosen central offices (COs) and/or Mobile Telephone Switching Offices (MTSOs). The traffic generated by a BTS/Node B is transported to the corresponding BSC/RNC across a network, referred to as the backhaul network, which is often a hub-and-spoke topology with hundreds of BTSs/Node Bs connected to a given BSC/RNC by point-to-point time-division multiplexing (TDM) trunks. These TDM trunks may be leased line T1/E1s or their logical equivalents, such as microwave links or satellite channels. The interface between the BTS and BSC in GSM and Code Division Multiple Access (CDMA) systems is called the Abis interface. The interface between the Node B and RNC in a UMTS system is called the Iub interface (see Appendix B, "Configuration Examples", for sample configurations.

RAN-Optimization Implementation

In RAN-Optimization (RAN-O), the Cisco 3825 router extends IP connectivity to the cell site and BTS. The router provides bandwidth-efficient IP transport of GSM and UMTS voice and data bearer traffic, as well as maintenance, control, and signaling traffic, over the leased line backhaul network between the BTS and leased line termination and aggregation node via compression (cRTP/cUDP) and packet multiplexing (Multilink PPP).

Figure 1-1 shows an example of the placement of and connections for the Cisco 3825 router in RAN-O.

Figure 1-1 Example of Cisco 3825 Router in a RAN-O

The BTS site consists of a pair of Cisco 3825 routers. The pair of routers provides an active router and a standby router for redundancy. A failure of the active router causes the standby router to take over as the active router for the BTS site.

Each pair of Cisco 3825 routers at the BTS site is identical in hardware configuration. The two routers connect to each other through the Gigabit Ethernet (GE) interfaces. The individual backhaul links to a Cisco 3825 router are cabled from a single T1/E1 termination block in the BTS, connecting to both the active and standby routers by means of a Y cable. The redundancy design to control the active/standby transitions of the router pair leverages Hot Standby Router Protocol (HSRP) to control the relays on the Cisco 2-port T1/E1-RAN interface card, Cisco product number VWIC-2T1/E1-RAN (for more information, see Cisco 2-port T1/E1-RAN Installation Instructions) in each router to ensure that the relays on the active router are closed while the relays on the standby router are open, thus avoiding double termination of the T1 (or E1).

Cisco Abis and Iub Optimization over IP Implementation

One solution that mobile wireless operators find of value is Cisco's ability to optimize RAN backhaul efficiency (see Figure 1-2). For example, Cisco's GSM Abis Optimization solution increases the T1/E1 bandwidth efficiency by as much as 50%. This means the current traffic loads can be carried using half as many T1/E1 trunks as are presently used. This allows more voice and data calls to be carried over the existing RAN backhaul network, eliminating the need for the operator to add expensive new T1/E1 trunks as traffic demands grow. It will also allow a number of existing trunks to be decommissioned, putting an end to their recurring costs.

Another equally important benefit is that substantial excess capacity is now available in the existing RAN backhaul network. The operator can reallocate this recovered bandwidth to carry traffic from other radios, such as UMTS Node Bs, GPRS, EDGE, 1xEV-DO, PWLANs, and other data overlays. This capability reduces the deployment and operating costs for new technologies, since the operator avoids the up-front and recurring costs of supplementing backhaul capacity. It also accelerates time to revenue from deployments of new radio technologies since there is no need for the operator to wait for additional microwave licenses or leased lines to be supplied.

Compliance with 3GPP2 and 3GPP R5 and R6 transport standards is another appealing aspect of Cisco's RAN-O solution. Cisco converts today's CDMA transport networks into 3GPP2-compliant IP RAN transport networks, and GSM and R4/R99 UMTS transport networks into R5/R6 IP RAN transport networks now—and adds multi-radio backhaul compression as well. This means operators can enjoy the benefits of IP transport in their CDMA, GSM, and R4/R99 UMTS RANs today.

Figure 1-2 Example of Cisco 3825 Router in a GSM Abis and UMTS Iub Optimization over IP

Cisco GSM Abis Optimization over IP

The Cisco GSM Abis Optimization over IP technology improves T1/E1 bandwidth efficiency by 33% to 50%, corresponding to a GSM voice call capacity gain of 50-100% per T1/E1, depending on the nature of the traffic on the interface.

In a GSM RAN, the interface between the BTS and BSC is a 3GPP reference interface called the Abis interface. The physical trunk connecting a BTS and BSC is typically a T1 or E1 circuit, and carries 24 (T1) or 32 (E1) separate 64 kbps DS0 channels. One or two of these DS0 channels is used to carry control and signaling traffic, while the remainder are used to carry bearer traffic—voice and data from mobile users. Each DS0 bearer channel carries up to four sub-multiplexed 16 kbps channels, termed sub-rate DS0s. The voice and data bearer traffic is carried over the sub-rate DS0s in Transcoder and Rate Adaptor Unit (TRAU) frames in accordance with 3GPP TS 08.60 v8.2.1, "In-band control of transcoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channels." There are several types of TRAU frames: full-rate (FR) or enhanced full-rate (EFR) GSM vocoder frames; Adaptive Multi-Rate (AMR) vocoder frames; silent speech frames; and OAM frames. When a sub-rate DS0 is assigned to a call, TRAU frames are generated in accordance with 3GPP TS 08.60 v8.2.1, "In-band control of transcoders and rate adaptors for EFR and full rate traffic channels." When a sub-rate DS0 is idle, that is, not assigned to a call, a repeating idle pattern is transmitted in accordance with 3GPP TS 08.54 v8.0.1, "Base Station Controller-Base Transceiver Station (BSC-BTS) interface; Layer 1 structure of physical circuits."

The transcoder and rate adaptation control function that specifies the TRAU frames provides several opportunities to optimize the Abis interface, and thus optimize the backhaul bandwidth efficiency. For example, when Discontinuous Transmission (DTX) is employed over the air interface, the TRAU frames that are transported on the Abis interface contain standardized redundant bit patterns, known as idle (silent) speech frames (FR and EFR) or "no data" frames (AMR), whenever a voice user is silent (typically 40-60% of the time). As another example, bearer channels that are not assigned to calls each carry known idle bit patterns on the Abis interface as mentioned previously. Thus, even though no radio transmissions are made during silent and idle periods, redundant information is nevertheless transported across the backhaul network thereby unnecessarily consuming precious bandwidth.

Cisco Pseudowire Emulation Edge-to-Edge (PWE3)

PWE3 is a mechanism that emulates the essential attributes of a service, such as ATM or EI/T1 (see Figure 1-3). The required functions of pseudowires (PWs) include encapsulating service-specific Packet Data Units (PDUs) arriving at an ingress port and carrying them across a path or tunnel, managing their timing and order, and any other operations required to emulate the behavior and characteristics of the service as efficiently as possible.

PW is perceived as an unshared link or circuit of the chosen service. However, there may be deficiencies that impede some applications from being carried on a PW. These limitations should be fully described in the appropriate service-specific documents and applicability statements.

Cisco supports standards-based PWE3 as defined by:

Structure-agnostic TDM over Packet (SAToP)

Structure-aware TDM CESoPSN

Transportation of ATM Service via MPLS/IP (PWE3/ATM)

Transportation of ATM Service via L2TPv3

A PW is a connection between two provider edge (PE) devices, which connects two attachment circuits (ACs). An AC can be an ATM virtual path identifier/virtual channel identifier (VPI/VCI) or an T1/E1 link.

Figure 1-3 Example of Cisco 3825 Router in a PWE3f

Cisco Iub Optimization over IP

The Cisco Iub Optimization over IP technology for R4/R99 (ATM) UMTS RANs improves bandwidth efficiency by as much as 15 to 40%, corresponding to a UMTS voice call capacity gain of 18 to 67%, depending on the type of Iub header and ATM Adaptation Layer traffic sub-cell multiplexing performance. For R5/R6 IP UMTS RANs, Cisco provides compression and low-overhead encryption.

Intelligent Cell Site IP Services

Cisco's RAN-O solutions also open up the possibility to deliver new profit-enhancing services. This is achieved through the rich set of IP networking features supported in Cisco IOS Software that are now extended to the cell site (see Figure 1-4).

Cell Site Points-of-Presence (POPs)

Since many cell sites are located in and around downtown areas, hotels, airports, and convention centers, they make attractive sites for co-locating public wireless LAN (PWLAN) access points and other wireless data overlays. Many of these wireless data radios are IP-based. IP networking features, like Mobile IP, VoIP, IP Multicast, Virtual Private Network (VPN), and content caching, enable delivery of new revenue-generating services over these radios. Cisco also provides a wide range of low-latency IP-based quality of service (QoS) and traffic shaping models to allow flexible mixing of multiple traffic types across the same backhaul network. Thus, the cell site becomes a physical point of presence or POP from which to offer hotspot services, or voice and wired Internet service provider (ISP) services to nearby enterprises and residences. The corresponding traffic "rides for free" on the spare backhaul bandwidth made available by Cisco's Abis and Iub Optimization solutions.

Figure 1-4 Example of Cisco 3825 Router in a Cell Site POP

Cisco IOS Software Features

There is one version of software available for the Cisco 3825 router. This version of the software is required for implementing the Cisco 3825 router in a Radio Access Network-Optimization (RAN-O) configuration.

Software features for the RAN-O Implementation

The software required for implementing the Cisco 3825 router consists the Cisco IOS software running on the MIPs-based portion of the Cisco 3825 router hardware.

Cisco IOS software functions added to the Cisco 3825 router for the RAN-O implementation include:

Redundancy logic—For monitoring Hot Standby Router Protocol (HSRP) information to determine the active and standby router and control T1 termination.

Failover logic—To force a switchover for hardware failures or an over-temperature condition.

Relay control—To open and close the T1/E1 interfaces on the active and standby routers.

Diagnostic functions—To monitor the "health" of the standby Cisco 3825 router.

Software Features

Standard Cisco IOS software features supported in the Cisco  3825 router for the RAN-O implementation include:

Simple Services

DHCP

PPP

NAT

OSPF

RIP

Intelligent Services

QoS

VPN

IP Multicast

Mobile IP/FA

content caching

MPLS

L2TPv3

Other Services

ACFC and PFC Handling During PPP Negotiation

HSRP

NTP

SNMP

Redundancy Support

In a RAN-O application, to ensure availability, the backhaul links to a Cisco 3825 router are redundantly cabled to the Cisco 2-port T1/E1-RAN card. This card, designed specifically for the Cisco MWR 1941-DC-A router and Cisco 3825 router includes relays that activate the T1/E1 ports. These relays allow "Y" cabling for router redundancy where the T1/E1 link is not redundant and default to open. The relays are controlled by HSRP/redundancy protocol between the two routers connected to the same T1/E1.


Note If you choose to use the Cisco 3825 router in a non-redundant configuration, you must close the relays on the card using the standalone subcommand. Also, redundancy parameters are processed when the router is booted up. These parameters cannot be changed "on the fly."


HSRP

Cisco's HSRP is used to control which router is active and which is standby. HSRP uses a priority scheme to determine which HSRP-configured router is to be the default active router. Priority is determined first by the configured priority value, then by the IP address. In each case, a higher value is of greater priority.

Configuration Statements for CISCO-IP-RAN-BACKHAUL-MIB

This section contains detailed information on how to enable notifications provided by the CISCO-IP-RAN-BACKHAUL-MIB.

With Cisco IOS Release 12.4(16)MR1, the Cisco 3825 router supports the following MIB:

CISCO-IP-RAN-BACKHAUL-MIB

This MIB is compatible with Cisco Mobile Wireless Transport Manager (MWTM) 5.0 or later. It provides information on the optimization on the optimization of the following traffic types:

GSM—providing information between a BTS and the corresponding BSC

UMTS—providing information on optimization between a Node Band the corresponding RNC.

NOTIFICATIONS

ciscoIpRanBackHaulGsmAlarm

Provides information alarms associated with Global System for Mobile Communications (GSM)-Abis interfaces. Only enables GSM Abis. See Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference" for more information.

conf t
snmp-server enable traps ipran alarm-gsm

ciscoIpRanBackHaulUmtsAlarm

Provides information alarms associated with Universal Mobile Telecommunications System (UMTS)-Iub interfaces. Only enables UMTS Iub. See Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference" for more information.

conf t
snmp-server enable traps ipran alarm-umts

ciscoIpRanBackHaulRcvdUtil + ciscoIpRanBackHaulSentUtil

Provides information on backhaul utilization. Only enables backhaul utilization. See Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference" for more information.

conf t
snmp-server enable traps ipran util

Note The snmp-server enable traps ipran util command is obsolete. CLI accepts the command to maintain compatibility.


To specify all notifications, specify the component name. See Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference" for more information.

conf t
snmp-server enable traps ipran

The following configuration statements are used to provide additional information about device and control generation of notifications:

ipran-mib ?

 

 backhaul-notify-interval

Interval for backhaul utilization (Obsolete. Provided only to maintain compatibility.)

 location

Location of device

 snmp-access 

Specify type snmp connectivity

 threshold-acceptable

Acceptable utilization threshold (Obsolete. Provided only to maintain compatibility.)

 threshold-overloaded

Overloaded utilization threshold (Obsolete. Provided only to maintain compatibility.)

 threshold-warning

Warning utilization threshold (Obsolete. Provided only to maintain compatibility.)

ipran-mib backhaul-notify-interval

 

 

For more information on these commands, see Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference".

MIB Support

The Cisco 3825 router supports the following MIBs:

ADSL-DMT-LINE-MIB

ADSL-LINE MIB

ATM-MIB

BRIDGE-MIB

CISCO-AAA-SERVER-MIB

CISCO-AAL5-MIB

CISCO-ACCESS-ENVMON-MIB

CISCO-ATM-EXT-MIB

CISCO-ATM-PVCTRAP-EXTN-MIB

CISCO-BULK-FILE-MIB

CISCO-CALL-APPLICATION-MIB

CISCO-CALL-HISTORY-MIB

CISCO-CAR-MIB

CISCO-CAS-IF-MIB

CISCO-CCME-MIB

CISCO-CDP-MIB

CISCO-CIRECUIT-INTERFACE-MIB

CISCO-CLASS-BASED-QOS-MIB

CISCO-CONFIG-MAN-MIB

CISCO-DIAL-CONTROL-MIB

CISCO-DSL-CPE-MIB

CISCO-ENTITY-ASSET-MIB

CISCO-ENTITY-EXT-MIB

CISCO-ENTITY-VENDORTYPE-OLD-MIB

CISCO-ENVMON-MIB

CISCO-FLASH-MIB

CISCO-FRAME-RELAY-MIB

CISCO-FTP-CLIENT-MIB

CISCO-HSRP-MIB

CISCO-ICSUDSU-MIB

CISCO-IETF-ATM2-PVCTRAP-MIB-EXTN

CISCO-IETF-ATM2-PVCTRAP-MIB

CISCO-IETF-NAT-MIB

CISCO-IETF-PW-MIB

CISCO-IETF-PW-MPLS-MIB

CISCO-IETF-PW-TC-MIB

CISCO-IF-EXTENSION-MIB

CISCO-IMAGE-MIB

CISCO-IP-RAN-BACKHAUL-MIB

CISCO-IPMROUTE-MIB

CISCO-MEMORY-POOL-MIB

CISCO-MVPN-MIB

CISCO-NBAR-PROTOCOL-DISCOVERY-MIB

CISCO-NETFLOW-MIB

CISCO-NTP-MIB

CISCO-PIM-MIB

CISCO-PING-MIB

CISCO-POP-MGMT-MIB

CISCO-PPPOE-MIB

CISCO-PROCESS-MIB

CISCO-QUEUE-MIB

CISCO-RTTMON-MIB

CISCO-SAA-APM-MIB

CISCO-SMI

CISCO-SNAPSHOT-MIB

CISCO-SNMP--TARGET-EXT-MIB

CISCO-SRST-MIB

CISCO-STACKMAKER-MIB

CISCO-SYSLOG-MIB

CISCO-TC


CISCO-TCP-MIB

CISCO-VLAN-IFTABLE-RELATIONSHIP-
MIB

CISCO-VLAN-MEMBERSHIP-MIB

CISCO-VOICE-ANALOG-IF-MIB

CISCO-VOICE-ATM-DIAL-CONTROL-MIB

CISCO-VOICE-COMMON-DIAL-CONTROL-
MIB

CISCO-VOICE-DIAL-CONTROL-MIB

CISCO-VOICE-DNIS-MIB

CISCO-VOICE-ENABLED-LINK-MIB

CISCO-VOICE-FR-DIAL-CONTROL-MIB

CISCO-VOICE-IF-MIB

CISCO-VOICE-NUMBER-EXPANSION-MIB

CISCO-VOICE-URI-CLASS-MIB

CISCO-VPDN-MGMT-EXT-MIB

CISCO-VPDN-MGMT-MIB

CISCO-VTP-MIB

DIAL-CONTROL-MIB

DS1-MIB

DS3-MIB

ETHERLIKE-MIB

EVENT-MIB

EXPRESSION-MIB

IF-MIB

IGMP-MIB

IMA-MIB

INT-SERV-GUARANTEED-MIB

INT-SERV-MIB

IP-FORWARD-MIB

ISDN-MIB

MSDP-MIB

OLD-CISCO-CHASSIS-MIB

OLD-CISCO-FLASH-MIB

OLD-CISCO-INTERFACES-MIB

OLD-CISCO-IP-MIB

OLD-CISCO-SYS-MIB

OLD-CISCO-TCP-MIB

OLD-CISCO-TS-MIB

OSPF-MIB

OSPF-TRAP-MIB

PIM-MIB

RFC1213-MIB

RFC1231-MIB

RFC1315-MIB

RFC1406-MIB

RMON-MIB

RS-232-MIB

RSVP-MIB

SMON-MIB

SNMP-TARGET-MIB

SONET-MIB

TCP-MIB

UDP-MIB

VRRP-MIB

XGCP-MIB


Limitations and Restrictions

The following restrictions applies when using the Cisco 2-port T1/E1-RAN interface card in the Cisco 3825 router:


Caution The Cisco 3825 router does not support online insertion and removal (OIR) of the Cisco 2-port T1/E1-RAN interface card. Any attempt to perform OIR on a card in a powered up router might cause damage to the card.


Caution The Cisco 3825 router does not support OIR of network modules. Any attempt to perform OIR on a card in a powered up router might cause damage to the card.


Note The Cisco NM-2W network interface module only is only supported on the Cisco 3825 router on shorthaul with or without Inverse Multiplexing over ATM (IMA). It is not supported on the Cisco 3825 router on shorthaul with GSM.


RAN-O Implementation Limitations and Restrictions

The following list of restrictions applies when implementing the Cisco 3825 router in a Radio Access Network-Optimization (RAN-O) configuration.

Hardware not Supported on the Cisco 3825 Router

Use of additional voice/WAN interface card (VWIC) cards. The only supported VWIC is the Cisco 2-port T1/E1-RAN.

UMTS Iub and GSM Abis Implementation Limitations and Restrictions

The following list of restrictions applies when implementing the UMTS Iub or GSM Abis application in a RAN-O configuration.

Hardware not Supported for UMTS Iub

The Cisco MWR 1941-DC router does not support UMTS Iub as it does not include the Advanced Integration Module (AIM) slot connector on the motherboard. Only the Cisco MWR 1941-DC-A router and Cisco 3825 router are supported for UMTS Iub.

Hardware not Supported for GSM Abis

The Network Interface Module (NM-2W) does not support GSM Abis as the HDLC Controller channel does not interface with the NM-2W. GSM Abis is only supported through the Cisco 2-port T1/E1-RAN card through the four voice/WAN interface card (VWIC) ports on the Cisco 3825 router (see Figure 1-5).

Figure 1-5 Example of Cisco 3825 Router VWIC and NM-2W Configuration Options Block Diagram

New Features in Cisco IOS Release 12.4(16)MR2

With Cisco IOS Release 12.4(16)MR2, the Cisco MWR 1941-DC-A router supports the following feature:

Keyword ignore-vpi-vci Added to xconnect Command

Keyword ignore-vpi-vci Added to xconnect Command

With the ignore-vpi-vci keyword configured, the MWR ignores the VPI/VCI value in the PW packet and does a blind rewrite with the local configured AC-side PVC's VPI/VCI value. This applies only when the xconnect command is configured under the PVC, which is the N:1 with N=1 special case. It does not apply when the xconnect command is configured under the subinterface, which supports N>1.

The xconnect command with keyword ignore-vpi-vci results in the PVC mapping being done in a cooperative way if the MWR works the same way as the receiving router. Without this command, the MWR checks the VPI/VCI value inside PW packet for matches against the local configured PVC or PVC-mapping. With the ignore-vpi-vci keyword configured, the MWR ignores the VPI/VCI header inside the received PW packet and does a blind rewrite with the local configured AC-side PVC's VPI/VCI value.

New Features in Cisco IOS Release 12.4(16)MR1

With Cisco IOS Release 12.4(16)MR1, the Cisco 3825 router supports the following:

Emulation of TDM Circuit via MPLS/IP (PWE3/TDM)

Structure-agnostic TDM over Packet (SAToP)

Structure-aware TDM CESoPSN

Transportation of ATM Service via MPLS/IP (PWE3/ATM)

Transparent Cell Transport Service/ATM Port Mode

ATM N-to-One VCC Cell Mode

ATM AAL5 CPCS-SDU Mode

ATM One-to-One VCC Cell Mode

Transportation of ATM Service via L2TPv3

ATM Port Cell Relay Service

ATM VCC Cell Relay Service

ATM AAL5-SDU Mode

Asymmetric PWE3

Ethernet over MPLS

VLAN Mode

Port Mode

PWE3 over MLPPP

PWE3 Redundancy

TDM PWE3 Redundancy

ATM PWE3 Redundancy

Ethernet PWE3 Redundancy

Maximum Number of Supported ATM Ports

ATM Cell Switching

Emulation of TDM Circuit via MPLS/IP (PWE3/TDM)

PWE3 is a mechanism that emulates the essential attributes of a T1/E1 line over a packet-switched network (PSN). This evolutionary technology allows you to migrate all packet networks from legacy TDM networks, yet provides transport for legacy applications. PWE3/TDM emulates T1/E1 unstructured and structured lines, including NxDS0 circuits over a Multiprotocol Label Switching (MPLS) infrastructure.

Configuration for provisioning and creating the PW is done through the existing xconnect interface.

A new command cem-group has been added to this feature to create a circuit emulation (CEM) channel from one or more time slots of T1/E1.

The group-number keyword identifies the group number used for this channel.

For T1 controller, the range is 0-23. (24 cem-groups id)

For E1 controller, the range is 0-30. (30 cem-groups id)

Use the unframed keyword to specify that a single CEM channel is being created, including all time slots with no framing structure defined. If time slots are defined, the PWE3 circuit is circuit emulation service over packet-switched network (CESoPSN).

Use the time slots keyword and the timeslot-range argument to specify the time slots to be included in the CEM channel. The list of time slots may include commas and hyphens with no spaces between the numbers, commas, and hyphens.

The following example illustrates the use of the cem-group command:

SATOP

	controller el 0/0/0
	 cem-group 0 unframed

	int cem 0/0/0
	 cem 0
	  xconnect 10.10.10.10 200 encap mpls

CESoPSN

	controller e1 0/0/1
	 cem-group 0 timeslots 1-31

	int cem 0/0/1
	 cem 0
	  xconnect 10.10.10.10 200 encap mpls

A new command sample-rate has been added to this feature to specify in milliseconds the rate that hardware samples data on the attached circuit.

The default is 1 ms. The sample-rate command translates into the payload-size that is sent over the circuit.

32-time slots at 1 ms = 256-bytes (32-time slots * 8-bytes/timeslot/ms)

24-time slots at 2 ms = 384-bytes (24-time slots * 16-bytes/timeslot/ms)

10-time slots at 1 ms = 80-bytes (10-time slots * 8-bytes/timeslot/ms)

The following example illustrates the use of the sample-rate command:

	interface CEM0/0/0
	no ip address
	cem 0
	 sample-rate 2
	 xconnect 10.10.10.10 200 encapsulation mpls

A new command dejitter-buffer has been added to this feature to specify the size of the dejitter-buffer used to compensate for the network jitter.

Use the size argument to specify the size of the buffer in milliseconds.

Size can vary from 4 - 500 ms; default is 4 ms.

The following example illustrates the use of the dejitter-buffer command:

	interface CEM0/0/0
	no ip address
	cem 0
  	 dejitter-buffer 10
	 xconnect 10.10.10.10 200 encapsulation mpls

A new command idle-pattern has been added to this feature to specify the data pattern transmitted on the T1/E1 when missing packets are detected on the PWE3 circuit.

The default idle-pattern command is 0xFF.

The following example illustrates the use of the idle-pattern command:

	interface CEM0/0/0
	no ip address
	cem 0
  	 idle-pattern 0x55
  	 xconnect 10.10.10.10 200 encapsulation mpls

A new command shutdown has been added to this feature to administratively shut down the CEM channel.

Default: cem channel is created in a "no shut" state.

The following example illustrates the use of the shutdown command:

	interface CEM0/0/0
	no ip address
	cem 0
  	 shutdown
  	 xconnect 10.10.10.10 200 encapsulation mpls

A new command class cem has been added to this feature to allow CEM interface parameters to be configured in a class and applied to CEM interfaces together. This command works in the same manner for CEM interfaces as the pseudowire-class command does for xconnect.

The following example illustrates the use of the class cem command:

	class cem mycemclass
	dejitter-buffer 10
	sample-rate 2

	interface CEM0/0/0
	no ip address
	cem 0
  	 xconnect 10.10.10.10 200 encapsulation mpls
  	 cem class mycemclass

Structure-agnostic TDM over Packet (SAToP)

SAToP encapsulates TDM bit-streams (T1, E1, T3, E3) as PWs over PSNs. It disregards any structure that may be imposed on streams, in particular the structure imposed by the standard TDM framing.

The protocol used for emulation of these services does not depend on the method in which attachment circuits are delivered to the PEs. For example, a T1 attachment circuit is treated in the same way regardless of whether it is delivered to the PE on copper, multiplexed in a T3 circuit, mapped into a virtual tributary of a SONET/SDH circuit, or carried over an ATM network using unstructured ATM circuit emulation service (CES) [ATM-CES]. Termination of any specific "carrier layers" used between the PE and CEM is performed by an appropriate network service provider (NSP).

Structure-aware TDM CESoPSN

CESoPSN encapsulates structured (NxDS0) TDM signals as PWs over PSNs. It complements similar work for structure-agnostic emulation of TDM bit-streams, such as PWE3-SAToP.

Emulation of NxDS0 circuits saves PSN bandwidth and supports DS0-level grooming and distributed cross-connect applications. It also enhances resilience of CE devices to the effects of loss of packets in the PSN.

Transportation of ATM Service via MPLS/IP (PWE3/ATM)

An ATM PW is used to carry ATM cells over an MPLS network. It is an evolutionary technology that allows you to migrate all packet networks from legacy ATM networks, yet provides transport for legacy applications.

Configuration for provisioning and creating the PW is done through the existing xconnect command.

The following PW modes are supported in this release:

Transparent Cell Transport Service/ATM Port Mode

ATM N-to-One VCC Cell Mode

ATM AAL5 CPCS-SDU Mode

ATM VCC Cell Relay Service

The following examples illustrates how different modes of PWs are configured.

Transparent Cell Transport Service/ATM Port Mode

ATM port mode maps the entire ATM interface to a PW. Use the xconnnect command under the interface mode to configure a port mode PW.

A sample configuration is written as follows:

	interface ATM0/0/0
	 no ip address
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 atm cell-packing 28 mcpt-timer 3
	 xconnect 99.99.99.99 100 encapsulation mpls sequencing both
	 pvc 1/35 l2transport
	  encapsulation aal0
	!
	 pvc 1/36 l2transport
	  encapsulation aal0
	!
	 pvc 1/37 l2transport
	  encapsulation aal0
	!

ATM N-to-One VCC Cell Mode

ATM N:1 VCC cell relay mode maps one or more permanent virtual circuits (PVCs) to one PW. There are two ways to configure N:1 VCC in cell relay mode:

1. When only one PVC needs to be mapped to a PW, configure the xconnect command under the PVC mode to configure a N:1 VCC cell relay mode PW.

A sample configuration is written as follows:

	interface ATM0/0/1
	 no ip address
	 load-interval 30
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 pvc 0/101 l2transport
	  encapsulation aal0
	  cell-packing 28 mcpt-timer 3
	  xconnect 99.99.99.99 1101 encapsulation mpls sequencing both
	!

2. When more than one PVC needs to be mapped to a PW, configure the xconnect command under the subinterface mode to configure N:1 VCC cell in relay mode PW. All PVCs configured under this subinterface are mapped to the PW.

A sample configuration is written as follows:

	interface ATM0/0/1.1 multipoint
	 no snmp trap link-status
	 atm cell-packing 28 mcpt-timer 3
	 xconnect 99.99.99.99 1200 encapsulation mpls sequencing both
	 pvc 1/35 l2transport
	  encapsulation aal0
	!
	 pvc 1/36 l2transport
	  encapsulation aal0
	!
	 pvc 1/37 l2transport
	  encapsulation aal0

ATM AAL5 CPCS-SDU Mode

ATM adaptation layer 5 (AAL5) SDU mode maps one AAL5 type PVC to a PW. Use the xconnect command under an AAL5 encapsulation type PVC to configure AAL5 SDU mode PW.

A sample configuration is written as follows:

	interface ATM0/0/1
	 no ip address
	 load-interval 30
	 scrambling-payload
	 no atm ilmi-keepalive
	 pvc 0/100 l2transport
	  encapsulation aal5
	  xconnect 99.99.99.99 1100 encapsulation mpls sequencing both
	!

ATM One-to-One VCC Cell Mode

ATM 1:1 VCC cell relay mode maps one PVC to a PW. Use a one-to-one keyword in the xconnect command mode to specify a 1:1 VCC relay mode PW.

A sample configuration is written as follows:

	interface ATM0/0/1
	 no ip address
	 load-interval 30
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 pvc 0/102 l2transport
	  encapsulation aal0
	  cell-packing 28 mcpt-timer 3
	  xconnect 99.99.99.99 1102 encapsulation mpls sequencing both one-to-one
	 !

Cell Packing

Cell packing or concatenation supports Port, N:1 VCC cell, or 1:1 VCC cell mode. Cell packing can be configured with a parameter of a maximum number of cells and a parameter of cell packing timer.

"atm mcpt-timers [timer1] [timer2] [timer3]" can be used under the interface mode to configure three cell packing timer values. Timer values are in microseconds, and the granularity is 1,000 microseconds, namely 1 millisecond. The timer value is referenced by the "atm cell-packing ..." and "cell-packing ..." commands.

The sample below configures cell packing for ATM port modes. It specifies a maximum number of cells as 28 and a cell packing timer as 3,000 microseconds.

	interface ATM0/0/0
	 no ip address
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 atm cell-packing 28 mcpt-timer 3
	 xconnect 99.99.99.99 100 encapsulation mpls sequencing both
	 pvc 1/35 l2transport
	  encapsulation aal0
	 !
	 pvc 1/36 l2transport
	  encapsulation aal0
	 !
	 pvc 1/37 l2transport
	  encapsulation aal0
	 !

The sample below configures cell packing for the N:1 VCC cell relay mode PW. It specifies a maximum number of cells as 20 and a cell packing timer as 4,000 microseconds.

	interface ATM0/0/1
	 no ip address
	 load-interval 30
	 scrambling-payload
	 atm mcpt-timers 2000 3000 4000 
	 no atm ilmi-keepalive
	 pvc 0/101 l2transport
	  encapsulation aal0
	  cell-packing 20 mcpt-timer 3
	  xconnect 99.99.99.99 1101 encapsulation mpls sequencing both

PVC Mapping

The pw-pvc command configures PVC mapping or rewrites for PW-configured PVCs. It specifies the PW-side vpi/vci value used in sending and receiving PW packets for specified PVCs.

The following example illustrates the use of the pw-pvc command:

	pvc 0/40 l2transport
	 encapsulation aal0
	 pw-pvc 1/40
	 xconnect 1.1.1.1 40 encapsulation mpls

Transportation of ATM Service via L2TPv3

This service transports ATM services over IP networks. It allows you to migrate all PSNs from ATM legacy networks while still providing ATM legacy services.

The following PW modes are supported in this release:

ATM Port Cell Relay Service

ATM VCC Cell Relay Service

ATM AAL5-SDU Mode

Configuring Layer 2 Tunnel Protocol version 3 (L2TPv3)-based PWs is very similar to configuring MPLS-based PWs, except that a pseudowire-class command is required to be configured for L2TPv3-based PWs.

A sample configuration of the L2TPv3 pseudowire-class command is written as follows:

	pseudowire-class l2tp
	 encapsulation l2tpv3
	 sequencing both
	 ip local interface Loopback0

ATM Port Cell Relay Service

ATM port mode maps the entire ATM interface to a PW. Use the xconnnect command under the interface mode to configure a port mode PW. The ATM interface maps to the PW.

A sample configuration is written as follows:

	interface ATM0/0/0
	 no ip address
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 atm cell-packing 28 mcpt-timer 3
	 xconnect 99.99.99.99 100 pw-class l2tp
	 pvc 1/35 l2transport
	  encapsulation aal0
	 !
	 pvc 1/36 l2transport
	  encapsulation aal0
	 !
	 pvc 1/37 l2transport
	  encapsulation aal0
	 !
	!

ATM VCC Cell Relay Service

ATM N:1 VCC cell relay mode maps one or more PVCs to one PW. There are two ways to configure N:1 VCC in cell relay mode:

1. When only one PVC needs to be mapped to the PW, configure the xconnect command under the PVC mode to configure a N:1 VCC cell relay mode PW.

A sample configuration is written as follows:

	interface ATM0/0/1
	 no ip address
	 load-interval 30
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 pvc 0/101 l2transport
	  encapsulation aal0
	  cell-packing 28 mcpt-timer 3
	  xconnect 99.99.99.99 1101 pw-class l2tp
	 !

2. When more than one PVC needs to be mapped to a PW, configure the xconnect command under the subinterface mode to configure a N:1 VCC cell relay mode PW. All PVCs configured under this subinterface are mapped to the PW.

A sample configuration is written as follows:

	interface ATM0/0/1.1 multipoint
	 no snmp trap link-status
	 atm cell-packing 28 mcpt-timer 3
	 xconnect 99.99.99.99 1200 pw-class l2tp
	 pvc 1/35 l2transport
	  encapsulation aal0
	  pw-pvc 2/135
	 !
	 pvc 1/36 l2transport
	  encapsulation aal0
	  pw-pvc 2/136
	 !
	 pvc 1/37 l2transport
	  encapsulation aal0
	  pw-pvc 2/137
	 !
	!

ATM AAL5-SDU Mode

ATM AAL5-SDU mode maps one AAL5 type PVC to a PW. Use the xconnect command under an AAL5 encapsulation type PVC to configure a AAL5-SDU mode PW.

A sample configuration is written as follows:

	interface ATM0/0/1
	 no ip address
	 load-interval 30
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 pvc 0/100 l2transport
	  encapsulation aal5
	  xconnect 99.99.99.99 1100 pw-class l2tp
	 !

Cell Packing

Cell packing or concatenation supports Port, N:1 VCC cell, or 1:1 VCC cell mode. Cell packing can be configured with a parameter of a maximum number of cells and a parameter of cell packing timer.

"atm mcpt-timers [timer1] [timer2] [timer3]" can be used under the interface mode to configure three cell packing timer values. Timer values are in microseconds, and the granularity is 1,000 microseconds, namely 1 millisecond. The timer value is referenced by the "atm cell-packing ..." and "cell-packing ..." commands.

The sample below configures cell packing for ATM port modes. It specifies a max number of cells as 28 and a cell packing timer as 3,000 microseconds.

	interface ATM0/0/0
	 no ip address
	 scrambling-payload
	 atm mcpt-timers 1000 2000 3000 
	 no atm ilmi-keepalive
	 atm cell-packing 28 mcpt-timer 3
	 xconnect 99.99.99.99 100 pw-class l2tp
	 pvc 1/35 l2transport
	  encapsulation aal0
	 !
	 pvc 1/36 l2transport
	  encapsulation aal0
	 !
	 pvc 1/37 l2transport
	  encapsulation aal0
	 !

The sample below configures cell packing for the N:1 VCC cell relay mode. It specifies a maximum number of cells as 20 and a cell packing timer as 4,000 microseconds.

	interface ATM0/0/1
	 no ip address
	 load-interval 30
	 scrambling-payload
	 atm mcpt-timers 2000 3000 4000 
	 no atm ilmi-keepalive
	 pvc 0/101 l2transport
	  encapsulation aal0
	  cell-packing 20 mcpt-timer 3
	  xconnect 99.99.99.99 1101 pw-class l2tp

PVC Mapping

The pw-pvc command configures PVC mapping or rewrites for PW-configured PVCs. It specifies the PW-side vpi/vci value used in sending and receiving specific PVCs.

The following example illustrates the use of PW packets for the pw-pvc command:

	pvc 0/40 l2transport
	 encapsulation aal0
	 pw-pvc 1/40
	 xconnect 1.1.1.1 40 pw-class l2tp

Asymmetric PWE3

This feature uses two different MPLS enabled IP routes in uplink and downlink directions for creating an asymmetric backhaul path between two Mobile Wireless Routers (MWRs) acting as provider edge (PE) routers.

For ATM over L2TPV3, this feature uses two different IP routes in uplink and downlink directions for creating an asymmetric backhaul path between two MWRs acting as end points for an L2TPV3 tunnel.

No special configuration is needed for this feature apart from configuring the IP routes and having multiple backhaul paths available between two MWRs.

For a configuration example, see the "Asymmetric PWE3 Configuration" section on page B-2 in Appendix B.

Ethernet over MPLS

The Ethernet over MPLS feature allows you to transport Ethernet traffic over MPLS networks. This feature can be configured in the following two ways:

VLAN Mode

A VLAN is a switched network that is logically segmented by functions, project teams, or applications regardless of the physical location of users.

To connect two VLAN networks in different locations, configure the PE routers at each end of the MPLS backbone and add a point-to-point virtual connection (VC). Only two PE routers at the ingress and egress points of the MPLS backbone have dedicated VCs to transport Layer 2 VLAN traffic.

Ethernet over MPLS in VLAN mode transports Ethernet traffic from a source 802.1Q VLAN to a destination 802.1Q VLAN over a core MPLS network.

The following example configures Ethernet in VLAN mode:

Router> enable 
Router# configure terminal 
Router(config)# interface gigabitethernet 0/0.1 
Router(config-subif)# encapsulation dot1q 100 
Router(config-subif)# xconnect 10.0.0.1 123 encapsulation mpls

Note Ethernet over MPLS in VLAN mode must be configured on subinterfaces.


Port Mode

Port mode allows a frame coming into an interface to be packed into an MPLS packet and transported over the MPLS backbone to an egress interface. The entire Ethernet frame without the preamble or a frame check sequence (FCS) is transported as a single packet.

To configure in port mode, use the xconnect command in the interface configuration mode and specify the destination address and the VC ID. The syntax of the xconnect command is the same for all other transport types. Each interface is associated with one unique PW VC label.

When configuring Ethernet over MPLS in port mode, use the following guidelines:

The pseudowire (PW) VC type is set to Ethernet.

Port mode and Ethernet VLAN mode are mutually exclusive. If you enable a main interface for port-to-port transport, you cannot also enter commands on a subinterface.


The command output in the following example shows two VCs for Ethernet over MPLS:

Router# show mpls l2transport vc 
Local intf     Local circuit        Dest address    VC ID      Status    
-------------  -------------------- --------------- ---------- ----------
Fa0/0.1 				Eth VLAN 2           10.1.1.1        2          UP        
Fa0/1				Ethernet 					 10.1.1.1        8          UP 

VC 2 is in Ethernet VLAN mode. VC 8 is in Ethernet port mode.

If you issue the show mpls l2transport vc detail command, the output is similar to the following:

Router# show mpls l2transport vc detail
Local interface: Fa0/0.1 up, line protocol up, Eth VLAN 2 up
Destination address: 10.1.1.1, VC ID: 2, VC status: up
.
.
.
Local interface: Fa0/1 up, line protocol up, Ethernet up
  Destination address: 10.1.1.1, VC ID: 8, VC status: up

PWE3 over MLPPP

PWE3 over MLPPP (Multi-Link Point-to-Point Protocol) enables PWE3 establishment over multilink backhaul. With this feature it is possible to use multilink as an MPLS or L2TPV3 (for ATM over L2TPv3) enabled backhaul between two MWRs acting as PE routers. This feature does not need any special configuration apart from enabling MPLS on MLPPP and using an MLPPP ip address for ip routing between two MWRs acting as PE routers.

Existing command MPLS IP has been added to this feature to enable MPLS forwarding of IPv4 packets along normally routed paths for a designated interface.

The following example illustrates that label switching is enabled on a designated Ethernet interface:

Router# configure terminal
Router(config)# interface multilink1
Router(config-if)# mpls ip

PWE3 Redundancy

The PWE3 Redundancy feature enables you to configure your network to detect a failure in the network and reroute the Layer 2 (L2) service to another endpoint that can continue to provide service. This feature provides the ability to recover from a failure of the PE router or the link between the PE and the CE router.

Existing command backup peer has been added to this feature to specify a redundant peer for a PW VC.

Existing command backup delay has been added to this feature to specify how long a backup PW VC should wait before resuming operation after the primary PW VC goes down.

Existing command xconnect logging redundancy has been added to this feature to enable system message log (syslog) reporting of the status of the xconnect redundancy group.

The following example enables syslog reporting of the status of the xconnect redundancy group and shows the messages that are generated during switchover events:

Router(config)# xconnect logging redundancy

Activating the Primary Member

00:01:07: %XCONNECT-5-REDUNDANCY: Activating primary member 10.55.55.2:1000

Activating the Backup Member:

00:01:05: %XCONNECT-5-REDUNDANCY: Activating secondary member 10.55.55.3:1001

TDM PWE3 Redundancy

The following examples illustrate the use of the backup peer command:

PW Redundancy Without PW Class

	interface CEM0/0/0
 	 no ip address
 	 cem 0
  	  xconnect 2.2.2.2 100 encapsulation mpls
   	   backup peer 2.2.2.2 200 
   	   backup delay 20 20

PW Redundancy With PW Class

 
	pseudowire-class pw_redundancy
 	 encapsulation mpls

	interface CEM0/0/0
	 no ip address
	 cem 0
	  xconnect 2.2.2.2 100 encapsulation mpls
	   backup peer 2.2.2.2 200 pw-class pw_redundancy
	   backup delay 20 20

ATM PWE3 Redundancy

The following examples illustrate the use of the backup delay command:

PW Redundancy Without PW Class

	interface ATM0/0/0
	 no ip address
	 xconnect 2.2.2.2 300 encapsulation mpls
	  backup peer 2.2.2.2 400 
	  backup delay 20 20

PW Redundancy With PW Class

	pseudowire-class pw_redundancy
	 encapsulation mpls

	interface ATM0/0/0
	 no ip address
	  xconnect 2.2.2.2 300 encapsulation mpls
	   backup peer 2.2.2.2 400 pw-class pw_redundancy
	   backup delay 20 20 

Ethernet PWE3 Redundancy

The following examples illustrate the use of the xconnect logging redundancy command:

PW Redundancy Without PW Class

	interface GigabitEthernet 0/0
	 xconnect 2.2.2.2 500 encapsulation mpls 
	  backup peer 2.2.2.2 600 
	  backup delay 20 20

PW Redundancy With PW Class

	pseudowire-class pw_redundancy
	 encapsulation mpls

	interface GigabitEthernet 0/0
	  xconnect 2.2.2.2 500 encapsulation mpls 
	  backup peer 2.2.2.2 600 pw-class pw_redundancy
	  backup delay 20 20 

Maximum Number of Supported ATM Ports

This enhancement increases the maximum number of supported ATM ports on the Cisco 3825 router.

The maximum number of ATM ports supported on the AIM-ATM-8 depends on the slot in which the AIM-ATM-8 is installed:

AIM-ATM-8 installed in slot 0—maximum of 12 ATM ports supported

AIM-ATM-8 installed in slot 1—maximum of 8 ATM ports supported

The ATM-AIM module still supports a maximum of 4 ATM ports.

ATM Cell Switching

This feature provides PVC-to-PVC cell switching on the Cisco 3825 router.

The feature includes PVC remapping within either an AIM-ATM module or AIM-ATM-8 module. Also, the feature is available for PVC-to-PVC switching between ATM interfaces and/or ATM IMA groups. Note that PVC values must be above the well-known virtual path identifier/virtual channel identifier (VPI/VCI) range (0/32).

The following configuration snippet shows a connection from ATM0/0/0 to ATM0/0/1. The PVC is mapped from 0/32 to 0/33 and vice versa.

	controller E1 0/0/0
	 mode atm aim 1
	!
	controller E1 0/0/1
	 mode atm aim 1
	!
	interface ATM0/0/0
	 pvc 0/32 12transport
	!
	interface ATM0/0/1
	 pvc 0/33 12transport
	!
	connection NAME a0/0 0/32 a0/1 0/33

Privileged EXEC commands of interest include:

Router# show connection ?
all

All Connections

elements

Show Connection Elements

id

ID Number

name

Connection Name

port

Port Number


 

New Features in Cisco IOS Release 12.4(16)MR

With Cisco IOS Release 12.4(16)MR, the Cisco 3825 router supports the following:

GSMmux—Global System for Mobile Communication (GSM) Abis Optimization over IP

UMTSmux—Universal Mobile Telecommunication System (UMTS) Iub Optimization over IP

UMTS Congestion Management Control

Inverse Multiplexing over ATM (IMA)

Permanent Virtual Circuit (PVC) Routing

UMTS QoS

GSMmux—Global System for Mobile Communication (GSM) Abis Optimization over IP

The Cisco GSM Abis Optimization and Iub Optimization solutions can optimize the excess capacity that exists in the current RAN backhaul network. This eliminates the need to add new T1/E1 trunks to meet growing demand and can even allow a number of existing trunks to be decommissioned.

The Cisco GSM Abis Optimization over IP technology improves T1/E1 bandwidth efficiency by 33% to 50%, corresponding to a GSM voice call capacity gain of 50-100% per T1/E1, depending on the nature of the traffic on the interface.

UMTSmux—Universal Mobile Telecommunication System (UMTS) Iub Optimization over IP

The Cisco Iub Optimization over IP technology for R4/R99 (ATM) UMTS RANs improves bandwidth efficiency by as much as 15 to 40%, corresponding to a UMTS voice call capacity gain of 18 to 67%, depending on the type of Iub header and ATM Adaptation Layer traffic sub-cell multiplexing performance. For R5/R6 IP UMTS RANs, Cisco provides compression and low-overhead encryption.

UMTS Congestion Management Control

The purpose of Congestion management control is to protect the most important traffic when congestion happens. Typically signaling and voice traffic are configured as the highest priority in QoS, and usually you do not expect these two types of combined traffic to congest the backhaul. But, if it does happen, some traffic will be dropped. The QoS on the Cisco 3825 router does not differentiate between signaling and voice traffic, which means the packets will drop randomly. Dropping signaling traffic could have much more severe results than voice traffic. If the RNC and Node B lose signaling communication, the Node B device could be reset. Signaling traffic needs to be passed through during this time. Congestion management control throttles any other traffic but the signaling traffic, thus leaving the backhaul resource for signaling traffic.

Typically, UMTS Congestion Management Control protects the most important PVC traffic (usually signalling pvc) during backhaul congestion. Each PVC can be configured with a congestion priority. There are nine congestion control priority levels, protected and priority 2- 9. The protected priority has the highest priority and priority 9 has the lowest priority.

When congestion happens, all other PVC traffic except protected PVC(s) traffic will be throttled to save the backhaul resource for the protected PVC traffic. If after a certain period (200 ms) and there is no congestion reported, a recovery mechanism is triggered. Recovery gradually includes back throttled PVC traffic in the order of their congestion control priority level (priority 2 being first and 9 being last). Recovery will unthrottle the traffic gradually every until all traffic is recovered or congestion happens again.

It is recommended that you configure UMTS QoS as your first line of defense when congestion happens so that the low priority/best effort traffic be dropped by the QoS during congestion. Congestion control will be triggered when combining priority traffic (signalling and voice) congested backhaul, and it will throttle relatively less important traffic (voice) to protect most important traffic (signaling) based on the congestion control priority configuration.

With UMTS Congestion Management Control, you can configure the UMTS congestion based on priority. Two new commands (umts-iub congestion priority and umts-iub congestion-control) are added using the PVC Configuration mode and Interface Configuration mode, respectively (see Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference").

interface ATM0/IMA0
 no ip address
 atm bandwidth dynamic
 atm umts-iub
 no atm ilmi-keepalive
 pvc 2/1 qsaal
  umts-iub congestion priority protected
 !
 pvc 2/2 
  encapsulation aal0
  umts-iub congestion priority protected
 !
 pvc 3/1 
  encapsulation aal0
  umts-iub congestion priority 4
 !
 pvc 3/2 
  encapsulation aal0
  umts-iub congestion priority 5
 !
 pvc 3/100 
  encapsulation aal2
 !
 umts-iub congestion-control
 umts-iub set dscp 8
 umts-iub set peering dscp 8
 umts-iub local 20.20.20.21 6666
 umts-iub remote 20.20.20.20 6666

One new CLI Show command show umts congestion atm slot/port has been added to this feature and a new field has been added to the show umts-iub peering command (see Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference").

The following example illustrates the use of show umts congestion atm.

Router# show umts congestion atm 0/ima0
UMTS-Iub(ATM0/IMA0):
   Congestion: ON
   Throttled ATM cells: 415801
   Last congestion time: Mar 13 18:09:49.858   duration: 0h 0m 53s

The following example illustrates the use of show atm umts-iub peering command with the new Congestion Control status field. In this example, it shows it On.

Router# show umts-iub peering atm 0/ima0
UMTS-Iub(ATM0/IMA0): Peering Information
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):       Local (20.20.20.21:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):            Connect State: OPEN    
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):            Redundancy State: ACTIVE
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):            Congestion Control: ON
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):            Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):            Alarm State: 
UMTS-Iub(ATM0/0 - ATM0/2):                    RX(NO ALARM)       TX(NO ALARM)
UMTS-Iub(ATM0/1 - ATM0/3):                    RX(NO ALARM)       TX(NO ALARM)
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):       Remote (20.20.20.20:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):            Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA1):            Alarm State: 
UMTS-Iub(ATM0/0 - ATM0/2):                    RX(NO ALARM)       TX(NO ALARM)
UMTS-Iub(ATM0/1 - ATM0/3):                    RX(NO ALARM)       TX(NO ALARM)

Inverse Multiplexing over ATM (IMA)

Inverse Multiplexing over ATM (IMA) interface as a shorthaul enables you to configure existing UMTS commands on IMA interfaces. No new commands are added for this new feature. Only previously existing Cisco IOS commands have been added for this feature (see the "Configuring Inverse Multiplexing over ATM (IMA)" section on page 4-37 and Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference").

When operating in the IMA environment, a sample ATM configuration is written as follows:

interface ATM0/0/0
	no ip address
	no atm ilmi-keepalive
	ima-group 0
	scrambling-payload

interface ATM0/0/1
	no ip address
	no atm ilmi-keepalive
	ima-group 0
	scrambling-payload

interface ATM0/IMA0
	no ip address
	atm bandwidth dynamic
	atm umts-iub
	no atm ilmi-keepalive
	pvc 2/1
		encapsulation aal0
	!
	pvc 2/2
		encapsulation aal0
	!
umts-iub local 20.20.20.21 6666
umts-iub remote 20.20.20.20 6666

Note The above sample configuration has one IMA shorthaul with two member links (atm0/0/0 and atm 0/0/1).


The output for the show umts-iub peering command has also changed and will look like the following:

Router#show umts peer
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0): Peering Information
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):      Local (20.20.20.21:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Connect State: OPEN   
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Redundancy State: ACTIVE
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Alarm State:
UMTS-Iub(ATM0/0/0 - ATM0/0/0): 	RX(NO ALARM) TX(NO ALARM)
UMTS-Iub(ATM0/0/1 - ATM0/0/1): 	RX(NO ALARM) TX(NO ALARM)
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):      Remote (20.20.20.20:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Alarm State:
UMTS-Iub(ATM0/0/0 - ATM0/0/0): 										RX(NO ALARM)       TX(NO ALARM)
UMTS-Iub(ATM0/0/1 - ATM0/0/1): 										RX(NO ALARM)       TX(NO ALARM)


Note In the previous output, the local shorthaul/interface name appears before the dash (-), and the remote shorthaul/interface name appears after the dash (-).


Permanent Virtual Circuit (PVC) Routing

PVC Routing allows you to offload PVC traffic from a physical ATM shorthaul to an alternate backhaul. For each alternate backhaul, you will need to create a logical shorthaul by creating an ATM sub-interface. Traffic from the PVCs configured under this logical shorthaul will go through the corresponding alternate backhaul. Three new commands are added using the Sub-interface Configuration mode for this new feature: atm umts, umts local, and umts remote (see the "Configuring PVC Routing (HSDPA Offload)" section on page 4-41 and Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference").

A sample configuration is written as follows:

interface ATM0/IMA0
 no ip address
 atm umts-iub
 no atm ilmi-keepalive
 pvc 2/1 
  encapsulation aal0
 !
 pvc 2/2 
  encapsulation aal0
 !
 umts-iub local 20.20.20.21 6666
 umts-iub remote 20.20.20.20 6666


interface ATM0/IMA0.1 multipoint
 atm umts-iub
 pvc 1/200
  encapsulation aal0
 !
 umts-iub local 192.168.10.2
 umts-iub remote 192.168.10.1

In the above sample, traffic for PVC 1/200 will be off-loaded to the alternate backhaul (192.168.10.2 -- 192.168.10.1). The new output of a show umts peer command will look like the following:


Router#show umts peer
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0): Peering Information
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):      Local (20.20.20.21:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Connect State: OPEN   
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Redundancy State: ACTIVE
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Alarm State:
UMTS-Iub(ATM0/0/0 - ATM0/0/0): 	RX(NO ALARM) TX(NO ALARM)
UMTS-Iub(ATM0/0/1 - ATM0/0/1): 	RX(NO ALARM) TX(NO ALARM)
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):      Remote (20.20.20.20:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Alarm State:
UMTS-Iub(ATM0/0/0 - ATM0/0/0): 										RX(NO ALARM)       TX(NO ALARM)
UMTS-Iub(ATM0/0/1 - ATM0/0/1): 										RX(NO ALARM)       TX(NO ALARM)

UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1): Peering Information
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):      Local (192.168.10.2:6666) States:
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Connect State: OPEN    
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Redundancy State: ACTIVE
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Version: 4
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):      Remote (192.168.10.1:6666) States:
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Version: 4


Note In the previous output, the local shorthaul/interface name appears before the dash (-), and the remote shorthaul/interface name appears after the dash (-).


Router#show umts pvc
UMTS-Iub(ATM0/IMA0): PVC matching 
   Peering state: OPEN    
   Local PVCs:
     PVC(2/1): has    MATCHING remote PVC.
     PVC(2/2): has    MATCHING remote PVC.

   Remote PVCs:
     PVC(2/1): has    MATCHING local PVC. 
     PVC(2/2): has    MATCHING local PVC. 


UMTS-Iub(ATM0/IMA0.1): PVC matching 
   Peering state: OPEN    
   Local PVCs:
     PVC(1/200): has    MATCHING remote PVC.

   Remote PVCs:
     PVC(1/200): has    MATCHING local PVC. 


Lisa#show umts packet
UMTS-Iub(ATM0/IMA0): packets:
  rxUMTS_count ================ 468845
  txUMTS_count ================ 276847
  rxUMTS_bytes ================ 22504560
  txUMTS_bytes ================ 13288656
  rxBackhaul_packets ========== 58216
  txBackhaul_packets ========== 88884
  rxBackhaul_bytes ============ 14687104
  txBackhaul_bytes ============ 24824360
  Last cleared 00:50:39
UMTS-Iub(ATM0/IMA0.1): packets:
  rxUMTS_count ================ 126173
  txUMTS_count ================ 126173
  rxUMTS_bytes ================ 6056304
  txUMTS_bytes ================ 6056304
  rxBackhaul_packets ========== 28405
  txBackhaul_packets ========== 28777
  rxBackhaul_bytes ============ 6532571
  txBackhaul_bytes ============ 7596968
  Last cleared 00:08:08

Behavior Changes

The following behavior changes will be apparent when using this PVC Routing feature.

1. When the no atm umts command is applied to a base ATM interface, the command will un-configure the ATM UMTS mode for all the sub-interfaces under that ATM interface.

2. When the no atm umts command is applied to an ATM sub-interface, the command will un-configure the ATM UMTS mode only for that sub-interface.

3. Alarms are carried over the primary backhaul only, while the primary peering will have the alarm information. The following is a sample output:

UMTS-Iub(ATM0/IMA0 - ATM0/IMA0): Peering Information
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):      Local (20.20.20.21:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Connect State: OPEN   
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Redundancy State: ACTIVE
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Alarm State:
UMTS-Iub(ATM0/0/0 - ATM0/0/0): 	RX(NO ALARM) TX(NO ALARM)
UMTS-Iub(ATM0/0/1 - ATM0/0/1): 	RX(NO ALARM) TX(NO ALARM)
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):      Remote (20.20.20.20:6666) States:
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Version: 4
UMTS-Iub(ATM0/IMA0 - ATM0/IMA0):           Alarm State:
UMTS-Iub(ATM0/0/0 - ATM0/0/0): 										RX(NO ALARM)       TX(NO ALARM)
UMTS-Iub(ATM0/0/1 - ATM0/0/1): 										RX(NO ALARM)       TX(NO ALARM)

UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1): Peering Information
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):      Local (192.168.10.2:6666) States:
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Connect State: OPEN    
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Redundancy State: ACTIVE
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Version: 4
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):      Remote (192.168.10.1:6666) States:
UMTS-Iub(ATM0/IMA0.1 - ATM0/IMA.1):           Version: 4


Note In the previous output, the local shorthaul/interface name appears before the dash (-), and the remote shorthaul/interface name appears after the dash (-).


4. An admin shutdown of the base ATM interface will shut down all the peering instances, including the primary peering and all the sub-interface peering(s). (In other words, they will move to the CLOSED state).

5. An admin shutdown of an ATM sub-interface will shut down only the peering for that sub-interface. (In other words, the admin shutdown of the ATM sub-interface will make the PVCs on that sub-interface inactive, but it won't change the status of the PVCs on the other end of the shorthaul, Node B or RNC.)

6. When the primary backhaul goes down and the primary peering goes down, the primary peering will start sending Alarm Indication Signals (AISs) on the shorthaul, and; therefore, bring down the shorthaul like before. So all shorthaul traffic will stop, including the PVC traffic off-loaded to the alternate backhaul(s). (In this situation, the sub-interface peering connection state will stay OPEN as long as the alternate backhaul doesn't go down).

7. When an alternate or sub-interface backhaul goes down, the sub-interface peering will go down, but it won't bring down the shorthaul or start any alarms on the T1/E1 link. So primary backhaul traffic won't be affected. (In this case, the sub-interface's state will not be changed since the sub-interface is only the logical interface and changing its state will not generate any notification to the Node B or RNC at the ATM level. If the Node B/RNC wants to be able to detect an alternate backhaul down situation, configure the OAM-CC on the PVCs that are off-loaded to the alternate/sub-interface backhaul).

8. Cannot configure the qsaal type PVC under the ATM sub-interface, which means the AAL5 type traffic cannot be off-loaded to the alternate backhaul unless they are configured as the AAL0 type on the Cisco 3825 router.

UMTS QoS

Three new commands are added using the Interface Configuration mode for this new feature: umts-iub set dscp, umts-iub set peering dscp, and gsm-abis set dscp and one new ATM-VC Interface Configuration command: umts-iub set dscp (see the "Configuring UMTS QoS" section on page 4-46 and Appendix A, "Cisco 3825 Mobile Wireless Edge Router RAN-O Command Reference"). These new commands allow you to perform the following:

UMTS Shorthaul Interface

Set the default description value to tag the backhaul packet including peering and data generated from the shorthaul in a UMTS Iub configuration.

Set the description value in the UMTS Iub configuration such that it overwrites the default value defined previously. It is also used to tag the peering backhaul packet.

PVC of a UMTS Shorthaul Interface

Set the description value in the UMTS Iub configuration such that it overwrites the default value defined previously. It is also used to tag the backhaul packet generated from traffic from the PVC.

GSM Shorthaul Interface

Set the description value in such a way as to tag all the backhaul packets generated from the shorthaul in the GSM Abis interface.

A sample configuration is written as follows:

class-map match-any llq-class
 match ip dscp cs2
 !
policy-map llq-policy
 class llq-class
  priority percent 99
 class class-default
  bandwidth remaining percent 1
  queue-limit 45
!

interface ATM0/0/0
 no ip address
 atm umts-iub
 no atm ilmi-keepalive
 pvc 2/1
  encapsulation aal0
  umts-iub set dscp 16
 !
 pvc 2/2
  encapsulation aal0
 !
 umts-iub set dscp 8
 umts-iub set peering dscp 16
 umts-iub local 20.20.20.21 6666
 umts-iub remote 20.20.20.20 6666
!

interface ATM0/0/1
 no ip address
 atm umts-iub
 no atm ilmi-keepalive
 pvc 2/1
  encapsulation aal0
  umts-iub set dscp 16
 !
 pvc 2/2
  encapsulation aal0
 !
 umts-iub set dscp 8
 umts-iub set peering dscp 16
 umts-iub local 20.20.20.21 8888
 umts-iub remote 20.20.20.20 8888

interface Multilink2
 ip address 20.20.20.21 255.255.255.0
 ip tcp header-compression ietf-format
 load-interval 30
 no keepalive
 no cdp enable
 ppp pfc local request
 ppp pfc remote apply
 ppp acfc local request
 ppp acfc remote apply
 ppp multilink
 ppp multilink interleave
 ppp multilink group 2
 ppp multilink fragment delay 0 1
 ppp multilink multiclass
 max-reserved-bandwidth 100
 service-policy output llq-policy
 hold-queue 50 out
 ip rtp header-compression ietf-format

In the above sample, PVC 2/1 of ATM0/0/0 and ATM0/0/1 will go to the priority queue and PVC 2/2 of ATM0/0/0 and ATM0/0/1 will be considered the best effort traffic and will go to the Weighted Fair Queue.


Note Defining the dscp value under the PVC affects the way the ATM cells are bundled together as a backhaul. The more dscp values that are defined, the more limitations on how the ATM cells can be bundled. This, as a result, could affect backhaul efficiency. We recommend that you define at most two different dscp values for each shorthaul. One for llq traffic, and the other for best effort traffic.