- Fundamentals of Voice over Frame Relay
- 11 Voice over Frame Relay
- 12 Data Fragmentation
- Bandwidth Calculations
- Summary
FRF.12 Data Fragmentation
Now that you have a basic grasp on the idea behind VoFR, it becomes necessary to discuss the manner in which voice traffic behaves when data traffic is present. FRF.12 defines data fragmentation of data frames when voice frames are present. Fragmentation is generally not necessary on high-speed links (i.e., higher than 768Kbps).
FRF.12 Frame fragmentation provides transmitting VoFR devices with the ability to break long frames into a sequence of shorter frames, which will then be reassembled into the original frame by the receiving VoFR device. Frame fragmentation is necessary to control delay and delay variation when real-time traffic, such as voice, is carried across the same interfaces as data. The size of the data fragments is configured by the administrator based upon the bandwidth of the link at the slower side of the Frame Relay network.
To properly support traffic on lower-speed links, it is necessary to fragment long frames that share the link with shorter frames. This is to ensure that the shorter frames are not excessively delayed. Fragmentation enables interleaving voice and data traffic.
FRF.12 Sub-Header
Each resulting fragment includes a sub-header that contains a 12-bit sequence number to facilitate reassembly at the remote end. The sequence number is incremented modulo 212 for every data fragment transmitted on a VC. There is a separate sequence number maintained for each DLCI across the interface.
The first fragment sent across a VC sets the sequence number, which can be any valid value (including zero). The sequence number subsequently must be incremented by one for each fragment transmitted. As mentioned earlier, the final fragment in a frame has the E bit set to 1. The first fragment of the next frame has the B bit set to 1. The sequence number of the first fragment of the next frame is the sequence number of the previous frame plus 1. For example, if the last fragment in one frame used sequence number "N", then the first fragment of the following frame will use sequence number "N+1". This allows for lost fragment detection. Each VC has its own fragmentation sequence number progression, independent of all other VCs. In the event of an error (i.e., one or more fragments are lost due to transmission error or reassembly buffer overflow), fragments that cannot be reconstructed back into the original frame must be discarded by the receiver.
The sub-header is illustrated in Figure 4.
){kind=link}
Figure 4 FRF.12 Sub-header structure
From the figure it is evident that each fragment is a Frame Relay frame with a sub-header prepended to it. Note that the 2-byte Frame Relay header still exists for each fragment. This is necessary for the Frame Relay switching function to work properly. The sub-header of the first fragment has a beginning bit set to 1, whereas the last fragment has an end bit set to 1. All fragments in between have both B and E bits set to 0.
The control bit (C) is not in use at this time and is reserved for future development.
Note that the low order bit of the first octet of the fragmentation header is set to 1. This allows the fragmentation header to be distinguishable from the Frame Relay header. Because of this, the VoFR device can detect the misconfiguration of its peer, since the peers must be configured identically to use or not use fragmentation across an interface. If a peer configured for fragmentation receives frames that do not contain the fragmentation header, those frames are discarded. If a peer is not configured for fragmentation and receives frames with the fragmentation header, those frames also are discarded.
FRF.12 Fragmentation Size
The inevitable question arises when performing data fragmentation: "How big should the fragments be?" The answer to this question is based on the bandwidth of the slower side of the Frame Relay link. In typical Frame Relay implementations, it is rare for all links to be provisioned with the same amount of bandwidth. Usually, a central site will have the highest bandwidth, with each branch office having a bandwidth allocation based on the type and volume of traffic expected to traverse the link. It is imperative that the fragment size is based upon the slower side, or else it will be possible to overrun the remote device. Refer to Table 2 for a general guideline.
Table 2 FRF.12 Fragmentation Size Guidelines
|
Link Speed (in Kbps) |
Fragment Size (in Bytes) |
|
56 |
70 |
|
64 |
80 |
|
128 |
160 |
|
256 |
320 |
|
512 |
640 |
|
768 |
1000 |
|
1536 |
N/A |
The faster the link, the less the need for fragmentation exists. It is not recommended that fragmentation be implemented on links with more than 768Kbps. The fragmentation size is set on a per-VC basis; therefore, the size should be altered for each VC based on the bandwidth available to the slower side of the link.