Enterasys Networks X-PeditionTM manual FRF.12 Fragmentation, End-to-End Fragmentation

FRF.12 Fragmentation

FRF.12 Fragmentation

Generally speaking, it is difficult to deliver good end-to-end quality of service for time-sensitive packets (voice and video) when operating over low speed FR lines (64 kbps or lower), especially when the link is also used to transport large packets (1500-byte FTP traffic). This is due to the fact that it takes 214 milliseconds to send a 1500-byte packet over a 56 kbps link. If a high priority voice packet happens to arrive after the FR port has started sending a large packet, the voice packet would be delayed for at least 214 mS before it can be sent over the link. This delay renders the voice quality choppy and unusable.

The FRF.12 implementation agreement aims to alleviate this problem by breaking up large packets into a series of small fragments, and allowing high priority, non-fragmented packets on the same DLCI to be sent between the small fragments that comprise a large packet. If the fragment size is 100 bytes, then the maximum delay a high priority packet can experience due to the serialization delay of a previous fragment is approximately 20 mS on the 56 kbps link. This is 10 times less than the case without fragmentation.

End-to-End Fragmentation

The XSR supports end-to-end fragmentation such that both end stations must participate in the fragmentation process and fragmentation must be transparent to the FR network. This feature is useful when the link between both end stations on the FR network is running at a relatively low speed.

End-to-end fragmentation is configured on a per DLCI basis. If one DLCI requires fragmentation, we recommend that all DLCIs on a given interface be configured for fragmentation. But, there are a couple of exceptions:

•For a link whose speed is fast enough to keep latency from large packets at a reasonable level

•For DLCIs known to pass only moderately- sized packets (those less than or equal to the fragment size) will not cause excessive serialization delay even when sent un-fragmented.

Enabling fragmentation on a Frame Relay connection is meant to allow data which is sensitive to latency to be transmitted with as low a delay as possible. To ensure a low delay path, QoS is required to classify the traffic so that only low latency traffic is configured on the high priority queue. All other traffic can then be classified appropriately on the remaining queues.

Careful configuration is mandatory since it is possible to defeat the purpose of fragmentation by sending a high priority packet which is larger than the configured fragment size.

Usually, a high priority packet will be interleaved between fragments of a larger lower priority packet. But, if the high priority packet is too large it will need to be fragmented before being transmitted. Only one packet which requires fragmenting can be transmitted at a time - multiple fragmented packets are not interleaved. If a low priority packet is currently being transmitted, the high priority packet will need to wait until all packets are delivered and so will suffer from higher latency.

The frame-relay fragment command sets the fragment size in the FR map class and the show frame-relay fragment command displays statistics.

User Configuration Commands

The XSR interprets all CLI commands immediately and become part of the running configuration. If a parameter in a FR map is changed, the change is reflected automatically by FR devices which reference this map. But new configuration changes are not saved into the startup configuration file

9-8 Configuring Frame Relay