Summary

  • RFC 1490 made fragmentation an optional way for attached Frame Relay devices to carry a packet larger than a network's supported frame size; it kept splitting and reassembly at the Frame Relay boundary rather than exposing fragments to IP.
  • The design depended on a strict per-virtual-circuit sequence. A lost or damaged fragment meant discarding the whole message and leaving retransmission to the upper-layer protocol.
  • In 1998, RFC 2427 said the broader RFC 1490 encapsulation had been widely implemented, but its fragmentation algorithm had no interoperable implementations. It removed the algorithm and pointed to FRF.12.

The verdict is unusually precise. In 1998, RFC 2427 said the multiprotocol encapsulation it was replacing had been widely implemented and used. In the same appendix, it said there were no interoperable implementations of the fragmentation algorithm in RFC 1490. Fragmentation was removed from the successor and replaced by the Frame Relay Forum's FRF.12 procedure. The record does not say that nobody ever wrote code for the earlier algorithm. It says devices did not interoperate with it. That distinction is the history.

The 1993 problem was practical. RFC 1490, published in July, described how an attached device could carry routed and bridged traffic over a Frame Relay backbone. The provider's network might support a maximum frame as small as 262 octets. A packet, after its protocol encapsulation, could be larger. The RFC therefore recommended fragmentation and reassembly, but did not make them mandatory. Its central encapsulation could be useful even if a particular pair of devices did not support this optional mechanism.

The boundary mattered. RFC 1490's fragmentation procedure was limited to the Frame Relay network's edge devices, the DTEs. A sender first encapsulated the packet; it then divided that encapsulated unit into frames sized for the Frame Relay network. The receiving DTE reassembled the packet and sent it through the same processing path it would have used had the packet arrived whole. IP did not receive a sequence of smaller IP datagrams from this procedure. This was a link-service workaround for a network-specific frame ceiling, not a change to the IP datagram's own size or identity.

That is different from the fragmentation procedure in RFC 791. IP puts identification, offset and fragmentation flags in the datagram header so an IP destination can reconstruct the original datagram. RFC 1490 placed a separate fragmentation envelope around the already-encapsulated packet and expected reconstruction at the Frame Relay boundary, before ordinary protocol processing. The two procedures could both divide data into pieces, but they assigned those pieces to different layers and different receivers.

RFC 1490's fragment format was compact but stateful. Each fragment carried the encapsulation identifier, a two-octet sequence number, an offset and a final-fragment bit. The sequence value advanced for each new message that had to be fragmented and began from a random value at initialization. Offsets counted in units of 32 bytes; the first fragment had offset zero. The receiver needed these fields to tell fragments of one message apart, place each piece and know when the set was complete.

The service contract supplied another part of the algorithm. Fragments had to be sent in order, starting at offset zero, and no other packet or information for the same data-link connection could interrupt them. The RFC required an endpoint to reassemble at least 2 KiB and suggested 8 KiB. If a fragment was missing or corrupted, the endpoint dropped the complete message. The upper-layer protocol, not Frame Relay fragmentation, was responsible for retransmission. RFC 1490 did not add a fragment-level retry mechanism.

It also did not add a reassembly timer. RFC 1490 reasoned that Frame Relay service was required to deliver frames in order, so the receiver did not need a timer to decide when an incomplete sequence had become stale. This is a design assumption stated in the document, not evidence that every provider met it or every device relied on it successfully. A receiver still needed memory for an unfinished message; a missing piece still meant loss of the complete packet; and no timer meant the recovery boundary rested on the service's ordering guarantee and the other endpoint's matching behavior.

Five years later, RFC 2427 separated the implementation record by mechanism. It described the overall RFC 1490 encapsulation as widely implemented and adopted in industry and ITU specifications. But it reported that the fragmentation algorithm had no interoperable implementations, noted suggestions that the mechanisms were inadequate for some Frame Relay applications, and removed them in favor of FRF.12. It did not identify a vendor, list incompatible traces or give a test count. We should not invent one. The evidence is enough to establish a design outcome, not its undocumented cause.

That split prevents two easy but false conclusions. The first is that RFC 1490 failed because one optional feature failed to interoperate; its successor says the wider encapsulation was broadly used. The second is that widespread use of the main encapsulation proves its fragmentation worked; the same successor explicitly says it did not interoperate. Standards have seams. One format can travel across products while another procedure in the same document fails to become a shared implementation contract.

The historical point is not that documents matter less than code, or that one unimplemented option invalidates a standard. It is that the words “supported RFC 1490” would have hidden the actual question. Which part? Under which frame-size limits? Did both attached devices implement the same fragment format and its ordering rules? Would they agree on when a complete message existed? RFC 2427 answered those questions at the system level: the encapsulation had a compatibility set; the fragmentation algorithm did not. Its removal and FRF.12 replacement are a documentary record of that boundary, not proof of universal adoption of the replacement.