Network Working Group I. Goyret Internet Draft Lucent Technologies Category: Standards Track November 2002 draft-ietf-l2tpext-v92-moh-02.txt Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026 [BCP9]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html The distribution of this memo is unlimited. It is filed as "draft- ietf-l2tpext-v92-moh-02.txt" and expires April 30, 2003. Please send comments to the L2TP mailing list (l2tpext@ietf.org). Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation is the ITU-T Recommendation V.92, which defines procedures that enable a client Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 1] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to 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 document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. Contents Status of this Memo .......................................... 1 Abstract ..................................................... 1 1. Introduction .............................................. 4 1.1 Specification of Requirements ......................... 4 1.2 Terminology ........................................... 4 2. Protocol Operation ........................................ 5 2.1 Typical modem on hold usage scenario .................. 6 2.2 Capability negotiation ................................ 6 2.3 Modem On-Hold ......................................... 6 2.4 Modem Online .......................................... 6 3. New Control Messages ...................................... 6 3.1 Modem-Status (MDMST) .................................. 7 4. New Attribute Value Pairs ................................. 7 4.1 Modem On-Hold Capable AVP ............................. 8 4.2 Modem On-Hold Status AVP .............................. 8 5. Sample LNS actions ........................................ 9 6. IANA Considerations ....................................... 10 7. Security Considerations ................................... 10 8. References ................................................ 11 9. Acknowledgments ........................................... 11 10. Author's Address ......................................... 12 Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 2] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 11. Full Copyright Statement ................................. 12 12. Expiration Date .......................................... 12 Appendix A: Vendor specific assignments ...................... 13 A.1 Interoperability notes ................................ 13 A.2 Modem-Status (LU_MDMST) ............................... 13 A.3 Modem On-Hold Capable AVP (LU_MOH_CAP) ................ 14 A.3 Modem On-Hold Status AVP (LU_MOH_STAT) ................ 14 Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 3] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 1. Introduction The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a general purpose mechanism for tunneling Point-to-Point Protocol (PPP) [STD51] sessions over various media. By design, the operation of L2TP is insulated from the details of the media from which the PPP session originated. It is common for PPP sessions to be established using modems connected over the public switched telephone network. The ITU-T Recommendation V.92 [V92] is one of the standards governing modem operation and it defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link without having to redial. While the modem call is on hold, the client phone line can be used for another phone call. The L2TP base protocol does not provide any means to 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. It may be desirable for this information (which is available only on the LAC) to be provided to the LNS. This document provides additional L2TP AVPs and control messages that may be used to communicate some modem information from the LAC to the LNS. However, it does not define what, if anything, the LNS should do with this information. A sample of the possible actions that an LNS may consider are 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 RFC 2119 [BCP14]. 1.2 Terminology Definition of terms used in this document may be found in the L2TP Protocol document [L2TP]. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 4] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 2. Protocol Operation The typical dial in topology looks like this: +-----+ { } +----------+ [ IP ] | |-[M]-----{ PSTN }-----[SM] |.....[ network ] +-----+ { } +----------+ [ ] Remote NAS System M 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 (a 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 place the call on-hold (usually, a flash hook). The user at the remote system can then use the same POTS line where the client modem is connected to make or receive another call. In the above scenario, the server modem module can notify the rest of the NAS of these events via its usual signalling mechanism. The NAS layers can then act on this information as desired. See section 5 for a sample list of possible actions. In the case of L2TP, this document looks at this particular topology: +-----+ { } +-----+ [ packet ] +-----+ [ home ] | |-[M]---{ PSTN }---[SM] |...[ network ]...| |...[ network ] +-----+ { } +-----+ [ ] +-----+ [ ] Remote LAC LNS System If the LAC implements the functionality described here, it can signal to the LNS when the client modem has gone on-hold and when it comes back online. This document does not define what, if anything, the LNS should do with this information. A sample of the possible actions that an LNS MAY consider are listed in section 5. However, 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. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 5] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 2.1 Typical modem on hold usage scenario A user connects to his internet service provider with a V.92-capable modem. He then starts downloading a big file which will take several minutes to complete. While the file is being downloaded, a friend calls him. If the user has call waiting enabled, his modem can let him know of the incoming call and he can choose to either pick up the incoming call or reject it. Let's say he chooses to pick up the phone to talk to his friend, for example because he recognized the caller's phone number. Before the user picks up his phone, he tells his modem to go on hold and switch to the incoming call (usually signalled with a "flash- hook"). His modem will then notify the server modem (attached to the LAC) that it is about to go on hold. If the server modem agrees, the client performs a flash hook so the user can talk to his friend. After talking to his friend, the user let's his modem know that 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 can continue. 2.2 Capability negotiation 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. This capability is indicated by adding a "Modem On-Hold Capable" AVP on the SCCRQ or SCCRP sent to the LAC when the tunnel is brought up. 2.3 Modem On-Hold 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) bit set to 1 and the negotiated maximum on-hold time. 2.4 Modem Online When the client modem returns back online after having gone on-hold, the LAC SHOULD send a MDMST control message to the LNS with the H (Hold) bit set to 0. 3. New Control Messages The following control messages MUST be sent with the M-bit in the Message Type AVP set to 0 to prevent interoperability issues. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 6] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 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 used by the LAC to notify the LNS when the client modem on-hold status changes. The MDMST control message MUST NOT be sent to peers that have not included the "Modem On-Hold Capable" AVP in their Start-Control- Connection-Request (SCCRQ) or Start-Control-Connection-Reply (SCCRP) control messages. Furthermore, the MDMST control message can only be sent after session establishment is successful (i.e., after the LAC has sent either an Incoming-Call-Connected (ICCN) or an Outgoing-Call-Connected (OCCN) control message), and before the session ends from the LAC's point of view (i.e., before the LAC has sent or received a Call-Disconnect- Notify (CDN) control message). Note that due to protocol race conditions, it is possible for a LAC to send a MDMST control message about the same time that the LNS is sending a CDN. An LNS MUST ignore MDMST control messages received after sending a CDN. An LNS MUST ignore redundant modem status reports. This control message is encoded as follows: Vendor ID = 0 (IETF) Attribute Type = TBDC1 The following AVPs MUST be present in the MDMST control message: Message Type Modem On-Hold Status The M-bit on the Message Type AVP for this control message MUST be set to 0. 4. New Attribute Value Pairs The following sections contain a list of the new L2TP AVPs defined in this document. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 7] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 4.1 Modem On-Hold Capable AVP The Modem On-Hold Capable AVP, Attribute Type TBDA1, indicates that the sender (an LNS) is capable of receiving MDMST control messages. This AVP MUST be included on the SCCRQ or SCCRP control messages to indicate that 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 The Modem On-Hold Status AVP, Attribute Type TBDA2, indicates the current on-hold status of the client modem. This AVP MUST be present on the MDMST control message. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H| reserved |Timeout| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Modem On-Hold Status AVP is a 16-bit quantity, containing two fields that indicate whether the client modem has placed the call on-hold and the maximum amount of time that the call is allowed to remain on-hold. The H field is a single bit that indicates whether the client modem has placed the call on-hold. If the H bit is 1, the client modem is on-hold. If the H bit is 0, the client modem is back online. The Timeout field is a 4 bits quantity that indicates the negotiated maximum amount of time that the call can remain on-hold. It is only valid if the H bit is 1 and it MUST be ignored if the H bit is 0. The value of this field is defined in [V92] and it is reproduced here for easy reference: Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 8] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 Bits Decimal Meaning ---- ------- ------- 0000 0 Reserved for the ITU 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 for the ITU 1111 15 Reserved for the ITU Bits 1 through 11 are reserved. These bits MUST be set to 0 when sending this AVP and MUST be ignored on reception. 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. 5. Sample LNS actions The specific actions taken by an LNS upon receipt of a Modem On-Hold Status AVP are implementation dependent. This document does not mandate what, if anything, the LNS should do with this information. The choice of actions taken by the LNS may have an impact on higher layer protocols. For example, TCP connections and other connection- oriented applications may timeout or disconnect during the on-hold time. The impact that those choices may have on these or other protocols is not addressed by this document. The following list is a sample of possible actions that an LNS implementation might consider. Note that some of these actions are not really alternatives, as some of the possibilities preclude 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. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 9] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 * Start a separate time accounting for the time that the modem is on hold. Here are a few things that 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 requires one new L2TP "Message Type" number to be assigned by IANA: TBDC1, Section 3.1, Modem Status It also requires two new "AVP Attributes" to be assigned by IANA: TBDA1, Section 4.1, Modem On-Hold Capable AVP TBDA2, Section 4.2, Modem On-Hold Status AVP The Modem On-Hold Status AVP includes an enumerated value, called "Timeout", whose value is defined by ITU in [V92]. The same AVP also contains a set of reserved bits (bits 1 through 11) that are assigned by IANA through IETF Consensus [BCP26]. 7. Security Considerations The integrity and confidentiality of the method described in this document relies on the underlying L2TP security mechanisms. The new Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 10] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 control message and AVPs are intended to indicate when a client modem has gone on-hold and cannot receive data. It does not define what, if anything, the LNS should do with this information. A sample of possible actions that an LNS may consider are 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. If desired, the new AVPs MAY be hidden as described in section 4.3 of [RFC2661]. 8. References [RFC2661] Townsley W., et al., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [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. [STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [V92] ITU-T Recommendation V.92, "Enhancements to Recommendation V.90", November 2000 9. Acknowledgments Josh Bailey of Lucent Technologies provided invaluable help in reviewing this draft. Mark Townsley of Cisco Systems provided helpful guidance. Thomas Narten of IBM Corporation provided invaluable insights and suggestions. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 11] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 10. Author's Address Ignacio Goyret Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 Email: igoyret@lucent.com 11. Full Copyright Statement Copyright (C) The Internet Society 2002. 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 develop- ing 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. 12. Expiration Date This memo is filed as "draft-ietf-l2tpext-v92-moh-02.txt" and expires April 30, 2003. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 12] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 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 describes those initial vendor-specific assignments for historical reference only. A.1 Interoperability notes To guarantee interoperability, the vendor-specific set of control messages and AVPs defined in this appendix MUST be treated as distinct from the standard set defined in the main body of this document. The standard set MUST take precedence. In particular, if a peer includes both the standard and the vendor-specific "Modem On-Hold Capable" AVPs, the standard set MUST be used, and the vendor-specific control message and the vendor-specific "Modem On-Hold Status" AVP MUST NOT be used. If an endpoint implements only the vendor-specific set and the remote peer offers both sets, the vendor-specific set MAY be used. A.2 Modem-Status (LU_MDMST) This is a vendor-specific control message and it is an alternate to the MDMST control message defined in section 3.1. It is used by the LAC to notify the LNS when the client modem on-hold status changes. The LU_MDMST control message MUST NOT be sent to peers that have not included the vendor-specific "Modem On-Hold Capable" AVP (LU_MOH_CAP) or that have included the standard "Modem On-Hold Capable" AVP, as defined in section 4.1, in their SCCRQ or SCCRP control messages. Furthermore, the LU_MDMST control message can only be sent after session establishment is successful (i.e., after the LAC has sent either an ICCN or an OCCN), and before the session ends from the LAC's point of view (i.e., before the LAC has sent or received a CDN control message). Note that due to protocol race conditions, it is possible for a LAC to send a LU_MDMST control message about the same time that the LNS is sending a CDN. An LNS MUST ignore LU_MDMST control messages received after sending a CDN. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 13] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 This vendor-specific control message is encoded as follows: Vendor ID = 529 (Lucent Technologies) Attribute Type = 0 (Message Type AVP) Attribute Value = 2 (vendor-specific Modem-Status) The following AVPs MUST be present in the MDMST control message: Message Type Vendor-specific Modem On-Hold Status (LU_MOH_STAT) The M-bit on the Message Type AVP for this control message MUST be set to 0. A.3 Modem On-Hold Capable AVP (LU_MOH_CAP) The vendor-specific "Modem On-Hold Capable" AVP (LU_MOH_CAP) is an alternate the "Modem On-Hold Capable" AVP defined in section 4.1. It is included in the SCCRQ or SCCRP sent by an LNS to indicate that the sender is capable of receiving the vendor-specific LU_MDMST control messages. This is a vendor-specific AVP and it is encoded as follows: Vendor ID = 529 (Lucent Technologies) Attribute Type = 2 (vendor-specific Modem On-Hold Capable AVP) This AVP has no Attribute Value field. It 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. A.3 Modem On-Hold Status AVP (LU_MOH_STAT) The vendor-specific "Modem On-Hold Status" AVP (LU_MOH_CAP) is an alternate the "Modem On-Hold Status" AVP defined in section 4.2. This AVP MUST be present on the vendor-specific LU_MDMST control message. This is a vendor-specific AVP and it is encoded as follows: Vendor ID = 529 (Lucent Technologies) Attribute Type = 3 (Modem On-Hold Status AVP) The Attribute Value field for this AVP has the same format and contents as described in section 4.2. 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. Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 14] INTERNET DRAFT Signalling of Modem-On-Hold status in L2TP November 2002 Goyret, I. draft-ietf-l2tpext-v92-moh-02.txt [Page 15]