cc/td/doc/product/wanbu/bpx8600/9_2
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Frame Relay to ATM Network
and Service Interworking

Frame Relay to ATM Network
and Service Interworking

This chapter describes Frame Relay to ATM interworking. Frame Relay to ATM Interworking allows users to retain their existing Frame Relay services, and as their needs expand, migrate to the higher bandwidth capabilities provided by BPX switch ATM networks.

This chapter contains the following:



Frame Relay to ATM Interworking enables frame relay traffic to be connected across high-speed ATM trunks using ATM standard Network and Service Interworking (see Figure 13-1 and Figure 13-2).

Two types of Frame Relay to ATM interworking are supported, Network Interworking and Service Interworking. The Network Interworking function is performed by the BTM card on the IGX switch. The FRSM card on the MGX 8220 supports both Network and Service Interworking. See Figure 13-3 for some examples of ATM to Frame Relay Interworking.


Figure 13-1: Frame Relay to ATM Network Interworking

Figure 13-2:
Frame Relay to ATM Service Interworking

Figure 13-3:
Frame Relay to ATM Interworking Examples with BTM Card on IGX Switch


Service Interworking

In Service Interworking, for example, for a connection between an ATM port and a frame relay port, unlike Network Interworking, the ATM device does not need to be aware that it is connected to an interworking function. The ATM device uses a standard service specific convergence sublayer, instead of using the Frame Relay FR-SSCS (see Figure 13-4).

The frame relay service user does not implement any ATM specific procedures, and the ATM service user does not need to provide any frame relay specific functions. All translational (mapping functions) are performed by the intermediate IWF. The ATM endpoints may be any ATM UNI/NNI interface supported by the MGX 8220, e.g., BXM, ASI, AUSM. Translation between the Frame Relay and ATM protocols is performed in accordance with RFC 1490 and RFC 1483.


Figure 13-4: Frame Relay to ATM Service Interworking Detail


Networking Interworking

In Network Interworking, in most cases, the source and destination ports are frame relay ports, and the interworking function is performed at both ends of the connection as shown in Part A of Figure 13-5.

If a frame relay port is connected across an ATM network to an ATM device, network interworking requires that the ATM device recognize that it is connected to an interworking function (frame relay, in this case). The ATM device must then exercise the appropriate service specific convergence sublayer (SSCS), in this case the frame relay service specific convergence sublayer (FR-SSCS) as shown in Part B of Figure 13-5.


Figure 13-5: Frame Relay to ATM NW Interworking Detail


The frame relay to ATM networking interworking function is available as follows:

On the IGX switch, interworking is performed by the BTM card. A simplified example of the connection paths is shown in Figure 13-6. In interworking, the BTM card receives FastPackets from the FRM, rebuilds the frames, and converts between frames and ATM cells. Data is removed from one package and placed in the other. Congestion information from the header is mapped to the new package. This processing by the BTM trunk card is called Complex Gateway. BTM trunk cards are required on every BPX switch to IGX switch hop in a Frame Relay to ATM connection's path.


Figure 13-6: ATF Connections, Simplified Example


The cells within the frame are expected to possess the standard ATM Access Interface cell header. The traffic is assumed to have AAL-5 PDUs, and will not function properly otherwise (framing errors will result). Within the AAL-5 PDUs, the data must be packaged in standard frame relay frames, one frame per PDU (with respect to the AAL-5 layer).

The UPC and ForeSight algorithms are applied according to their configured values. The cell headers are converted into the proprietary Cisco WAN switching STI format before entering the network. The cells are delivered to their destination according to the configured route of the connection. Cells can be lost due to congestion.

Discard selection is based upon the standard CLP bit in the cells. When the routing path enters an IGX switch, a BTM card which supports Interworking traffic is required to convert the connection data from cells to frames (frames to fastpackets out onto MuxBus to FRP/cell bus to FRM), and visa versa. Additionally, the AAL-5 framing is removed upon conversion to frames, and added upon conversion to cells. At the destination (FRM), FastPackets are placed in the port queue and, when a complete frame has been assembled, the frame is played out the remote port in the original format (as provided in the frames delivered inside AAL-5 PDUs).

For each connection, only a single dlci can be played out for all traffic exiting the port, and is inserted into the frame headers. The standard LAPD framing format is played out the port on the FRM.

At the FRM card, several additional protocol mappings take place. First, the Interworking Unit acts as a pseudo endpoint for the purposes of ATM for all constructs which have no direct mapping into Frame Relay, such as loopbacks and FERF indications. Thus, end-to-end loopback OAM cells which ingress to FRM cards from the network are returned to the ATM network without allowing them to proceed into the Frame Relay network, which has no equivalent message construct. Further, AIS and supervisory cells and FastPackets (from the Frame Relay direction) are converted into their counterparts within the other network.

ATM Protocol Stack

A general view of the ATM protocol layers with respect to the Open Systems Interconnection model is shown in Figure 13-7. In this example, a large frame might be input into the top of the stacks. Each layer performs a specific function before passing it to the layer below. A protocol data unit (PDU) is the name of the data passed down from one layer to another and is the Service Data Unit (SDU) of the layer below it. For Frame Relay to ATM interworking, a specific convergent sublayer, Frame Relay Service Specific Convergent Sublayer, FR-SSCS is defined. This is also referred to as FR-CS, in shortened notation.


Figure 13-7: ATM Layers

BTM Interworking and the ATM Protocol Stack

ATM to Frame Relay interworking (ATF) performs various tasks including the following:

Figure 13-8 depicts the function of the protocol stack layers in the interworking between ATM and Frame Relay PDUs. Interworking by the BTM card in the IGX switch includes the following functions:


Figure 13-8: Protocol Stack Operation

BTM Control Mapping, Frames and Cells

In addition to performing DLCI to PVC/VCC conversion, the network interworking feature provided by the BTM in the IGX switch maps cell loss priority, congestion information, and management information between frame relay and ATM formats as follows:

CELL LOSS PRIORITY, Frame Relay to ATM Direction

Each frame relay to ATM network interworking connection can be configured as one of the following DE to CLP mapping choices:

The following 2 choices are not available on IGX switch NIW (network interworking):

CELL LOSS PRIORITY, ATM to Frame Relay Direction

Each frame relay to ATM network interworking connection can be configured as one of the following CLP to DE mapping choices:

The following choice is not available:

CONGESTION INDICATION, Frame Relay to ATM direction
CONGESTION INDICATION, ATM to Frame Relay Direction
For PVC Status Management

The AIT/BTM does convert OAM cells to OAM fastpackets, and vice-versa, including the AIS OAM. Also, "Abit" status is now propagated via software messaging.

The ATM layer and frame relay PVC Status Management can operate independently. The PVC status from the ATM layer will be used when determining the status of the FR PVCs. However, no direct actions of mapping LMI Abit to OAM AIS will be performed.

Management, OAM Cells

OAM cell processing:

Functional Description

ATF Summary

Features

Limitations

Some ATF Connection Criteria

ATF connections are allowed between any combination of ATM and Frame Relay UNI and NNI ports. Virtual circuit connections are allowed. Virtual path connections are not.

ATF connections can be mastered by the IGX switch or BPX switch end.

ATF bundled connections and ATF point-to-point connections are not supported.

ATF connections use the frame relay trunk queues: bursty data A for non-ForeSight, bursty data B for ForeSight.

Bandwidth related parameters are defined using cells per second (cps) on the BPX switch and bits per second (bps) on the IGX switch. On a given endpoint node, the bandwidth parms for both ends of the ATF connection are changed/displayed using this end's units. This saves the user from having to convert from cps to bps repeatedly.

ATF connections use the VBR egress queue on the ASI-1 card. ATF with ForeSight connections use the ABR egress queue.

Connection Management

The following user commands are used to provision and modify ATF connections:

Port Management

The following features are added to the ASI-1 at the port level:

Structure

The NNI format supports a 12-bit VPI. Abit status changes are passed to the remote end of the connection.

The ILMI MIB and protocol was implemented in release 7.2. The additional support in consists of an activation and configuration interface, collection of statistics, and end-to-end status updates.

The LMI Annex G protocol was implemented in release 7.2. The additional support consists of an activation and configuration interface, collection of statistics, and end-to-end status updates.

Each of the pre-defined ASI-1 port egress queues can be configured by the user. These queues consist of CBR, VBR, and VBR with ForeSight (ABR). The configurable parameters are queue depth, EFCN threshold, and CLP thresholds.

Backward congestion management cells indicate congestion across the UNI or NNI. Transmission of these cells is enabled on a per-port basis. Software allows BCM to be configured on a UNI or NNI port for maximum flexibility should BCM over UNI be standards-defined.

The following user commands are used to configure ASI-1 port features:

Channel Statistics

Statistics are supported on a per-channel basis. A range of traffic and error statistics are available. ASI-1 channel statistics are enabled by StrataView+ or by the BPX switch control terminal using the existing statistics mechanism. The existing collection intervals apply.

Channel statistics of the following general types are supported:

The following user commands are used to configure and display channel statistics:

OAM Cell Support

OAM cells are detected and transmitted by the ASI-1 firmware. System software displays alarm indications detected by the firmware. Additionally, loopbacks between the ATM-UNI and the ATM-CPE can be established. ForeSight round-trip delay cells are generated by firmware upon software request.

System software deals with the following OAM cell flows:

The following user commands are associated with OAM cell status changes:

Diagnostics

Loopbacks

Card Tests

Connection Tests

User Commands

The following user commands are associated with diagnostics changes:

Virtual Circuit Features

The following virtual circuit features are supported by the ASI-1:

  Connection groups are supported for ASI-1 and BXM ATM Band interworking connection types, allowing termination of up to 5000 (grouped) virtual circuits per BPX switch. The connection grouping feature currently available on frame relay connections is expanded to include ASI-1 and BXM ATM and interworking connections.
  Frame-Based Generic Cell Rate Algorithm is an ASI-1 firmware feature that controls admission of cells to the network. It is configurable on a per-connection basis. It is a Cisco WAN switching enhancement of the ATM-UNI standard Generic Cell Rate Algorithm. System software allows configuration of FGCRA on a per-connection basis.
  Initial Burst Size is an ATM bandwidth parameter that is used by firmware to allow short initial bursts, similar to the Cmax mechanism on the IGX switch. It is configurable on a per-connection basis
  The entire range of VPI and VCI on both UNI and NNI interfaces is supported. For ATM-UNI, 8 bits of VPI and 16 bits of VCI are supported. For ATM-NNI, 12 bits of VPI and 16 bits of VCI are supported. In either case, VPC connections only pass through the lower 12 bits of the VCI field.
  ATM and interworking connection classes are defined with appropriate bandwidth parameter defaults. These classes only apply at addcon time. They are templates to ease the user's task of configuring the large number of bandwidth parameters that exist per connection.

User Commands

The following user commands are associated with virtual circuit feature changes:

AUser Commands

The following user commands are modified to support ASI-1 E3:

Management

Connection Management

Interworking connections may be added from either the BPX switch, the IGX switch, or the MGX 8220. Intra- and inter-domain interworking connections are supported.

Connection configuration parameters are endpoint-specific. Thus, the ATM-only parameters are only configurable on the BPX switch end. The IGX switch does not know about these parameters, so they cannot be configured or displayed at the IGX switch end. Parameter units are endpoint-specific also. Units on the BPX switch are cells per second, units on the IGX switch are bits per second.

Bundled interworking connections are not supported.

Virtual path interworking connections are not supported.

Routing

Interworking connections use the complex gateway feature of the AIT trunk card to repackage data from frames to ATM cells, and vice-versa. All BPX switch-IGX switch hops these connections route over must provide the complex gateway function. IGX switch-IGX switch hops (frame relay connections) can be any trunk card type. This requirement simplifies the routing mechanism when dealing with structured networks, as software does not know the type of trunks in remote domains.

Bandwidth Management

Bandwidth calculations for interworking connections assume a large frame size, which minimizes the loading inefficiency of packets vs. cells. In other words, the translation between packets and cells assumes 100 percent efficiency, so the conversion is simply based on 20 payload bytes per fastpacket vs. 48 payload bytes per ATM cell.

This mechanism keeps the fastpacket/cell conversion consistent with the bits per second/cells per second conversion. Thus, conversion of endpoint rates to trunk loading is straightforward.

User Interface

ATM connection classes are added for convenience. Classes can be configured as interworking or regular ATM. The cnfcls command is used to configure a class. The class is specified as part of the addcon command. ATM connection classes are maintained on all BPX switch. IPX switch nodes do not know about these classes.

A special ATM class is defined as the default interworking class. When an interworking connection is added from the frame relay end, the ATM-only parameters for this connection are taken from this default class.

Network-wide ForeSight parameters are supported for the frame relay end of interworking connections. The cnffstparm command is used to configure these parameters. Since the ATM end of interworking connections has per-virtual circuit ForeSight parameter configurability, the network-wide ForeSight parameters do not apply.

Note that the default ATM ForeSight parameters will match the default frame relay ForeSight parameters, with appropriate units conversion.

Port Management

The cnfport command supports the following new features:

The cnfportq command supports configuration of queue depth, EFCN threshold, and CLP thresholds for all port egress queues (CBR, VBR, VBR w/ForeSight).

Connection Management

The NNI cell format has 12 bits for the VPI, so addcon allows specification of VPI 0-4095 on NNI ports.

Signaling

System software supports the following LMI/ILMI signaling actions:

Alarms

LMI communication failure on an ASI-1 causes declaration of a minor alarm. The dspport screen shows the failure, as does the dspalms screen.

Abit = 0 on an NNI port causes declaration of a minor alarm. The dspcon, dspcons, and dspalms screens show this failure.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Sun Jan 14 18:38:18 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.