Routing characteristics for frame relay

This topic provides information about how data is routed through a frame-relay network.

The frame-relay network routes frames through the network by examining the data link connection identifier (DLCI) field and then routing the frame to an outgoing link. The network delivers frames to the remote terminal equipment (TE) in the same sequence as they were provided to the network by the local TE.

At each node within the frame-relay network, the system verifies the frame check sequence (FCS) and checks the frame format and size. If the frame is valid, the system replaces the DLCI and FCS before routing the frame to the next node. If the frame is damaged or otherwise not valid, the system discards it. The network node provides no error recovery.

Frame-relay core services frame format

The following figure shows the basic frame format that is used for frame-relay communications.

Figure 1. Frame format that frame-relay networks use

The frame-relay core services (FRCS) portion of the frame routes the frame through the frame-relay network. The frame structure is based on the ITU-T Q.922 protocol.

Figure 2 shows the FRCS frame format on the fields within the 2-byte Q.922 address field (QA).

Figure 2. Frame format for frame-relay core services (FRCS)
The QA portion of the frame
includes: DLCI0 = DLCI high order bits (6 bits); DLCII = DLCI low order bits
(4 bits); C/R = Command/response bit (not used); EA0/1 = Extended address
indicators; CC = Congestion control (3 bits).

The QA portion of the frame
includes: DLCI0 = DLCI high order bits (6 bits); DLCII = DLCI low order bits
(4 bits); C/R = Command/response bit (not used); EA0/1 = Extended address
indicators; CC = Congestion control (3 bits).

Frame-relay protocol headers

TEs use frame-relay protocol headers to provide routing for frames, to assure data integrity, and to perform recovery when frames are damaged or lost. iSeries™ frame-relay support uses protocol headers that are defined in Frame-Relay Forum IA 3.1.

The IBM^® eServer iSeries system uses protocol header formats for Systems Network Architecture (SNA) direct, bridged local area network (LAN), and local management interface (LMI) connections. The information field of the FRCS frame contains these headers and information fields (protocol data units or IP packets).

The following figures show the protocol header formats.

Figure 3. SNA direct frame format

Figure 4. IP direct frame format

Figure 5. High-Performance Routing (HPR) frame format
High-Performance Routing
(HPR) frame format

Figure 6. Bridged token-ring and DDI LAN frame format (Frame-Relay Forum IA 3.1)
Bridged token-ring and DDI
LAN frame format (Frame-Relay Forum IA 3.1)

Figure 7. Bridged IEEE Ethernet LAN frame format (Frame-Relay Forum IA 3.1)
Bridged IEEE Ethernet LAN
frame format (Frame-Relay Forum IA 3.1)

Figure 8. Bridged Ethernet version 2 LAN frame format (Frame-Relay Forum IA 3.1)
Bridged Ethernet version
2 LAN frame format (Frame-Relay Forum IA 3.1)

Figure 9. LMI message frame format

Figure 10. Address Resolution Protocol (ARP) format
Address Resolution Protocol
(ARP) format

Table 1 describes the protocol header fields.

Table 1. Format fields for the frame-relay protocol header
Field	Description	Values and notes
C	Q.922 (HDLC) control field
PAD	Pad characters	Pad characters (hex 00) are permitted between the control field and the NLPID field. Pad characters are used for boundary alignment.
NLPID	Network-level protocol identifier	08 ITU-T Q.931 (SNA direct and HPR) 80 IEEE Subnetwork Access Protocol (SNAP) for bridged LAN connections CC Internet Protocol (IP) direct
PD	Protocol discriminator	LMI frames use hex 08
OUI	Organization-unique identifier	0080C2 IEEE 802.1 000000 ARP
PID	Protocol identifier	The iSeries system supports the following formats not using frame check sequence (FCS): 0007 Ethernet 0009 Token-ring network 000A DDI network 0806 ARP The iSeries system provides receive-only support for the following formats using FCS: 0001 Ethernet 0003 Token-ring network 0004 DDI network
L2	Layer 2 protocol	For iSeries systems using SNA direct connections, 4C80 is placed in the L2 field Byte 1 4C IEEE 802.2 (ISO 8802/2) 4E Q.922 (IDLC) 46 LAP-B (X.25) 4A HDLC NRM (SDLC) 51 ISO 7776 70 Without IEEE 802.2 (ISO 8802/2) header Byte 2 80 Undefined 81 MAC address included (IEEE 802.2, ISO 8802/2) or HDLC address included (ISO 7776)
L3	Layer 3 protocol	For iSeries systems using SNA direct connections, 7082 is placed in the L3 field. Byte 1 66 ITU-T X.25 67 ISO 8208 (X.25 PLC) 70 User-specified Byte 2 81 SNA subarea (FID4) 82 SNA peripheral (FID2) 83 APPN (FID2) 85 HPR Network Layer Protocol (FID5)
	Information field	iSeries support for SNA direct, frame-relay connections requires the information field to contain a FID2 protocol data unit (PDU). Information fields sent over bridged connections may contain FID2 PDUs or IP packets.

Notes:

AC: Access control
FC: Frame control
DA: Destination address
SA: Source address
RI: Routing information
Lth: Length
Type: Ethernet type
DSAP: Destination service access point
SSAP: Source service access point
Ctl: IEEE 802.2 control field