< draft-ietf-l2tpext-v92-moh-04.txt		draft-ietf-l2tpext-v92-moh-05.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group I. Goyret		RFC 3573
	Internet Draft Lucent Technologies
	Category: Standards Track February 2003
	draft-ietf-l2tpext-v92-moh-04.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-04.txt" and expires July 31, 2003. Please send
	comments to the L2TP mailing list (l2tpext@ietf.org).
	Copyright Notice
	Copyright (C) The Internet Society (2003). 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 defines procedures
	that enable a client 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
	11. Full Copyright Statement ................................. 12
	12. Expiration Date .......................................... 12
	Appendix A: Vendor specific assignments ...................... 13
	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].
	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.
	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.
	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.
	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:
	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 Reserved
	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.
	* 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 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].
	8. References
	8.1. Normative references
	[RFC2661] Townsley W., et al., "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.
	[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.
	[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.
	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.
	10. Author's Address
	Ignacio Goyret		Title: Signalling of Modem-On-Hold status
	Lucent Technologies		in Layer 2 Tunneling Protocol (L2TP)
	1701 Harbor Bay Parkway		Author(s): I. Goyret
	Alameda, CA 94502		Status: Standards Track
			Date: July 2003
			Mailbox: igoyret@lucent.com
			Pages: 13
			Characters: 22758
			Updates/Obsoletes/SeeAlso: None
	Email: igoyret@lucent.com		I-D Tag: draft-ietf-l2tpext-v92-moh-05.txt
	11. Full Copyright Statement		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3573.txt
	Copyright (C) The Internet Society 2003. All Rights Reserved.		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.
	This document and translations of it may be copied and furnished to		One of the standards governing modem operation defines procedures
	others, and derivative works that comment on or otherwise explain it		that enable a client modem to put the call on hold and later, re-
	or assist in its implementation may be prepared, copied, published		establish the modem link with minimal delay and without having to
	and distributed, in whole or in part, without restriction of any		redial. While the modem call is on hold, the client phone line can
	kind, provided that the above copyright notice and this paragraph are		be used to place or receive other calls.
	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		The L2TP base protocol does not provide any means to signal these
	revoked by the Internet Society or its successors or assigns.		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 and the information contained herein is provided on an		This document describes a method to let the LNS know when a client
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		modem connected to a LAC has placed the call on hold.
	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 document is a product of the Layer Two Tunneling Protocol
			Extensions Working Group of the IETF.
	This memo is filed as "draft-ietf-l2tpext-v92-moh-04.txt" and expires		This is now a Proposed Standard Protocol.
	July 31, 2003.
	Appendix A: Vendor specific assignments		This document specifies an Internet standards track protocol for
			the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	THIS SECTION IS NOT NORMATIVE		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Early implementations of this specification used vendor-specific		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	values for the new control message and AVPs. This appendix describes		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	those initial vendor-specific assignments for historical reference		help: ways_to_get_rfcs. For example:
	only.
	The following table shows the vendor-specific assignments:		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	Vendor Attr Attr		help: ways_to_get_rfcs
	ID Type Value Equivalent to
	------ ---- ----- -------------
	Control message:
	Modem-Status 529 0 2 Section 3.1
	AVP:		Requests for special distribution should be addressed to either the
	Modem On-Hold Capable 529 2 none Section 4.1		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	Modem On-Hold Status 529 3 [..] Section 4.2		specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 17 change blocks.
	494 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/