Summary

  • RFC 1963's default Header-Last format let a sender observe compressed size before marking whether one transported serial frame had to continue in another SDTP packet.
  • Its actual segmentation fields were B and F; E selected a header extension, and SDTP carried no sequence number. B/E/sequence belonged to the separate PPP Multilink design in RFC 1990.
  • Length could separate several SDTP packets inside one compound PPP frame and Port could multiplex negotiated channels, but neither field proved that every fragment arrived, that a port label authenticated a physical endpoint, or that an application recovered.

In an ordinary packet drawing, the header comes first because it tells the receiver how to read what follows. RFC 1963 deliberately broke that habit. Its default PPP Serial Data Transport Protocol packet placed transported serial data before a terminal-adaptation header, reversed the order of the header octets, and required a receiver to read from both ends.

The reason was not aesthetic. RFC 1963 was published as an Informational memo in August 1996 after work on compressing synchronous data in DSU/CSUs. When a serial frame was compressed and might have to be divided among several SDTP packets, a transmitter did not necessarily know the useful packet boundary before the compressor had produced enough output. If the adaptation header came first, the sender would have to declare the boundary before learning the compressed size.

Put the header last, and the sender could observe that size, decide whether this packet began, continued or finished the transported frame, then feed the header through the compressor.

The format turned time into layout. Data was available first; the decision describing its boundary was committed later. Header-First remained negotiable for cases where frames were not divided across SDTP packets, where compression was not coupled to SDTP, or where an implementation's hardware preferred the conventional order. Negotiation therefore selected a representation suited to a transmitter path. It did not report a compression ratio, prove compressor state, or show that the receiver had rebuilt anything.

SDTP also had a strict admission point. PPP first had to reach the Network-Layer Protocol phase, and the Serial Data Control Protocol had to reach Opened. Only then could protocol 0x0049, registered by IANA for PPP-SDTP, carry data. The associated control protocol used 0x8049. Reaching Opened established the agreed packet grammar. It did not make a later packet complete, authentic or useful.

By default, one PPP Information field held exactly one SDTP packet. The optional Length field changed that economy. If SDTP's Length-Field-Present option and RFC 1570's LCP Compound-Frames option were both successfully negotiated, several SDTP packets could share one PPP Information field. Each Length value covered its own Length field, an optional Port, the adaptation header, transported data and any odd-bit padding. A one-octet field described combined lengths from 2 through 255; two octets extended the range to 65535; zero meant the remainder of the PPP Information field.

This was enough to cut a compound container into parseable units. It was not enough to infer what each unit meant outside its negotiated context. Two adjacent units might carry different portions, frames or ports. A correct Length proved where the parser should stop, not that an original serial frame had reached its final boundary or that every earlier portion existed.

Multi-Port added another namespace. Without it, all traffic went to default Port 0 and no Port octet appeared. With successful negotiation, every SDTP packet carried a port number. Data ports ran from 0 through 254, while 255 was reserved for control. Several configuration options were per-port, and flow-control messages on Port 255 could affect all ports.

The label was useful because both peers had agreed how to interpret it. It was not an identity credential. RFC 1963 did not bind a Port number cryptographically to a cable, customer, device or service. A receiver could demultiplex Port 7 according to local state; the octet alone could not prove that the state still described the intended physical port.

The adaptation header supplied the serial-frame boundary. In synchronous HDLC-like mode, B marked the beginning and F marked the final portion. Neither bit set meant a middle portion; both set meant a whole frame in one packet. In asynchronous mode both had to be set. The E bit had a different job: it said whether the optional CS header extension followed. It was not an ending bit.

That distinction matters because a familiar but wrong shorthand imports another protocol's fields. RFC 1990 PPP Multilink used B and E plus a 12- or 24-bit sequence number across a bundle of member links. RFC 1963 did not. SDTP has B/F, an extension E, and no sequence field. It contains no Multilink-style rule for inferring a missing fragment from sequence progress.

The RFC itself exposes one reason to read the prose, not merely copy the diagram. Its B/F table prints 1,0 for both Begin Frame and Final Frame, while the sentence immediately above says setting F marks the final portion. The surrounding definitions support B/F semantics; the repeated table row is not evidence for a second begin code. A robust implementation record would need code, tests or packet traces to show how that ambiguity was handled. This article has none and makes no implementation claim.

An even sharper boundary appears in the inner frame check. For an HDLC-like frame, SDTP transported only the bytes between flags; the flags themselves did not travel. The inner FCS travelled by default. A negotiated FCS-Type could instead remove the FCS at the transmitter and regenerate it at the receiver. RFC 1963 warned that regeneration should not be used unless PPP Reliable Transmission or another layer reliably reported a dropped packet. It also forbade presenting an incomplete or bad frame to the user with a newly generated good FCS.

That warning is the negative space around reconstruction. B and F tell a parser where a frame appears to start and end. Length tells it where an SDTP packet ends. Port tells it which negotiated stream receives the bytes. None supplies loss notification. If a middle packet vanished and no other layer exposed the loss, a receiver could have convincing boundaries around incomplete material. A fresh checksum would then convert an absence into false confidence—the exact outcome the memo prohibited.

RFC 1663 addressed a different problem through separately negotiated Numbered-Mode, windows, acknowledgements and retransmission. RFC 1962 addressed compression algorithm negotiation and Reset exchanges. Neither mechanism should be smuggled into SDTP's fields. Header-Last was designed to cooperate with a compressor's timing, not to negotiate that compressor or repair its state.

Read through Lu Heng's distinction between declared structure and executable evidence, RFC 1963 is unusually candid. It declares a small shared grammar: packet position, boundary bits, optional extent and port labels. Running systems still have to demonstrate ordered arrival, loss handling, buffer policy, local port binding, FCS treatment and delivery to the user. Publication can make those questions precise. It cannot answer them on behalf of the receiver.

Sources