|
|
This chapter describes frame relay to ATM interworking which enables frame relay traffic to be connected across high-speed ATM trunks using ATM standard Network and Service Interworking.
The chapter contains the following:
Interworking allows users to retain their existing Frame Relay services, and as their needs expand, migrate to the higher bandwidth capabilities provided by BPX ATM networks. Frame Relay to ATM Interworking enables frame relay traffic to be connected across high-speed ATM trunks using ATM standard Network and Service Interworking.
Two types of Frame Relay to ATM interworking are supported, Network Interworking (Figure 13-1) and Service Interworking (Figure 13-2). The Network Interworking function is performed by the AIT card on the IPX and by the BTM card on the IGX, and the FRSM card on the AXIS. The FRSM card on the AXIS and the UFM cards on the IGX also support Service Interworking. See Figure 13-3 for some examples of ATM to Frame Relay Interworking.
Network Interworking: Part A of Figure 13-1 shows typical frame relay to network interworking. In this example, a frame relay connection is transported across an ATM network, and the interworking function is performed by both ends of the ATM network. The following are typical configurations:
Service Interworking: Part B of Figure 13-1 shows a form of network interworking where the interworking function is performed by only one end of the ATM network, and the CPE connected to the other end of the network must itself perform the appropriate service specific convergence sublayer function. The following are example configurations:
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 (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 AXIS shelf, e.g., ASI, 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 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.
The frame relay to ATM networking interworking function is available as follows:
On the IPX, interworking is performed by the AIT card, and on the IGX by the BTM card. A simplified example of the connection paths is shown in Figure 13-6. In interworking, the AIT card receives FastPackets from the FRP, 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 AIT trunk card is called Complex Gateway. AIT trunk cards are required on every BPX to IPX hop in a Frame Relay to ATM connection's path.
e
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 StrataCom 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 IPX/IGX, an AIT/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 (FRP), 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 FRP/FRM.
At the AIT/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 come to AIT/FRM cards 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 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.
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 AIT/BTM card in the IPX/IGX includes the following functions:
In addition to performing DLCI to VPI/VCI conversion, the network interworking feature provided by the AIT card in the IPX or BTM in the IGX 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 following DE to CLP mapping choices:
The following 2 choices are not available on IPX/IGX NIW (network interworking):
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:
The AIT/BTM does convert OAM cells to OAM fastpackets, and vice-versa, including the AIS OAM. Also, "A-bit" 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 A bit 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 IPX or BPX 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, and bits per second (bps) on the IPX/IGX. 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.
The following user commands are used to provision and modify ATF connections:
The following features are added to the ASI-1 at the port level:
The following user commands are used to configure ASI-1 port features:
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 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 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:
The following user commands are associated with diagnostics changes:
The following virtual circuit features are supported by the ASI-1:
The following user commands are associated with virtual circuit feature changes:
The following user commands are modified to support ASI-1 E3:
Interworking connections may be added from either the BPX, the IPX, the IGX, or the AXIS. 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 end. The IPX does not know about these parameters, so they cannot be configured or displayed at the IPX end. Parameter units are endpoint-specific also. Units on the BPX are cells per second, units on the IPX are bits per second.
Bundled interworking connections are not supported.
Virtual path interworking connections are not supported.
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-IPX hops these connections route over must provide the complex gateway function. IPX-IPX 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 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.
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 nodes. IPX 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.
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).
The NNI cell format has 12 bits for the VPI, so `addcon' allows specification of VPI 0-4095 on NNI ports.
System software supports the following LMI/ILMI signaling actions:
LMI communication failure on an ASI-1 causes declaration of a minor alarm. The `dspport' screen shows the failure, as does the `dspalms' screen.
A-bit = 0 on an NNI port causes declaration of a minor alarm. The `dspcon', `dspcons', and `dspalms' screens show this failure.
Posted: Thu Jan 18 12:23:14 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.