Guest

Cisco IOS Software Releases 12.0 Special and Early Deployments

Frame Relay�ATM Service Interworking�FRF.8 on the Cisco MC3810

Hierarchical Navigation

Downloads

Table Of Contents

Frame Relay—ATM Service Interworking—FRF.8 on the
Cisco MC3810

Feature Overview

Benefits

Restrictions

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Configuration Tasks

Configuring the ATM Interface and PVCs

Verifying ATM Interface and PVC Configuration

Configuring the Frame Relay Interface and PVCs

Verifying Frame Relay Interface and PVC Configuration

Configuration Example

Command Reference

encapsulation

Syntax Description

Default

Command Mode

Command History

Usage Guidelines

Examples

Related Command

frame-relay pvc

Syntax Description

Defaults

Command Mode

Command History

Usage Guidelines

Example

Related Command

Glossary


Frame Relay—ATM Service Interworking—FRF.8 on the
Cisco MC3810

FRF.8 Frame Relay to Asynchronous Transfer Mode (ATM) Interworking allows connection of Frame Relay traffic across high-speed ATM trunks using ATM standard Network and Service Interworking. This document describes Frame Relay-to-ATM Service Interworking for data transfer, outlined in Frame Relay Forum implementation agreement FRF.8 and designed for the Cisco MC3810 multiservice access concentrator.

This document includes the following sections:

•Feature Overview

•Supported Platforms

•Supported Standards, MIBs, and RFCs

•Prerequisites

•Configuration Tasks

•Configuration Example

•Command Reference

•Glossary

Feature Overview

Service Interworking connects a Frame Relay network to an ATM network while the networks function independently. Service Interworking allows bidirectional PVC protocol conversion functions and provides a standards-based solution for service providers, enterprises, and end users.

In Service Interworking translation mode, Frame Relay PVCs are mapped to ATM PVCs without the necessity for symmetric topologies—the paths can terminate on the ATM side. The ATM-connected Cisco MC3810 need not be directly linked to a Frame Relay network. Some network devices in a Frame Relay network can evolve to ATM without all network devices doing so.

In , customers' Frame Relay devices are connected to Cisco MC3810 multiservice access concentrators, which in turn connect to a service provider's ATM network and switch.

Figure 1 Service Interworking Function

This feature supports two modes of operation of the IWF for upper-layer user protocol encapsulation—transparent mode and translation mode—as defined in FRF.8 section 5.3. The modes are configured at the PVC level. They differ in the following ways:

•Translation mode maps between ATM and Frame Relay encapsulation; it also supports interworking of routed and/or bridged protocols.

•Transparent mode does not map encapsulations but sends them unaltered. This mode is used when translation is not practical because encapsulation methods do not conform to the supported standards for Service Interworking.

The Service Interworking Function (IWF) in translation mode works like a protocol converter in the following ways:

•When Inverse Address-Resolution Protocol (INARP) or static mapping is configured, addresses are resolved one-to-one between Frame Relay and ATM schemes.

•Header function mapping and multiprotocol data unit headers are converted between protocols.

•ATM Adaptation Layer 5 (AAL5) information assists in translating boundary information in both directions:

•In the Frame Relay-to-ATM direction, a frame is mapped to an ATM Adaptation Layer 5 (AAL5) protocol data unit (PDU).

•In the ATM-to-Frame Relay direction, the AAL5 information is used to delineate frame boundaries and insert flags and other information that is stripped from frames in the opposite direction.

•Discard Eligibility (DE) and Cell Loss Priority (CLP) can be mapped in both directions.

•Mapping can occur between the Frame Relay Forward Explicit Congestion Notification (FECN) and the ATM Explicit Forward Congestion Indicator (EFCI) in both directions, depending upon the configuration. In some cases, it may be desirable for the mapping to occur, but in many cases it is better to turn the mapping off. This is configurable on each PVC.

•Mapping occurs between the Frame Relay Command Response (C/R) field and the ATM common part convergence sublayer user-to-user least significant bit (CPCS-UU LSB), as defined in FRF.8.

•PVC Management interworking is supported, as defined in FRF.8 section 5.2. The optional asynchronous Local Management Interface (LMI) status message is not implemented.

Benefits

Eases Network Management

In internetworks that include both Frame Relay and ATM networks, Service Interworking makes linking the two types of networks relatively easy.

Eases Network Migration

If migration from Frame Relay to higher-bandwidth ATM networking is desirable, Service Interworking allows a gradual change, linking the two types of networks before the transition is complete. The conversion features of Service Interworking mean that interoperability need not be assured across all network nodes.

Expands ATM-Frame Relay Interworking Options

Formerly, the Cisco MC3810 directly supported Network Interworking only, as outlined in the FRF.5 Implementation agreement, which allows Frame Relay voice or data traffic to be encapsulated in Asynchronous Transfer Mode (ATM) cells. Service Interworking could be used on the Cisco MC3810 but only when it was provided by a carrier's ATM equipment. Now, both Service Interworking and Network Interworking are supported on the Cisco MC3810 multiservice access concentrator. While Network Interworking requires special configuration on the ATM side in order to support the link between networks, Service Interworking does not.

Protocol Conversion

Conversion functions between Frame Relay and ATM require minimal configuration and mean that ATM activities need not be performed on the Frame Relay side and Frame Relay activities need not be performed on the ATM side.

Restrictions

The following functions are not supported in the FRF.8 Cisco MC3810 Frame Relay-to-ATM Service Interworking feature:

•Fragmentation and Reassembly of RFC 1490, as defined in FRF.8, section 5.3.1.4

•Traffic Management

•The optional asynchronous LMI status message

•Compression

•Cisco MC3810 voice encapsulation—only data is supported

Related Features and Technologies

There are two types of Frame Relay-ATM interworking, Service Interworking as described in this document, and Network Interworking, which is also supported on the Cisco MC3810 multiservice access concentrator.

Network Interworking allows the transparent tunneling of Frame Relay user traffic and PVCs over ATM. This function is often used to link Frame Relay networks over an ATM backbone. The most distant nodes must be configured to interoperate with one another—in contrast to Service Interworking—because intact Frame Relay frames are sent over the ATM network. The ATM backbone is used as an alternative to a leased line, and provides cost savings over leased lines. There can be a one-to-one relationship between Frame Relay and ATM PVCs, or multiple Frame Relay PVCs can be multiplexed into a single ATM PVC.

In contrast, Service Interworking works to convert the components of the two different transmission methods—as described in the "Feature Overview" section. In addition, there is always a one-to-one relationship between Frame Relay and ATM PVCs.

Related Documents

For information about Frame Relay and ATM IOS configuration for the Cisco MC3810, consult the following Cisco IOS Release 12.0 documents:

•Wide-Area Networking Configuration Guide

•Wide-Area Networking Command Reference

For information about Frame Relay and ATM IOS configuration that is unique to the Cisco MC3810, consult the following Cisco documents:

•Cisco MC3810 Multiservice Access Concentrator Software Configuration Guide

•Cisco MC3810 Multiservice Access Concentrator Software Command Reference

Supported Platforms

The Service Interworking feature is supported on the Cisco MC3810 multiservice access concentrator only.

Supported Standards, MIBs, and RFCs

This feature supports the Frame Relay Forum Frame Relay/ATM Service Interworking Implementation Agreement, document number FRF.8, April 14, 1995.

Prerequisites

Frame Relay-ATM Service Interworking requires specific software, hardware, and preliminary configuration:

•Cisco IOS Software Release 12.0(5)XK, 12.0(7)T or later

•Configured ATM and Frame Relay networks

•One or more Cisco MC3810 multiservice access concentrators (a Cisco MC3810 acts as the interface between networks)

Configuration Tasks

Perform the following tasks to configure FRF.8 Frame Relay-ATM Service Interworking.

•Configure the ATM interface and PVCs.

•Configure the Frame Relay serial interface and PVCs.

The configuration tasks sections do not include complete configuration information; they assume that your networks are already set up for Frame Relay and ATM transport modes. Instead, the configuration tasks focus on those steps that are necessary or may be important to Frame Relay-ATM Service Interworking.

For a complete configuration example, see the "Configuration Example" section. For more information about configuring your Cisco MC3810, see the Cisco IOS Release 12.0 configuration guides and command references.

Configuring the ATM Interface and PVCs

This section shows the steps for setting global and interface configuration parameters to support ATM interfaces, as well as setting up those interfaces with ATM PVCs that interwork with Frame Relay PVCs.

Note   Frame Relay-ATM Service Interworking supports neither Frame Relay nor ATM switched virtual circuits (SVCs).

1 

Router(config)# configure terminal

Enter global configuration mode.

2 

Router(config)# controller {T1 | E1} 0

Enter controller configuration mode for controller T1/E1 0. ATM traffic is supported on controller T1/E1 0 only.

3 

Router(config-controller)# framing esf

or 

Router(config-controller)# framing crc4

Set the framing to Extended Superframe (ESF) format, required for ATM on T1. This setting is automatic for T1 when the ATM mode is set.

Set the framing to CRC4, required for ATM on E1. This setting is automatic for E1 when the ATM mode is set.

4 

Router(config-controller)# linecode b8zs

or 

Router(config-controller)# linecode hdb3

Set the line coding to binary zero 0 substitution (B8ZS), required for ATM on T1. This setting is automatic for T1 when the ATM mode is set.

Set the line coding to HDB3, required for ATM on E1. This setting is automatic for E1 when the ATM mode is set.

Note   When the E1 controller is specified, you must also configure scrambling on the ATM 0 interface.

5 

Router(config-controller)# mode atm

This allows the controller to support ATM encapsulation and create virtual ATM interface 0 for PVCs. Channel groups, channel-associated signaling (CAS) groups, Common Channel Signaling (CCS) groups or clear channels are not allowed on the trunk because ATM traffic occupies all the DS0s.

6 

Router(config-controller)# interface atm0

Enter interface configuration mode for ATM interface 0, the only available ATM interface for this purpose.

7 

Router(config-if)# pvc [name] vpi/vci

Use this form of the pvc command to enter ATM PVC configuration mode and set up PVCs for Service Interworking; set up an ATM PVC for each Frame Relay PVC you are using for Service Interworking.

The optional name is a unique label that can be up to 16 characters long.

The ATM network VPI of this PVC is an 8-bit field in the header of the ATM cell. Valid values are from 0 to 255, but the values from 0 to 31 are usually reserved for particular services.

The arguments vpi and vci cannot both be set to 0; if one is 0, the other cannot be 0.

The VCI is a 16-bit field in the header of the ATM cell.

Note   There are additional optional keywords for this command that are not used for Service Interworking PVCs. For more information, see the Cisco IOS Release 12.0 Wide-Area Networking Command Reference Guide.

8 

Router(config-if-atm-pvc)# oam-pvc [manage] [frequency]

To enable PVC management, you must use this command, which allows the PVC to generate end-to-end OAM (Operation, Administration, and Maintenance) loopback cells that verify connectivity on the virtual circuit. The remote end must respond by echoing back such cells. If OAM response cells are missed (indicating a lack of connectivity), the PVC state goes down. If all the PVCs on a subinterface go down, the subinterface goes down. If the command is not used, OAM loopback verification is off.

The manage keyword allows OAM management of the PVC.

The optional frequency number indicates the interval between transmission of loopback cells and is a value in seconds from 0 to 600. If the command is issued without this parameter, the default value is 10 seconds.

Note   To permit PVC management, you must also enable keepalive on the serial interface. See Step 6 of "Configuring the Frame Relay Interface and PVCs" on page 7.

9 

Router(config-if-atm-pvc)# encapsulation aal5mux

fr-atm-srv

Use this form of the ATM encapsulation command to set the PVC for Frame Relay-to-ATM Service Interworking. The fr-atm-srv keyword specifies the interworking function.

Note   The command encapsulation aal5mux frame-relay specifies FRF.5 Frame Relay-to-ATM Network Interworking.


Verifying ATM Interface and PVC Configuration

Follow the steps below to verify configuration of ATM interface 0 and the PVCs you have created.

Step 1 Use the show interface atm0 command to verify configuration of the ATM interface. Important information appears in bold. Note that the total count of configured virtual circuits (VCs) is shown. 

router# show interface atm0

ATM0 is up, line protocol is up

  Hardware is PQUICC Atom1

  MTU 3000 bytes, sub MTU 3000, BW 1536 Kbit, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ATM, loopback not set

  Keepalive not supported

  Encapsulation(s):, PVC mode

  1024 maximum active VCs, 11 current VCCs

  VC idle disconnect time: 300 seconds

  Last input never, output never, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0 (size/max/drops); Total output drops: 0

  Queueing strategy: weighted fair

  Output queue: 0/1000/64/0 (size/max total/threshold/drops)

     Conversations  0/0/256 (active/max active/max total)

     Reserved Conversations 0/0 (allocated/max allocated)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 1000 bits/sec, 1 packets/sec

     2838 packets input, 971318 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     201591 packets output, 16783240 bytes, 0 underruns

     0 output errors, 0 collisions, 2 interface resets

     0 output buffer failures, 0 output buffers swapped out

Step 2 Use the show atm pvc command to verify the PVCs you created. Note that in this example, PVC 10 is set up for Network Interworking; the other PVCs are configured for Service Interworking. 

router# show atm pvc

            VCD /                                      Peak  Avg/Min Burst

Interface   Name       VPI   VCI  Type   Encaps   SC   Kbps   Kbps   Cells  Sts

0          2           24    36   PVC    FRATMSRV UBR       0              DOWN

0          1           24    37   PVC    FRATMSRV UBR       0                UP

0          9           44    44   PVC    FRATMSRV UBR       0              DOWN

0          11          94    92   PVC    FRATMSRV UBR       0                UP

0          3          100   100   PVC    FRATMSRV UBR      56              DOWN

0          6          120   120   PVC    FRATMSRV UBR       0                UP

Configuring the Frame Relay Interface and PVCs

The steps below show how to configure the Frame Relay interface for Service Interworking and set up Frame Relay PVCs to work with ATM PVCs. Some preliminary global configuration commands are also included. For more information about setting up Frame Relay on the Cisco MC3810, see the Cisco MC3810 Multiservice Access Concentrator Software Configuration Guide.

To configure the Frame Relay interface and PVCs, follow the steps below.

Step
Command
Purpose

1 

Router# configure terminal

Enter global configuration mode.

2 

Router(config)# network-clock base-rate {56k | 64k}

Configure the network clock base rate for serial ports; the default setting is 56 kbps.

3 

Router(config)# frame-relay switching

Enables PVC switching on the serial interfaces.

4 

Router(config)# interface serial {0 | 1}

Specify a serial interface for Frame Relay PVCs and enter interface configuration mode.

5 

Router(config-if)# encapsulation frame-relay [cisco |

ietf]

Specify the Frame Relay encapsulation on the interface.

To allow FRF.8 communications in translation mode, you must use the Internet Engineering Task Force (IETF) form of Frame Relay encapsulation, which allows interoperability among devices from different vendors.

Use the default cisco option when Cisco devices are communicating in transparent mode. This method uses a 4-byte header, with 2 bytes to identify the data-link connection identifier (DLCI) and 2 bytes to identify the packet type.

6 

Router(config-if)# keepalive [number]

To enable the keepalive timer and allow PVC management in FRF.8 communications, enter the keepalive command.

The optional number is and integer value for the keepalive interval, which is the frequency at which the Cisco IOS software sends messages to the other end to ensure that a network interface is alive. The interval is adjustable in 1-second increments down to 1 second. An interface is declared down after three update intervals have passed without receiving a keepalive packet. The default setting is 10 seconds.

7 

Router(config-if)# frame-relay intf-type [dce | dte |

nni]

(Optional) This command sets the switch type.

dce indicates a router that functions as a switch connected to a router.

dte is used when the Cisco MC3810 is connected to a Frame Relay network. This is the default.

The nni option specifies a switch connected to a switch, Network-to-Network Interface (NNI) connections.

8 

Router(config-if)# frame-relay lmi-type {ansi | cisco |

q933a}

(Optional) Unless this command is set, Local Management Interface (LMI) autosensing automatically selects a method for addressing the LMI. If you connect to the public data network (PDN), the LMI type must match the type used on the PDN. Otherwise, you can specify a parameter that suits your private network's needs.

ansi specifies Annex D defined by American National Standards Institute (ANSI) standard T1.617.

cisco sets an LMI type defined jointly by Cisco and three other companies.

q933a sets a type defined by ITU-T Q.933 Annex A.

9 

Router(config-if)# frame-relay pvc dlci service

{transparent | translation} [clp-bit {0 | 1 |

map-de}][de-bit {0 | 1 | map-clp}][efci-bit {0 | 1 |

map-fecn}]interface atm0 {vpi/vci | vcd}

This command sets up Frame Relay PVCs for Frame Relay-ATM Service Interworking. Repeat this step for each PVC that you wish to set up. Corresponding ATM PVCs are configured in "Configuring the ATM Interface and PVCs" section.

dlci sets the data-link connection identifier (DLCI), a value ranging from 16 to 1007 for the PVC. This label is used when you associate a Frame Relay PVC with an ATM PVC.

The service setting configures Service Interworking in transparent mode, where encapsulations are sent unaltered, or in translation mode, where mapping and translation take place. There is no default.

The clp-bit parameter configures the discard eligible (DE) and cell loss priority (CLP) mapping in the Frame Relay-to-ATM direction according to Mode 1 or 2 as specified in FRF.8, section 4. The selections are as follows:

•The default keyword, map-de, adheres to Mode 1 and maps the DE field in the frame to the ATM CLP field generated by each cell during AAL5 segmentation.

•Rather than mapping, 0 or 1 adheres to Mode 2 and sets a constant value (of 0 or 1) for the ATM CLP of each ATM cell that the AAL5 segmentation process generates.

The de-bit parameter configures the cell loss priority (CLP) and discard eligibility (DE) mapping in the ATM-to-Frame Relay direction according to Mode 1 or 2 as specified in FRF.8, section 4. The selections are as follows:

•The default keyword, map-clp, adheres to Mode 1 and sets the DE field in the frame if one or more cells in a frame have a CLP field set.

•0 or 1 adheres to Mode 2 and sets a constant value (of 0 or 1) for each DE field.

The efci-bit parameter sets the mode of Forward Explicit Congestion Notification (FECN) and the ATM Explicit Forward Congestion Indicator (EFCI) in the Frame Relay-to-ATM direction.

The default map-fecn adheres to Mode 1 and maps the FECN indicators to EFCI indicators.

0 sets a constant value rather than mapping, as does 1.

The last part of the command maps the Frame Relay PVC to an ATM PVC by specifying the ATM interface (0 is the only value), and either the ATM virtual circuit descriptor (VCD), or the virtual path identifier-virtual channel identifier (VPI-VCI) pair for the PVC.

10 

Router(config-if)# exit

Exit interface configuration mode.


Verifying Frame Relay Interface and PVC Configuration

Step 1 Use the show interface serial command to confirm serial interface configuration for Frame Relay. Note that some important text appears in bold, as follows:

•Encapsulation is set to IETF, and the default keepalive is in effect. These settings allow translation mode and management of PVCs respectively.

•The LMI type of CCITT was specified with the q933a keyword, as ITU-T is the successor to CCITT and the type is set to ITU-T Q.933 Annex A.

•The Frame Relay switch type is DCE. 

router# show interface serial0

Serial0 is up, line protocol is up

  Hardware is PQUICC Serial

  MTU 5000 bytes, BW 1544 Kbit, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation FRAME-RELAY IETF, crc 16, loopback not set

  Keepalive set (10 sec)

  Scramble enabled

  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0

  LMI enq recvd 36108, LMI stat sent  36108, LMI upd sent  0, DCE LMI up

  LMI DLCI 0  LMI type is CCITT  frame relay DCE

  FR SVC disabled, LAPF state down

  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0

  Last input 00:00:02, output 00:00:02, output hang never

  Last clearing of "show interface" counters 4d04h

  Input queue: 0/75/0 (size/max/drops); Total output drops: 0

  Queueing strategy: weighted fair

  Output queue: 0/1000/64/0 (size/max total/threshold/drops)

     Conversations  0/1/256 (active/max active/max total)

     Reserved Conversations 0/0 (allocated/max allocated)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     54846 packets input, 7038195 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 8 giants, 0 throttles

     9 input errors, 0 CRC, 1 frame, 0 overrun, 0 ignored, 0 abort

     36436 packets output, 1599185 bytes, 0 underruns

     0 output errors, 0 collisions, 2 interface resets

     0 output buffer failures, 0 output buffers swapped out

     0 carrier transitions

  Cable attached: V.35 (DTE)

  Hardware config: V.35; DTE;  DSR = UP   DTR = UP   RTS = UP   CTS = UP   DCD = 
UP

Note   For a description of each output display field, refer to the show interface serial command reference page in the Cisco IOS Release 12.0 Interface Command Reference.

Step 2 Use the show frame-relay pvc [type number [dlci]] command to see status and traffic information about Frame Relay PVCs that you have configured. The type, number, and dlci arguments are optional and allow you to specify the switch type of the interface, an interface number, and a DLCI number. 

Router# show frame-relay pvc dce

PVC Statistics for interface Serial0 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0

  input pkts 4936          output pkts 62           in bytes 989118    

  out bytes 63676          dropped pkts 4           in FECN pkts 8         

  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         

  in DE pkts 8             out DE pkts 0         

  out bcast pkts 0          out bcast bytes 0            Num Pkts Switched 4932      

  pvc create time 1d16h, last time pvc status changed 1d16h

Configuration Example

This section provides a configuration example where both sides of the Frame Relay-ATM Service Interworking function are performed on the same Cisco MC3810 multiservice access concentrator, which is acting as a gateway to mediate traffic between the two transport methods.

A serial interface is configured for Frame Relay with Frame Relay PVCs, and an ATM interface is configured on the same Cisco MC3810. 

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname iwf

!

!

network-clock base-rate 56k

ip subnet-zero

This command enables Frame-Relay switching on the serial interfaces of the Cisco MC3810: 

frame-relay switching

!

!

controller T1 0

 framing esf

The mode atm command is required for ATM service. 

mode atm

!

!

!

interface Ethernet0

 ip address 1.3.16.1 255.255.0.0

 no ip directed-broadcast

!

The frame-relay pvc commands below set up Frame Relay PVCs that correspond to ATM PVCs. Although one uses translation mode and one transparent mode, Cell Loss Priority (CLP) and Discard Eligibility (DE) bits are mapped in both directions, corresponding to Mode 1 of the FRF.8 agreement for these parameters.

In the Frame Relay-to-ATM direction, Forward Explicit Congestion Notification (FECN) and the ATM Explicit Forward Congestion Indicator (EFCI) are mapped to one another.

Finally, the command points to the ATM PVC that corresponds to the Frame Relay PVC, using the ATM interface number (0) and the virtual path identifier-virtual channel identifier (VPI/VCI) pair as identification. 

interface Serial0

 mtu 5000

 no ip address

 no ip directed-broadcast

 encapsulation frame-relay IETF

 frame-relay pvc 44 service transparent clp-bit map-de de-bit map-clp efci-bit map-fecn 
interface ATM0 44/44

 frame-relay pvc 120 service translation clp-bit map-de de-bit map-clp efci-bit 
map-fecn interface ATM0 120/120

!

The frame-relay lmi-type command is set to the type defined by ITU-T Q.933 Annex A. 

frame-relay lmi-type q933a

The frame-relay intf-type command designates digital communications equipment (DCE), because the Cisco MC3810 is acting as a switch connected to a router rather than being connected directly to a Frame Relay network. 

 frame-relay intf-type dce

!


interface Serial1

 no ip address

 no ip directed-broadcast

 shutdown

!

The ATM PVCs are created on interface ATM 0, the only available interface for this purpose. The oam-pvc setting provides for loopback testing and PVC management on PVC 44/44.

Note that these PVCs are specified in the frame-relay pvc commands that are configured on serial interface 0. Encapsulation is set for Service Interworking.

Because the interworking function is used for data transfer, unspecified bit rate (UBR) can be configured as the QoS class for a PVC, as in PVC 44/44. The peak cell rate for output is set at 56 Kbps. 

interface ATM0

 mtu 3000

 no ip address

 no ip directed-broadcast

 no atm ilmi-keepalive


 pvc 120/120 

  encapsulation aal5mux fr-atm-srv

 !        

 pvc 44/44 

  ubr 56

  oam-pvc manage

  encapsulation aal5mux fr-atm-srv

 !

The balance of the configuration does not bear on Frame Relay-to-ATM interworking.

Command Reference

This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references.

•encapsulation

•frame-relay pvc

encapsulation

To configure the ATM adaptation layer (AAL) and encapsulation type for an ATM PVC class, use the encapsulation ATM virtual circuit. Use the no form of this command to remove an encapsulation from a PVC.

encapsulation aal-encap

no encapsulation aal-encap

Syntax Description

aal-encap

ATM adaptation layer (AAL) and encapsulation type. When aal5mux is specified, a protocol is required. Possible values for aal-encap are as follows:

aal5mux frame-relay---For a MUX-type virtual circuit for FRF.5 Frame Relay-ATM Network Interworking on the Cisco MC3810.

aal5mux fr-atm-srv---For a MUX-type virtual circuit for FRF.8 Frame Relay-ATM Service Interworking on the Cisco MC3810.

aal5mux voice---For a MUX-type virtual circuit for Voice over ATM on the Cisco MC3810.

aal5snap---The only encapsulation supported for Inverse ARP. Logical Link Control/Subnetwork Access Protocol (LLC/SNAP) precedes the protocol datagram. This keyword is used for data.


Default

The global default encapsulation is aal5snap. See the "Usage Guidelines" section for other default characteristics.

Command Mode

Interface-ATM-VC configuration mode (for an ATM PVC or SVC)

Command History

Release
Modification

11.3(3)T

This command was introduced.

12.0

This command superseded the encapsulation atm command on the Cisco MC3810, and the aal5mux frame and aal5mux voice suboptions appeared.

12.0(7)T

The aal5mux fr-atm-srv suboption appeared for the Cisco MC3810.


Usage Guidelines

Use one of the aal5mux encapsulation options to dedicate the specified PVC to a single protocol; use the aal5snap encapsulation option to multiplex two or more protocols over the same PVC. Whether you select aal5mux or aal5snap encapsulation might depend on practical considerations, such as the type of network and the pricing offered by the network. If the network's pricing depends on the number of PVCs set up, aal5snap might be the appropriate choice. If pricing depends on the number of bytes transmitted, aal5mux might be the appropriate choice because it has slightly less overhead.

If you specify virtual template parameters after the ATM PVC is configured, you should issue a shutdown command followed by a no shutdown command on the ATM subinterface to restart the interface, causing the newly configured parameters (such as an IP address) to take effect.

Examples

The following example configures a PVC to support encapsulation for Voice over ATM on the Cisco MC3810: 

pvc 20

encapsulation aal5mux voice

The following example configures a PVC to support encapsulation for Frame Relay-ATM Network Interworking on the Cisco MC3810: 

pvc 21

encapsulation aal5mux frame

The following example configures a PVC to support encapsulation for Frame Relay-ATM Service Interworking on the Cisco MC3810: 

pvc 22

encapsulation aal5mux fr-atm-srv

Related Command

Command
Description

pvc

This interface command creates an ATM PVC for FRF.8 Service Interworking with a corresponding Frame Relay PVC.


frame-relay pvc

To configure Frame Relay PVCs for FRF.8 Frame Relay-ATM Service Interworking, use the frame-relay pvc interface configuration command. The no form of the command removes the PVC.

frame-relay pvc dlci service {transparent | translation} [clp-bit {0 | 1 | map-de}][de-bit {0 | 1 | map-clp}][efci-bit {0 | 1 | map-fecn}] interface atm0 {vpi/vci | vcd}

no frame-relay pvc dlci service {transparent | translation} [clp-bit {0 | 1 | map-de}][de-bit {0 | 1 | map-clp}][efci-bit {0 | 1 | map-fecn}] interface atm0 {vpi/vci | vcd}

Syntax Description

dlci

(Required) A value ranging from 16 to 1007 for the PVC's data-link connection identifier (DLCI). Use this label when you associate a Frame Relay PVC with an ATM PVC.

service {transparent | translation}

(Required) In the transparent mode of Service Interworking, encapsulations are sent unaltered. In translation mode, mapping and translation take place. There is no default.

clp-bit {0 | 1 | map-de}

(Optional) Sets the mode of DE/CLP mapping in Frame Relay to the ATM direction. The default is map-de.

map-de—Specifies Mode 1, which is described in 4.2.1 of FRF.8. The DE field in the Q.922 core frame is mapped to the ATM CLP field of every cell generated by the segmentation process of the AAL5 PDU containing the information of that frame.

0 or 1—Specifies Mode 2 described in 4.2.1 of FRF.8. The ATM CLP of each ATM cell generated by the segmentation process of the AAL5 PDU containing the information of that frame is set to a constant value (either 0 or 1).

de-bit {0 | 1 | map-clp}

(Optional) Sets the mode of DE/CLP mapping in the ATM-to-Frame Relay direction. The default is map-clp.

map-clp—Specifies Mode 1, which is described in 4.2.2 of FRF.8. If one or more cells in a frame has its CLP field set, the Service Interworking function sets the DE field of the Q.922 core frame.

0 or 1—Specifies Mode 2 described in 4.2.2 of FRF.8. The DE field is set to a constant value (either 0 or 1).

efci-bit {0 | 1 | map-fecn}

(Optional) This part of the command sets the mode of Forward Explicit Congestion Notification (FECN) and the ATM Explicit Forward Congestion Indicator (EFCI) in the Frame Relay-to-ATM direction. map-fecn is the default.

0—Sets a constant value rather than mapping.

1—Sets a constant value rather than mapping.

map-fecn—Adheres to Mode 1 and maps the FECN indicators to EFCI indicators.

interface atm0 {vpi/vci | vcd}

(Required) This part of the command maps the Frame Relay PVC to an ATM PVC specified by slot number (0 is the only option for ATM on the Cisco MC3810) and either one of the following labels:

vpi/vci—The virtual path identifier-virtual channel identifier (VPI-VCI) pair for the ATM PVC

vcd—The ATM virtual circuit descriptor (VCD) for the ATM PVC


Defaults

See the syntax description above.

Command Mode

Interface configuration

Command History

Release
Modification

12.0(5)XK and 12.0(7)T

This command was introduced.


Usage Guidelines

Use this command to create Frame Relay PVCs for association with ATM PVCs when you are configuring FRF.8 Frame Relay-ATM Service Interworking on the Cisco MC3810 multiservice access concentrator.

Example

In the example below, two Frame Relay PVCs are configured on a serial interface of a Cisco MC3810. 

 frame-relay pvc 222 service translation clp-bit map-de de-bit map-clp efci-bit 
map-fecn interface ATM0 222/222

 frame-relay pvc 925 service transparent clp-bit map-de de-bit map-clp efci-bit 
map-fecn interface ATM0 92/92

Related Command

Command
Description

pvc

ATM interface configuration command to create ATM PVCs that correspond to Frame Relay PVCs for FRF.8 Service Interworking.


Glossary

AAL—ATM Adaptation Layer. Service-dependent sublayer of the data link layer. The AAL accepts data from different applications and presents it to the ATM layer in the form of 48-byte ATM payload segments. AALs consist of two sublayers: convergence sublayer (CS) and segmentation and reassembly (SAR). AALs differ on the basis of the source-destination timing used, whether they use constant bit rate (CBR) or variable bit rate (VBR), and whether they are used for connection-oriented or connectionless mode data transfer. At present, the four types of AAL recommended by the ITU-T are AAL1, AAL2, AAL3/4, and AAL5.

AAL1—ATM adaptation layer 1. One of four AALs recommended by the ITU-T. AAL1 is used for connection-oriented, delay-sensitive services requiring constant bit rates, such as uncompressed voice.

ATM—Asynchronous Transfer Mode. International standard for cell relay in which multiple service types (such as voice, video, or data) are conveyed in fixed-length (53-byte) cells. Fixed-length cells allow cell processing to occur in hardware, thereby reducing transit delays. ATM is designed to take advantage of high-speed transmission media such as E3, SONET, and T3.

B8ZS—binary 8-zero substitution. Line-code type, used on T1 and E1 circuits, in which a special code is substituted whenever 8 consecutive zeros are sent over the link. This code is then interpreted at the remote end of the connection. This technique guarantees ones density independent of the data stream.

BECN—backward explicit congestion notification. Bit set by a Frame Relay network in frames traveling in the opposite direction of frames encountering a congested path. DTE receiving frames with the BECN bit set can request that higher-level protocols take flow control action as appropriate.

CBR—constant bit rate. QoS class defined by the ATM Forum for ATM networks. CBR is used for connections that depend on precise clocking to ensure undistorted delivery.

CPCS—common part convergence sublayer. One of the two sublayers of any AAL. The CPCS is service-independent and is further divided into the CS and the SAR sublayers. The CPCS is responsible for preparing data for transport across the ATM network, including the creation of the 48-byte payload cells that are passed to the ATM layer.

CS— convergence sublayer. One of the two sublayers of the AAL CPCS, which is responsible for padding and error checking. PDUs passed from the SSCS are appended with an 8-byte trailer (for error checking and other control information) and padded, if necessary, so that the length of the resulting PDU is divisible by 48. These PDUs are then passed to the SAR sublayer of the CPCS for further processing.

DLCI— data-link connection identifier. Value that specifies a PVC or SVC in a Frame Relay network. In the basic Frame Relay specification, DLCIs are locally significant (connected devices might use different values to specify the same connection). In the LMI extended specification, DLCIs are globally significant (DLCIs specify individual end devices).

E1—European digital carrier facility used for transmitting data through the telephone hierarchy. The transmission rate for E1 is 2.048 megabits per second (Mbps).

EFCI—Explicit Forward Congestion Indication. In ATM, one of the congestion feedback modes allowed by ABR service. A network element in an impending congestion state or in a congested state can set the EFCI. The destination end-system can implement a protocol that adaptively lowers the cell rate of the connection based on the value of the EFCI.

ESF—Extended Superframe. Framing type used on T1 circuits that consists of 24 frames of 192 bits each, with the 193rd bit providing timing and other functions. ESF is an enhanced version of Superframe format.

FECN—forward explicit congestion notification. Bit set by a Frame Relay network to inform DTE receiving the frame that congestion was experienced in the path from source to destination. DTE receiving frames with the FECN bit set can request that higher-level protocols take flow-control action as appropriate.

FRF.5—Frame Relay Forum implementation agreement for Frame Relay-to-ATM Network Interworking.

FRF.8—Frame Relay Forum implementation agreement for Frame Relay-to-ATM Service Interworking.

IETF—Internet Engineering Task Force

ILMI—Interim Local Management Interface. Specification developed by the ATM Forum for incorporating network-management capabilities into the ATM User-Network Interface (UNI).

ISDN—Integrated Services Digital Network. Communication protocol, offered by telephone companies, that permits telephone networks to carry data, voice, and other source traffic.

IWF—Interworking Function.

LMI—Local Management Interface

Network Interworking—FRF.5 Frame Relay-to-ATM Network Interworking, where Frame Relay user traffic and PVCs are tunneled transparently over ATM. This function is often used to link Frame Relay networks over an ATM backbone.

NNI—Network-to-Network Interface. ATM Forum standard that defines the interface between two ATM switches that are both located in a private network or are both located in a public network. The interface between a public switch and private one is defined by the UNI standard. Also, the standard interface between two Frame Relay switches meeting the same criteria.

OAM cell—Operation, Administration, and Maintenance cell. ATM Forum specification for cells used to monitor virtual circuits. OAM cells provide a virtual circuit-level loopback in which a router responds to the cells, demonstrating that the circuit is up, and the router is operational.

PDU—protocol data unit

PVC—permanent virtual circuit. Virtual circuit that is permanently established. PVCs save bandwidth associated with circuit establishment and tear down in situations where certain virtual circuits must exist all the time. In ATM terminology, called a permanent virtual connection.

QoS—quality of service. Measure of performance for a transmission system that reflects its transmission quality and service availability.

SAR—segmentation and reassembly. One of the two sublayers of the AAL CPCS, responsible for dividing (at the source) and reassembling (at the destination) the PDUs passed from the CS. The SAR sublayer takes the PDUs processed by the CS and, after dividing them into 48-byte pieces of payload data, passes them to the ATM layer for further processing.

Service Interworking—FRF.8 Frame Relay-to-ATM Service Interworking, where Frame Relay PVCs are mapped to ATM PVCs bidirectionally through protocol conversion functions. This function is often used to migrate Frame Relay network devices or networks selectively or gradually to ATM.

SONET—Synchronous Optical Network. High-speed (up to 2.5 Gbps) synchronous network specification developed by Bellcore and designed to run on optical fiber. STS-1 is the basic building block of SONET.

SVC—switched virtual circuit. Virtual circuit that is dynamically established on demand and is torn down when transmission is complete. SVCs are used in situations where data transmission is sporadic. Called a switched virtual connection in ATM terminology.

T1—Digital WAN carrier facility. T1 transmits DS-1-formatted data at 1.544 Mbps through the telephone switching network, using alternate mark inversion or B8ZS coding.

UNI—User-Network Interface. ATM Forum specification that defines an interoperability standard for the interface between ATM-based products (a router or an ATM switch) located in a private network and the ATM switches located within the public carrier networks. Also used to describe similar connections in Frame Relay networks.

UBR—unspecified bit rate. QoS class defined by the ATM Forum for ATM networks. UBR allows any amount of data up to a specified maximum to be sent across the network, but there are no guarantees in terms of cell loss rate and delay.

VC—virtual circuit. Logical circuit created to ensure reliable communication between two network devices. A virtual circuit is defined by a VPI/VCI pair, and can be either permanent (PVC) or switched (SVC). Virtual circuits are used in Frame Relay and X.25. In ATM, a virtual circuit is sometimes called a virtual channel.

VCI—virtual channel identifier. 16-bit field in the header of an ATM cell. The VCI, together with the virtual path identifier (VPI), is used to identify the next destination of a cell as it passes through a series of ATM switches on its way to its destination. ATM switches use the VPI/VCI fields to identify the next network virtual channel link (VCL) that a cell needs to transit on its way to its final destination.

VCL—virtual channel link. Connection between two ATM devices. A VCC is made up of one or more VCLs.

VPI—virtual path identifier. 8-bit field in the header of an ATM cell. The VPI, together with the VCI, is used to identify the next destination of a cell as it passes through a series of ATM switches on its way to its destination. ATM switches use the VPI/VCI fields to identify the next VCL that a cell needs to transit on its way to its final destination.