Frame Relay and Upper-Layer Protocols

Flow control and error recovery functions can be performed by the full LAPF protocol. Typically, the full LAPF is not used in PVC circuits. Therefore, these functions must be performed by the higher-layer protocols, which are encapsulated in the PDU as a component of the information field of the frame format. This approach is the most commonly implemented today. To ensure the interoperability of Frame Relay and higher-layer protocols, two major issues must be addressed: multiprotocol support and fragmentation.

Multiprotocol support refers to the encapsulation of higher-layer protocols such as IP, TCP, Internetwork Packet Exchange (IPX), and X.25, in the frame format. FRF.3.2 and RFC 1490, "Multiprotocol Interconnect over Frame Relay" (by Bradley and published by IETF) both address this topic. Fragmentation refers to the process of dividing large network packets into smaller packets and then reassembling them at the receiver site. This subject is governed by ANSI T1.617a Annex A, "Signaling Specification for Frame Relay Bearer Service for Digital Subscriber Signaling System Number 1 (DSS1) Protocol Encapsulation and PICS."

Frame Relay carries two types of data: routed packets and bridged packets. The remote user's router must distinguish between the two types of frames. To assist with this purpose, up to four fields can be added to the T1.618 information field format, as shown in Figure 15-5. They are the Network Layer Protocol ID (NLPID), L2 Protocol ID, L3 Protocol ID, and Subnetwork Access Protocol (SNAP).

Figure 15-5. Multiprotocol Encapsulation Options

The Q.922 Control field specifies an Unnumbered Information (UI), Supervisory (S), or Information (I) frame. The Pad field aligns the rest of the frame on a two-octet boundary and contains up to a single octet with the value 00h. The ISO and ITU-T administer the NLPID, which defines the encapsulation of the protocol that follows. The common values are 08h for Q.933; 80h for SNAP; 81h for ISO Connectionless Network Protocol (CLNP); and CCh (0xCC) for IP. In some cases, Layer 2 and Layer 3 Protocol IDs or a SNAP header follow the NLPID. Some of the encapsulated protocols are covered in the next section.

Encapsulating IP, Q.933, and SNAP

ANSI T1.617a Annex F defines the standards for encapsulating IP, Q.933, and SNAP. When encapsulating IP, an optional pad can be added to align the rest of the frame on a two-octet boundary. No further control information, such as IDs or a SNAP header is required.

The encapsulation format for Q.933 can be used when no specific network protocol is defined.

SNAP is used for encapsulating bridged IEEE 802.3 frames for routed and bridged packets that contain LAN-to-LAN traffic. The NLPID is set to 80h and is followed by a 5-byte SNAP header (3-byte OUI + 2-byte PID). Routed packets use OUI 00 00 00h, and bridged packets use OUI 00 80 C2h to identify the IEEE 802.1. Figure 15-6 shows the encapsulation formats for IP, Q.933, and SNAP.

Figure 15-6. Encapsulating IP, Q.933, and SNAP

Encapsulating Other Protocols over Frame Relay

To indicate the usage of the ISO CLNP protocol, the NLPID field must be set to 81h. As soon as the NLPID field indicates ISO CLNP, the data packet immediately follows. NLPID is also considered part of the CLNP packet, and as such, it should not be removed before being sent to the upper layers for processing.

IPX does not have a NLPID value defined. For this reason, IPX is encapsulated using the SNAP header. The frame format is in the following order: Initial Q.922 Address and Control field = 03h, then the Pad field is added (00h). NLPID is 80h (SNAP) and OUI = 00 00 00h (routed packets), followed by PID = 8137h, and then the IPX packet itself with possible fragmentation.

FRF.3.2 provides additional encapsulation examples, including Systems Network Architecture (SNA) and NetBios traffic over Frame Relay.

Frame Relay Fragmentation

The upper-layer protocols use different formats and usually the information field contains more than one T1.618 frame. T1.617A Annex F and RFC 1490 address the fragmentation process. When a packet must be fragmented, the fragmentation protocol adds an encapsulation header to it and divides the packet into many smaller fragments, according to network requirements. Each fragment receives a fragmentation header (see Figure 15-7). In the example, the size of the IP packet is greater than the size of the T1.618 frame, and you use the RFC 1490 recommendations.

Figure 15-7. Fragmented IP Packet in Frame Relay

The fragmentation header consists of four fields:

• A Sequence (Seq.) field (2 bytes) that is incremented for every fragment

• A Reserved (Rsvd) field (4 bits, all 0s)

• A Final bit, which is 0 for the first fragment and 1 for the last one

• An Offset field, which is an 11-bit value that represents the logical offset of this fragment, divided by 32. The first fragment has an offset = 0.

The Cisco recommendations for fragment sizes in Table 15-1 are based on port access rates.

Table 15-1. Cisco Recommendations for Fragment Sizes

Port Access Rate	Recommended Data Segmentation Size
64 kbps	80 bytes
128 kbps	160 bytes
256 kbps	320 bytes
512 kbps	640 bytes
1536 (full T1)	1600 bytes
2048 (full E1)	1600 bytes