Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)
Extracted elements (20)
The LNS is explicitly prohibited from buffering data packets for an on-hold client because the appropriate buffer size is undefined, buffering would impact TCP and other higher-layer protocols, and it would introduce delay upon client return.
The LNS must not stop processing data packets from the LAC even when modem is on-hold, because there is a race condition between the on-hold notification and the first data packet upon return (delivered on independent channels), and dropping packets would slow recovery.
The MDMST control message M-bit is set to 0 so that L2TP peers that do not understand it will silently ignore it (per RFC 2661), avoiding interoperability failures with non-implementing peers.
Early implementations used vendor-specific assignments (Vendor ID 529): Modem-Status as Attr Type 0 value 2, Modem On-Hold Capable as Attr Type 2, and Modem On-Hold Status as Attr Type 3. These are superseded by the IANA-assigned values in this document.
A LAC MUST NOT send a Modem Status (MDMST) control message to an LNS that has not indicated the capability of processing such control messages via the Modem On-Hold Capable AVP in SCCRQ or SCCRP.
An LNS MUST ignore MDMST control messages received after sending a CDN, and MUST ignore redundant modem status reports.
MDMST control messages MUST be sent with the M-bit in the Message Type AVP set to 0 to prevent interoperability issues.
Reserved bits 1 through 11 of the Modem On-Hold Status AVP MUST be set to 0 when sending and MUST be ignored on reception.
The LNS MUST NOT stop processing otherwise valid data packets arriving from the LAC, regardless of the current state of the modem on-hold indications.
The MDMST control message can only be sent after session establishment (after ICCN or OCCN) and before the session ends from the LAC's point of view (before CDN is sent or received).
The MDMST control message MUST NOT be sent to peers that have not included the Modem On-Hold Capable AVP in their SCCRQ or SCCRP control messages.
The Modem On-Hold Capable AVP MUST be included on SCCRQ or SCCRP control messages to indicate that the sender implements this specification; the M-bit for this AVP MUST be set to 0.
When the client modem requests the LAC to go on-hold, the LAC SHOULD send a MDMST control message to the LNS with the H (Hold) field set to 1 and the negotiated maximum on-hold time.
When the client modem returns back online after having gone on-hold, the LAC SHOULD send a MDMST control message with H=0. The LAC MUST send this message if it previously sent a MDMST with H=1.
The Modem On-Hold Capable AVP (Attribute Type 53) is sent by an LNS in SCCRQ or SCCRP to indicate it can receive MDMST control messages. It has no Attribute Value field, M-bit MUST be 0, and Length is 6.
The Modem-Status (MDMST) control message is a new L2TP control message (Attribute Type 17, Vendor ID 0) used by the LAC to notify the LNS when the client modem on-hold status changes. It requires the Message Type and Modem On-Hold Status AVPs.
The Timeout field in the Modem On-Hold Status AVP is a 4-bit quantity encoding negotiated maximum on-hold duration per V.92, ranging from 10 seconds (0001) to no limit (1101); values 0000, 1110, and 1111 are reserved. It is valid only when H=1.
This document registers L2TP Message Type 17 (Modem Status/MDMST), AVP Attribute Type 53 (Modem On-Hold Capable), and AVP Attribute Type 54 (Modem On-Hold Status) with IANA. Reserved bits 1-11 of the Modem On-Hold Status AVP are assigned via IETF Consensus.
Integrity and confidentiality of the modem on-hold signaling relies entirely on the underlying L2TP security mechanisms. The extension is believed not to provide information useful to an attacker. New AVPs MAY be hidden using L2TP's AVP hiding mechanism (RFC 2661 section 4.3).
The Modem On-Hold Status AVP (Attribute Type 54) is a 16-bit field with: H (Hold) bit at position 0, reserved bits 1-11 (MUST be 0), and a 4-bit Timeout field at positions 12-15. Length is 8.