Frame Relay has enjoyed much success with end users primarily because of its increased performance and reduced cost. Asynchronous Transfer Mode (ATM), commonly known as cell relay, is a popular WAN technology broadly deployed on high-speed networks. ATM delivers higher availability and speed over Frame Relay and is the most widely deployed backbone technology. Both Frame Relay and ATM networks are widespread today. Each protocol is unique in its own way, and each has its own advantages. This chapter explains Cisco's implementation of the Frame Relay to ATM Interworking feature, which provides the functionalities to allow disparate Frame Relay and ATM networks to communicate and exchange information despite their dissimilar network protocols.
This chapter explains the main reasons for connecting Frame Relay networks with ATM networks. This chapter focuses on the Frame Relay Forum Implementation Agreements Document Number FRF.5 and Document Number FRF.8.1, largely the basis for Cisco Frame Relay to ATM Interworking feature. The key differences between FRF.5 and FRF.8.1 will be discussed. Then, this chapter introduces the Cisco router products capable of supporting both methods of implementation. Subsequently, this chapter explains the configuration tasks and the Cisco IOS commands for configuring FRF.5 and FRF.8.1 on the supported Cisco platforms. Finally, this chapter demonstrates the relevant Cisco IOS show and debug commands for monitoring and troubleshooting FRF.5 and FRF.8.1 on Cisco routers.
NOTE
The Frame Relay Forum Implementation Agreements FRF.5 and FRF.8.1 can be downloaded from http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf. and http://www.mplsforum.org/frame/Approved/FRF.8/FRF.8.1.pdf.
This chapter begins with a brief overview of the fundamentals of the ATM technology. Because this book focuses on Frame Relay, a basic understanding of the ATM technology is assumed, and this chapter does not go extensively into explaining how the ATM protocol works. ATM technology and the Cisco ATM features are well explained in Cisco Press's Cisco ATM Solutions by Galina Diker Pildush (ISBN: 1578702135). Alternatively, a beginner's guide on ATM can be downloaded from the ATM Forum (http://www.atmforum.com/aboutatm/guide.html).
The topics and questions that this chapter addresses include the following:
A brief overview of ATM technology
The requirements for Frame Relay and ATM Interworking
Frame Relay Forum Implementation Agreement FRF.5
Frame Relay Forum Implementation Agreement FRF.8.1
Configuring FRF.5 and FRF.8.1 on Cisco routers
Monitoring and maintaining FRF.5 and FRF.8.1 on Cisco routers
After completing this chapter, readers will understand ATM as a reliable high-speed backbone technology. Readers will recognize the benefits of interworking Frame Relay with ATM networks by converging the two completely different data link layer protocols. Readers will become familiar with the basic operations of the two implementation agreements that are defined by the Frame Relay Forum: FRF.5 and FRF.8.1. Readers will also become familiar with the tasks and the Cisco IOS commands required to configure FRF.5 and FRF.8.1 on Cisco routers. Finally, readers will be able to monitor and maintain FRF.5 and FRF.8.1 configurations on Cisco routers using Cisco IOS show and debug commands.
ATM is a reliable and high-speed data link layer technology that guarantees a certain or predefined quality of service for voice, video, or data traffic. The history of the ATM technology dates back to 1980. At that time, the high demand for fast speed and reliable access over long distances led the ITU-T and other standards groups to establish an industry standard for Broadband Integrated Services Digital Network (B-ISDN). The new generation of networks defined by the B-ISDN standard would offer bandwidth greater than those provided by the Narrowband Integrated Services Digital Networks (N-ISDN). By 1990, ATM technology provided B-ISDN with the capability to offer subscribers a large variety of high speed services at variable data rates.
Today, ATM is a broadband technology commonly deployed within core backbone networks over optical infrastructures to switch voice, video, or data packets at ultrahigh speeds. ATM is easy to manage and provides sophisticated Quality of Service (QoS) features in the different layers of the ATM protocol. These features make ATM extremely robust and suitable for supporting multimedia traffic. ATM is designed to support high-speed networks at data rates greater than those of Frame Relay, such as OC-192 (10 Gbps). Moreover, ATM requires dedicated hardware built on Application Specific Integrated Circuit (ASIC), which enables faster processing on the interface.
Like Frame Relay, ATM transports data via virtual circuits (VCs), either permanent (PVCs) or switched (SVCs), which are used to switch users' data from the source to the destination.
Unlike the Frame Relay protocol, which uses a variable-length frame, ATM employs a fixed-length packet format of 53 bytes, most commonly referred to as a cell. ATM uses the segmentation and reassembly (SAR) function in the ATM Adaptation Layer (AAL) to divide information handed down from the upper layers into these 53-byte cells. Out of the 53 bytes in the ATM cell, 5 bytes are reserved for the ATM header, and the remaining 48 bytes make up the payload. These fixed-length cells are sent into the ATM network to their destination, where they are reassembled by the remote ATM equipment. A cyclic redundancy check (CRC), known as the Header Error Control (HEC), is computed in the ATM headers to allow the destination ATM device to detect bit errors, loss of cells, or cells that are out of sequence.
Figure 8-1 illustrates a standard ATM cell comprised of a 5-byte header and a 48-byte information field. Inside the ATM cell header, there is a 12-bit virtual path identifier (VPI) field, which is used to identify the virtual path in the ATM circuit. The 16-bit virtual circuit identifier (VCI) field is used to identify the VC within a virtual path. In many situations, the virtual path can be thought of as a bundle or collection of VCs. The function of the VCI is similar to the role played by the DLCI in Frame Relay.
NOTE
On Cisco routers, it is possible to change the value of the VCI in the virtual path configurations to increase the range of the VPI.
The 3-bit payload type (PT) field is used to indicate whether the ATM cell consists of user or control data. The 1-bit cell loss priority (CLP) functions very much like the discard eligibility (DE) bit in the standard Frame Relay headers. It is used to indicate whether the cell should be discarded if it encounters extreme congestion as it moves through the ATM network. Then the 8-bit HEC field is used to calculate the checksum of the headers. Finally, the information field makes up the remaining 48 bytes to create the entire 53-byte ATM cell.
Frame Relay has became immensely popular because it is an efficient and simple protocol designed to transport data traffic effectively up to the data rates of T3/E3 without incurring the excessive overheads commonly present in WAN protocols such as X.25. The resultant popularity of Frame Relay services has led to a rapid growth of high concentrations of low-speed remote Frame Relay connections. However, because of Frame Relay's simplicity, the basic Frame Relay protocol lacks the necessary features, such as differentiated classes of service, QoS, and class of service, to support multiservice networks. On the contrary, ATM is able to make up for what Frame Relay can't deliver. ATM is designed to support a wide range of service requirements and to provide different QoS service levels at very high speeds: OC-3 (155 Mbps), OC-12 (655 Mbps), OC-48 (2.4 Gbps), or higher. For this reason, Frame Relay and ATM technologies complement each other perfectly.
Figure 8-2 shows a converged hybrid network where Frame Relay service users running at speeds lower than T3/E3 are connecting to the higher-speed ATM backbone running at DS3 (44Mbps) or faster. Service providers recognize the benefits of connecting lower-speed Frame Relay networks to the high-speed ATM backbones to improve economies of scale and network scalability. The ATM backbone is used as an alternative to a leased line and provides cost savings over leased lines. With Frame Relay to ATM Interworking, end users can adopt the technology best suited to their needs at their location and ensure optimization of price and performance. Moreover, a hybrid network helps to smooth evolution between different emerging technologies and lowers the overall cost of network ownership.
The functional specifications of network interworking between Frame Relay and ATM are defined in the Frame Relay Forum Implementation Agreement Document Number FRF.5. FRF.5 describes the implementation agreement on PVC network interworking between Frame Relay and ATM protocols, jointly agreed upon by the Frame Relay Forum and the ATM Forum. The complete FRF.5 documentation can be downloaded from the Frame Relay Forum's web site address at http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf.
FRF.5, also known as Frame Relay/ATM PVC Network Interworking, allows two Frame Relay peer devices to communicate with each other via an interworking function over an ATM network supporting FRF.5. As you shall see later in the “Frame Relay Forum Implementation Agreement Document Number FRF.8.1” section on FRF.8.1, FRF.5 is in contrast with FRF.8.1 service interworking. In the latter case, a Frame Relay service user interoperates directly with an ATM service user.
The interworking function can be a part of the Frame Relay or ATM device, or it can be a standalone device that interfaces directly between the Frame Relay and ATM networks. The specifications in FRF.5 do not indicate where the interworking function needs to be placed.
Figure 8-3 illustrates the possible locations for the interworking function.
As shown in Figure 8-3, there are three possible configurations where the interworking function can be placed. The main purpose of the network interworking function is to translate between the Frame Relay and ATM protocol stacks connecting the Frame Relay and ATM networks.
A user's applications have no knowledge of the interworking function taking place at the network edge. Data from the upper layers is transported over Frame Relay, over ATM, and then over Frame Relay again at the final destination. The network interworking function is totally transparent to the Frame Relay end devices, meaning the Frame Relay service users have no knowledge that they are connected to each other over an ATM network. Figure 8-4 illustrates a typical diagram of an FRF.5 network, whereby the interworking function performs the protocol translation process between the Frame Relay and ATM protocol stacks.
In this section, note the new terms observed in the ATM protocol stacks: Frame Relay Service Specific Convergence Sublayer (FR-SSCS) and Common Part Convergence Sublayer (CPCS). These terms are used often in the discussion of Frame Relay to ATM interworking. Recall from Chapter 1, “Introduction to Frame Relay,” that the standard Q.922 Frame Relay basic header structure consists of a 2-byte address field. The standard Frame Relay frame is revisited in Figure 8-5.
Compare the format of the Q.922 Frame Relay headers in Figure 8-5 with the format of the FR-SSCS protocol data unit (PDU) in the next figure (Figure 8-6). The FR-SSCS uses a PDU format almost identical to the Q.922 Frame Relay headers (both are 2 bytes long) but without the FCS and flags. The FRF.5 implementation agreement specifies a default FR-SSCS format with a 2-byte address field. The use of a 4-byte address field is specified, but its implementation is optional. The 3-byte address field format is not used presently. Cisco's implementation only supports the default FR-SSCS format.
When a Frame Relay frame enters an ATM network, the interworking function translates the protocol by creating a FR-SSCS frame out of the standard Frame Relay frame. The resultant FR-SSCS frame is placed in a CPCS PDU and is handed to the ATM protocol stacks. In fact, this process involves a direct mapping from the address field in the Q.922 Frame Relay header to the address field in the FR-SSCS.
Then the CPCS sublayer adds an 8-byte trailer to the frame that includes a 32-bit CRC checksum computed across the entire PDU to provide error detection over the FR-SSCS PDU. In addition, a length field and padding bits are added in the trailer to ensure that the CPCS-PDU has a size that is an integral multiple of 48 bytes. This becomes the payload of the ATM cells. There are two 1-byte fields in the trailers that are unused: Common Part Indicator (CPI) and CPCS User-to-User notification (CPCS-UU). After the CPCS-PDU is constructed, the CPCS sublayer hands the CPCS PDU to the SAR function.
The step performed by the CPCS sublayer to insert padding bits into the PDU is vital to the SAR function. The CPCS function allows the SAR sublayer to segment the CPCS PDU equally into 48-byte blocks. Then the ATM layer places each 48-byte block into the payload field of an ATM cell. The 5-byte ATM headers are appended to each 48-byte payload field to construct a 53-byte ATM cell ready for transmission. The functions performed by CPCS and SAR sublayers are collectively known as ATM adaptation layer 5 (AAL5).
Cisco's implementation of FRF.5 allows a single VC or multiple (many-to-one) Frame Relay VCs from the same interface to be mapped to a single ATM VC. Many-to-one multiplexing is done by mapping the DLCI address field in the FR-SSCS PDU to the ATM VPI/VCI value of the outgoing ATM VC. Both one-to-one and many-to-one multiplexing methods are supported by Cisco. Figure 8-7 illustrates the state when multiple DLCIs are multiplexed to a single ATM VC.
In Figure 8-7, a frame is delivered from a host to the router performing the interworking function on DLCI 200. Because the router is configured to map DLCI 200 to VPI/VCI 2/10, the router sends the frame received on DLCI 200 from the Frame Relay network to its remote destination over the ATM network on VPI/VCI 2/10. At the destination, the end router performing the interworking function strips off the ATM headers and inspects the FR-SSCS address field. The address field indicates a destination DLCI of 200, and the end router delivers the frame on DLCI 200 to its destination host.
Figure 8-8 illustrates how the fields in the FR-SSCS PDU are mapped to the relevant fields in an ATM cell to allow multiplexing of multiple Frame Relay VCs to one ATM VC.
Referring to Figure 8-8, it is evident that both Frame Relay DLCI and the ATM VPI/VCI pair have an equivalent purpose; they are fields used in their respective protocol headers to identify a VC. During Frame Relay frame to ATM cell multiplexing, the value of the Frame Relay DLCI is mapped to the corresponding ATM VPI/VCI fields to identify a VC on the ATM network. Next, the congestion notification fields in the Frame Relay headers (FECN, DE bits) are mapped to the corresponding fields in the ATM headers (CLP, EFCI). This allows the network to preserve the congestion information across the Frame Relay and ATM boundary.
Therefore, using the FR-SSCS to ATM VPI/VCI mapping, it is possible to multiplex multiple Frame Relay DLCIs to a single ATM VC. The same approach is used to demultiplex the ATM VPI/VCI to the Frame Relay DLCIs at the destination.
NOTE
For one-to-one connections, the default FR-SSCS DLCI value of 1022 is used. The FR-SSCS value is user-configurable in the IOS and is in the range of 16 to 991.
If you decide not to use the default FR-SSCS value of 1022 when configuring multiplexing between multiple Frame Relay VCs to one ATM VC, you must ensure that the interworking functions at both legs of the network are referring to the common FR-SSCS value. Otherwise, the interworking function receiving the ATM cells would not be able to map the DLCI field in the FR-SSCS to the DLCI in the Q.922 headers correctly. This will be emphasized later in the configuration section.
The 1-bit CLP field in the ATM headers performs a function almost identical to the DE bit in the Frame Relay headers. The CLP field indicates the drop-priority of the cell if it encounters extreme congestion as it moves through the ATM network. The value of 0 indicates higher priority, and the value of 1 indicates lower priority. In other words, setting the CLP bit to 1 lowers the priority of the cells and increases the likelihood that the cell will be dropped when the ATM network experiences congestion on the physical lines or buffer queues.
NOTE
Take note that not all ATM carriers provide QoS based on the Frame Relay DE bit or ATM CLP bit for all types of traffic. This is largely dependent on the differentiated service categories supplied by the carriers.
Both FRF.5 and FRF.8.1 implementation agreements outline several options for supporting the Frame Relay DE bit to the ATM CLP bit mapping. Cisco's Frame Relay to ATM interworking implementation supports all of the options stipulated in FRF.5 and FRF.8.1 regarding DE to CLP bit mapping.
Two modes are available to network providers when mapping the Frame Relay DE bit to the ATM CLP bit for all traffic in the Frame Relay to ATM direction. Both of these modes, and the specifications for the Frame Relay to ATM direction stated in FRF.5, are given in Table 8-1.
Table 8-1. DE to CLP Mapping for Frame Relay to ATM Direction for FRF.5
Mode 1 | The Discard Eligibility field in the Q.922 frame shall be mapped unchanged into the DE field in the FR-SSCS PDU header and mapped to the ATM CLP bit of every ATM cell generated by the segmentation process of that frame. |
Mode 2 | The Discard Eligibility field in the Q.922 frame shall be mapped unchanged into the DE field in the FR-SSCS PDU header, and the ATM CLP bit of every ATM cell generated by the segmentation process of that frame shall be set to a constant value (0 or 1), as determined by the user at setup. |
All Cisco platforms that support FRF.5 allow both modes of operation explained in Table 8-1 to be configured. Mode 1 is the default behavior when FRF.5 is configured on Cisco platforms. Alternatively, the user can set the CLP bit in the ATM cell header to a constant 0 or 1 as outlined in mode 2. Example 8-1 makes use of the network setup depicted in Figure 8-4 to demonstrate the default behavior described in mode 1 for FRF.5.
In Example 8-1, R1 sends out 10 packets (payload size 100 bytes) with the DE bits marked to the destination R4 over its Frame Relay PVC connected to R2. This can be easily done by configuring frame-relay de-list at R1 and applying it to the outgoing interface with the frame-relay de-group interface configuration command.
R2 is the router performing the FRF.5 network interworking function between Frame Relay and ATM. The show frame-relay pvc command performed at R2 indicates that 10 frames are received with the DE bit set. By the default behavior expressed in mode 1, R2 maps the DE bit to the ATM CLP bit for every ATM cell generated into the ATM network. The show atm vc interface {interface name} {vpi} {vci} command performed at the ATM LS1010 switch reveals that 30 ATM cells with the CLP bit set are received. Notice that the LS1010 switch has received 30 ATM cells for the 10 Frame Relay frames R1 has sent. This ratio is normal. Recall that the ATM AAL5 layer divides the payloads into equal blocks of 48 bytes. Because the average size of every packet sent is roughly 124 bytes (100 bytes payload plus 4 bytes Frame Relay headers plus 20 bytes IP header), this works out to a ratio of about three ATM cells generated to one Frame Relay frame received.
Example 8-1. DE Bit to CLP Bit Mapping in the Frame Relay to ATM Direction
R2#show frame-relay pvc 16 PVC Statistics for interface Serial1/3 (Frame Relay DCE) DLCI = 16, DLCI USAGE = FRF.5, PVC STATUS = ACTIVE, INTERFACE = Serial1/3 input pkts 11 output pkts 11 in bytes 1403 out bytes 1378 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 10 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 switched pkts 11 Detailed packet drop counters: no out intf 0 out intf down 0 no out PVC 0 in PVC down 0 out PVC down 0 pkt too big 0 shaping Q full 0 pkt above DE 0 policing drop 0 pvc create time 16:19:42, last time pvc status changed 16:17:11 LS1010#show atm vc interface atm4/0/0 1 32 Interface: ATM4/0/0, Type: t1suni VPI = 1 VCI = 32 Status: UP Time-since-last-status-change: 00:00:26 Connection-type: PVC Cast-type: point-to-point Packet-discard-option: disabled Usage-Parameter-Control (UPC): pass Wrr weight: 2 Number of OAM-configured connections: 0 OAM-configuration: disabled OAM-states: Not-applicable Cross-connect-interface: ATM1/1/0, Type: oc3suni Cross-connect-VPI = 1 Cross-connect-VCI = 32 Cross-connect-UPC: pass Cross-connect OAM-configuration: disabled Cross-connect OAM-state: Not-applicable Threshold Group: 5, Cells queued: 0 Rx cells: 38, Tx cells: 46 Tx Clp0:16, Tx Clp1: 30 Rx Clp0:8, Rx Clp1: 30 Rx Upc Violations:0, Rx cell drops:0 Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0 Rx connection-traffic-table-index: 1 Rx service-category: UBR (Unspecified Bit Rate) Rx pcr-clp01: 7113539 Rx scr-clp01: none Rx mcr-clp01: none Rx cdvt: 1024 (from default for interface) Rx mbs: none Tx connection-traffic-table-index: 1 Tx service-category: UBR (Unspecified Bit Rate) Tx pcr-clp01: 7113539 Tx scr-clp01: none Tx mcr-clp01: none Tx cdvt: none Tx mbs: none
Similar to the Frame Relay to ATM direction, two modes of operation are specified in FRF.5 for CLP bit to FR DE bit mapping for all traffic in the ATM to Frame Relay direction. Cisco's implementation of FRF.5 supports both.
Table 8-2. CLP to DE Bit Mapping for ATM to Frame Relay Direction for FRF.5
Mode 1 | If one or more ATM cells belonging to a frame has its CLP field set to 1, or if the DE field of the FR-SSCS PDU is set to 1, the interworking function shall set the DE field of the Q.922 frame. |
Mode 2 | No mapping is performed from the ATM layer to Q.922 layer. The FR-SSCS PDU DE field is copied unchanged to the Q.922 core frame DE field, independent of the CLP indications received at the ATM layer. |
For CLP to DE bit mapping of all traffic traveling in the ATM to Frame Relay direction, the behavior described in mode 1 is the default.
Example 8-2 shows that mode 1 is the default action when ATM cells are reassembled back to Frame Relay frames by the destination FRF.5 router, which is R3 in this setup. The show frame-relay pvc command performed at R3 indicates that 10 frames with the DE bit marked are sent to R4. This is because all the ATM cells received by R3 have the CLP bit set to 1. In fact, R3 sets the DE bit in the Frame Relay headers as long as it sees the CLP bit set in only one ATM cell belonging to the frame.
Example 8-2. CLP Bit to DE Bit Mapping in the ATM to Frame Relay Direction
R3#show frame-relay pvc 26 PVC Statistics for interface Serial1 (Frame Relay DCE) DLCI = 26, DLCI USAGE = FRF.5, PVC STATUS = ACTIVE, INTERFACE = Serial1 input pkts 26 output pkts 26 in bytes 6448 out bytes 6848 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 10 out bcast pkts 0 out bcast bytes 0 Num Pkts Switched 26 pvc create time 16:22:18, last time pvc status changed 16:22:03
The configuration commands for enabling the Frame Relay DE bit to ATM CLP bit mapping are shown in the “Configuring FRF.5 Network Interworking” section later on in this chapter.
Both Frame Relay and ATM have congestion indication mechanisms designed as part of the protocols. For Frame Relay, the BECN and FECN bits in the headers are the means by which Frame Relay notifies the network about congested conditions. On the other hand, ATM uses the Explicit Forward Congestion Indication (EFCI) in the cell headers to communicate the congested condition in the forward direction. The function of EFCI is identical to FECN. However, ATM does not have anything that mirrors the role of BECN in Frame Relay.
In the Frame Relay to ATM direction, FRF.5 itself does not support the mapping of FECN to EFCI, nor does Cisco's implementation of FRF.5. However, the mapping of EFCI bit in the ATM cell to FECN bit in the frame headers is supported.
Cisco's implementation of network interworking supports the majority of the specifications defined in FRF.5. The remaining sections and subsections of FRF.5 are supported as follows:
4.5.2.1 BECN Field in FR-SSCS PDU—. The BECN field in FR-SSCS PDU is copied unchanged into the BECN field of the Q.922 frame.
4.5.2.2 Frame Relay to B-ISDN Direction—. Backward congestion indication is not supported.
5.1 Traffic Management—. There is no direct mapping between Frame Relay and ATM traffic parameters; these parameters are configured independently.
5.2 PVC Management—. PVC management is not supported.
5.3 Description of Upper Layer User Protocol Encapsulation Methods—. This section applies only to terminal equipment and is not supported. However, this is used by FRF.8.1 operating in the translation mode.
5.4.1 Operations for the Common Part of the AAL Type 5—. The error counters mentioned in this section are reset at startup and are counted until they are reset.
The complete Frame Relay Forum Implementation Agreement Document Number FRF.5 can be downloaded from the Frame Relay Forum's public web site at http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf.
A couple of years after the Frame Relay Implementation Agreement Document Number FRF.5 was introduced, the Frame Relay Forum and ATM Forum outlined the Frame Relay to ATM Service Interworking specifications. These are defined in the Frame Relay Forum Implementation Agreement Document Number FRF.8.1. The complete FRF.8.1 documentation can be downloaded from the Frame Relay Forum's public web site at http://www.mplsforum.org/frame/Approved/FRF.8/FRF.8.1.pdf.
The new FRF.8.1 implementation agreement allows a Frame Relay service user to interwork with an ATM service user without requiring either user to perform any interworking functions.
The traffic is translated by an interworking function acting as a protocol translator between Frame Relay and ATM equipment. In contrast to FRF.5, FRF.8.1 does not require the ATM service user to perform Frame Relay-specific functions in the FR-SSCS within the AAL5. With FRF.8.1, the Frame Relay service user has no knowledge that the distant device is an ATM service user. Figure 8-9 gives you an idea where the interworking function is most commonly located when FRF.8.1 is used. Compare Figure 8-9 with FRF.5's diagram in Figure 8-2. Observe that when FRF.5 is used, two interworking functions are required to allow two Frame Relay service users to communicate over an ATM network. In FRF.8.1, one interworking function translates between the Frame Relay and ATM service users.
FRF.8.1 does not preserve the Frame Relay information from the Q.922 headers inside the FR-SSCS field of the ATM cell because the peer device is an ATM end user. The interworking function performs service interworking for the connected ATM and Frame Relay service users.
Compared with the functionalities offered by FRF.5, FRF.8.1 gives greater flexibility to the users by allowing a Frame Relay service user to communicate directly with an ATM service user. Also note that the FRF.8.1 specifications only support one-to-one mapping of Frame Relay service user to the ATM service user. Many-to-one mapping, as in the case of FRF.5, is not supported.
Some commonalities between FRF.5 and FRF.8.1 exist. Both FRF.5 and FRF.8.1 allow a Frame Relay network to connect to a disparate ATM network via an interworking function. FRF.5 and FRF.8.1 both provide congestion indication (DE to CLP mapping, FECN to EFCI mapping support), traffic management, and PVC management interworking.
Figure 8-10 illustrates the protocol stack when FRF.8.1 service interworking is deployed between Frame Relay and ATM service users.
The first thing to notice in Figure 8-10 is that a Null SSCS field has now replaced the FR-SSCS field in the ATM protocol stack. In the Frame Relay to ATM service interworking function, this Null SSCS provides an interface to Q.922 on the Frame Relay side and an interface to AAL5 CPCS on the ATM side. FRF.8.1 supports two modes of operation, translation and transparent, which are selected at configuration time. Cisco supports both modes of operation.
Using either mode of operation, when data is transported from Frame Relay to ATM direction, the Frame Relay payload is simply copied into the CPCS-PDU payload. The Frame Relay frame's flags, inserted zero bits, and the CRC-16 checksum fields are all removed. The Q.922 Frame Relay headers are removed, and the relevant fields are mapped into the ATM cell headers. AAL5 adds frame delineation to indicate the frame boundaries and computes a 32-bit CRC checksum for error detection. Conversely, in the opposite ATM to Frame Relay direction, the service interworking function uses the message delineation provided by AAL5 to identify frame boundaries to add the zero bit insertion, flags, and 16-bit CRC checksum to construct the Frame Relay frame.
If translation mode is used, the service interworking function inspects the NLPID field of the RFC 1490 encapsulated payload and translates it into the corresponding fields of the RFC 2684 encapsulated payload.
If transparent mode is used, this step is not performed by the service interworking function.
With FRF.8.1 operating in translation mode, the service interworking function translates Frame Relay PDU into ATM AAL5 CPCS-PDU without preserving any Frame Relay-specific information inside the FR-SSCS field, unlike in the FRF.5 case. For this reason, the Null SSCS field replaces the FR-SSCS field in the AAL5 CPSC headers when FRF.8.1 translation mode is used. Using FRF.8.1, the translation interworking function allows bidirectional protocol translation between Frame Relay and ATM. The translation mode maps between Frame Relay and ATM encapsulation, and none of the Frame Relay Q.922 headers information is preserved during the translation process. FRF.8.1 translation mode should be used when the encapsulation types of the end terminal equipment are not compatible with each other and require the FRF.8.1 translation interworking function to translate between them.
Translation mode supports interworking of routed and bridged protocols. When routed protocols are translated, FRF.8.1 translates between RFC 1490 for the Frame Relay and RFC 2684 for ATM. The service interworking function translates the Frame Relay NLPID values to ATM logical link control (LLC) or Subnetwork Access Protocol (SNAP), conforming to RFC 2684. RFC 2684 outlines the specifications for multiprotocol encapsulations over ATM AAL5 and is in many ways similar to RFC 1490 for Frame Relay (RFC 2684 supercedes RFC 1483), which was discussed in Chapter 2, “Cisco Frame Relay Devices and Network Implementation.” For more information on RFC 2684 and RFC 1483, please visit http://www.ietf.org/rfc.
Referring to the network diagram in Figure 8-10, the debug frame-relay packets and debug atm packets commands are enabled at R1 and R3, respectively, to verify the translation that takes place at R2. In addition, the debug ip packet command is turned on at router R3 to validate that the network layer IP packets are sent from the source Frame Relay interface serial0/0.16 on router R1 with IP address 172.16.1.1/24 and received by the destination ATM interface ATM0.1 with IP address 172.16.1.2/24. Without router R2 performing the ATM to Frame Relay translation between the two different protocols, the end-to-end ping would not be successful. The NLPID (type IP, 0x3CC) in the encapsulated payload of the Frame Relay frame is translated to ATM cells with SNAP encapsulation of type IP (0800) by R2.
Example 8-3. FRF.8.1 Translation Mode Between Frame Relay and ATM When R1 Sends Five IP Packets to R3
Show running configuration at R1: <output omitted> interface Serial0/0 no ip address encapsulation frame-relay IETF ! interface Serial0/0.16 point-to-point ip address 172.16.1.1 255.255.255.0 frame-relay interface-dlci 16 Show logging at R1 to display the output of debug frame-relay packet: R1#debug frame-relay packet R1#show logging <output omitted> ! *Aug 16 01:50:59.557: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104– NLPID 0x3CC(IP) indicates an IP packet is transmitted on the Frame Relay DLCI 16 at R1. *Aug 16 01:50:59.617: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.617: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.677: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.677: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.737: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.737: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.797: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.797: Serial0/0.16(o): dlci 16(0x403), NLPID 0x3CC(IP), datagramsize 104 *Aug 16 01:50:59.857: Serial0/0(i): dlci 16(0x401), NLPID 0x3CC(IP), datagramsize 104 Show running configuration at R3: <output omitted> ! interface ATM0 no ip address no atm ilmi-keepalive ! interface ATM0.1 multipoint ip address 172.16.1.2 255.255.255.0 pvc 1/32 protocol ip 172.16.1.1 broadcast encapsulation aal5snap Show logging at R3 to display the output of debug atm packet: R3#debug atm packet R3#debug ip packet R3#show logging <output omitted> ! 1d00h: ATM0.1(I): VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:AAAA CTL:03 OUI:000000 TYPE:0800 Length:0x70 –
FRF.8.1 operating in transparent mode does not perform any protocol translation, but it forwards the encapsulations unaltered. The FRF.8.1 transparent mode is applicable when the encapsulation types used by the end terminal equipment do not conform to the standards specified by FRF.8.1 translation mode but are fully compatible with each other. In addition, FRF.8.1 transparent mode does not perform mapping, fragmentation, or reassembly.
This section demonstrates the FRF.8.1 service transparent interworking using the same setup as in Example 8-3. At router R2, translation mode is disabled with the no service translation command. The no service translation command turns off the default translation mode and allows transparent mode to be used. In Example 8-4, the debug atm packet and debug atm error commands are enabled at R3. R3 is now unable to interpret the ATM cells received from R2, because R3 is still using the AAL5 SNAP encapsulation on VPI/VCI 1/32. It looks for the destination service-assess point (DSAP) and source service-assess point (SSAP) values of the SNAP header. In other words, the encapsulation types used by the two end terminal equipment (routers R1 and R3) are incompatible with each other.
Example 8-4. Common Problems Encountered When End Service Users Are Using Different Encapsulation Methods FRF 8.1 Transparent Mode
R3#debug atm packet R3#show logging ! <output omitted> ! 1d22h: ATM0.1(I): VCD:0x7 VPI:0x1 VCI:0x20 Type:0x0 SAP:03CC CTL:45 Length:0x6A 1d22h: 0000 6402 0F00 00FF 015F 66AC 1001 01AC 1001 0208 008A 671A 960B 1400 0000 1d22h: 0033 C09A 78AB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB 1d22h: CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB CDAB 1d22h: CDAB CDAB CDAB CDAB CD00 1d22h: 1d22h: ATM(ATM0.1): VC(7) Bad SAP received 03CC – this indicates R3 is unable to
The encapsulation type on Router R3 has been changed to ATM AAL5 NPLID encapsulation so that it is using the same encapsulation type as R1. After the change, R3 can communicate successfully with R1. Example 8-5 shows the output of the debug atm packet command at router R3, which confirms that R3 is no longer reporting bad encapsulation type received.
Example 8-5. Successful Communication after the Matching the Encapsulation Method R3 when Using FRF 8.1 Transparent Mode
R3#debug atm packet R3#show logging ! <output omitted> ! 1d22h: ATM0.1(I): VCD:0x7 VPI:0x1 VCI:0x20 Type:0x2 NLPID:0x03CC Length:0x6A 1d22h: 4500 0064 0214 0000 FE01 6061 AC10 0101 AC10 0102 0800 8093 050A 0F05 0000 1d22h: 0000 33C3 B5E4 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1d22h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1d22h: ABCD ABCD ABCD ABCD ABCD 1d22h: 1d22h: ATM0.1(O): VCD:0x7 VPI:0x1 VCI:0x20 DM:0x100 NLPID:0x03CC Length:0x6A 1d22h: 4500 0064 0214 0000 FF01 5F61 AC10 0102 AC10 0101 0000 8893 050A 0F05 0000 1d22h: 0000 33C3 B5E4 ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1d22h: ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD ABCD 1d22h: ABCD ABCD ABCD ABCD ABCD – there is no more bad SAP message indicating
Similar to FRF.5, two modes of operations are available to network providers when mapping DE to CLP bits for all traffic in the Frame Relay to ATM direction for FRF.8.1. Cisco supports both modes as specified for the Frame Relay to ATM direction, documented in section 4.2.1 of FRF.8.1. Section 4.2.1 of FRF.8.1 is summarized in Table 8-3.
Table 8-3. DE to CLP Mapping for Frame Relay to ATM Direction for FRF.8.1
Mode 1 | The Discard Eligibility field in the Q.922 frame shall be mapped to the ATM CLP bit of every ATM cell generated by the segmentation process of the AAL5 PDU containing information of that frame. |
Mode 2 | The ATM CLP bit of every ATM cell generated by the segmentation process of the AAL5 PDU containing information of that frame shall be set to a constant value (0 or 1), as determined by the user at setup. |
The DE to CLP bit mapping action for all traffic in the Frame Relay to ATM direction described in mode 1 of Table 8-3 is the default behavior for all Cisco routers running FRF.8.1. Based on the network setup illustrated in Figure 8-10, Example 8-3 shows the default mapping action on router R2, the FRF.8.1 router performing service translation between R1 and the ATM network. The running configurations for enabling FRF.8.1 on R2 are shown in Example 8-6. The show frame-relay pvc command performed at the end Frame Relay router R1 indicates 10 DE bit marked frames are sent out on the Frame Relay PVC to R2, the FRF.8.1 performing interworking translation. At the ATM LS1010 switch, 30 ATM cells with the CLP bit set are received from R2.
Example 8-6. DE to CLP Bit Mapping in the Frame Relay to ATM Direction for FRF.8.1
! R2: connect frf.8 Serial1/3 16 ATM3/0 1/32 service-interworking ! R1#show frame-relay pvc 16 PVC Statistics for interface Serial0/0 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.16 input pkts 10 output pkts 11 in bytes 1040 out bytes 1398 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 10 out bcast pkts 1 out bcast bytes 358 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec pvc create time 20:56:07, last time pvc status changed 20:56:07 LS1010#show atm vc inter atm4/0/0 1 32 Interface: ATM4/0/0, Type: t1suni VPI = 1 VCI = 32 Status: UP Time-since-last-status-change: 04:40:13 Connection-type: PVC Cast-type: point-to-point Packet-discard-option: disabled Usage-Parameter-Control (UPC): pass Wrr weight: 2 Number of OAM-configured connections: 0 OAM-configuration: disabled OAM-states: Not-applicable Cross-connect-interface: ATM1/1/0, Type: oc3suni Cross-connect-VPI = 1 Cross-connect-VCI = 32 Cross-connect-UPC: pass Cross-connect OAM-configuration: disabled Cross-connect OAM-state: Not-applicable Threshold Group: 5, Cells queued: 0 Rx cells: 4381, Tx cells: 4517 Tx Clp0:4352, Tx Clp1: 165 Rx Clp0:4351, Rx Clp1: 30 Rx Upc Violations:0, Rx cell drops:0 Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0 Rx connection-traffic-table-index: 1 Rx service-category: UBR (Unspecified Bit Rate) Rx pcr-clp01: 7113539 Rx scr-clp01: none Rx mcr-clp01: none Rx cdvt: 1024 (from default for interface) Rx mbs: none Tx connection-traffic-table-index: 1 Tx service-category: UBR (Unspecified Bit Rate) Tx pcr-clp01: 7113539 Tx scr-clp01: none Tx mcr-clp01: none Tx cdvt: none Tx mbs: none
This simple test shows that by default, R2 maps the DE bit in the Q.922 headers to the CLP field for every ATM cell that it generates.
Two modes of operation are specified in FRF.8.1 for CLP bit to FR DE bit mapping for all traffic in the ATM to Frame Relay direction. Cisco's implementation of FRF.8.1 supports both options.
Mode 1 described in Table 8-4 is the default behavior on all Cisco routers supporting FRF.8.1 for all traffic in the ATM to Frame Relay direction. In Example 8-7, based on Figure 8-10, R3 sends out some CLP bit-marked traffic into the ATM network with R1 as the destination. This example shows that when the CLP bit-marked ATM traffic destined for R1 is received by R2, R2 applies the default behavior and maps the CLP bit in the ATM cell headers to the DE bit in the Frame Relay headers. Eventually, R1 receives Frame Relay frames with the DE bit marked.
Example 8-7. CLP to DE Bit Mapping in the ATM to Frame Relay Direction for FRF.8.1
LS1010#show atm vc inter atm1/1/0 1 32 Interface: ATM1/1/0, Type: oc3suni VPI = 1 VCI = 32 Status: UP Time-since-last-status-change: 05:10:05 Connection-type: PVC Cast-type: point-to-point Packet-discard-option: disabled Usage-Parameter-Control (UPC): pass Wrr weight: 2 Number of OAM-configured connections: 0 OAM-configuration: disabled OAM-states: Not-applicable Cross-connect-interface: ATM4/0/0, Type: t1suni Cross-connect-VPI = 1 Cross-connect-VCI = 32 Cross-connect-UPC: pass Cross-connect OAM-configuration: disabled Cross-connect OAM-state: Not-applicable Threshold Group: 5, Cells queued: 0 Rx cells: 4802, Tx cells: 4426 Tx Clp0:4396, Tx Clp1: 30 Rx Clp0:4592, Rx Clp1: 210 Rx Upc Violations:0, Rx cell drops:0 Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0 Rx connection-traffic-table-index: 1 Rx service-category: UBR (Unspecified Bit Rate) Rx pcr-clp01: 7113539 Rx scr-clp01: none Rx mcr-clp01: none Rx cdvt: 1024 (from default for interface) Rx mbs: none Tx connection-traffic-table-index: 1 Tx service-category: UBR (Unspecified Bit Rate) Tx pcr-clp01: 7113539 Tx scr-clp01: none Tx mcr-clp01: none Tx cdvt: none Tx mbs: none R1#show frame-relay pvc 16 PVC Statistics for interface Serial1/3 (Frame Relay DCE) DLCI = 16, DLCI USAGE = FRF.8, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.16 input pkts 112 output pkts 60 in bytes 24992 out bytes 6240 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 60 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 switched pkts 112 Detailed packet drop counters: no out intf 0 out intf down 0 no out PVC 0 in PVC down 0 out PVC down 0 pkt too big 0 shaping Q full 0 pkt above DE 0 policing drop 0 pvc create time 00:52:11, last time pvc status changed 00:52:09
Table 8-4. CLP to DE Bit Mapping for ATM to Frame Relay Direction for FRF.8.1
Mode 1 | If one or more ATM cells belonging to a frame has its CLP field set to 1, the interworking function shall set the DE field of the Q.922 frame. |
Mode 2 | The DE field of the Q.922 frame is set to a constant value of 1 or 0, configured by the user at setup. |
For FRF.8.1, Cisco supports the bidirectional mapping of FECN and EFCI bits outlined in Table 8-5.
Table 8-5. EFCI and FECN Mapping for FRF.8.1
Frame Relay to ATM Direction | |
|---|---|
Default | The EFCI field in the ATM cell header is set to 1 if the FECN field in the Frame Relay headers is set. |
User configurable | The EFCI field in the ATM cell header is set to a constant 0. |
ATM to Frame Relay Direction | |
|---|---|
Default | The FECN field in the Frame Relay header is set to 1 if the EFCI field in the last cell of the segmented frame is set. |
User configurable | The EFCI field in the ATM cell header is set to a constant 0. |
The remaining sections and subsections of FRF.8.1 are supported as follows on Cisco platforms:
5.1 Traffic Management —. There is no direct mapping between the Frame Relay and ATM traffic parameters; these parameters are configured independently.
5.2 Frame Relay PVC Management Procedures—. The procedures for the asynchronous status message defined in Q.933 Annex-A are not supported.
5.3.1.4 Fragmentation and Reassembly—. Fragmentation and reassembly are not supported.
5.4 Address Resolution—. The IP and IPX protocols are supported.
6.0 Operations for the Common Part of the AAL Type 5—. The error counters mentioned in this section are reset at startup and are counted until they are reset.
This section presents an overview of the Cisco router platforms that support the Frame Relay to ATM Interworking feature. During the early development stage, not all Cisco router platforms offer the support for the Frame Relay to ATM interworking function. The early supported router platforms include the Cisco MC3810, the Cisco 2600 series, the Cisco 3600 series, and the Cisco 7200 series.
For Cisco IOS software support, the Frame Relay to ATM Interworking feature is available in Cisco IOS Software Release 12.1(2)T or later. With the correct Cisco IOS software release, the Frame Relay to ATM Interworking feature is supported on the following list of router platforms discussed in this section.
The Cisco MC3810 platform originated from Cisco's acquisition of Ardent Communication Corporation in 1997. The Cisco MC3810 (see Figure 8-11) is a compact, low-cost, multiservice access concentrator. The MC3810 provides integration of video, voice, and data onto public or private Frame Relay, ATM, leased-line, or IP networks. The MC3810 supports the Frame Relay to ATM Internetworking (FRF.5 and FRF.8.1) feature with its T1/E1 ATM interface. It permits remote sites using Frame Relay access to work directly with ATM at larger sites.
Cisco's early development of the Frame Relay to ATM Interworking feature was based largely on the MC3810 platform. However, as of the date that this book was written, Cisco has officially announced the end of sales of the MC3810 series, and this platform and its components will no longer be available. Nonetheless, the configuration tasks in the Cisco IOS software for the Frame Relay to ATM Interworking feature are independent across all supported platforms and the MC3810 platform is used in the discussion in the configuration commands section.
The Cisco 2600 series (see Figure 8-12) is a family of modular multiservice access branch office routers suitable for a wide range of business requirements. The Cisco 2600 series router supports the Frame Relay to ATM Interworking feature with its ATM OC-3 and Inverse Multiplexing over ATM (IMA) network modules.
The Cisco 3600 series (see Figure 8-13) is a family of modular multiservice access platforms for medium and large-sized offices and smaller Internet service providers. It supports more than 70 modular interface options to meet data, voice, video, dial access, VPN, and multiprotocol data routing requirements. The Cisco 3600 series router supports Frame Relay to ATM Interworking with the ATM OC-3 and inverse multiplexing over ATM (IMA) network modules. Both the Cisco 2600 and Cisco 3600 series routers can share the same modular interfaces.
The Cisco 7200 Series router (see Figure 8-14) is a scalable and modular high performance router that can address a wide range of service requirements. The Cisco 7200 series router supports the Frame Relay to ATM Interworking feature on all ATM interface types.
This section discusses the configuration tasks required to enable Frame Relay network interworking (FRF.5) on the Cisco router. The network, consisting of four routers and an ATM LS1010 switch, is depicted in Figure 8-15 and is used to illustrate the configuration examples in this section. Note that R2 and R3 belong to the supported Cisco platforms required for Frame Relay to ATM Interworking.
R2 and R3 in Figure 8-15 are the routers performing the FRF.5 network interworking function between the Frame Relay and the ATM networks. To enable FRF.5 on R2 or R3 using one-to-one multiplexing, follow the configuration steps listed below:
Enter the interface configuration mode of the serial interface connected to the Frame Relay network with the interface serial number command and enable Frame Relay encapsulation with the encapsulation frame-relay command.
If the incoming Frame Relay PVC is a switched VC, identify it with the frame-relay interface-dlci dlci switched interface configuration command. If the incoming Frame Relay PVC is a terminated VC, this step is not required.
Configure the ATM interface connected to the ATM network and enter the interface configuration mode with the interface atm number command.
Create the ATM PVC with the VPI/VCI pair using pvc [pvc-name] vpi/vci interface configuration command. The ATM PVC can be identified using a pvc-name but it is optional. The VPI/VCI value is usually assigned by the provider and configured on the ATM switch.
Configure the ATM adaptation layer and encapsulation type for the ATM PVC with the encapsulation aal5mux frame-relay command. The aal5mux encapsulation has slightly less overhead compared with the default aal5snap encapsulation. The aal5mux encapsulation is usually used to dedicate the specified PVC to only a single protocol.
Create a connection to connect the Frame Relay DLCI to the ATM PVC using the connect connection-name FR-interface FR-DLCI ATM-interface ATM-PVC network-interworking global configuration command. The network-interworking option is specified to indicate that FRF.5 is to be used.
(optional) Under the FRF.5 mode, set the ATM CLP bit for traffic in the Frame Relay to ATM direction using the clp-bit {0 | 1 | map-de} command. As you saw earlier, the default configuration is clp-bit map-de. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
(optional) Under the FRF.5 mode, set the DE bit for traffic in the ATM to Frame Relay direction using the de-bit map-clp command. This is the default. Use the no form of the command to disable CLP bit to DE bit mapping. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
To enable the FRF.5 network interworking connection, perform no shutdown. Use the shutdown command to disconnect the FRF.5 network interworking connection.
Example 8-8 below shows the complete FRF.5 configuration on routers R2 and R3.
Example 8-8. Configuration on R2 and R3 (One-to-One Connection)
! R2: <output omitted> ! interface Serial1/3 no ip address encapsulation frame-relay frame-relay interface-dlci 16 switched ! interface ATM3/0 no ip address no ip route-cache no atm ilmi-keepalive pvc 1/32 encapsulation aal5mux frame-relay ! connect frf5 Serial1/3 16 ATM3/0 1/32 network-interworking clp-bit map-de ! R3 <output omitted> ! interface Serial1 no ip address encapsulation frame-relay frame-relay interface-dlci 26 switched ! interface ATM0 no ip address no atm ilmi-keepalive pvc 1/32 encapsulation aal5mux frame-relay ! connect frf5 Serial1 26 ATM0 1/32 network-interworking de-bit map-clp
This section looks at how many-to-one multiplexing is configured for FRF.5 network interworking. In Figure 8-15, two Frame Relay PVCs are provisioned on each service user at each of the Frame Relay networks. A vc-group command has to be created to assign multiple Frame Relay DLCIs to one ATM VC. The configuration tasks required for enabling many-to-one multiplexing are almost the same as the one-to-one case presented previously. As such, only the additional configuration commands necessary for configuring many-to-one multiplexing are explained.
Configure a VC group to assign multiple Frame Relay DLCIs to a single ATM VC using the vc-group group-name global configuration command.
In the vc-group configuration mode, specify the Frame Relay DLCIs and map them to the Frame Relay SSCS DLCIs using the FR-interface FR-DLCI FR-SSCS-DLCI vc-group configuration command. Note that both the FR-DLCI and FR-SSCS-DLCI are required.
Create a connection to connect the VC group to the ATM PVC using connect connection-name vc-group group-name ATM-interface ATM-PVC network-interworking global configuration command.
Two show commands applicable to the Frame Relay to ATM interworking feature can be used to verify its correct operation.
Use the show connection global EXEC command to verify the status of the FRF.5 connection. The all option is used with the show connection command to display all existing connections created on the router. The id option can be used with the command to view more detailed information of the specified id connection. Note that the router sequentially allocates the connection id when the interworking connection is provisioned. The connection id is not reset when the interworking connection is shut down or removed but only when the router is reloaded. Example 8-9 shows the two variations of the show connection command executed on router R2. The possible state or status of the connection can be UP, DOWN, or ADMIN DOWN.
Example 8-9. Display Output of the show connection Command at R2
R2#show connection all
ID Name Segment 1 Segment 2 State
========================================================================
6 frf5 Serial1/3 16 ATM3/0 1/32 UP
R2#show connection id 6
FR/ATM Network Interworking Connection: frf5
Status - UP
Segment 1 - Serial1/3 DLCI 16
Segment 2 - ATM3/0 VPI 1 VCI 32
Interworking Parameters -
fr-sscs-dlci 1022
de-bit map-clp
clp-bit map-de
The first thing to notice in Example 8-9 is the State. The State indicates the FRF.5 connection is up and running properly. The more detailed display by the show connection id command shows the interworking parameters configured. Observe that the FR-SSCS DLCI used is 1022, which is the default if it is not configured under the vc-group. The show frame-relay pvc command and the show atm pvc command can be used at R2 to verify the status of the Frame Relay DLCI and ATM PVC respectively, as shown in Example 8-10. Notice in Example 8-10, the DLCI usage now reflects that the Frame Relay PVC is being configured for FRF.5. The output of the show atm pvc command displays the ATM PVC statistics, and the encapsulation used is for Frame Relay to ATM interworking.
Example 8-10. Output of the show frame-relay pvc Command at R2
R2#show frame-relay pvc 16
PVC Statistics for interface Serial1/3 (Frame Relay DCE)
DLCI = 16, DLCI USAGE = FRF.5, PVC STATUS = ACTIVE, INTERFACE = Serial1/3
input pkts 13 output pkts 10 in bytes 4407
out bytes 3290 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
switched pkts 13
Detailed packet drop counters:
no out intf 0 out intf down 0 no out PVC 0
in PVC down 0 out PVC down 0 pkt too big 0
shaping Q full 0 pkt above DE 0 policing drop 0
pvc create time 00:09:53, last time pvc status changed 00:09:52
R2#show atm pvc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
3/0 5 1 32 PVC FR-ATM UBR 155000 UP
Example 8-11 checks out the connectivity between the end stations R1 and R4.
Example 8-11. R1 Is Able to Reach R4 Over the ATM Network Supporting FRF.5
R1#ping 172.16.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
The next example verifies the configuration for FRF.5 connection using many-to-one multiplexing. R2 and R3 are reconfigured for a many-to-one connection, and Example 8-12 shows the configuration changes at R2 and R3. Most noticeably, a vc-group is created at each FRF.5 router to map multiple Frame Relay DLCIs to FR-SSCS DLCIs. The FR-SSCS DLCIs configured between R2 and R3 must match, otherwise the FRF.5 router is not able to match the correct frame sent from its peer. Example 8-13 shows the output displayed by the show connection id and show vc-group commands after the configuration changes are applied.
Example 8-12. Configuration Changes at R2 and R3 to Enable Many-to-One Multiplexing
R2#show running <output omitted> ! connect frf5 vc-group many-to-one ATM3/0 1/32 ! ! vc-group many-to-one Serial1/3 16 100 Serial1/3 17 101 R3#show running <output omitted> ! connect frf5 vc-group many-to-one ATM0 1/32 ! ! vc-group many-to-one Serial1 26 100 Serial1 27 101
Example 8-13. Shows the Output of the show connection id Command and the show vc-group Command Executed at R2 and R3
! R2 R2#show connection id 7 FR/ATM Network Interworking Connection: frf5 Status - UP Segment 1 - VC-Group many-to-one Segment 2 - ATM3/0 VPI 1 VCI 32 Interworking Parameters - de-bit map-clp clp-bit map-de R2#show vc-group many-to-one VC Group: many-to-one, Number of VCs: 2 ====================================================== Serial1/3 DLCI 16, FR-SSCS DLCI 100 Serial1/3 DLCI 17, FR-SSCS DLCI 101 ! R3 R3#show connection id 8 FR/ATM Network Interworking Connection: frf5 Status - UP Segment 1 - VC-Group many-to-one Segment 2 - ATM0 VPI 1 VCI 32 Interworking Parameters - de-bit map-clp clp-bit map-de R3#show vc-group many-to-one VC Group: many-to-one, Number of VCs: 2 ====================================================== Serial1 DLCI 26, FR-SSCS DLCI 100 Serial1 DLCI 27, FR-SSCS DLCI 101
Example 8-14 demonstrates the router R1 is now able to reach router R4 over the ATM networking supporting FRF.5.
Example 8-14. R1 Is Able to Reach R4 over the ATM Network Supporting FRF.5 via Both 172.16.1.0/30 and 172.16.2.0/30
R1#ping 172.16.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms R1#ping 172.16.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
To understand the configuration commands needed to enable FRF.8.1 service interworking, refer to the network depicted in Figure 8-16 for illustration.
In Figure 8-16, R2 is the FRF.8.1 router that performs the service interworking function between the Frame Relay and the ATM networks. To enable FRF.8.1 on R2, follow the configuration steps listed below:
Enter the interface configuration mode of the serial interface connected to the Frame Relay network with the interface serial number command and enable Frame Relay encapsulation with the encapsulation frame-relay command.
If the incoming Frame Relay PVC is an SVC, identify it with the frame-relay interface-dlci dlci switched interface configuration command. If the incoming Frame Relay PVC is a terminated VC, this step is not required.
Configure the ATM interface connected to the ATM network and enter the interface configuration mode with the interface atm number command.
Create the ATM PVC with the VPI/VCI pair using the pvc [pvc-name] vpi/vci interface configuration command. The ATM PVC can be identified using a pvc-name but it is optional. The VPI/VCI value is usually assigned by the provider and configured on the ATM switch.
Configure the ATM adaptation layer and encapsulation type for the ATM PVC with the encapsulation aal5mux fr-atm-srv command. The aal5mux encapsulation has slightly less overhead compared with the default aal5snap encapsulation. The aal5mux encapsulation is usually used to dedicate the specified PVC to only a single protocol.
Create a connection to connect the Frame Relay DLCI to the ATM PVC using connect connection-name FR-interface FR-DLCI ATM-interface ATM-PVC service-interworking global configuration command. The service-interworking option specifies that FRF.8.1 is used.
(optional) Under the FRF.8.1 configuration mode, set the ATM CLP bit for traffic in the Frame Relay to ATM direction using the clp-bit {0 | 1 | map-de} command. As we have seen earlier, the default configuration is clp-bit map-de. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
(optional) Under the FRF.8.1 configuration mode, set the DE bit for traffic in the ATM to Frame Relay direction using the de-bit {0 | 1 | map-clp} command. This is the default. Use the no form of the command to disable CLP bit to DE bit mapping. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
(optional) Under the FRF.8.1 configuration mode, use the efci-bit {0 | map-fecn} command to set the EFCI bit in the ATM cell header to 0 or specify that the EFCI is to be mapped from the FECN bit for traffic in the Frame Relay to ATM direction. (Note that this command is presently available on Cisco MC3810, 2600, and 3600 series routers only.)
(optional) Select FRF.8.1 to use transparent or translation mode with the service translation command under frf8 configuration mode. The default is service translation.
To enable the FRF.8.1 service interworking connection, perform no shutdown. Use the shutdown command to disconnect the FRF.5 service interworking connection.
The configuration commands required to enable the FRF.8.1 service interworking function at R2 are shown in Example 8-15.
Example 8-15. Configuration Examples of Routers R1, R2, and R3 in Figure 8-16 for Setting Up FRF.8.1 Service Interworking
R1#show running <output omitted> ! interface Serial0/0.16 point-to-point ip address 172.16.1.1 255.255.255.0 frame-relay interface-dlci 16 R2#show running <output omitted> ! interface Serial1/3 no ip address encapsulation frame-relay frame-relay interface-dlci 16 switched ! interface ATM3/0 no ip address no ip route-cache no atm ilmi-keepalive pvc 1/32 encapsulation aal5mux fr-atm-srv ! connect frf8 Serial1/3 16 ATM3/0 1/32 service-interworking R3#show running <output omitted> ! interface ATM0.1 multipoint ip address 172.16.1.2 255.255.255.0 pvc 1/32 protocol ip 172.16.1.1 broadcast encapsulation aal5snap
The next example in Example 8-16 shows the output displayed by the show connection id, show frame-relay pvc and the show atm pvc commands performed at router R2.
Example 8-16. Output of the show connection id, show frame-relay pvc, and show atm pvc Commands Executed at R2
R2#show connection id 8
FR/ATM Service Interworking Connection: frf8
Status - UP
Segment 1 - Serial1/3 DLCI 16
Segment 2 - ATM3/0 VPI 1 VCI 32
Interworking Parameters -
service translation
efci-bit 0
de-bit map-clp
clp-bit map-de
R2#show frame-relay pvc 16
PVC Statistics for interface Serial1/3 (Frame Relay DCE)
DLCI = 16, DLCI USAGE = FRF.8, PVC STATUS = ACTIVE, INTERFACE = Serial1/3
input pkts 2 output pkts 0 in bytes 674
out bytes 0 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
switched pkts 2
Detailed packet drop counters:
no out intf 0 out intf down 0 no out PVC 0
in PVC down 0 out PVC down 0 pkt too big 0
shaping Q full 0 pkt above DE 0 policing drop 0
pvc create time 00:07:32, last time pvc status changed 00:07:24
R2#show atm pvc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
3/0 5 1 32 PVC FRATMSRV UBR 155000 UP
Example 8-17 validates router R1 is now able to exchange packets with router R3 due to the FRF.8.1 Service Interworking Function performed by router R2.
In this chapter, you learned about the ATM WAN protocol and how this emerging technology can complement Frame Relay to improve the economics of scale and network scalability for service providers.
The Frame Relay Forum and the ATM Forum outlined two Frame Relay to ATM interworking implementation agreement documents to support Frame Relay to ATM Interworking: network interworking (FRF.5) and service interworking (FRF.8.1). Cisco's implementation of the Frame Relay to ATM Interworking feature supports both FRF.5 and FRF.8.1.
The Frame Relay to ATM Interworking function has gained popularity in the market because of the emergence of high-speed and affordable access technologies such as Digital Subscriber Line (DSL). In some of the most popular applications, a Frame Relay end user uses DSL technology to gain high-speed access to the core ATM backbone. The FRF.8.1 service interworking function performs the frame-to-cell translation to allow the Frame Relay traffic to be carried into an ATM network.
FRF.5, or networking interworking, allows two similar Frame Relay service users to communicate with each other over an ATM network that supports FRF.5.
FRF.8.1, or service interworking, allows a Frame Relay service user to interoperate directly with an ATM service user. FRF.8.1 supports two modes of operation, transparent and translation. Translation mode performs protocol translation between the supported protocol stacks, whereas transparent mode forwards the payload unaltered.
Both FRF.5 and FRF.8.1 support functionalities to allow native congestion indication mechanisms in Frame Relay and ATM protocols to be mapped over to each other.
This chapter demonstrated the configuration tasks necessary to configure FRF.5 and FRF.8.1 on a Cisco router. This chapter showed the relevant Cisco IOS configuration commands for FRF.5 and FRF.8.1 using practical configuration examples. Furthermore, this chapter discussed the Cisco IOS show and debug commands for monitoring and maintaining the FRF.5 and FRF.8.1 configurations on a Cisco router.
The next chapter discusses the Adaptive Frame Relay Traffic Shaping for Interface Congestion feature.
This chapter is based on the following documentation:
Frame Relay Forum Implementation Agreement FRF.5: Frame Relay/ATM PVC Networking Interworking, December 1994: http://www.mplsforum.org/frame/Approved/FRF.5/frf.5.pdf
Frame Relay Forum Implementation Agreement FRF.8.1: Frame Relay/ATM PVC Service Interworking, February 2000: http://www.mplsforum.org/frame/Approved/FRF.8/FRF.8.1.pdf
Cisco IOS Release 12.1(2)T: Frame Relay-to-ATM Network Interworking (FRF.5): http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfratm5.htm
Cisco IOS Release 12.1(2)T: Frame Relay-to-ATM Service Interworking (FRF.8): http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfratm8.htm