RFC 3573
Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)
Signaling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) 💖
okay bestie, the title block first 🎀
- Network Working Group
- Request for Comments: 3573
- Author: I. Goyret, Lucent Technologies
- Category: Standards Track
- Date: July 2003
- Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates 🦋
Status of this Memo ✨
okay so this doc is an Internet standards track protocol spec for the whole Internet community, and it's literally asking for discussion and suggestions for improvements 💅 if you want the official standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). and distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
Abstract
so L2TP is the thing that tunnels Point-to-Point Protocol (PPP) sessions, and a lot of those PPP sessions get set up over modems hooked into the public switched telephone network 📞
one of the standards that governs modem operation has a whole procedure where a client modem can put the call on hold and bring the modem link back later with minimal delay, no redialing needed 🙌 meanwhile the client's phone line is free to place or receive other calls. the catch? the base L2TP protocol has no way to signal these events from the L2TP Access Controller (LAC), where the modem physically lives, over to the L2TP Network Server (LNS), where the PPP session is handled 😭
so this document describes a method for letting the LNS know when a client modem connected to a LAC has placed the call on hold ✨
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Typical Modem on Hold Usage Scenario . . . . . . . . . . 4
2.2. Capability Negotiation . . . . . . . . . . . . . . . . . 4
2.3. Modem On-Hold. . . . . . . . . . . . . . . . . . . . . . 5
2.4. Modem Online . . . . . . . . . . . . . . . . . . . . . . 5
3. New Control Messages . . . . . . . . . . . . . . . . . . . . . 5
3.1. Modem-Status (MDMST) . . . . . . . . . . . . . . . . . . 5
4. New Attribute Value Pairs. . . . . . . . . . . . . . . . . . . 6
4.1. Modem On-Hold Capable AVP. . . . . . . . . . . . . . . . 6
4.2. Modem On-Hold Status AVP . . . . . . . . . . . . . . . . 6
5. Sample LNS Actions . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A: Vendor Specific Assignments. . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 131. Introduction ✨
okay so L2TP [RFC2661] is a general purpose mechanism for tunneling Point-to-Point Protocol (PPP) [STD51] sessions over all sorts of media. by design, L2TP doesn't care about the details of the media the PPP session came from 🦋
PPP sessions are super commonly set up with modems on the public switched telephone network. the ITU-T Recommendation V.92 [V92] is one of the standards running modem operation, and it has procedures that let a client modem put the call on hold and re-establish the modem link later without redialing 📞 while that call is on hold, the client phone line can be used for another phone call 💅
the L2TP base protocol still can't signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. this info only lives on the LAC, so it might be really useful for the LNS to get it 🥺
this document adds extra L2TP AVPs and control messages that can be used to pass some modem information from the LAC to the LNS. however, it doesn't define what, if anything, the LNS should do with that info. a sample of possible actions an LNS may consider is listed in section 5 🌸
1.1. Specification of Requirements
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [BCP14]. 🎀
1.2. Terminology
the definitions of terms used in this document live in the L2TP Protocol document [L2TP]. 📚
2. Protocol Operation 🦋
okay so the typical dial-in topology looks like this:
+-----+ { } +----------+ [ IP ]
| |-[M]-----{ PSTN }-----[SM] |.....[ network ]
+-----+ { } +----------+ [ ]
Remote NAS
SystemM is the client modem, and it may be an integral part of the Remote System. if this modem implements V.92, it can ask the server modem SM (which is part of the NAS) whether the call can be placed on hold for some period of time 🙏
if the server modem agrees, the client modem can signal the PSTN to put the call on hold (usually with a flash hook). the user at the remote system can then use the same POTS line the client modem is plugged into to make or receive another call 💖
in that scenario, the server modem module can tell the rest of the NAS about these events through its usual signaling mechanism, and the NAS layers can act on that info however they like. check section 5. for a sample list of possible actions 🌈
now, for L2TP this document looks at this particular topology:
+-----+ { } +-----+ [ packet ] +-----+ [ home ]
| |-[M]---{ PSTN }---[SM] |...[ network ]...| |...[ network ]
+-----+ { } +-----+ [ ] +-----+ [ ]
Remote LAC LNS
Systemif the LAC implements the functionality described here, it can signal the LNS when the client modem has gone on hold and when it comes back online ✨
the document doesn't define what, if anything, the LNS should do with this info. a sample of possible actions an LNS MAY consider is listed in section 5. but here's the big rule 👑
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. no matter what the hold status says, valid data packets keep flowing 💅
2.1. Typical Modem on Hold Usage Scenario
so picture this: a user connects to his Internet service provider with a V.92-capable modem. he starts downloading a big file that will take several minutes 📥
while the download is going, a friend calls him 📞 if the user has call waiting enabled, his modem can let him know about the incoming call, and he can pick up or reject it. let's say he picks up, because he recognized the caller's phone number 🙈
before he picks up the phone, he tells his modem to go on hold and switch to the incoming call (usually signaled with a "flash-hook"). his modem then notifies the server modem (attached to the LAC) that it's about to go on hold. if the server modem agrees, the client does a flash hook so the user can talk to his friend 💬
after talking to his friend, the user lets his modem know it can return to the original call, where the server modem has been patiently waiting 🥹 after another flash hook, the modems are connected again and the download picks right back up 🎉
2.2. Capability Negotiation
a LAC MUST NOT send a Modem Status (MDMST) control message to an LNS that hasn't indicated it can process those control messages. that capability gets indicated by adding a "Modem On-Hold Capable" AVP on the SCCRQ or SCCRP sent to the LAC when the tunnel comes up 🔐
2.3. Modem On-Hold
when the client modem asks the LAC to go on hold, the LAC SHOULD send an MDMST control message to the LNS with the H (Hold) field set to 1 and the negotiated maximum on-hold time 🙌
2.4. Modem Online
when the client modem comes back online after going on hold, the LAC SHOULD send an MDMST control message to the LNS with the H (Hold) field set to 0. and the LAC MUST send this message if it previously sent an MDMST message with the H (Hold) field set to 1 ✅
3. New Control Messages 🧚
the following control messages MUST be sent with the M-bit in the Message Type AVP set to 0, to avoid interoperability issues 🛠️
messages with unknown values in the Message Type AVP with the M-bit set to 0 should be ignored by compliant L2TP peers [RFC2661]. 🙈
3.1. Modem-Status (MDMST)
the Modem-Status (MDMST) control message is how the LAC tells the LNS that the client modem's on-hold status has changed 📡
the MDMST control message MUST NOT be sent to peers that didn't include the "Modem On-Hold Capable" AVP in their Start-Control-Connection-Request (SCCRQ) or Start-Control-Connection-Reply (SCCRP) control messages 🚫
also, the MDMST control message can only be sent after session establishment succeeds (that is, after the LAC has sent either an Incoming-Call-Connected (ICCN) or an Outgoing-Call-Connected (OCCN) control message). and it can only be sent before the session ends from the LAC's point of view (that is, before the LAC has sent or received a Call-Disconnect-Notify (CDN) control message) 🕰️
heads up for race conditions: it's possible for a LAC to send an MDMST control message around the same time the LNS is sending a CDN 😬 an LNS MUST ignore MDMST control messages received after it sends a CDN.
an LNS MUST ignore redundant modem status reports 🗑️
this control message is encoded like this:
Vendor ID = 0 (IETF)
Attribute Type = 17the following AVPs MUST be present in the MDMST control message:
Message Type
Modem On-Hold Statusthe M-bit on the Message Type AVP for this control message MUST be set to 0 🎀
4. New Attribute Value Pairs 💜
the following sections list the new L2TP AVPs defined in this document ✨
4.1. Modem On-Hold Capable AVP
the Modem On-Hold Capable AVP, Attribute Type 53, says the sender (an LNS) can receive MDMST control messages. this AVP MUST be included on the SCCRQ or SCCRP control messages to show the sender implements this specification 🫶
this AVP has no Attribute Value field 🙃
this AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1). the M-bit for this AVP MUST be set to 0. the Length is 6. 🦋
4.2. Modem On-Hold Status AVP 💖
okay bestie, this one is the big deal 📞 It tells the LNS whether the client modem is on-hold right now. It's Attribute Type 54, and this AVP MUST be present on the MDMST control message ✨
The Attribute Value field looks like this 🦋
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| reserved |Timeout|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So it's a 16-bit quantity with two fields 🧚 One says whether the client modem has put the call on-hold, and the other says the max amount of time the call is allowed to stay on-hold. Iconic packing, honestly 💅
The H (Hold) field is a single bit. If H is 1, the client modem is on-hold. If H is 0, the client modem is back online 🌈
The Timeout field is a 4-bit quantity that shows the negotiated maximum on-hold time. It only counts when H is 1, and it MUST be ignored if H is 0 🙈 The values come from [V92], and they're copied here so you don't have to go hunting:
Bits Decimal Meaning
---- ------- -------
0000 0 Reserved
0001 1 10 seconds
0010 2 20 seconds
0011 3 30 seconds
0100 4 40 seconds
0101 5 1 minute
0110 6 2 minutes
0111 7 3 minutes
1000 8 4 minutes
1001 9 6 minutes
1010 10 8 minutes
1011 11 12 minutes
1100 12 16 minutes
1101 13 No limit
1110 14 Reserved
1111 15 ReservedBits 1 through 11 are reserved 🔒 These bits MUST be set to 0 when you send this AVP, and MUST be ignored when you receive it. No drama, just zeros 🍓
This AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1) 🫶 The M-bit for this AVP MUST be set to 0. The Length is 8. Periodt ✨
5. Sample LNS Actions 🌸
The specific actions an LNS takes when it gets a Modem On-Hold Status AVP are implementation dependent. This document doesn't decide what, if anything, the LNS should do with the info 🤷♀️
The choices the LNS makes can affect higher layer protocols, though 😭 For example, TCP connections and other connection-oriented applications may time out or disconnect during the on-hold time. How those choices hit these protocols (or others) is not covered in this document, so that's a whole other vibe 💀
Here's a sample of actions an LNS implementation might think about. Heads up, some of these aren't alternatives at all, because some of them rule out others 🙃
- Temporarily stop polling protocols such as LCP Echo Requests, Link Quality Monitoring (LQM), Multilink PPP (MP), etc.
- Drop data packets directed to the now on-hold remote client.
- Start a new accounting session, to account for the on-hold time.
- Stop or hold accounting until the modem returns online again.
- Start a separate time accounting for the time that the modem is on hold.
Now, here are a few things an LNS should probably NOT do 🚫
- Buffer data packets directed to the now on-hold remote client. Reason: How many data packets should be buffered? What would be the impact on higher layer protocols such as TCP? What would be the impact caused by the delay introduced when the client returns online again?
- Answer TCP keepalives in lieu of the client. Reason: It may interfere with TCP's recovery once the client returns online.
- Stop processing otherwise valid data packets from the client. Reason: There is a race condition between the notification of the modem returning online and the first packet from the client because they are delivered on independent channels. Dropping valid client packets may lead to a slower recovery after returning online due to the forced retries.
6. IANA Considerations 📋
This document needs one new L2TP "Message Type" number to be assigned by IANA ✨
17, Section 3.1., Modem StatusIt also needs two new "AVP Attributes" to be assigned by IANA 💜
53, Section 4.1., Modem On-Hold Capable AVP
54, Section 4.2., Modem On-Hold Status AVPThe Modem On-Hold Status AVP has a set of reserved bits (bits 1 through 11), and IANA assigns those through IETF Consensus [BCP26] 🔥
7. Security Considerations 🚨
Okay, this section is serious, so I'm keeping it all 😤
The integrity and confidentiality of the method in this document depend on the underlying L2TP security mechanisms. The new control message and AVPs are meant to show when a client modem has gone on-hold and can't receive data. They don't define what, if anything, the LNS should do with this information. A sample of possible actions an LNS may consider is listed in section 5.
It is believed that the defined extension does not provide information that would be useful to an attacker, and as such, it should not pose a threat to system security. Still, stay alert, bestie 👀
If desired, the new AVPs MAY be hidden as described in section 4.3 of [RFC2661] 🦋
8. References 📚
8.1. Normative References
- [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
- [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [V92] ITU-T Recommendation V.92, "Enhancements to Recommendation V.90", November 2000.
8.2. Informative References
- [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
9. Acknowledgments 🫶
Josh Bailey, Emmanuel Hislen and Marc Bongartz of Lucent Technologies gave invaluable help reviewing this document and its implementation. They're the real MVPs 👑
Mark Townsley of Cisco Systems gave helpful guidance 🌸
Thomas Narten of IBM Corporation gave invaluable insights and suggestions 💖
Appendix A: Vendor Specific Assignments 🧚
THIS SECTION IS NOT NORMATIVE
Early implementations of this specification used vendor-specific values for the new control message and AVPs. This appendix keeps those initial vendor-specific assignments for historical reference only, so it's a throwback, not a to-do list 🕰️
The following table shows the vendor-specific assignments:
Vendor Attr Attr
ID Type Value Equivalent to
------ ---- ----- -------------
Control message:
Modem-Status 529 0 2 Section 3.1.
AVP:
Modem On-Hold Capable 529 2 none Section 4.1.
Modem On-Hold Status 529 3 [..] Section 4.2.Author's Address 🖋️
Ignacio Goyret Lucent Technologies 1801 Harbor Bay Parkway Alameda, CA 94502
EMail: igoyret@lucent.com
Full Copyright Statement ©️
These legal bits stay word-for-word, no cap 🙅♀️
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3573 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms