We continue our comprehensive look at Frame Relay from Cisco Press' Network Consultants Handbook, complete with illustrations, charts and tables you'll want to keep as a reference.
Network Consultants Handbook - Frame Relay
by Matthew Castelli
SVC X.121/E.164 Addressing
X.121 is a hierarchical addressing scheme that was originally designed to number X.25 nodes. X.121 addresses are up to 14 digits in length and are structured as follows:
- Country Code: 3 digits
The first digit is a zone number that identifies a part of the world. For example, Zone 2 covers Europe and Zone 3 includes North America). The zone numbers can be found in Appendix C, List of ITU-TX.121 Data Country or Geographical Codes. These codes can also be found in ITU-T Recommendation X.121.
- Service Provider: 1 digit
- Terminal Number: Up to 10 digits
- E.164 is a hierarchical global telecommunications numbering plan, similar to the North American Number Plan (NANP). E.164 addresses are up to 15 digits in length and are structured as follows:
- Country Code: 1, 2, or 3 digits
This code is based on the international telephony numbering plan and can be found in Appendix D, International Country Codes. These codes can also be found in any phone book.
- National Destination Code and Subscriber Number: Up to 14 digits in length (maximum length is dependent on the length of the Country Code).
Subaddress: Up to 40 digits
Frame Relay Status Polling
The Frame Relay Customer Premises Equipment (CPE) polls the switch at set intervals to determine the status of both the network and DLCI connections. A Link Integrity Verification (LIV) packet exchange takes place about every 10 seconds, verifying that the connection is still good. The LIV also provides information to the network that the CPE is active, and this status is exported at the other end. Approximately every minute, a Full Status (FS) exchange occurs, passing information regarding which DLCIs are configured and active. Until the first FS exchange occurs, the CPE does not know which DLCIs are active, and as such, no data transfer can take place.
Frame Relay Error Handling
Frame Relay uses the Cyclic Redundancy Check (CRC) method for error detection. Frame Relay services perform error detection rather than error checking; error detection is based on the premise that the underlying network media is reliable. Frame Relay error detection uses the CRC checksum to determine if the frame is received by the Frame Relay networking device (router or switch) with, or without, error. Error correction is left to the upper-layer protocols, such as the TCP (of the TCP/IP protocol suite).
Error detection detects errors, but does not make attempts to correct the condition. Error correction detects errors and attempts to correct the condition, usually under control or direction of a higher-layer protocol. The termination node performs error detection.
Frame Relay Frame Format
Figure 15-13 illustrates the standard Frame Relay frame format.
Figure 15-13: Frame Relay Standard Frame Format
(Click image for larger view in a new window)
Table 15-7 presents a description of each of the Frame Relay standard frame fields.
|Flags ||Delimits the beginning and end of the frame. The value of this field is always the same and is represented as hexadecimal 7E or as binary 0111110.|
|Address ||Contains the following information:
- DLCI -- The 10-bit DLCI is the most significant part of the Frame Relay header. This value identifies and represents the VC* between the FRAD and the Frame Relay [network service provider] switch. Each VC that is multiplexed onto a physical channel will be represented by a unique DLCI. The DLCI values have local significance only, meaning they are only significant to the physical channel on which they reside. Devices on each end of a VC can use different DLCIs to identify the same VC.
- Extended Address (EA) -- Used to indicate whether the byte in which the EA value is 1 is the last addressing field. If the value is 1, then the current byte is determined to be the last DLCI byte. Although current Frame Relay implementations all use a two-byte DLCI, this capability does allow for the use of longer DLCIs in the future. The eighth bit of each byte of the Address field is used to indicate the EA.
MPLS labels use the extended address field of the Frame Relay frame header.
- C/R -- The C/R (Command/Response) bit that follows is the most significant DLCI byte in the Address field. The C/R bit is not currently defined.
- Congestion Control -- Consists of the 3 bits that control the Frame Relay congestion-notification mechanism. These are the FECN, BECN, and DE bits; they are the last 3 bits in the Address field.
- Forward-Explicit Congestion Notification (FECN) -- A single-bit field that can be set to a value of 1 by a switch to indicate to an end DTE device (router) that congestion was encountered in the direction of the frame transmission from source to destination. The primary benefit of both the FECN and BECN fields is the capability of higher-layer protocols to react intelligently to these congestion indicators. Currently, DECnet and OSI are the only higher-layer protocols that implement these capabilities.
- Backward-Explicit Congestion Notification (BECN) -- A single-bit field that, when set to a value of 1 by a switch, indicates that congestion was encountered in the network in the direction opposite of the frame transmission from source to destination. Explicit congestion notification is proposed as the congestion avoidance policy. It tries to keep the network operating at its desired equilibrium point so that a certain quality of service (QOS) for the network can be met. To do so, special congestion control bits have been incorporated into the address field of the Frame Relay: FECN and BECN. The basic idea is to avoid data accumulation inside the network.
- Discard Eligibility (DE) -- Set by the Frame Relay networking device (router) to indicate that the marked frame is of lesser importance relative to other frames being transmitted. Frames that are marked as DE should be discarded before other frames in a congested network. This allows for basic prioritization in Frame Relay networks.
|Data ||Contains encapsulated upper-layer data. Each frame in this variable-length field includes a user data or payload field that will vary in length up to 4096 bytes. This field serves to transport the higher-layer protocol data unit (PDU) through a Frame Relay network.|
|Frame Check Sequence (FCS) ||Ensures the integrity of transmitted data. This value is computed by the source device and is verified by the receiver to ensure integrity of the data transmission.|
Frame Relay LMI
The Frame Relay LMI is a set of Frame Relay specification enhancements. The original LMI was developed in 1990 by the Gang of Four (Cisco, DEC, Nortel, and StrataCom). LMI includes support for the following:
- Keepalive mechanismsVerify the flow of data
- Multicast mechanismsProvide the network server with local and multicast DLCI information
- Global addressingGive DLCIs global rather than local significance
- Status mechanismsProvide ongoing status reports on the switch-known DLCIs
Figure 15-14 illustrates the endpoints for LMI status messages.
Figure 15-14: LMI Status Message Endpoints
(Click image for larger view in a new window)
The original LMI supports a number of features, or enhancements, to the original Frame Relay protocol, for managing Frame Relay internetworks. The most notable Frame Relay LMI extensions include support for the following:
- Global addressing -- The LMI global addressing extension gives Frame Relay DLCI values a global, rather than local, significance. These global DLCI values become Frame Relay networking device addresses that are unique in the Frame Relay WAN.
As discussed earlier in this chapter, global addressing has an inherent limitation in that no more than 992 DLCIs (1024 DLCIs less the 32 reserved DLCIs) can be used. In a Frame Relay network of more than 992 sites, global addressing will not work. Apart from global addressing of DLCIs, the LMI status message presents an inherent limitation on the number of DLCIs that can be supported by an interface. Cisco has published a brief detailing these limitations at http://www.cisco.com/warp/public/125/lmidlci.html
- Virtual circuit status messagesProvide communication and synchronization between Frame Relay network access devices (FRADs) and the network provider devices (switches). These messages report (in a regular interval) the status of PVCs, which prevents data from being pointed to a PVC that does not exist.
- MulticastingSupports the assignment management of multicast groups. Multicasting preserves bandwidth by enabling routing updates and address-resolution (such as ARP, RARP) messages to be sent only to specific groups of routers.
LMI VC status messages provide communication and synchronization between Frame Relay DTE and DCE devices. These messages are used to periodically report on the status of PVCs, which prevents data from being sent into black holes (over PVCs that no longer exist).
Three types of LMI are found in Frame Relay network implementations:
- ANSI T1.617 (Annex D)Maximum number of connections (PVCs) supported is limited to 976. LMI type ANSI T1.627 (Annex D) uses DLCI 0 to carry local (link) management information.
- ITU-T Q.933 (Annex A)Like LMI type Annex D, the maximum number of connections (PVCs) supported is limited to 976. LMI type ITU-T Q.933 (Annex A) also uses DLCI 0 to carry local (link) management information.
- LMI (Original)Maximum number of connections (PVCs) supported is limited to 992. LMI type LMI uses DLCI 1023 to carry local (link) management information.
LMI Type LMI (Original) is annotated as LMI type Cisco within the Cisco IOS.
The frame MTU setting impacts LMI messages. If PVCs appear to be bouncing, (that is, repeated up/down indications), it might be because of the MTU size of the Frame Relay frame. If the MTU size is too small, not all PVC status messages will be communicated between the service provider edge and the Frame Relay access router. If this condition is suspected, the next step is to contact the network service provider to troubleshoot.
LMI Frame Format
Figure 15-15 illustrates the LMI frame format to which Frame Relay LMI frames must conform, as deemed by the LMI specification.
Figure 15-15: LMI Frame Format
(Click image for larger view in a new window)
Table 15-8 presents a description of each LMI field.
Table 15-8: LMI Frame Format Field Description
|Flag ||Delimits the start and end of the LMI frame.|
|LMI DLCI ||Identifies the frame as an LMI frame rather than a Frame Relay data frame. The DLCI value is dependent on the LMI specification used; LMI (original) uses DLCI 1023, LMI (Annex A) and LMI (Annex D) use DLCI 0.|
|Unnumbered Information Indicator ||Sets the poll/final bit to zero (0).|
|Protocol Discriminator ||Always contains a value indicating that the frame is an LMI frame. |
|Call Reference ||Always contains zeros. This field is currently not used for any purpose.|
|Message Type ||Labels the frame as one of the following message types:
- Status-inquiry message -- Allows a user device to inquire about the status of the network.
- Status message -- Responds to status-inquiry messages. Status messages include keepalive and PVC status messages.
|Information Elements ||Contains a variable number of individual information elements (IEs). IEs consist of the following fields:
- IE IdentifierUniquely identifies the IE.
- IE LengthIndicates the length of the IE.
- DataConsists of one or more bytes containing encapsulated upper-layer data.
|Frame Check Sequence (FCS) ||Ensures the integrity of transmitted data.|
The LMI global addressing extension gives Frame Relay DLCI values global rather than local significance. DLCI values become DTE addresses that are unique in the Frame Relay WAN. The global addressing extension adds functionality and manageability to Frame Relay internetworks. Individual network interfaces and the end nodes attached to them can be identified by using standard address-resolution and discovery techniques. Additionally, the entire Frame Relay WAN appears as a LAN to routers on the periphery.
The LMI multicasting extension allows multicast groups to be assigned. Multicasting saves bandwidth by allowing routing updates and address-resolution messages to be sent only to specific groups of routers. The extension also transmits reports on the status of multicast groups in update messages.
Our next segment from Cisco Press' Network Consultants Handbook will deal with Frame Relay Applications.