Summary

  • RFC 1618 could use a called-party identifier to select PPP on an ISDN access facility, but the identifier came from the local switch and did not grant permission to operate the service.
  • If LCP had not received its administrative Open, the call had to be rejected. Accepting the circuit and then closing it or ignoring its packets was explicitly forbidden.
  • Admission was only the first receipt. Encoding, framing, lower-layer readiness, LCP negotiation, authentication, NCP state and application outcome remained separate facts.

A numbered doorway on one physical facility

In May 1994, RFC 1618 described PPP over ISDN switched circuits. Its applicability statement began with a warning against architectural fantasy: there was unlikely ever to be one monolithic worldwide ISDN. The document therefore chose a few common defaults from a varied installed landscape. Interoperability required a shared starting point, not a claim that every switch, subscription and terminal behaved alike.

The physical arrangement already contained several layers. A B-channel was a point-to-point bearer suited to PPP. A Primary Rate Interface could expose many concurrent B-channels. The D-channel could sometimes carry framed PPP packets, but its bandwidth was limited and communication was often confined to a local switch. Devices at the R, S, T and U reference points could also be combined, hiding where one responsibility ended and another began.

One access facility could serve more than one purpose. RFC 1618 described multiple directory numbers terminating on the same physical facility, with each number bound administratively to a particular service. The called-party identifier supplied by the local switch could therefore answer a narrow question: which advertised doorway did the caller choose?

That was useful evidence. It was not a command.

The signal that did not survive the network

ISDN also offered a more descriptive-looking possibility, the LLC Information Element. One might expect such an out-of-band field to announce the framing or encoding before the data link began. RFC 1618 refused that shortcut. Experience had shown that the element was not carried reliably end to end: compatible switches were too sparsely deployed, and providers applied different subscription policies.

At publication, no LLC-IE value for PPP had been assigned. Other values were not valid for a PPP link and could be ignored for PPP service. More generally, the document said the element should not be trusted to determine framing or encoding.

This is a precise limit on shared intelligence. An intermediate signaling system can transport a label only where every relevant switch and subscription preserves its meaning. A field that disappears, changes scope or arrives under a different provider policy cannot settle an endpoint's local operating mode. The specification did not try to repair that institutional diversity with a larger universal label. It moved the dependable decision closer to the receiving facility.

The called-party identifier was described as reliably provided by the local switch. The word local matters. The field could select the configured service attached to that number. It did not authenticate the caller, prove a remote network's intent, establish an end-to-end signaling chain or show that PPP was ready.

Open was an administrative event

RFC 1618 attached a strict consequence to service selection. When the receiver used a called-party identifier—or if a future PPP-specific LLC value arrived—and LCP had not had the administrative Open event, the call must be rejected. The receiver must not accept the incoming call merely to close the circuit or ignore its packets.

The contemporary PPP specification, RFC 1548, and its July 1994 successor, RFC 1661, explain the state name. Open is an external decision that the link is administratively available for traffic: a network administrator, human or program, has allowed the link to be opened. It is not the same as Up, where the lower layer reports availability. It is not the same as Opened, the later automaton state reached after configuration exchange.

The distinction is easy to lose in a dashboard. A switch has delivered a bearer. A number maps to PPP. The lower layer may be physically available. Yet the local operator has disabled the service, a schedule has closed it, a policy has withheld admission or a program has not issued Open. None of the first three facts may impersonate the fourth.

Rejecting before acceptance preserved that refusal at the correct boundary. It avoided consuming a switched circuit for a service that had already decided not to run. It also prevented late silence from masquerading as a framing error, an unresponsive peer or packet loss. The caller received a circuit-level refusal rather than an apparently accepted path whose endpoint quietly discarded the attempt.

Acceptance began discovery; it did not finish it

Even an administratively open service did not know every property of the incoming link. From PPP's perspective, the ISDN channel was a full-duplex synchronous link, while encoding and scrambling belonged to the DTE/DCE equipment and sat outside PPP itself. RFC 1618 recommended NRZ as the default at the T reference point and NRZI as an alternative when configured. Inverted NRZ, used historically by some implementations, was deprecated.

For equipment that wanted to interoperate with several simple encodings, the only reliable detection method described was active rotation. Send an LCP Configure-Request twice in one mode, wait long enough for a response, then try the next. The combined attempts had to terminate within 59 seconds, and the usual 30-second ceiling was preferred.

That procedure did not “recognize” a hidden truth in one packet. It performed bounded experiments. Each negative interval had a cost because a switched circuit might be billable, scarce or occupying one channel among many. Unlimited curiosity would become resource consumption.

Framing had its own defaults. Without prior configuration, a B-channel had to begin with bit-synchronous HDLC. Octet-synchronous HDLC was recommended only where octet boundaries were available and configured. Nominally distinguishable schemes—HDLC, LAPB, LAPD and LAPF—were not permission to run several framings concurrently and expect PPP to infer them all.

The document deprecated V.120 for this use because its framing could be difficult to distinguish from Frame Relay, and recommended carrying PPP in Frame Relay instead. That preference was a bounded interoperability choice, not evidence that either method had been deployed on a particular call.

The companion RFC 1549 shows why a bit-level choice had consequences beyond naming. NRZI weakened some error-detection properties of the 16-bit FCS, leading to a recommendation for a negotiated 32-bit FCS. A successful carrier indication therefore could not certify that the endpoints shared the same framing or error-detection posture.

Failure needed an end

RFC 1618 applied the same restraint to packet size and retries. It recommended a network-layer MTU no greater than 1500 unless the peer specifically negotiated an MRU of at least 2048. It also recommended exponential restart backoff from 250 milliseconds to three seconds. Persistent dial or redial features should have limits. After failure to complete link establishment, an implementation could discard the transmit queue; doing so could temporarily remove the traffic stimulus that kept redialing.

This was not a promise that one timer policy suited every network. It was recognition that an automatically generated attempt can become its own cause. A queued packet triggers a call; failed establishment leaves the packet queued; the packet triggers another call. Without an explicit ceiling and cleanup owner, the system converts an unserved application request into repeated use of the switched network.

The document also preferred PPP Multilink over BONDING because BONDING introduced its own initialization and could demand extensive per-channel configuration. RFC 1990 later specified Multilink PPP for ISDN bandwidth on demand and other cases. Even there, several physical links became one bundle only after an LCP capability exchange. Parallel bearers did not merge themselves.

The receipts after admission

Once a call was accepted with administrative Open, the evidence chain continued. The chosen encoding and framing had to work. The lower layer had to become Up. LCP peers had to exchange configuration and reach Opened. If authentication had been selected, it had to succeed. Each network-layer protocol needed its own NCP to reach Opened. Only then could the relevant datagrams pass, and packet carriage still did not establish an application result.

Those later stages are not RFC 1618's admission rule, and they should not be collapsed back into it. A rejected call may reflect deliberate policy, not a broken line. An accepted call may still fail at framing or negotiation. LCP Opened may coexist with a closed IP control protocol. A received packet may never produce useful work.

The RFC Editor record establishes publication, authorship and present Proposed Standard status. It does not provide a deployment census, a named product trace or current ISDN practice. RFC 1618 itself says security issues are not discussed. Its called-party identifier is therefore not evidence of caller identity or authorization.

Heng Lu's Running-Code Primacy supplies the analytical discipline: the field, the configured number and the standards label are inputs; the receiver's actual decision and later link behavior are different reality layers. Minimum Initial Specification explains why the common layer can stay narrow while admission remains local.

The switch named a service. The endpoint still had to decide whether that service was allowed to exist on this call. RFC 1618 made the refusal early, visible and attributable—and refused to let an incoming circuit speak for the administrator.

Sources