MC-MLPPP Emulation
using Client-Server
Overview
The Multi-Class Extension to Multi-Link PPP allows a sender to fragment the packets of various priorities into multiple classes of fragments, and allows
high-priority packets to be sent between fragments of lower priorities.
MLPPP bundles multiple link-layer channels into a single network-layer channel. Data sent through this channel will be distributed among all the links.
It is a technique used to derive larger bandwidth pipe by aggregating smaller bandwidth pipes e.g. from multiple T1s or E1s.
GL's flexible and versatile MC-MLPPP Emulator is GUI based WCS client, which simulates MC-MLPPP and PPP protocols over T1/E1 links. The unit is capable
of generating and receiving MC-MLPPP/PPP traffic (with or without impairments). Traffic source can be sequence number, HDL files (containing packets/frames),
flat binary file, user-defined frames (ASCII HEX file), and Ethernet data.
|
|
|
MLPPP emulator can be configured as a router or as a bridge to establish connection and route traffic between LANs.
Main Features:
- Performs MC-MLPPP as well as PPP simulation.
- Supports LCP with the following negotiation options.
- PPP options: MRU (Maximum Receive Unit), ACFC (Address and Control Field Compression), PFC (Protocol Field Compression), and
Magic Number.
- MLPPP Options: MRRU (Maximum Received Reconstructed Unit), Short Sequence Number Format, Long sequence header format,
Endpoint Discrimination, PPP in MLPPP, and Multi-class option.
- Multi-Class Options: Multilink Header Format.
- Supports the following NCPs -
- IPCP - RFC 1332 (The PPP Internet Protocol Control Protocol) and RFC 1877 (PPP Internet Protocol Control Protocol Extensions for Name
Server Addresses) standards.
- BCP - RFC 3518 (Point-to-Point (PPP) Bridging Control Protocol) standard.
- PPPMuxCP - RFC 3153.
- Payload traffic generation and verification using Sequence number, HDL file (containing packets/frames), Flat Binary file, Ethernet traffic, and User defined
frames (ASCII HEX file) for each class independently.
- Transmit and receive Ethernet traffic over T1E1 links by operating either in bridge or router mode.
- Provides PPP Multiplexing feature to send / receive multiplexed PPP and MLPPP frames confirming to RFC 3153.
- Supports up to 16 T1/E1 ports.
- Differential link delay insertion between PPP links during transmission.
- User configurable timers and counters like Restart-timer, Max-Configure, Max-Terminate, and Max-Failure.
- User configurable bandwidth using flags.
- Supports hyper channels with discontinuous (sparse) timeslots.
- Supports full or fractional timeslots for PPP Link.
- Supports Fragmentation and Reassembly at MLPPP level.
- Supports Van Jacobson Compression (RFC 1144) and IP Header Compression (RFC 2507 and RFC 3544).
- Supports RTP Compression enabling IP/UDP/RTP compression conforming to RFC 2508.
- Dynamically add/remove (open/close) PPP links without loss in data.
- Supports various impairments at PPP layer - CRC error, frame error, frame duplication, and more.
- Supports various Fragment/Packet impairments for each Class at MLPPP level.
- Provides detailed PPP and MLPPP statistics.
- Provides detailed test (Tx/Rx) results per class / per link in GUI as well as through log file in command line.
- Ideal solution for automated testing using command line scripts.
- Support for HDLC framing with CRC16, CRC32 or without CRC.
References
- RFC 1661 Point-to-Point Protocol (PPP).
- RFC 1662 PPP links in HDLC framing.
- RFC 1990 Multi-link PPP bundles.
- RFC 2686 Multi-class extensions to PPP.
- RFC 1332 PPP Internet Protocol Control Protocol.
- RFC 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses.
- RFC 3518 PPP Bridging Control Protocol.
- RFC 1144 VanJacobson Compression.
- RFC 3544 IPHC Compression.
- RFC 2507 only IP Compression.
- RFC 2508 Compressed RTP.
- RFC 3153 PPP Network Control Protocol for PPP Multiplexing (PPPMuxCP).
Screen Shot of GUI Based MC-MLPPP Emulator
Screen Shot of Command Line Based MC-MLPPP Emulator
Adding PPP Links
Various PPP links (of any bandwidth varying from 64Kbps to n*64Kpbs or sub channels) can be added to form the MLPPP bundle.
Each of the added links in the bundle can be configured with selected PPP, MLPPP, and Multi-class configuration options. PPP options can be selected for each
link individually; however, MC and MLPPP options are selected for the complete bundle.
As the transmission and reception is in progress, any of the PPP links in the bundle can be removed (terminated) or added back to the bundle without loss in
data. All the actions performed in GUI can also be executed through command line interface.
Screen Shot of adding PPP links
Click here to download a sample script that illustrates
addition and removal of PPP links
Common Configuration
The PPP configuration parameters include Max-Configure, Restart-timer, Max-Terminate and Max-Failure. The HDLC
configuration allows configuring the CRC parameters for HDLC frames. The PPP Multiplexing feature allows sending multiple
PPP encapsulated packets in a single PPP Multiplexed frame.
Screen Shot of Common Configuration
Link Control Protocol Negotiation
MC-MLPPP supports Link Control Protocol (LCP) to configure PPP links with the various negotiation options. Link
configuration is an optional feature. LCP Negotiation at MLPPP Level includes ‘PPP in MLPPP’ option to configure PPP header in MLPPP payload.
If LCP is enabled for a link, then open action on that link performs Link Configuration (option negotiation) by
exchanging LCP Configuration packets with peer end. If LCP configuration is disabled then an open action on that link will
go to UP state assuming that the peer end is also up.
Screen Shot of LCP Negotiation at PPP Level
Screen Shot of LCP Negotiation at MLPPP Level
Network Control Protocol Configuration
The application supports NCP configuration (option negotiation). Once LCP enters open state, NCP configuration allows negotiation of IPCP, BCP, and PPP Mux
Control Protocol (PPPMuxCP). In MLPPP Simulation, NCP negotiation starts as soon as any PPP link in the bundle goes to LCP UP state.
Note: In MLPPP Simulation, NCP can be configured to send Packets over PPP links in the bundle or on the MLPPP bundle.
Screen Shot of IPCP and BCP Negotiation
Link Test using Echo Request/Reply
Link Testing is used for testing link connectivity. When the link status is UP, it will test by sending LCP keep alive messages (Echo Req/Reply). The Link Test
provides test parameters along with the statistics of number of requests sent and number of replies received. Link Test can be performed over PPP links in the
bundle or on the MLPPP bundle.
Screen Shot of PPP Link Test
Traffic Generation and Verification
In MLPPP Simulation the traffic is generated and received on the entire MLPPP bundle for various classes. But in PPP simulation, PPP traffic can be generated
and received on each PPP link individually. Tx parameters are used to generate traffic and Rx parameters are used as reference to verify the received frames.
GUI provides options to add classes to MLPPP bundle or PPP links for Tx/Rx traffic. All the actions performed in GUI can also be executed through command
line interface.
Click
here to download a sample script that illustrates the transmission and reception of traffic in mlppp and ppp simulation using Sequence numbers.
Click
here to download a sample script that illustrates the transmission and reception of traffic in mlppp and ppp simulation using HDL Trace Files.
The MC-MLPPP permits transmission and reception of following source/sink types:
- Sequence numbers (1, 2, 4 or 8 least significant byte first (LSB) or most significant byte first (MSB)) with configurable start sequence numbers and
increments.
- User defined HEX string frame, which is ASCII based. Can be edited, loaded and saved.
- Binary flat files that allows user to provide any random data.
- GL *.HDL trace file is GL's packet file format which can be constructed pre-hand or captured using MLPPP Analyzer.
- Network traffic (LAN traffic) - This allows user to receive traffic from Ethernet, convert to PPP traffic and send through T1/E1 line and vice versa. MLPPP
emulator can be configured in router mode or in bridge mode to establish connection and route traffic between LANs. Priority is set based on source IP address,
destination IP address, length, or type of service of the packets received from the Ethernet.
Other parameters that can be customized include –
- Prefix Header - allows the user to prefix a header at the beginning of the MLPPP packet to be transmitted
- Duration Spec - defines the duration for which Tx/Rx will be done
- Payload length - defines the PPP packet size. Each link can have its own payload size.
- Multiplex PPP - select Multiplex PPP option to send Multiplexed PPP frame.
Traffic mode provides an option to maintain timing between frames. If the emulator is configured as router (using NETWORK TRAFFIC source and sink type) it
might be required to maintain the timing while forwarding packets from Ethernet to T1/E1 and vice versa, i.e., the time difference between the consecutive
packets captured from NIC card is maintained while transmitting on T1/E1 and vice versa.
MLPPP Emulator as a Router

Subnet1 and Subnet2 have been connected through T1/E1 lines using MLPPP
Emulator that is configured to work as router.
The Emulator allows user to setup routing table by configuring IP-Address and Mask. Once configured, the Emulator forwards the IP packets which match
routing criteria over MLPPP links. Emulator respond to all ARP requests whose IP addresses present in routing table.
The Emulator allows user to configure which MLPPP class can be used based on the parameters set in Priority Dialog table - Packet Length, Source IP
Address, Destination IP Address, and IP Type of Service (TOS).
MLPPP Emulator as MLPPP Bridge
When the emulator is configured to act as bridge between two networks, all ARP and traffic (checked against the priority table) received from the network is
encapsulated as BPDU (Bridging Protocol Data Unit) and streamed over T1/E1 links. The Emulator on another network removes BPDU header, converts to Ethernet
and streams to the destination.
Limitations (Click to expand)
- Input line rate (Ethernet) has to be always less than output line rate (i.e. T1/E1), otherwise it may result in packet loss. The input line rate
has to be constant and should match the output line rate to avoid loss of packets. If the frame transmission is in burst mode it will result in loss
- The delay introduced due to packet routing will need a bit longer RTT for applications like Ping. Tx delay is approximately 3 to 4 sec. Rx Delay
is around 40 to 50 msec.
- Only one NIC card is supported - Irrespective of how many NIC cards are installed in the PC only one NIC can be configured for routing using
the IPMACAddressMap.ini file.
Future enhancements to support finding out MAC and IP address automatically, and support for multiple NIC cards.
- To route traffic over different MLPP bundles, that many instances of MLPPP Emulator need to be invoked. (Note: Each MLPPP Emulator
instance represents one MLPPP bundle)
Future enhancements to support creating multiple bundles in a single instance.
- Up to 14 instances of MLPPP Emulator can be opened successfully; with the current implementation, the total number of T1/E1 ports supported
in the emulator is 18.
Screen Shot of Data Transmission and Reception over MLPPP
Screen Shot of Data Transmission and Reception over PPP
Screen Shot of Data Transmission and Reception over
Network Traffic over MLPPP
Impairments
Various impairments can be introduced before frames are transmitted or during traffic generation. In PPP simulation frames are impaired by applying
impairment to a particular PPP link. One can specify a limited number of impairments or continuous impairment.
Impairments that affect an entire frame:
- CRC Error
- Insert and delete frame
- Frame Error
- Frame duplication
Impairments that affect a frame by impairing frame data:
- Inserting bytes
- Deleting bytes
- Bitwise ANDing octets
- Bitwise Oring octets
- Bitwise XORing octets
Differential delay can also be introduced between PPP links
Screen Shot of Impairments at PPP layer
In MLPPP Simulation, frames can be impaired by applying impairment at fragment level, packet level and also by impairing ppp link. Flexible support for
impairments during test allows various protocol and payload errors insertion. One can specify a limited number of impairments or continuous impairment.
Screen Shot of Impairments at MLPPP layer
Click here to download a sample script that illustrates impairment of a
PPP and MLPPP link during transmission of traffic.
Data Verification using Statistics
MLPPP Statistics
MLPPP statistics provides important information about the MLPPP bundle such as Number of transmitted/received octets, frames, fragments, lost fragments,
and PPP/ML/MC packet fragments received with invalid sequence numbers.
Screen Shot of MLPPP Statistics
Tx/Rx Verification
Traffic verification results provide the overall statistics for all classes (MLPPP Simulation) or links (PPP Simulation). The statistics include number of Transmitted,
Received, Matched, Modified, Inserted and Deleted frames.
Screen Shot of Tx/Rx Verification in PPP Simulation
Screen Shot of Tx/Rx Verification in MLPPP Simulation
PPP and HDLC Statistics
PPP Statistics provides important statistics information for the selected PPP link, such as the Number of transmitted/received octets, frames, PPP packets
with bad addresses, PPP packets with bad control bytes, and PPP packets exceeding the MRU. The errors that occur during file transmission like the Tx
Under/Over Runs, Rx Under/Over Runs, Number of PPP packets with bad FCS and Number of Frame Errors are recorded in the HDLC Statistics.
Screen Shot of PPP Statistics
Screen Shot of HDLC Statistics
Detail Log File
This option is available in command line only. The optional log file produced by the WCS task shows the hex data dump to understand the source of errors along
with the timestamp. This can be useful to diagnose problems.
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 List of T1E1 Basic and Optional Applications Index Page