|
|
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.
This chapter describes Frame Relay to ATM interworking:
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:
See Figure 22-3 for some examples of ATM-to-Frame Relay 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.
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.
These Frame Relay-to-ATM networking interworking functions are available:
On the IGX switch, interworking is performed by the BTM card.
A simplified example of the connection paths is shown in Figure 22-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.
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 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 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.
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.
ATM to Frame Relay interworking (ATF) performs these tasks:
Figure 22-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 these functions:
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:
Each Frame Relay to ATM network interworking connection can be configured as one of the DE to CLP mapping choices:
These 2 choices are not available on IGX switch NIW (network interworking):
Each Frame Relay to ATM network interworking connection can be configured as one of the CLP to DE mapping choices:
This choice is not available:
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.
OAM cell processing:
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.
Use these commands to provision and modify ATF connections:
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:
Use these commands to configure and display channel statistics:
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 these OAM cell flows:
These commands are associated with OAM cell status changes:
Loopbacks
Card Tests
Connection Tests
These commands are associated with diagnostics changes:
The following virtual circuit features are supported:
These commands are associated with virtual circuit feature changes:
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.
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-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 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.
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.
The cnfport command supports these features:
The cnfportq command supports configuration of queue depth, EFCN threshold, and CLP thresholds for all port egress queues (Cbr, Vbr, Vbr with ForeSight).
System software supports these LMI/ILMI signaling actions:
Abit = 0 on an NNI port causes declaration of a minor alarm. The dspcon, dspcons, and dspalms screens show this failure.
Posted: Fri Jul 27 17:46:44 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.