This second half of the chapter discusses frame relay configuration, mostly basics, and much of which was explicitly covered or at least alluded to in previous chapters. I’ll hit the highlights.
- A major component of configuring frame is to associate DLCIs with the appropriate interface, or subinterface as the case may be. Both of the following commands can accomplish this:
- “frame-relay map” (alternative method, not typical)
- “frame-relay interface-dlci” (common)
- A router can learn about DLCI numbers via LMI, but naturally this does not tell the router what subinterface the router should assign that DLCI to.
Frame Relay Payload Compression
- Frame offers 3 different options for payload compression on a virtual circuit. All 3 use the LZS algorithm, but utilize it differently in regards to the LZS dynamic dictionary. LZS builds a dictionary containing a binary string, and the smaller string that represents the binary string during transmission. If the compression method uses “packet-by-packet”, that implies that the dictionary is built for each packet and discarded. If packet-by-packet is not used, then the dictionary perseveres.
- Packet-by-packet uses LZS, does not use the same dictionary for each packet, and is Cisco proprietary.
- Frame Relay Forum Implementation Agreement 9 (FRF.9) uses LZS, uses the same dictionary, and is not Cisco proprietary.
- Data-stream uses LZS, uses the same dictionary, and is Cisco proprietary.
- “frame-relay payload-compress <type>” can be used on point-to-point interfaces.
- For interfaces not point-to-point, “payload-compress <type>” is used at the tail end of the “frame-relay map” command.
Frame Relay Fragmentation
- As with PPP, it’s possible to set up your frame-relay virtual circuit for fragmentation and interleaving, to support latency-sensitive packets. The idea is to take small packets with latency sensitivity, and place them in a LLQ, and interleave them out the interface with fragments of other, larger packets that may not be sensitive to delay.
- Frame Relay Forum IA 12 (FRF.12) defines the standard for link fragmentation and interleaving (LFI) over frame relay.
- Traffic leaving the frame-relay traffic shaping (FRTS) LLQ go into the “high” dual FIFO queue defined by FRF.12.
- All other traffic ends up in the normal dual FIFO queue.
- Cisco recommends that you set a fragment size such that the high-priority traffic doesn’t typically fragment.
- To configure FRF.12, “frame-relay fragment <size>” goes into the FRTS map class on either end of the virtual circuit.
- To configure “Frame Relay Fragmentation at the Interface”, you can turn on LFI for frame without requiring FRTS.
- “frame-relay fragment” on the physical interface will enable this.