Fact-checked by Grok 2 weeks ago

Serial Line Internet Protocol

The Serial Line Internet Protocol (SLIP) is a for encapsulating () datagrams over point-to-point links, enabling / networking between devices connected via serial lines such as modems or direct cables. Developed in the early 1980s as part of 3Com's / implementation, SLIP gained widespread adoption around 1984, particularly for integrating Berkeley Unix and workstations into IP networks over low-speed serial connections. SLIP operates by framing IP packets with special delimiter bytes: each packet begins and ends with an END character (hexadecimal 0xC0 or decimal 192), while data bytes matching END or the ESC character (0xDB or 219) undergo byte stuffing to avoid confusion—replaced by two-byte escape sequences (ESC followed by 0xDC for END or 0xDD for ESC). This simple framing supports a maximum packet size of 1006 bytes (including IP and transport headers but excluding SLIP framing overhead) and is optimized for serial lines operating at speeds from 1200 bits per second up to 19.2 kilobits per second. However, SLIP lacks native support for address resolution, protocol type identification, error detection or correction, and data compression, making it suitable only for reliable, low-error environments like direct connections or well-maintained dial-up lines. Historically, SLIP facilitated early for personal computers and workstations via dial-up modems, serving as a foundational technology for remote connectivity before the proliferation of Ethernet and . Although not an official , it was commonly implemented in (BSD) Unix systems, with widely available by the late . Due to its limitations, SLIP has largely been supplanted by the more robust (PPP), which adds features like authentication, multilink support, and error checking, as documented in Internet standards. Today, SLIP remains a historical protocol, occasionally referenced in legacy systems or embedded applications requiring minimal overhead serial tunneling.

Overview

Definition and Purpose

The Serial Line Internet Protocol (SLIP) is a simple, non-proprietary protocol that encapsulates () datagrams for transmission over point-to-point connections, such as those using modems or interfaces. Developed as a , SLIP enables the operation of TCP/IP networking over asynchronous lines, facilitating remote access to networks in the pre-broadband era when dial-up connections were prevalent. Its design emphasizes minimal overhead to support low-speed links, typically ranging from 1200 bits per second to 19.2 kilobits per second. SLIP relies on the fundamentals of , where data is sent one bit at a time without a shared between sender and receiver. In this mode, each byte of data is framed by a start bit to signal the beginning of transmission and one or more stop bits to indicate the end, allowing the receiver to synchronize timing for accurate . This approach is well-suited for point-to-point links like , which provide reliable, direct connections between devices without the need for complex synchronization hardware. In its early applications, SLIP was widely used around 1984 to connect Unix workstations—such as those running (BSD) Unix or produced by —to local area networks or the nascent via dedicated or dial-up serial ports. These connections allowed researchers and early users to extend TCP/IP capabilities beyond local Ethernet setups, bridging serial-based remote sites to broader networks. Over time, SLIP was largely succeeded by the more versatile (PPP), which addressed its limitations in authentication and error handling.

Basic Operation

The Serial Line Internet Protocol (SLIP) facilitates the transmission of datagrams over serial connections by encapsulating each within a simple framing structure. On the sender side, the process begins with the IP packet serving as the payload, which is then delimited by special end-of-packet markers to define the frame boundaries. To ensure these markers are uniquely identifiable, any occurrences of the END delimiter or the character within the packet data are replaced with a two-byte during encapsulation. This framed packet is subsequently transmitted as a continuous byte stream over the serial link, enabling the transport of IP traffic without requiring complex hardware. At the receiving end, SLIP reverses this process to reconstruct the original . The receiver scans the incoming byte stream for the initial , which signals the start of a new and prompts the collection of subsequent bytes until the matching end is encountered. During this extraction, the receiver identifies and interprets the escape sequences to restore any escaped END or data bytes, effectively decapsulating the to yield the intact for delivery to the network layer. This byte-by-byte handling maintains the integrity of the packet boundaries in a stream-oriented medium. SLIP provides no inherent mechanisms for detection, correction, or , depending instead on the error-checking capabilities of upper-layer protocols such as the or retransmissions to handle transmission issues. Synchronization between sender and receiver is achieved through the framing delimiters, which allow the receiver to delineate packets accurately within the ongoing and to recover following potential or bit errors. These delimiters effectively prevent bytes from being misinterpreted as frame controls, ensuring reliable packet demarcation. The protocol operates under the assumption of a dedicated point-to-point serial link, such as an connection, where both endpoints are preconfigured with identical communication parameters, including baud rates typically ranging from 1200 bps to 19.2 kbps. This setup supports asynchronous transmission without additional synchronization signals, making SLIP suitable for low-speed, direct connections in early networking environments.

Technical Specifications

Frame Format

The Serial Line Internet Protocol (SLIP) frame is a simple byte-oriented structure designed for encapsulating datagrams over links, consisting primarily of a start flag, the payload data, and an end flag. The frame begins and ends with a flag byte set to 0xC0 (END), which delimits the packet boundaries. Data bytes within the payload are transmitted as-is, except for special characters that require escaping to prevent misinterpretation as control bytes. To handle byte stuffing, SLIP employs an escape mechanism using the byte 0xDB () as the . If a data byte equals 0xC0 (END), it is replaced by the two-byte sequence 0xDB followed by 0xDC (ESC_END); similarly, if a data byte equals 0xDB (), it is replaced by 0xDB followed by 0xDD (ESC_ESC). This ensures that control bytes do not appear unescaped in the , maintaining without additional headers or checksums. Some implementations include an optional leading 0xC0 before the start to flush any residual on the line, but this is not strictly required. SLIP frames lack any protocol headers, trailers, or address fields beyond the flags, relying on the inherent point-to-point nature of serial connections for address resolution. This results in minimal overhead, typically 2 bytes per frame (the start and end flags), plus 1 additional byte for each END or byte in the data that requires escaping. For illustration, consider encapsulating a simple 4-byte payload sequence [0x45, 0x00, 0xC0, 0x01], where the third byte (0xC0) triggers escaping. The resulting SLIP frame would be: 0xC0 (start) + 0x45 + 0x00 + 0xDB + 0xDC (escaped 0xC0) + 0x01 + 0xC0 (end), totaling 7 bytes with 2 bytes of overhead from the flags and 1 additional byte from the escape.

Encapsulation Process

The encapsulation process in SLIP begins on the sender side, where an is wrapped into a serial stream by prefixing it with an END byte (0xC0 in hexadecimal) to flush any residual noise on the line. Each subsequent data byte from the is transmitted as-is unless it matches the END byte (0xC0) or the byte (0xDB), in which case it is escaped: an END byte is replaced by the sequence followed by ESC_END (0xDB 0xDC), and an byte is replaced by followed by ESC_ESC (0xDB 0xDD). After all data bytes are processed and escaped as needed, the frame is terminated with another END byte. This byte-stuffing mechanism ensures that the serial line interprets only the explicit END bytes as frame delimiters, preventing data bytes from prematurely signaling packet boundaries. On the receiver side, the process involves continuous byte reading from the serial line, with synchronization achieved by discarding bytes until the first END byte is encountered, marking the potential start of a valid frame. Subsequent bytes are collected into a until another END byte is detected, which signals the end of the frame; during collection, any ESC byte prompts the reading of the next byte for unescaping—replacing ESC_END with END (0xC0) and ESC_ESC with ESC (0xDB), while treating other sequences after ESC as literal data (though this may indicate a error). The reconstructed is then validated for length and passed to the layer if it fits within the buffer; otherwise, it is truncated or discarded. Consecutive END bytes, which may occur for noise flushing or idle lines, result in zero-length packets that are simply ignored by the receiver. The encapsulation introduces overhead primarily from the two END bytes per frame and additional bytes for each escaped special character in the data, effectively expanding the transmitted size by one byte per occurrence of 0xC0 or 0xDB in the original . This variable overhead depends on the data content but remains minimal for most traffic, as special bytes are relatively rare in typical IP payloads. Edge cases in encapsulation include empty IP packets, which transmit as back-to-back END bytes and are ignored upon receipt to avoid processing null s. Streams consisting entirely of special bytes, such as repeated 0xC0, are handled by systematic escaping, potentially doubling the size but preserving without loss. SLIP assumes no fragmentation, requiring that the IP (MTU) be set small enough to fit within the serial buffer, typically up to 1006 bytes.

Variants

Compressed SLIP (CSLIP)

Compressed SLIP (CSLIP) is an extension of the Serial Line Internet Protocol (SLIP) that incorporates header to enhance efficiency over low-speed serial links, typically operating at 300 to 19,200 bits per second. Developed by , this technique, often referred to as Van Jacobson , targets the overhead of and headers in datagrams transmitted via SLIP, allowing for reduced bandwidth usage without altering the underlying SLIP framing. The mechanism in CSLIP operates by maintaining a state table of recent packet headers for each active , sending only the differences (deltas) from the previous header rather than the full 40-byte combined and header (20 bytes each) for subsequent packets. On the first packet of a or upon context loss, the full uncompressed header is transmitted to establish the ; thereafter, a compressed packet includes a identifier (8 bits) and a bitmask indicating which fields have changed, such as sequence numbers, acknowledgments, or window sizes, encoded in a compact . This delta-based approach exploits the predictability of TCP traffic patterns, where many fields remain static or change incrementally, resulting in an average compressed header size of about 3 bytes. CSLIP provides substantial bandwidth savings for interactive applications like , where small payloads dominate and header overhead can exceed data size; for instance, it limits the bandwidth demand of typing and acknowledgment traffic to at most 300 bits per second, enabling acceptable performance even at 2,400 bits per second links that would otherwise be impractical without . By reducing header size from 40 bytes to typically 3-5 bytes, CSLIP can decrease overall overhead by factors sufficient to improve interactive response times, such as reducing round-trip delays in low-bandwidth environments. Implementation of CSLIP is optional within SLIP drivers and requires symmetric support on both communicating endpoints to maintain shared state, using a table of up to 16 connection slots that consumes approximately 2 kilobytes of . The is integrated into the SLIP encapsulation , where compressed packets are flagged with a special type (e.g., via an in SLIP framing) to distinguish them from uncompressed ones, ensuring the receiver can decompress correctly. Despite its advantages, CSLIP introduces unique drawbacks, including increased computational overhead for both compression and decompression algorithms, which process each packet's header fields through delta calculations and state lookups. Additionally, it is vulnerable to packet loss, as undetected errors or lost compressed packets can corrupt the compression context, necessitating a full header retransmission via TCP's error recovery mechanisms to reset the state and avoid error propagation.

SLIP over Other Media

While the Serial Line Internet Protocol (SLIP) was originally designed for asynchronous lines, adaptations have extended its use to other media, particularly in scenarios requiring point-to-point encapsulation over non-standard serial interfaces. One notable extension involves synchronous links, allowing transmission over leased lines or early digital circuits that provide , though such implementations remained non-standard and were often limited to specific configurations in the 1990s. In applications, SLIP found use over radio modems through integration with Terminal Node Controllers (TNCs) operating in (Keep It Simple, Stupid) mode. This setup treats the TNC as a serial bridge, encapsulating packets via SLIP for transmission over links, enabling /IP connectivity in low-bandwidth, half-duplex environments like VHF/UHF bands. For instance, 1990s implementations allowed hosts to run SLIP drivers alongside TNC software to route through networks, supporting applications such as relays or basic web access in remote areas. SLIP was also adapted for use over X.25 packet-switched data networks (PSDNs) via tunneling mechanisms, particularly with X.25 Packet Assembler/Disassemblers (). Protocol translation rules in routers enabled SLIP encapsulation to traverse X.25 virtual circuits, allowing datagrams to be transported without modifying the underlying PSDN infrastructure. A proposed for on PSDNs explicitly leveraged SLIP's simplicity to coexist with remote PAD processes, encapsulating over lines connected to X.25 interfaces while adhering to CCITT standards like X.3, X.28, and X.29. This approach facilitated early connectivity in environments where X.25 was prevalent, such as WANs. Deploying SLIP over these alternative media introduced challenges related to differences. On synchronous links, asynchronous SLIP required adjustments for , often involving hardware-level synchronization or hybrid framing to avoid desynchronization. In serial contexts like radio modems, higher bit rates posed significant issues, as standard SLIP lacks built-in error detection or correction mechanisms, relying solely on higher-layer protocols like checksums. Non-standard enhancements were occasionally implemented in systems to mitigate packet corruption from fading or interference, though these deviated from RFC 1055 specifications. Today, remnants of SLIP persist in embedded systems and applications as a bridging over UART or other interfaces. For example, modern operating systems like support SLIP for networking microcontrollers to hosts via connections, enabling communication in resource-constrained devices without the overhead of more complex . These uses are rare and typically confined to legacy bridges or custom gateways, where SLIP's minimalism suits low-power environments, but it has been largely superseded by or Ethernet-based alternatives in contemporary deployments.

History and Development

Origins and Early Use

The (SLIP) emerged in the early as a simple method to encapsulate (IP) datagrams over serial lines, originating from the /IP implementation. Around 1984, Rick Adams—later the founder of —developed SLIP while involved in networking, to enable /IP communication over serial connections, bridging UUCP-based systems with the growing ecosystem. This innovation addressed the need for affordable, low-cost connectivity during the transition from to the broader , where high-speed Ethernet was not yet ubiquitous and dial-up modems offered a practical alternative for remote access. Initial implementations of SLIP appeared as bootstrap code in 4.2BSD Unix distributions, with Adams releasing it publicly for Berkeley Unix and workstations. By the mid-1980s, it was integrated into the 4.3BSD release from the , and made available via anonymous FTP from servers, facilitating adoption on various Unix-derived systems like . Adams founded in 1987 to support networking, and its servers hosted SLIP software for public download. Universities and early research networks quickly incorporated SLIP for point-to-point serial links operating at speeds from 1200 bps to 19.2 Kbps, supporting configurations such as host-to-host, host-to-router, and router-to-router connections in TCP/IP environments. SLIP saw early practical use in the mid-1980s for dial-up access from computers via modems. Early Internet service providers (ISPs), including those building on infrastructure, leveraged SLIP to provide remote connectivity to academic and research users, marking a key step in democratizing beyond dedicated leased lines. This grassroots adoption established SLIP as a for serial transmission by the late 1980s, predating formal protocol evolutions.

Standardization and Evolution

The Serial Line Internet Protocol (SLIP) was formally documented in RFC 1055, published in June 1988 by J. L. Romkey, which served as its official specification despite being labeled a "nonstandard." This document outlined the protocol's core mechanics, including byte-oriented framing with the END character (0xC0) to delimit packets and the character (0xDB) for escaping special sequences to avoid conflicts over serial lines, as well as recommendations such as a (MTU) of 1006 bytes to accommodate typical serial link constraints. Although widely implemented as a for encapsulating IP datagrams over asynchronous serial connections, SLIP never advanced to the IETF standards track due to its simplicity and lack of advanced features. Following RFC 1055, SLIP saw limited extensions through informational RFCs rather than formal standards updates, reflecting its role as a basic without ongoing IETF stewardship. A notable enhancement was RFC 1144, published in February 1990 by V. Jacobson, which introduced TCP/IP header techniques specifically tailored for low-speed serial links like those using SLIP, reducing average header overhead from 40 bytes to 3-5 bytes to improve throughput on bandwidth-limited connections. This , often termed Compressed SLIP (CSLIP), was proposed as an elective and implemented in various systems, but no further standards-track evolution occurred, as SLIP's design prioritized minimalism over extensibility. SLIP's evolution involved widespread integration into operating system kernels during the , enabling broader adoption for early over modems. For instance, the incorporated SLIP support through initial drivers developed by Laurence Culhane around as part of the NET-2 networking , allowing users without Ethernet to connect via lines and facilitating experimentation with TCP/IP. Similar integrations appeared in BSD variants and other systems, solidifying SLIP's utility in academic and hobbyist environments until the late . However, by the late and early , SLIP was gradually phased out in favor of more robust protocols and technologies.

Limitations and Comparisons

Key Limitations

One of the primary limitations of the Serial Line Internet Protocol (SLIP) is its complete absence of built-in error detection or correction mechanisms at the protocol level. SLIP relies entirely on higher-layer protocols such as checksums or / error checking to identify damaged packets, leaving it vulnerable to undetected corruption from serial line noise, which is common in asynchronous connections like modems or direct cables. This design choice, while simplifying implementation, can lead to inefficient retransmissions on noisy links, as erroneous frames may propagate undetected until higher layers discard them. SLIP also provides no security features, including or , making transmitted data susceptible to , especially over shared or unsecured lines where physical access to the serial connection allows interception without any protocol-level protections. In an era of dial-up connectivity, this lack of safeguards exposed users to risks like unauthorized access or data tampering, as the protocol assumes a trusted point-to-point link without verifying . The protocol's framing mechanism introduces significant inefficiency through its byte-stuffing approach, where special characters like the END byte (0xC0) and ESC byte (0xDB) in the data stream must be escaped, potentially doubling the size of affected bytes and adding at least one byte of overhead per frame. Without support for multilink bundling, dynamic parameter negotiation, or header compression—though later variants like Compressed SLIP addressed some header overhead—SLIP requires fixed, manual configuration of all parameters, limiting its adaptability to varying network conditions. Compatibility challenges further hinder SLIP's reliability, as it assumes identical implementations on both ends with no mechanism for address negotiation or discovery, necessitating pre-configured addresses and restricting it to single- (IP-only) use without a type field to support . This lack of a link control equivalent means mismatches in framing or can cause silent failures, complicating across diverse hardware. Finally, SLIP proves outdated for larger-scale or modern deployments, performing poorly on high-speed links or multi-protocol environments due to its asynchronous, byte-oriented design, which caps practical throughput at around 115 kbps on typical hardware despite theoretical support for higher rates. Its simplicity, while enabling early adoption, fails to scale with increasing demands for and diversity, contributing to its in favor of more robust alternatives.

Comparison to PPP

The (PPP) was developed as a successor to SLIP, addressing its key deficiencies by providing a more robust and flexible framework for point-to-point links. Unlike SLIP, which supports only IP datagrams without built-in configuration or management capabilities, PPP enables multi-protocol transport and includes the Link Control Protocol (LCP) for automatic negotiation of encapsulation formats, packet size limits, and link quality testing. This LCP facilitates link establishment, configuration, and termination, allowing dynamic adaptation to varying network conditions that SLIP cannot handle. PPP further enhances security and reliability through integrated authentication mechanisms, such as the (PAP) and (CHAP), which require peers to verify identities before full link activation—features absent in SLIP's primitive design. For error detection, PPP incorporates a Frame Check Sequence (FCS) in its HDLC-like framing, ensuring across noisy serial lines, whereas SLIP relies solely on higher-layer checksums like those in , leading to undetected corruption. Additionally, PPP supports multilink operation via the (MP) defined in RFC , which aggregates multiple physical links into a single logical channel for increased , a capability SLIP lacks entirely. In terms of overhead, PPP adds a fixed 8 octets per frame in its default configuration, compressible to as few as 2 octets through field , making it more efficient on bandwidth-constrained links compared to SLIP's variable byte-stuffing , which inserts sequences (adding 1 byte per ) and can inflate packet sizes unpredictably. PPP's native support for header , including / , further reduces on slow serial connections, outperforming SLIP's lack of such optimizations. The transition from SLIP to PPP was formalized in RFC 1661 (1994), which explicitly positions PPP as an extensible replacement for SLIP, with rarely implemented due to PPP's superior feature set. While SLIP persists in simple legacy serial connections requiring minimal setup, PPP remains widely used in modern scenarios like dial-up modems, VPNs, and mobile data links, where its authentication, error handling, and multilink capabilities provide essential reliability.

References

  1. [1]
    RFC 1055 - Nonstandard for transmission of IP datagrams over ...
    SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard.
  2. [2]
    RFC 1983 - Internet Users' Glossary - IETF Datatracker
    SLIP is defined in RFC 1055, but is not an Internet Standard. It is being replaced by PPP. See also: Point-to-Point Protocol. server A provider of resources ...
  3. [3]
    Understanding the RS-232 Standard - DigiKey
    Oct 25, 2023 · RS-232 defines that asynchronous serial communication is used to exchange data between devices, meaning that information is transmitted one bit ...
  4. [4]
    Linux Network Administrator's Guide, 2nd Edition: Chapter 7 - O'Reilly
    The SLIP driver itself understands a number of variations on the SLIP protocol. Apart from ordinary SLIP, it also understands CSLIP, which performs the so- ...Missing: Unix if_slip
  5. [5]
    RFC 1144: Compressing TCP/IP Headers for Low-Speed Serial Links
    It describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links.
  6. [6]
    Header Compression CPPP/CSLIP - freesoft.org
    Van Jacobson compression can reduce packet header overhead from 4000% to 300%, enough to yield acceptable interactive performance at 2400 bps.
  7. [7]
    HDLC Protocol Overview - freesoft.org
    Many varients of HDLC have been developed. Both PPP and SLIP use a subnet of HDLC's functionality. ISDN's D channel uses a slightly modified version of HDLC.Missing: adaptation | Show results with:adaptation
  8. [8]
    6 Links - An Introduction to Computer Networks
    Note that bit stuffing is used by HDLC to solve two unrelated problems: the synchronization problem where long runs of the same bit cause the receiver to lose ...
  9. [9]
    [PDF] INTRODUCTION TO PACKET RADIO
    Packet Radio was one of the major developments to hit the world of Amateur Radio and ... Serial Link Interface Protocol (SLIP) to be run. Before turning KISS on, ...
  10. [10]
    2. The Packet Radio Protocols and Linux
    The Packet Radio Protocols and Linux. The AX.25 protocol offers both connected and connectionless modes of operation, and is used either by itself for ...
  11. [11]
    https://www.keil.com/pack/doc/mw6/network/html/group__slip__routines.html
  12. [12]
    Chapter 2. Link Layer
    On a synchronous link this is done by the hardware using a technique called bit stuffing [Tanenbaum 1989]. On asynchronous links the special byte 0x7d is used ...
  13. [13]
    Experiments with a Simple File Transfer Protocol for Radio Links ...
    ETFTP is designed to allow a user to control transmission parameters to optimize file transfer rates through half-duplex radio links.
  14. [14]
    Exploring SLIP Networking Over UART with Zephyr and Linux
    Jul 25, 2025 · In this article we will explore network connectivity over UART connection using SLIP framing on Zephyr RTOS.
  15. [15]
    Serial Line Internet Protocol (SLIP) - Keil
    The Serial Line Internet Protocol (SLIP) is an encapsulation of the Internet Protocol designed to work over serial ports and modem connections.
  16. [16]
    RFC 1144 - Compressing TCP/IP Headers for Low-Speed Serial Links
    One design goal of the compression should be to limit the bandwidth demand of typing and ack traffic to at most 300 bps.
  17. [17]
    We Talk to Everybody - Linux Journal
    Jan 6, 2000 · Laurence wrote the original alpha SLIP code for the Linux kernel ... At night, he worked on the kernel, adding support for core files.
  18. [18]
    https://www.ibm.com/docs/en/aix/7.1.0?topic=communications-serial-line-internet-protocol
  19. [19]
    Nonstandard for transmission of IP datagrams over serial lines: SLIP
    SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard.Missing: ARPANET RS- 232<|control11|><|separator|>
  20. [20]
    Serial Line Internet Protocol (SLIP) - The TCP/IP Guide!
    If that's just noise, then this “noise datagram” is just gibberish that will be rejected at the IP layer. Meanwhile, it doesn't corrupt the real datagram we ...
  21. [21]
    Serial Line Internet Protocol (SLIP) - The TCP/IP Guide!
    The authors of the paper that describes it, RFC 1055, made sure nobody would miss this point, by naming it A Nonstandard For Transmission Of IP Datagrams Over ...
  22. [22]
    SLIP vs PPP: Comparing Dial-Up Internet Protocols
    Explore the differences between SLIP and PPP, two protocols used for dial-up internet. Learn about SLIP's limitations and how PPP addresses them, ...
  23. [23]
    Serial Line Internet Protocol - IBM
    Serial Line Internet Protocol (SLIP) is the protocol which TCP/IP uses when operating through a serial connection. It is commonly used on dedicated serial ...
  24. [24]
    RFC 1661: The Point-to-Point Protocol (PPP)
    Summary of each segment:
  25. [25]
    https://datatracker.ietf.org/doc/html/rfc1661#section-1
  26. [26]
    https://datatracker.ietf.org/doc/html/rfc1661#section-3.5
  27. [27]
    https://datatracker.ietf.org/doc/html/rfc1661#section-6.5
  28. [28]
    RFC 1990 - The PPP Multilink Protocol (MP) - IETF Datatracker
    RFC 1990 proposes a method for splitting, recombining, and sequencing datagrams across multiple logical data links, creating a virtual link with greater ...
  29. [29]
    https://datatracker.ietf.org/doc/html/rfc1661#section-6.6