Network Working Group I. Goyret
Internet Draft Lucent Technologies
Category: Standards Track July 2002
draft-ietf-l2tpext-v92-moh-01.txt
V.92 Modem-On-Hold signalling on L2TP
Status of this Memo
This document is an Internet-Draft and is subject to 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-01.txt" and expires December 31, 2002. Please
send comments to the L2TP mailing list (l2tp@l2tp.net).
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism
for tunneling PPP [STD51] sessions.
One of the features introduced by V.92 [V92] is the ability of the
client modem to put the call on hold. The L2TP base protocol does
not provide any means to signal this event. This document describes
a method to indicate when a client modem has gone on-hold.
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 1]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 2002
Contents
Status of this Memo .......................................... 1
Abstract ..................................................... 1
1. Introduction .............................................. 3
1.1 Specification of Requirements ......................... 3
2. Protocol Operation ........................................ 3
2.1 Capability negotiation ................................ 4
2.2 Modem On-Hold ......................................... 4
2.3 Modem Online .......................................... 4
3. New Control Messages ...................................... 4
3.1 Modem-Status (MDMST) .................................. 4
4. New Attribute Value Pairs ................................. 5
4.1 Modem On-Hold Capable AVP ............................. 5
4.2 Modem On-Hold Status AVP .............................. 5
5. Sample LNS actions ........................................ 7
6. IANA Considerations ....................................... 8
7. Security Considerations ................................... 8
8. References ................................................ 9
9. Acknowledgments ........................................... 9
10. Author's Address ......................................... 9
11. Full Copyright Statement ................................. 9
12. Expiration Date .......................................... 10
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 2]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 2002
1. Introduction
L2TP defines a general purpose mechanism for tunneling PPP over
various media. By design, the operation of L2TP is insulated from
the details of the media from which the PPP session originated,
including when a V.92 client modem requests to go on-hold. It may be
desirable for this information to be provided to the LNS.
There are no standard AVPs that can communicate this information.
This document provides additional AVPs and control messages that may
be used to provide modem information. 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].
2. Protocol Operation
L2TP can be used in many different topologies. This document looks at
this particular topology:
+-----+ { } +-----+ [ packet ] +-----+ [ home ]
| |-[M]---{ PSTN }---| LAC |...[ network ]...| LNS |...[ network ]
+-----+ { } +-----+ [ ] +-----+ [ ]
Remote
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 request the server
modem (part of the LAC) to go on-hold for some period of time.
If the server modem agrees, the client modem can signal the PSTN to
go on-hold (usually, a flash hook). The user at the remote system may
then use the same POTS line where the client modem is connected to
make or receive another call.
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
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 3]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 2002
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.
2.1 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.2 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.3 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.
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 in their SCCRQ or SCCRP the Modem On-Hold Capable AVP.
Furthermore, the 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). 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
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 4]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 2002
a CDN.
There is currently no number assigned to this control message by the
IANA. A number will be requested if this draft is approved by the
L2TP WG. Currently, this control message is encoded as follows:
Vendor ID = 529
Attribute Type = 0 (Message Type AVP)
Attribute Value = 2 (MDMST)
The above encoding corresponds to a vendor-specific control message.
Vendor ID 529 indicates Lucent Technologies, the initial developer of
this specification.
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.
4.1 Modem On-Hold Capable AVP
The Modem On-Hold Capable AVP indicates that the sender is capable of
sending or receiving MDMST control messages. This AVP MUST be
included on the SCCRQ or SCCRP control messages to indicate that the
sender implements this specification.
It is encoded as Vendor ID 529 with an Attribute Type of 2. The
Vendor ID 529 indicates Lucent Technologies, the initial developer of
this specification. It SHOULD be changed to 0 and an official
Attribute Type chosen if this specification advances on a standards
track.
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
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 5]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 2002
The Modem On-Hold Status AVP indicates the current on-hold status of
the client modem. This AVP MUST be present on the MDMST control
message.
It is encoded as Vendor ID 529 with an Attribute Type of 3. The
Vendor ID 529 indicates Lucent Technologies, the initial developer of
this specification. It SHOULD be changed to 0 and an official
Attribute Type chosen if this specification advances on a standards
track.
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 gone on-hold and
the maximum amount of time that the modem is allowed to remain on-
hold.
The H field is a single bit that indicates whether the client modem
has gone 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 client modem 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-01.txt [Page 6]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 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-01.txt [Page 7]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 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
The Modem On-Hold Status AVP includes an enumerated value, called
"Timeout", whose value is defined by ITU in [V92].
This 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
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].
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 8]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 2002
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.
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
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 9]
INTERNET DRAFT V.92 Modem-On-Hold signalling on L2TP July 2002
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-01.txt" and expires
December 31, 2002.
Goyret, I. draft-ietf-l2tpext-v92-moh-01.txt [Page 10]