Subject: I-D ACTION:draft-ietf-tsvwg-mlpp-that-works-03.txt

From: [email-masked]
Date: Fri, 10 Feb 2006 18:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: Implementing an Emergency Telecommunications Service for Real Time Services in the Internet Protocol Suite
	Author(s)	: F. Baker, J. Polk
	Filename	: draft-ietf-tsvwg-mlpp-that-works-03.txt
	Pages		: 45
	Date		: 2006-2-10
	
RFCs 3689 and 3690 detail requirements for an Emergency
   Telecommunications Service (ETS), of which an Internet Emergency
Preparedness Service (IEPS) would be a part.  Some of these types of
services require call preemption; others, call for call queuing or
other mechanisms.  The key requirement is to guarantee an elevated
probability of call completion to an authorized user in time of
crisis.

IEPS requires a Call Admission Control (CAC) procedure and a Per Hop
Behavior for the data which meet the needs of this architecture.
Such a CAC procedure and PHB is appropriate to any service that might
use H.323 or SIP to set up real time sessions.  These obviously
include, but are not limited to, Voice and Video applications,
although at this writing the community is mostly thinking about Voice
on IP and many of the examples in the document are taken from that
environment.

In a network where a call that is permitted initially and is not
denied or rejected at a later time, call and capacity admission
procedures performed only at the time of call setup may be
sufficient.  However, in a network where session status can be
reviewed by the network and preempted or denied due to changes in
routing (when the new routes lack capacity to carry calls switched to
them) or changes in offered load (where higher precedence calls
supersede existing calls), maintaining a continuing model of the
status of the various calls is required.

Although this document primarily discusses requirements for the US
Government and NATO, the architecture described here is applicable
outside these two organizations.

IEPS requires a Call Admission Control procedure and a Per Hop
Behavior for the data which meet the needs of this architecture.
Such a CAC procedure and PHB is appropriate to any service that might
use H.323 or SIP to set up real time sessions.  These obviously
include but are not limited to Voice and Video applications, although
at this writing the community is mostly thinking about Voice on IP
and many of the examples in the document are taken from that
environment.

In a network where a call that is permitted initially and is not
denied or rejected at a later time, call and capacity admission
procedures performed only at the time of call setup may be
sufficient.  However in a network where sessions status can be
reviewed by the network and preempted or denied due to changes in
routing (when the new routes lack capacity to carry calls switched to
them) or changes in offered load (where higher precedence calls
supersede existing calls), maintaining a continuing model of the
status of the various calls is required.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-mlpp-that-works-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-mlpp-that-works-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-mlpp-that-works-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce