Summary

  • RFC 1973 placed PPP behind the Frame Relay NLPID 0xcf, but reception still depended on the first octet, negotiated Protocol-Field-Compression and the state of the relevant NCP.
  • Repeated LCP replies from different framing addresses could reveal accidental multipoint attachment; an equivalent non-PPP encapsulation after NCP negotiation forced a return to Link Establishment because a peer might have forgotten the session.

A protocol discriminator is a small claim. It says which grammar should parse the bytes that follow. Operational systems often promote that claim into something much larger: a peer was unique, a circuit was correctly provisioned, authentication succeeded, the network layer is ready, or the customer’s traffic arrived. RFC 1973 is useful history because its rules resist that promotion. The document repeatedly separates recognizable framing from negotiated state and negotiated state from service.

Published in June 1996, RFC 1973 describes PPP inside a point-to-point Frame Relay circuit. PPP brought Link Control Protocol negotiation, Network Control Protocols, authentication and compression. Those facilities assumed a relationship between two peers. Frame Relay, however, could connect stations through virtual circuits and could also present multipoint conditions. The specification therefore had to do more than place one packet inside another. It had to defend a two-party state machine against a medium whose framing and topology could say less than operators wished.

The coexistence that could not be made safe

PPP normally borrowed an ISO 3309 HDLC-like frame. Early designers hoped this framing and Frame Relay could coexist on the same link. RFC 1973 records why that hope failed: Q.922 expands its address from one octet to two or four, and the structure of its DLCI subfields cannot always be distinguished from the HDLC-like interpretation. A receiver could not reliably decide which address grammar it was seeing. Coexistence was therefore precluded.

The chosen boundary was explicit. After the 0x7e flag came the Q.922 Address and Control fields, then the Network Layer Protocol Identifier 0xcf, then the PPP Protocol field. The first two fields belonged to Frame Relay transport; 0xcf selected PPP; the PPP Protocol value selected LCP, an NCP or a carried network-layer protocol. Each field narrowed the interpretation without certifying the truth of the next layer.

That division also explains a prohibition. In ordinary HDLC-like PPP, Address-and-Control-Field-Compression could remove constant values. Here the Q.922 Address and Control values were not constant and could be changed by the switching fabric. RFC 1973 therefore said that compression must not be negotiated. The visible address was part of the delivery context, not a redundant decoration.

One octet, read in state

Protocol-Field-Compression was different. It could shorten a two-octet PPP Protocol field to one octet. On this framing, removing the NLPID for compressed traffic and reducing the Protocol field also aligned the Information field on a 32-bit boundary, so the RFC recommended PFC when it improved throughput.

Compression created a classification problem, and Section 4 answered it with an ordered test. The receiver examined the first octet after the Frame Relay header. Zero meant the packet was formatted according to RFC 1490. 0xcf introduced an explicit PPP NLPID. A non-zero value other than 0xcf could be a compressed PPP Protocol only if PFC was enabled and the associated NCP had already been negotiated. Without both conditions, the receiver had to treat the frame as RFC 1490 encapsulation.

The byte therefore had no free-standing meaning. The same observed value crossed different parsing branches depending on negotiated capability and protocol phase. RFC 1973 also reserved PPP Protocol value 0x00cf, avoiding a collision when PFC was active. It allowed that value to indicate that another PPP Protocol packet followed, but did not turn it into evidence of network-layer acceptance.

The modern IANA registries preserve both sides of this choice: 0xCF appears as the PPP NLPID, while 00cf is reserved in the PPP Protocol Field assignments. A number can keep a namespace unambiguous. It cannot make the source authentic.

The address that exposed an extra peer

Initial LCP packets put cf-c0-21 after the Frame Relay header: the PPP NLPID followed by the uncompressed LCP Protocol c021. A recognized LCP Configure-Request moved the PPP link into Link Establishment. That sequence is a decisive parser cue, but it is not a receipt for a completed negotiation.

The RFC then described a rare but revealing diagnostic. If a purported point-to-point feed had accidentally been connected to a multipoint network or multicast group, several nodes might answer one Configure-Request. Multiple replies carrying the same one-octet LCP Identifier but arriving from different framing addresses should produce a misconfiguration indication.

The Identifier linked replies to the request. The differing framing addresses supplied the evidence of plurality. Neither fact alone established a durable identity. A single response did not prove there was only one peer; a DLCI was not a globally stable organization identifier; and the absence of an alarm was weak evidence because some implementations might be physically unable to log or report the framing addresses.

This is the useful audit shape: request identifier, observed address, response multiplicity and local reporting capability remain separate records.

The frame that meant the peer had forgotten

State mattered most after negotiation began. During Link Establishment, packets with other NLPID values could not be sent and had to be silently discarded on receipt until the link reached the Network-Layer Protocol phase. The rule protected an unfinished PPP state machine from traffic using a competing interpretation.

Later, once a particular NCP had been successfully negotiated, an equivalent RFC 1490 data encapsulation was not merely “another way” to carry the same network-layer protocol. Its arrival was evidence that the peer might have lost PPP state. RFC 1973 required the link to re-enter Link Establishment and send a fresh LCP Configure-Request. The purpose was to prevent a black hole in which one side transmitted according to a negotiated PPP context that the other side no longer remembered.

The reset did not prove why the peer changed behavior. It did not recover discarded packets, authenticate the sender or guarantee that the new negotiation would finish. It converted an ambiguous data-plane symptom into an explicit control-plane attempt whose result could be observed.

There was also a policy fork. An implementation that required PPP configuration or negotiated features such as authentication could enter Termination when configuration failed. Otherwise, after the Configure-Request sender reached Max-Configure, it had to fall back to sending only RFC 1490 encapsulations. One system valued the negotiated properties enough to stop; another valued continued carriage enough to downgrade. The wire symptom did not choose between them.

The limits around the circuit

RFC 1973 required a full-duplex link, whether permanent or switched. Frame Relay control signals could provide LCP Up and Down events, yet failure of those signals could not be allowed to break correct PPP operation. It recommended Magic Number and PFC, set the initial MRU to 1600 octets, and advised a network-layer MTU no higher than 1500 unless a peer MRU of at least 2048 had been specifically negotiated.

Compatibility with small switches left another trace. Some equipment could handle only 262-octet frames. PPP implementations therefore had to be configurable to limit LCP packets to 259 octets until negotiation completed, leaving room for the NLPID and Protocol fields. XID negotiation and Inverse ARP were not required for these PPP links because PPP negotiation supplied the needed function. These are scoped interoperation rules, not a general judgment about every Frame Relay network.

RFC 2427 later replaced RFC 1490’s general multiprotocol Frame Relay specification, but it did not obsolete RFC 1973. The historical record should keep those lines distinct. It should also keep deployment claims out: the RFC and IANA assignments establish formats and registry values, not current adoption, vendor defaults, incidents or service outcomes. RFC 1973 itself said that security issues were not discussed.

Sources