The Frame Relay protocols are designed to reflect the concept of the second layer of the OSI model, based on services from the physical layer and providing services for the higher-layer protocols. At the same time these protocols are not simplistic. They provide a mechanism to maintain PVCs to establish SVCs, and to encapsulate higher-layer protocols. LAPFFrame Relay technology provides second layer functions such as framing, error control, and sequence control, and support for third layer functionality such as addressing and multiplexing. This is the core functionality of LAPF, which is defined in Recommendation Q.922. The protocol allows statistical multiplexing of one or more frame connections over a single channel. LAPF can be used over Frame Relay to provide end-to-end error and flow control. LAPF defines core functions and full functionality. The core LAPF is used for Frame Relay, and full LAPF (core LAPF and control LAPF) is used for frame switching. LAPF Core Protocol and the T1.618 (Q.922 Annex A) Frame FormatLAPF core functions are organized around five elementary procedures:
A Frame Relay network consists of endpoints (PCs, servers, local-area networks [LANs]), Frame Relay access equipment (bridges, routers, hosts and Frame Relay access devices [FRADs]), and network devices (switches, network routers and T1/E1 multiplexers). The protocol interconnecting these devices is a subset of the high-level data link control (HDLC) frame format that is shown in Figure 14-4. The frame consists of five fields:
Figure 14-4. Frame Relay Frame FormatNOTE For the purposes of this book, the term router is used later in the discussion as a common name for a Frame Relay access device. The information field and the FCS fields are no different from most protocol formats. The information field contains encapsulated upper-layer data. Each frame in this Variable-length field includes a user data or payload field that varies in length as large as 16,000 octets. This field serves to transport the higher-layer protocol packet (protocol data unit [PDU]) through a Frame Relay network. The FCS precedes the ending flag delimiter and is usually a cyclic redundancy check (CRC) calculation remainder. The CRC calculation is redone in the receiver. If the result differs from the value in the original frame, an error is reported. This field uses a 2-byte CRC sequence with a CRC-16 polynomial. The information field can vary in length up to 16,000 octets, but FCS code provides error detection for frames up to 4096 bytes. The next sections concentrate on Frame Relay specific format fields such as the Flag field and Address field. Flag FieldThe Flag field is one byte that is a fixed sequence and consists of 01111110 (binary) or 0x7E (7Eh). The Flag indicates the beginning and end of the frame. If the sender needs to send 7Eh as part of the information in the middle of the transmission, but not as a Flag, the sender inspects the data stream for 011111. If found, a 0 is inserted immediately after the fifth 1, which changes the data stream (see Figure 14-5). Figure 14-5. The Zero-Insertion ProcedureThis procedure works regardless of the value of bit 7 (0 or 1), because of the content of the next (address) field. Address FieldThe address field has three different formats, shown in Figure 14-6. Figure 14-6. LAPF Core Formats of the Address FieldDescriptions of the fields follow:
Two UNI interfaces connect to each other by using a 10-bit DLCI (by default), which provides 210 = 1024 DLCIs, from 0 to 1023 (see Table 14-5). The core LAPF protocol uses simple logic. The first check of the incoming frame is for a valid/not valid frame. If the frame is valid, the LAPF core checks the known/unknown DLCI. If it is OK, the frame proceeds further. However, a Frame Relay network drops erroneous and non-erroneous frames. The first group of erroneous frames is dropped regardless of the condition of the network and includes packets without opening and closing flag fields, frames with the wrong DLCI, larger and smaller than expected frames, and frames with a FCS error. The second group of drops are frames with DE = 1, if there is network congestion. A third group of non-erroneous frames can be discarded randomly during periods of congestion.
Overall, Cisco LMI provides for 992 VCs, and ANSI provides for 976. NOTE The original LMI specification defines DLCI 1023 for LMI, but the AnnexD standard assigns DLCI 0 for this function. This change aligns the LMI function with previously defined ISDN, where DLCI 0 is used for signaling (refer to Table 14-5). AnnexD is the most widely accepted for multivendor solutions. LAPF Control ProtocolFor frame switching services, the LAPF control protocol is used along side the LAPF core protocol. This protocol is the full Q.922, and it is implemented both in the user's system and in the network (called the frame handler). Figure 14-4 shows one of the common formats, where the information field carries a higher-layer PDU and represents Frame Relay with other end-to-end protocols above LAPF, thus providing error and flow control. Here again, the Flag and Address fields and FCS are the same as in the LAPF core format. The specific fields for this protocol, the control field and information (data) field are discussed in the following sections. Control FieldIn Figure 14-7 and Figure 14-8, two formats of Q.922 are shown. The only difference between the core format and the control protocol format is the control field. The control field has the same format and identical functionality as the Link Access Procedure on the D channel (LAPD) field. The control protocol provides the functions of error and flow control that are missing from the LAPF core protocol. Figure 14-7. LAPF Frame Formats; Frame Relay with End-to-End LAPF ControlFigure 14-8. LAPF Frame-Switching FormatFigure 14-7 represents one possible option for end-to-end flow control and error control, based on the full LAPF protocol frame. The Frame Relay control field is part of the information field of the frame, and because Frame Relay does not monitor the information field, this feature is significant for end-to-end connections. At the same time, the information field can contain network and transport layer PDUs. Figure 14-8 represents the frame switching bearer service. The control field is visible to the network because it is not part of the information field. Therefore, error control is performed in the user-to-network part of the structure. Regardless of this second layer control feature, the error and flow control functions can still be exercised by the higher-layer protocols. The different LAPF control formats are shown in Figure 14-9. Figure 14-9. LAPF Control FormatsNOTE The control field in LAPF is used between the user and the network; it is not an end-to-end function. End-to-end functions are based on PDUs for the higher-layer protocols, which provide end-to-end flow and error control. Information (Data) Field of the LAPF Control Protocol FrameIn the LAPF control protocol, the information field carries both non-data (signaling) and user data information. A Frame Relay network uses four categories of signaling messages:
In general, the information field uses two formats as shown in Figure 14-10. In the figure, IE indicates the information elements. Figure 14-10. Information Field FormatsThe IE fields carry higher-layer protocol information such as user data and higher-layer overhead and routing updates. It is transparent to the Frame Relay network. There is no inspection or change to this field, which allows the use of new features such as compression, Virtual Private Network (VPN), quality of service (QoS), and VoFR. ANSI T1.618 and FRF.1.1 recommend a maximum negotiated information length up to 1600 bytes to reduce the number of segmentations and re-assembly functions in wide-area network (WAN)-LAN borders. Each of the four categories of signaling messages use a Q.931 header to carry different information. NOTE The protocol discriminator field of Q931 (single octet) (refer to Figure 10-7) carries the format of the message that follows. The value 08H indicates messages defined by ANSI T1.607, and 09H indicates a Consortium message. The messages that do not relate to the call establishment disconnect, or status use a Dummy Call Reference in Q.931 header with the field containing all zeros (00H). Part of the signaling message is the IE, which can follow one of two basic single octet formats: single octet (type 1) and single octet (type 2). The IE can have variable length information. The two single octet types (type 1 and type 2) are shown in Figure 14-11. The single octet basic IE format and the variable-length basic IE format are explained in Table 14-6. Figure 14-11. Two Basic Single Octet Formats of IE. The First Format Is the Common Single Octet Format and the Second Two Show Type 1 and Type 2 Formats
There is no commonly implemented minimum or maximum frame size for Frame Relay, although a network must support at least a 262-octet. Generally, each Frame Relay provider specifies an appropriate value for its network. Frame Relay DTE must allow the maximum acceptable frame size to be configurable. The minimum frame size allowed for Frame Relay is five octets between the opening and closing flags, assuming a two-octet Q.922 address field. This minimum increases to six octets for a three-octet Q.922 address and to seven octets for a four-octet Q.922 address format. The Cisco maximum transmission unit (MTU) is set by default to 1500 bytes. Given the fact that the two flag fields, the default address field and the FCS, are 6 bytes, only a small portion of the size of the packet (up to (1500 6) / 1500 = 0.004) is the technology overhead, which is one of the unique features of Frame Relay. (See Chapter 9, "ISDN Technology Background," for a comparison with ISDN overhead.) |