Table of Contents
Advertisement
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.
frame-relay fragment
The
frame-relay fragment
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
command sets the fragment size in the FR map class and the
command displays statistics.
show
Advertisement
Table of Contents
Troubleshooting
