Frame Relay and Testing with the PFA-35 Application Note: PFA-35 Summary This application note describes the essentials of Frame Relay, and how to perform three important tests for installing and maintaining Frame Relay services using the PFA-35 with Frame Relay option.
The Key Benefits of Frame Relay: Frame Relay brings two key benefits: It uses a packet-switching, not a circuit-switching, technology. As a result multiple data communication paths can be configured over one physical link so the high cost of multiple point-to-point circuits is eliminated. The switching performed by Frame Relay nodes is a very efficient process with minimal end-to-end delays. This low delay, high bandwidth combination equals increased capacity and throughput and so is ideal for data intensive LAN/WAN internetworking applications. A Typical Frame Relay Network At the customer premises the inter-network device is, in most cases, a LAN bridge or router. The inter-network device typically connects to the Frame Relay network via a Customer Service Unit with a V.11 standard interface. The physical link between this CSU and the Frame Relay switching node is typically an E1 link. The user to network Interface (UNI), i.e. the interface between the Customer Premise Equipment () and the network, is specified using Frame Relay standards. Traffic is routed through the network using Permanent Virtual Circuits (PVCs). Frame Relay Frame Structure To transmit data between one user and another across the Frame Relay network, the data is inserted into frames. These can be of variable length and the structure employed is based on HDLC framing. All frames start and end with a flag. The start flag is followed by an address field, the exact format of which is dependant on the Link Management Protocol in use and may be two, three, or four bytes long. In the example below a two byte, sixteen bit header is employed. 10 bits are used for the Data Link Connection Identifier (DLCI) - this identifies the address to which data being carried in the frame is going to, or coming from. The Extended Address bit (EA) is set to 1 in the last address byte. The Command/Response indication bit (CR) is not used by the Frame Relay protocol. The Forward Explicit Congestion Notification bit (FECN); Backward Explicit Congestion Notification bit (BECN); and Discard Eligibility bit (DE) are used to notify the user that congestion is occurring in the network. The information field is a variable length field and contains the user data being passed across the network. This is followed by the Frame Check Sequence (FCS) used to check the frame has been received without error. Unlike a leased line, the connection is only made from end to end through the network when it is required. The connection should always be available on request, so from the customer s point of view the connection is permanent. Flag Address Field Information Field FCS Flag In reality no permanent connection exists on a single circuit. The circuit is made using routing tables within Frame Relay switches. When one customer is not using a certain physical connection between switches, it is available for other traffic. It is therefore only virtually established. DLCI C/R EA DLCI FECN BECN DE EA Bit: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 LAN Internetwork Device Router V.11 Frame Relay Interface DSU CSU ACCESS CIRCUIT Access Circuit 2Mb E1 DLCI C/R EA FECN BECN DE FCS - Data Link Connection Identifier - Command/Response Bit - Extended Address Bit - Forward Explicit Congestion - Backward Explicit Congestion - Discard Eligibility - Frame Check Sequence AME RELAY NETWORK
Data Link Connection Identifier (DLCI) The diagram below shows a simple network connecting two customer premises at locations A and B. So location A can communicate with location B, a PVC between the two must be configured. Each frame must have a valid DLCI address corresponding to the specific PVC. The frames are then transmitted to the network. Routing tables within the switches guide valid frames to their correct destination. This is achieved by altering the DLCI to that of the next link in the PVC. In the example below, all frames being sent from location A are given a DLCI of 15. The Frame Relay switch, using its routing table, then modifies this to a DLCI of 33 and by so doing directs the frames to location B. Frame Relay networks provide users with the ability to send and receive data to and from multiple locations using a single physical connection. The addressing used for multiple locations is the same. Frame Routing - Multiple PVCs Adding extra locations with which to establish PVCs is very easy. Unlike with leased lines, there is no need to physically wire another connection from location A to the near switch, let alone through the network. In the example below, location A when communicating with location C, simply needs to use a different (pre-agreed) DLCI, in this example 67. This different DLCI indicates to the first switch to route the frames in another direction. The tables in the following switch(es) will ensure the frames reach the right destination. Location A DLCI = 15 DLCI = 67 Location B Location A DLCI = 15 DLCI = 15 Location B DLCI = 33 DLCI = 33 Location C
Congestion Within The Network Too many frames being routed through a single switch, in excess of its capacity, will result in congestion. Ideally this would never happen because each customer is allocated a specific bandwidth, called Committed Information Rate (CIR) and the network is dimensioned accordingly. However problems can still occur, such as a line being down or problems of allocation. In the example, the highlighted Frame Relay switch, which is relaying frames from location A to location B, is experiencing congestion. This switch is able to indicate to location A and B s terminal devices that the node is congested by setting the FECN and BECN bits. Link Management Signalling The Frame Relay protocol described so far offers a basic data transport mechanism. It does not permit any local control or management of the interface, nor is there any way for the end terminal to determine the status of its connection. Link Management Signalling is used for this purpose. The vast majority of devices and service providers are specified to support one or more of the following three standards: ANSI (TI.617 Annex D), CCITT (0.933 Annex A), and LMI. These specify the link management process. The link management process consists of two core elements. Location A Congestion experienced in A-B direction The first, Link Integrity Verification, is a procedure wher the sends Status Enquiry (Keep Alive) frames to the network. Each enquiry is answered by the network, provided all is well, to confirm integrity of the link. Secondly, Full Status Enquiry frames are sent to the network. The network responds by supplying a Full Status Response. This FSR will identify which DLCIs are available to the customer s, and whether they are active, inactive or new, for example. BECN = 1 Location B FECN = 1 KEEP ALIVE LINK INTEGRITY VERIFICATION FULL STATUS FECN bits are set to 1 in frames travelling away from the congestion towards B; BECN bits are set to 1 in frames travelling away from the congestion towards A. Higher level protocols within the at location A should ensure that the transmission rate of frames from location A is reduced to avoid congestion. If this does not happen, the network will commence discarding frames to relieve the problem. It will do this selectively by discarding those frames where the DE bit is set to 1. The DE bit being set to 1 will indicate either low priority data, or data being sent above the agreed CIR. Either of which can be discarded in the event of congestion in the network. FULL STATUS RESPONSE The frequency of these frames and the link management type is configured at the and the near-end switch.
What Needs Testing? There are a number of questions that need to be answered before a Frame Relay service can be turned over to an end-user. Frame Relay has no error correction capabilities, so optimum performance requires error free transmission circuits, so is the circuit error free? The Link Management procedure must be checked to ensure that the inter-network devices are configured identically, both in terms the protocol in use and various other settings for the keep alive and full status messages. As an example, the intervals between the messages from and network must be identical. The PVCs must also be checked to ensure they are correctly configured. It must be confirmed whether the PVC to each end user has been satisfactorily established. The status of each DLCI should be reported for examination. It is vital to test that traffic may be sent across the PVCs. It is important to test whether frames can be sent and received across the network, and whether the CIR (if agreed) is achievable. Changing Market Needs/Demands Equipment is clearly needed to test the Frame Relay service. Protocol analysers have until recently been the main instrument for testing Frame Relay networks. However, the increasing demand for Frame Relay services has brought with it the need for a new type of tester for installation, commissioning and maintenance: a tester that provides all the applications and features for comprehensive transmission and Frame Relay testing, without complex protocol decoding and analysis a tester that is more cost effective and much easier to use than a protocol analyser a tester that can automate Frame Relay equipment turn-up and save test time a tester that really is small and portable a tester that is battery operated The solution is the Frame Relay option for the PFA-35. Finally, the network/pvc should be stress tested at higher rates than those agreed, to identify any other problem areas. All of these testing requirements are geared towards confirming the network switches have been correctly configured, and that the network itself can cope with the intended traffic.
Frame Relay Software Option for PFA-35 Loaded into PFA-35, the frame relay option addresses three different types of test that can be used for installing and maintaining Frame Relay services. These are: Frame Relay service turn-up, to verify user-to-network connectivity and configuration TCP/IP PING Request Testing, providing additional tests to verify the connectivity of far-end terminals, and Fox Test to dimension a link and verify connectivity of non TCP/IP links Frame Relay service turn-up If any alarms and errors are detected on the link, the large OK disappears and alarm/error information is summarised. This includes the number of: - Errored frames - Bad frames (Runt, Giant etc) - Frame Check Sequence (FCS) errors LAN Testing the Heartbeat of your Frame Relay Network ROUTER DSU CSU ACCESS CIRCUIT AME RELAY NETWORK An incremental count indicates that received frames are being corrupted between the network and the. - Frames with FECN, BECN and DE These point to congestion in the network and the number of frames being discarded. - Average and Peak frame rates - % Utilisation V.11 2Mbit/s Before a frame relay service is turned over to a customer, it is important to check the service is alive to verify that the user-to-network link is properly connected and configured. This is the function of the PFA-35 s heartbeat check. PFA-35 is typically terminated at the Customer Premise Equipment. With one key press the PFA-35 then automatically steps through the heartbeat check process to verify the link is alive. The process is as follows: PFA-35 first autoconfigures to the physical interface and line rate. This can be V.11, V.35, or G.703 PFA-35 then transmits and receives idle flags. Detected flags are indicated on the screen PFA-35 then autoconfigures to the link management type, i.e. ANSI D, CCITT A or LMI Link management is then emulated. This involves emulating the 'keep alive' and 'full status' and monitoring the response from the network. Correct detection of these responses is indicated by a large OK on the left hand side of the screen. A pulsing heart confirms the link is 'alive', turn-up is complete, and link management is functioning correctly. The response to the full status enquiry is also decoded. This is displayed on the right hand side of the screen and shows the status of the various PVCs to which the user should have access.
TCP/IP PING Request Test While the PVC status result gives an insight to a far-end link and a corresponding PVC, it does not verify complete connectivity between one user internetworking device and another across the network. This is the function of the TCP/IP PING request test. The test involves transmitting simple 'are you there?' frames through the network to a specific device, in this case a terminal, through a destination DLCI. A correctly configured far end station will then respond, confirming connectivity. minimum) for each successful ping is measured. These are important, because large differences between these times can provide an early indication to the user of congestion on the network. PFA-35 provides continuous pinging and the user can edit the TCP/IP source and destination addresses of the terminal being pinged. The round trip time (maximum and DLCI 19 DLCI 23 LAN AME RELAY NETWORK ROUTER PFA-35 IP Source address: 69.0.0.40 IP Destination address: 104.239.0.0 Terminal IP Source address: 104.239.0.0 IP Destination address: 69.0.0.40 'Fox Test' The TCP/IP PING request test is only possible if the farend terminal is operational and can handle the TCP/IP protocol. To enable connectivity to be verified where this is not the case an alternative test method is required. This is the function of the 'Fox test'. defined utilisation. This is particularly useful for proving the capacity of a virtual circuit, i.e. confirming a customers CIR, and to provide an insight to how the network will respond to different levels of traffic. The 'Fox test' can be performed end-to-end with another PFA-35. End-to-end connectivity across the network is verified by transmitting frames to a specific destination DLCI and counting the received frames. The 'Fox Test' may also be used to stress the network by generating frames of a user defined length and at a user User A User B AME RELAY NETWORK PFA-35 PFA-35
For further information contact: Local Sales Office Wandel & Goltermann GmbH & Co. Elektronische Meßtechnik International Marketing Postfach 12 62 D-72795 Eningen u.a. Germany Tel. +49-7121-86 16 16 Fax +49-7121-86 13 33 Telex 7 29 833 wug d e-mail: info@wago.de World-Wide Web: http://www.wg.com E/02.98/D4/867/5