|
|
Table Of Contents
Configuring Frame Relay to ATM Network and Service Interworking
Configuring Frame Relay to ATM Network and Service Interworking
This chapter describes Frame Relay to ATM interworking.
Frame Relay to ATM Interworking lets you retain your existing Frame Relay services, and as your needs expand, migrate to the higher bandwidth capabilities provided by BPX switch ATM networks.
Contents of this chapter include:
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 22-1 and Figure 22-2).
Two types of Frame Relay to ATM interworking are supported:
•
Network Interworking—Specifies that the performance is done by the UXM card on the IGX switch and the FRSM card on the MGX 8220.
•
For some examples of ATM-to-Frame Relay Interworking, see Figure 22-3.
Figure 22-1 Frame Relay to ATM Network Interworking
Figure 22-2 Frame Relay to ATM Service Interworking
Figure 22-3 Frame Relay to ATM Interworking Examples with UXM Card on IGX Switch
Service Interworking
In Service Interworking, the ATM port connected to a Frame Relay port does not need to be aware that it is connected to an interworking function. However, in Network Interworking, the ATM device does 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 22-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 or MGX 8800, such as BXM and AUSM. Translation between the Frame Relay and ATM protocols is performed in accordance with RFC 1490 and RFC 1483.
Figure 22-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 22-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 22-5.
Figure 22-5 Frame Relay to ATM NW Interworking Detail
The following are the Frame Relay-to-ATM networking interworking functions:
•
•
•
•
•
On the IGX switch, interworking is performed by the UXM card.
A simplified example of the connection paths is shown in Figure 22-6. In interworking, the UXM 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 UXM trunk card is called Complex Gateway. UXM trunk cards are required on every BPX switch to IGX switch hop in a Frame Relay to the ATM connection path.
Figure 22-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 that supports Interworking traffic is required to convert the connection data from cells to frames (frames to fastpackets out onto MuxBus to cell bus to FRM), and so forth.
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 that have no direct mapping into Frame Relay, such as loopbacks and FERF indications. Thus, end-to-end loopback OAM cells that 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 22-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 22-7 ATM Layers
OAM Cells
OAM cell processing:
•
•
•
•
ATF Features
•
•
•
•
•
•
•
•
•
•
•
•
•
ATF Limitations
•
•
•
•
•
•
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 you from having to convert from cps to bps repeatedly.
ATF with ForeSight connections use the ABR egress queue.
ATF Connection Management
The following are the commands used to provision and modify ATF connections:
•
•
•
•
•
•
•
Structure
•
•
•
•
•
Channel Statistics
Statistics are supported on a per-channel basis. A range of traffic and error statistics are available.
Channel statistics of these general types are supported:
•
•
•
The following are the commands used to configure and display channel statistics:
•
•
•
•
•
OAM Cell Support
OAM cells are detected and transmitted by 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 are the commands associated with OAM cell status changes:
•
•
•
•
•
Diagnostics
Loopbacks
•
•
Card Tests
Connection Tests
•
Commands
The following are the commands associated with diagnostics changes:
•
•
•
•
•
•
•
•
Virtual Circuit Features
The following virtual circuit features are supported:
•
•
•
•
•
Commands
The following are the commands that are associated with virtual circuit feature changes:
•
•
•
•
•
•
•
•
•
Connection Management
Interworking connections may be added from either the BPX switch, the IGX switch, the MGX 8800, 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.
Because the NNI cell format has 12 bits for the VPI, the command addcon allows specification of VPI 0-4095 on NNI ports.
Routing
Interworking connections use the complex gateway feature of the UXM card to repackage data from frames to ATM cells, and so forth. All BPX switch-IGX switch hops these connections route over must provide the complex gateway function.
IGX-to-IGX hops (Frame Relay connections) can be any trunk card type. This requirement simplifies the routing mechanism when dealing with structured networks, because 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 versus 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.
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 features:
•
•
The cnfportq command supports configuration of queue depth, EFCN threshold, and CLP thresholds for all port egress queues (CBR, VBR, VBR with ForeSight).
Signaling
System software supports the following LMI/ILMI signaling actions:
•
•
•
Alarms
Abit = 0 on an NNI port causes declaration of a minor alarm. The dspcon, dspcons, and dspalms screens show this failure.
Posted: Tue May 10 21:17:05 PDT 2005
All contents are Copyright © 1992--2005 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
