Summary

  • RFC 3573 lets an L2TP Access Concentrator report that a V.92 modem has gone on hold, how long the negotiated maximum may be, and when it returns. The message carries observed state; it does not prescribe the L2TP Network Server's policy or prove that upper-layer service survived.
  • The decisive operational risk is ordering: the return-status message and the first valid client packet travel on independent channels. A control-plane description can arrive after the data-plane fact it describes, so evidence must preserve both rather than treating notification order as reality.

The phone rings while a file is downloading. On a V.92 connection, the modem can ask to put the data call on hold, let the subscriber use the same copper line for a voice call, and later resume without dialling again. At the physical edge, the event is obvious. At the remote server handling the PPP session, it is invisible.

That split is the reason RFC 3573 exists. In an L2TP dial-in design, the server modem belongs to the L2TP Access Concentrator, or LAC. The PPP session terminates elsewhere, at the L2TP Network Server, or LNS, across a packet network. The LAC knows that the access medium has temporarily disappeared. The LNS owns timers, packet treatment and accounting. Neither view is the whole service.

Published in July 2003 and still listed by the RFC Editor as a Proposed Standard, RFC 3573 adds a small control-plane vocabulary across that gap. Its restraint matters more than its age. It reports capability, state and a maximum interval, then refuses to pretend that the report determines the receiver's action.

Capability comes before notification

An LNS that can process modem-hold reports advertises a Modem On-Hold Capable Attribute Value Pair when the L2TP control connection is established. A LAC must not send the new Modem-Status, or MDMST, message to an LNS that did not advertise that capability.

That exchange proves only a declared ability to parse the extension. It does not prove that a later report will be generated, delivered in time, believed, acted upon correctly or reflected in accounting. Capability is one receipt in a longer chain.

The status message is also confined to a live session. It can be sent after successful session establishment and before the LAC regards that session as ended. If the LNS has already sent a Call-Disconnect-Notify, a contemporaneous MDMST must be ignored. This prevents a late description of access state from reviving a session whose lifecycle has already closed.

One bit carries state; four bits carry a ceiling

When the client modem asks for hold, the LAC should send MDMST with H=1 and the negotiated maximum hold time. When the modem comes back, the LAC should send H=0. If it previously reported H=1, the clearing report is mandatory.

The status AVP is sixteen bits. One is the Hold bit; four encode the V.92 timeout; the remainder are reserved. The timeout ranges from ten seconds through sixteen minutes and includes a “no limit” value. It is meaningful only while Hold equals one and must be ignored when Hold equals zero.

The field is easily overread. It is not elapsed time. It is not a promise that the physical call will remain recoverable until that point. It is not proof that the LNS installed a matching timer, preserved packets or suspended billing. It is the maximum negotiated at the modem layer as reported by the LAC.

An evidence system therefore needs both the raw encoding and the interpretation used at that moment. It should retain the tunnel and session identifiers, endpoints, sequence and time of the report, decoded ceiling, delivery status, duplicate classification and the session lifecycle around it. A database row saying on_hold=true erases most of the operational truth.

The receiver owns the consequence

RFC 3573 states the boundary repeatedly: it does not mandate what, if anything, the LNS should do with the information. It offers possible actions, not a universal policy.

The LNS might pause LCP Echo Requests, Link Quality Monitoring or Multilink PPP polling. It might drop packets headed toward the absent client. It might start a separate accounting session, suspend accounting or meter the hold interval separately. Some choices exclude others. Each changes a different receipt: liveness, traffic, session identity or money.

The RFC is more decisive about three tempting responses. Buffering packets has no obvious safe budget and may damage TCP when a delayed burst is released. Answering TCP keepalives on behalf of the client fabricates presence and may interfere with recovery. Stopping processing of otherwise valid packets from the LAC is prohibited, because the returning modem's first packet can arrive before the separate control message saying it is back online.

That last race is the article's central mechanism. The control plane is a description of reality, not reality's clock. If an implementation blocks data until Hold zero arrives, it can discard the strongest evidence that the client has already returned. The supposedly conservative policy creates the outage.

A clean control exchange can accompany a failed service

Even a perfect MDMST trace leaves the upper layers unresolved. TCP can time out while the modem is away. An application can abandon a transfer. Packets toward the client can be dropped by local policy. Accounting can remain continuous, pause or split. The user's voice call can end while data never recovers.

Conversely, the first returning packet can be valid even while the last stored status still says hold. A monitor that accepts only the control-plane state will label live traffic anomalous. A monitor that accepts only packets will lose the explanation for the gap. The right model preserves independent observations and reconciles them without allowing either to impersonate the other.

Use separate receipts for modem negotiation, LAC observation, MDMST delivery, LNS policy, directional packet handling, reconnection, PPP state, TCP/application recovery and accounting. Join them with stable tunnel/session identifiers and clocks whose uncertainty is known. Then the record can explain disagreement rather than smoothing it into one synthetic state.

Protection secures the report, not its meaning

RFC 3573 relies on L2TP's underlying security mechanisms for integrity and confidentiality. The new AVPs may be hidden. RFC 3193 later specifies IPsec protection for L2TP traffic. These controls can strengthen evidence that a particular peer sent an untampered control message over a protected channel.

They cannot prove that the modem was physically on hold, that the LAC observed the event without error, that the LNS chose a sensible policy, or that the application completed. Cryptographic protection answers who carried which bytes under which keys. Operational truth still requires the adjoining receipts.

The current IANA registry retains message type 17 for Modem Status and attributes 53 and 54 for capability and status. Those assignments prove coordinated numeric identity, not present deployment. The RFC's appendix records early vendor-specific numbers and explicitly labels them historical and non-normative. Neither registry permanence nor an implementation note is adoption evidence.

Evidence boundary

This Article identifies no ISP, LAC, LNS, modem maker, subscriber, PSTN carrier, session, incident, billing result or implementation share. It reports the RFC's protocol contract and the limits the document itself states.

RFC 2661 supplies the L2TP base model; RFC 1661 the PPP context; RFC 1989 and RFC 1990 the polling mechanisms mentioned in the receiver choices; RFC 2865, RFC 2866 and RFC 2869 the surrounding authentication and accounting context; RFC 3193 the L2TP/IPsec boundary. RFC 3931 is later L2TPv3 context only. The IANA L2TP registry and ITU-T V.92 record establish assigned identifiers and the referenced modem recommendation, not operating results.

Heng Lu's Running-Code Primacy and Minimum Initial Specification essays are disclosed editorial lenses. They support asking whether the running service followed the declaration and keeping the shared contract smaller than local operating policy. They are not evidence of RFC 3573's authors' intent or of deployment.

The bounded conclusion is sharper than “signals can be stale.” A temporary-state message is useful precisely because it is not a command and not an outcome. Preserve the report, preserve the local decision, preserve the later packets and user result—and never let one stand in for the others.

Sources