T1 E1 Testing

MC-MLPPP Emulation using Client-Server


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), Magic Number, LQR (Link Quality Report), Reporting Period in tens of millisecond, Authentication, and Link Bandwidth Control
    • 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
  • Supports PAP and CHAP authentication protocols
  • 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


  • 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)

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.

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.

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.

  • Magic Number: Provides a method to detect looped-back links and other Data Link Layer anomalies
  • LQR (Link Quality Report): Creates Link Quality Reports on the PPP link for link quality monitoring
  • Link Band Width Control: Controls bandwidth either by Flags Between Frames or Link Utilization
  • Authentication: Provides options to configure Self and Peer Authentication. The two sides of PPP Links authenticate each other using the authentication protocol.

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.

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.

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.

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


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

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.

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.

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.

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.

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.


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 ETA or EEA (Octal/Quad Boards), PTA or PEA (tProbe Units), UTA or UEA (USB Units), HUT or HUE (Universal Cards), and HDT or HDE (HD cards) depending upon the hardware.

 Back to List of T1E1 Basic and Optional Applications Index Page