Frame Relay Protocols


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.

LAPF

Frame 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 Format

LAPF core functions are organized around five elementary procedures:

  • Frame Relay must provide services to delimit and align frames and provide transparency of the frame flags with zero-bit stuffing and unstuffing.

  • Frame Relay must support virtual circuit multiplexing and demultiplexing through the use of the data-link connection identifier (DLCI) field in the frame.

  • The system must inspect the frame to ensure that it aligns itself on an integer number of octets, prior to zero bit insertion and following the unstuffing of the zero bit.

  • The system must inspect the frame to ensure that it does not exceed the maximum and minimum frame size (the frame sizes are established by the service provider).

  • The systems must be able to detect transmission errors through the use of the Frame Check Sequence (FCS) field.

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:

  • Beginning flag field

  • Ending flag field

  • Two-byte address field

  • Variable-length information field

  • FCS field, used for error control

Figure 14-4. Frame Relay Frame Format


NOTE

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 Field

The 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 Procedure


This procedure works regardless of the value of bit 7 (0 or 1), because of the content of the next (address) field.

Address Field

The address field has three different formats, shown in Figure 14-6.

Figure 14-6. LAPF Core Formats of the Address Field


Descriptions of the fields follow:

  • DLCI Data link connection identifier is a unique number that provides local identification of the connection. The default address field format is 2 bytes or 10 bits. The extended address frame format can be 3 bytes (16 or 17 bits) or 4 bytes (23 bits).

  • C/R Command/Response Field provides interconnectivity with higher-layer protocols. Frame Relay does not check it and the router can use this bit for signaling and control.

  • FECN Forward explicit congestion notification indicates congestion in the direction of the traffic flow.

  • BECN Backward explicit congestion notification indicates congestion in the direction opposite of the traffic flow.

  • DE Discard eligible indicates the importance of the packet. If DE = 1, the packet is eligible for discarding, and in the case of congestion it can be dropped without any notification. It is a bit that can be set by the user and by the network. Setting a bit DE = 1 does not necessarily mean that the frame will be dropped; however, the packet is eligible for discard when congestion exists on the network. In fact, in CIR = 0 provisioned networks, you might have up to 99.9 percent of frames delivered.

  • EA Extended address extends the addressing structure from a default of 2 bytes, to 3 and 4 bytes. The EA = 0 indicates that more address follows, and EA = 1 indicates that it is the last address byte.

  • D/C Data or control field that exists in either the DLCI or the DL-core control indicator.

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.

Table 14-5. Frame Relay Forum (FRF) 10-Bit DLCI Values and Their Functions

DLCI Values

Function

DLCI Assignments

0

Reserved for Call Control Signaling; AnnexD Local Management Interface (LMI)

1-15

Reserved

16-1007

Available for PVC

1008-1022

Reserved

1019-1022

Used by some vendors for multicast

1023

Initially defined for LMI by Consortium; used for consolidated link-layer management (CLLM) messages in T1.618

ANSI (T1.618) and ITU-T (Q.922) 10-Bit DLCI Recommendations and Management (LMI)

0

In-channel signaling

1-15

Reserved

16-991

Assigned, using Frame Relay connection procedure

992- 1007

Layer 2 management of Frame Relay Bearer Services

1008-1022

Reserved

1023

In-channel layer management


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 Protocol

For 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 Field

In 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 Control


Figure 14-8. LAPF Frame-Switching Format


Figure 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 Formats


NOTE

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 Frame

In 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:

  • LMI messages

  • T1.617 AnnexD messages

  • CLLM messages

  • SVC 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 Formats


The 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


Table 14-6. Single Octet and Variable-Length IE Format[*]

Bits[*]

8765 4321

Description of the IE Formats

Max Length (Octets)

1xxx xxxx

Single Octet IE

1000 xxxx

Reserved

1

1001 xxxx

Shift

1

1101 xxxx

Repeat indicator

1

0xxx xxxx

Variable Length IE

0000 0001

Report type

3

0000 0011

Keepalive

4

0000 0100

Bearer capability

5

0000 0111

PVC status

5

0000 1000

Cause

32

0001 0100

Call state

3

0001 1000

Channel ID

n/a

0001 1001

DLCI

6

0001 1010

Link integrity verification

4

0001 1110

Progress indicator

4

0010 0000

Network specific facilities

n/a

0010 1000

Display

82

0100 0010

End-to-end transit delay

11

0100 0100

Packet layer binary parameters

3

0100 1000

Link-layer core parameters

27

0100 1001

Link-layer protocol parameters

9

0100 1100

Connected number

n/a

0100 1101

Connected subaddress

23

0110 1100

Calling party number

n/a

0110 1101

Calling party subaddress

23

0111 0000

Called party number

n/a

0111 0001

Called party subaddress

23

0111 1000

Transit network selection

n/a

0111 1100

Low-layer compatibility

14

0111 1101

High-layer compatibility

4

0111 1110

User-user

131

0111 1111

Escape for extension

n/a


[*] All other values are reserved; x means the value does not matter. n/a means it is not defined.

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.)




Troubleshooting Remote Access Networks CCIE Professional Development
Troubleshooting Remote Access Networks (CCIE Professional Development)
ISBN: 1587050765
EAN: 2147483647
Year: 2002
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net