Overview
Multi-Link Frame Relay, or MFR, is similar to Multi-Link PPP, and both are a form of inverse multiplexing. Users rely on inverse multiplexing when access
line capacity does not scale smoothly, i.e. notice the big jumps in bandwidth from 56kbps, 1.544 Mbps, and 45 Mbps. In such cases, intermediate bandwidth
must be derived by aggregating a number of smaller access lines into larger ones. MFR is used to derive a larger frame relay pipe by aggregating smaller
frame relay pipes. For example, 5 T1 frame relay pipes could be bundled to appear as a single 7.5 Mbps frame relay pipe. Some of the advantages of
using MFR are: better bandwidth sizing according to customer traffic requirements and potentially better QOS by minimizing delay.
MFR works by bundling multiple T1 circuits into a multilink bundle and fragmenting the individual frame relay frames into fragments. These fragments are
then transported in parallel over the multiple T1 circuits. At the other end, the fragments are reassembled into the original frame relay frames. The protocol
includes the use of sequence numbers to allow the fragments to be reassembled correctly and to ensure that the reconstructed frames are sent out in the
original order in which they entered the network.
FR and MFR can be emulated and analyzed using GL’s client-server based MFR Emulation and FR Analysis software modules. MFR is an optional
application for GL’s Card and USB based T1 E1 platforms.
Main Features:
- Adheres to FRF.12 and FRF.15 standards
- Support two simulation modes - FR and MFR
- Add Frame Relay links to MFR bundle
- Activate and deactivate Frame Relay links (streams) dynamically
- Create and delete Virtual Channels on FR links/MFR bundle
- Generate and verify end to end traffic on each Virtual Channel
- Supports both Interface (UNI and NNI) and End-to-End fragmentation
- Supports various traffic source/sink types namely, Sequence Number, Binary File, Hex String and HDL file
- Create and delete Aggregated Virtual Channels
- Supports various Byte and Frame level Impairments
- Provides detailed statistics for FR link/MFR bundle and each Virtual Channel
Operations
Adding Frame Relay links (streams)
Syntax: inform task n "TS [HC|SC] 'Link Name'";
It is used to add new frame relay links (streams) to the task. In FR simulation the added links are independent of each other, and Virtual Channels
will be created on each individual link. In MFR simulation all the added links will constitute one MFR bundle, and Virtual Channels will be created on the
bundle but not the constituent bundle links.
Activating/Deactivating Frame Relay links (streams)
Syntax: inform task n "ACTIVATE TS [HC|SC] ‘Link Name’";
inform task n "DEACTIVATE TS [HC|SC] ‘Link Name’";
This command is used to activate /deactivate the individual bundle links in the MFR bundle. Provides an option to dynamically activate/deactivate
the links, deactivated links are not be used for Tx/Rx.
Creating/deleting Virtual Channels on the links
FR simulation:
Syntax: inform task n "CREATE VC HC #1:0..23 DLCI x FRAG FORMAT UNI NNI [END TO END] FRAGSIZE n";
MFR simulation:
Syntax: inform task n "CREATE VC DLCI x [y z …] FRAGSIZE n";
This is used to create or delete virtual channels on the FR links. In case of MFR simulation, virtual channels are created on the MFR bundle.
The following information is required to create a virtual channel:
- DLCI value
- Fragmentation format – Interface (uni/nni) or End-to-End
- Fragment size.
- Link Name.
Multiple Virtual Channels can be crated in a single command on the same physical link with same fragmentation format and fragment size. Multiple
VC’s on the same physical link can be deleted using a single command.
Creating/deleting Aggregated Virtual Channels on the links
Syntax: inform task n "CREATE AVC k HC #1:0..23 DLCI x y";
Clubbing different individual virtual channels on a FR link will create an aggregated virtual channel. Here in the syntax, an Aggregated Virtual
Channel with id ‘k’ is created on a FR link by clubbing two Virtual channels on that link with DLCI’s x and y.
Traffic Generation and Verification
FR Simulation
Syntax: inform task n "Tx[Rx]: HC #1:0..23 DLCI x CONT [FRAMES n |EOF] FIXLEN 1500 SEQNUM MSB4 [MSB|LSB 8|2|1]";
MFR Simulation:
Syntax: inform task n "Rx:[Tx:] DLCI x CONT FIXLEN 1500 SEQNUM MSB4";
Aggregated Virtual Channel
Syntax: inform task n "Rx [t]: HC #1:0..23 AVC x CONT [FRAMES n|EOF] FIXLEN 1500 SEQNUM MSB4 [MSB|LSB 8|2|1]";
In MFR Simulation the traffic is generated and received on the entire MFR bundle. But in FR simulation, traffic can be generated and received on
each individual FR link. Transmission parameters are used to generate traffic and receiving parameters are used as reference to verify the received frames.
Applying Impairments on Frame transmission
Syntax: inform task n "ERROR REP n [CONT] SKIP m #1:0..23 DLCI x OFFS x DEL x";
Impairment commands are used to intentionally introduce errors in frame transmission. Various impairments can be introduced before
frames are transmitted or during traffic generation. Impairment types are supported which can impair a frame at Bit, Byte and Frame level.
One can specify a limited number of impairments or continuous impairment.
Impairments can be applied at different levels, i.e.
- Impair all packets sent over a Physical Link
- Impair frames on a particular Virtual Channel [VC may be on a physical link or on the MFR bundle].
- Impair frames on a particular Aggregated Virtual Channel
- Impair all packets on the MFR bundle
Following impairment types are supported:
- DELETE – Delete few bytes in a frame or the delete the full frame itself
- INSERT- Insert few bytes in a frame or insert the full frame itself
- DUPLICATE – Duplicate a frame given number of times
- AND, OR, XOR – Logically And/Or/Xor an octet in the frame
- CRC – Introduce CRC error.
- FRAME ERROR – Introduce frame error.
- DELAY – Delay transmission on a physical link by x msec.
Click here to
download the Multi-link Frame Relay Client-Server E1/T1 scripts.
Buyer's Guide:
Please Note: The XX in the Item No. refers to the hardware platform, listed at the bottom of the Buyer's Guide,
which the software will be running on. Therefore, XX can either be HDT, HDE, HUT, HUE, UTA or UEA depending upon
the hardware.
Back to Client/Server Scripted Control Software Page
