< draft-ietf-ieprep-ets-telephony-06.txt		draft-ietf-ieprep-ets-telephony-07.txt >
	Internet Engineering Task Force Ken Carlberg		Internet Engineering Task Force Ken Carlberg
	INTERNET DRAFT UCL		INTERNET DRAFT UCL
	Sept 8, 2003 Ran Atkinson		November 28, 2003 Ran Atkinson
	Extreme Networks		Extreme Networks
	IP Telephony Requirements for		IP Telephony Requirements for
	Emergency Telecommunication Service		Emergency Telecommunication Service
	<draft-ietf-ieprep-ets-telephony-06.txt>		<draft-ietf-ieprep-ets-telephony-07.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [1].		all provisions of Section 10 of RFC2026 [1].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft		http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
	Shadow Directories can be accessed at		Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	For potential updates to the above required-text see:		For potential updates to the above required-text see:
	http://www.ietf.org/ietf/1id-guidelines.txt		http://www.ietf.org/ietf/1id-guidelines.txt
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	infrastructure (traditional PSTN over some portion(s) of the path,		infrastructure (traditional PSTN over some portion(s) of the path,
	Internet telephony over some other portion(s) of the path) can		Internet telephony over some other portion(s) of the path) can
	carry the labels end-to-end with appropriate translation at		carry the labels end-to-end with appropriate translation at
	PSTN/Internet boundaries. Absence of a mapping means that the		PSTN/Internet boundaries. Absence of a mapping means that the
	signaling reverts to a default service (presumably one attributed		signaling reverts to a default service (presumably one attributed
	to the general public).		to the general public).
	4) Application layer IP telephony capabilities MUST NOT preclude		4) Application layer IP telephony capabilities MUST NOT preclude
	the ability to do application layer accounting.		the ability to do application layer accounting.
			Accounting is a useful feature in support of billing and tracking
			down abuse of service. If specific solutions or protocols in
			support of ETS require accounting, then this will be articulated
			in future document(s).
	5) Application layer mechanisms in gateways and stateful proxies		5) Application layer mechanisms in gateways and stateful proxies
	that are specifically in place to recognize ETS type labels MUST		that are specifically in place to recognize ETS type labels MUST
	be able to support "best available" service (this will probably be		be able to support "best available" service (this will probably be
	realized as better than best effort). These labels MAY exist in		realized as better than best effort). These labels MAY exist in
			^L
	the application layer headers of data (i.e., bearer) traffic or		the application layer headers of data (i.e., bearer) traffic or
	signaling traffic used for call completion.		signaling traffic used for call completion.
	The support for best available service SHOULD focus on		The support for best available service SHOULD focus on
	probability of forwarding packets. Probability MAY reach 100%		probability of forwarding packets. Probability MAY reach 100%
	^L
	depending on the local policy associated with the label. Local		depending on the local policy associated with the label. Local
	policy MUST also be used to determine if better than best effort		policy MUST also be used to determine if better than best effort
	is to be applied to a specific label (or related set of labels).		is to be applied to a specific label (or related set of labels).
	Additional comments on this topic are presented below in item 2		Additional comments on this topic are presented below in item 2
	of section 4.		of section 4.
	The above paragraphs MUST be taken in their entirety. The ability		The above paragraphs MUST be taken in their entirety. The ability
	to support best available service does not mean that the		to support best available service does not mean that the
	application layer mechanism is expected to be activated. Further,		application layer mechanism is expected to be activated. Further,
	we do not define the means by which best available service is		we do not define the means by which best available service is
	realized. Application layer mechanisms that do not recognize		realized. Application layer mechanisms that do not recognize
	ETS ytype labels are not subject to this requirement.		ETS type labels are not subject to this requirement.
	4. Issues		4. Issues
	This section presents issues that arise in considering solutions for		This section presents issues that arise in considering solutions for
	the telephony requirements that have been defined for ETS. This		the telephony requirements that have been defined for ETS. This
	section does not specify solutions nor is it to be confused with		section does not specify solutions nor is it to be confused with
	requirements. Subsequent documents that articulate a more specific		requirements. Subsequent documents that articulate a more specific
	set of requirements for a particular service may make a statement		set of requirements for a particular service may make a statement
	about the following issues.		about the following issues.
	skipping to change at page 4, line 48 ¶		skipping to change at page 5, line 4 ¶
	causes IP packets to travel the best current path. The Internet		causes IP packets to travel the best current path. The Internet
	network infrastructure does not have the concept of a "call" or		network infrastructure does not have the concept of a "call" or
	the concept of "call setup", though IP telephony applications		the concept of "call setup", though IP telephony applications
	might have application layer awareness of calls or the call		might have application layer awareness of calls or the call
	setup concept.		setup concept.
	2) Application of Best Available Service		2) Application of Best Available Service
	In item 5 of section 3 above, we discuss the requirement of		In item 5 of section 3 above, we discuss the requirement of
	supporting best available service. We note that in this		supporting best available service. We note that in this
			^L
	document, the scope of that support is constrained to the		document, the scope of that support is constrained to the
	application layer and flows that traverse that layer. This		application layer and flows that traverse that layer. This
	may involve direct support for the flow containing the ETS		may involve direct support for the flow containing the ETS
	type label, or may involve indirect support (e.g., ETS labels		type label, or may involve indirect support (e.g., ETS labels
	in signaling messages that causes an effect on corresponding		in signaling messages that causes an effect on corresponding
	^L
	data or bearer flows).		data or bearer flows).
	It is critical to understand that how the support for best		It is critical to understand that how the support for best
	available service can be realized is outside the scope of this		available service can be realized is outside the scope of this
	document. In addition, the perceived effectiveness of a given		document. In addition, the perceived effectiveness of a given
	approach or implementation also outside the scope of this		approach or implementation also outside the scope of this
	document.		document.
	5. Security		5. Security
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 34 ¶
	strong end-to-end integrity during their transmission through the		strong end-to-end integrity during their transmission through the
	telephony systems. Finally, in cases where labels are expected to be		telephony systems. Finally, in cases where labels are expected to be
	acted upon by operators, these operators SHOULD have the capability		acted upon by operators, these operators SHOULD have the capability
	of authenticating the label on a received message or transmission in		of authenticating the label on a received message or transmission in
	order to prevent theft of service and reduce risk of denial of		order to prevent theft of service and reduce risk of denial of
	service (e.g. by unauthorized users consuming any limited resources).		service (e.g. by unauthorized users consuming any limited resources).
	Security is also discussed in the general requirements of [2], which		Security is also discussed in the general requirements of [2], which
	applies to section 3 above.		applies to section 3 above.
	6. References		Normative References
			There are no Normative References because this is an Informational
			document.
			Informative References
	1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP		1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
	9, RFC 2026, October 1996.		9, RFC 2026, October 1996.
	2 Carlberg, K., Atkinson, R., "General System Requirements for		2 Carlberg, K., Atkinson, R., "General System Requirements for
	Emergency Telecommunications Service", Internet Draft,		Emergency Telecommunications Service", Internet Draft,
	Work In Progress, September, 2002		Work In Progress, September, 2002
	3 Schulzrinne, H., "Requirements for Resource Priority Mechanisms		3 Schulzrinne, H., "Requirements for Resource Priority Mechanisms
	for the Session Initiation Protocol (SIP)", RFC 3487, February,		for the Session Initiation Protocol (SIP)", RFC 3487, February,
	2003.		2003.
			^L
	4 ANSI, "Signaling System No. 7(SS7): High Probability of		4 ANSI, "Signaling System No. 7(SS7): High Probability of
	Completion (HPC) Network Capability", ANSI T1.631, 1993.		Completion (HPC) Network Capability", ANSI T1.631, 1993.
	5 Bradner, S., "Key words for use in RFCs to Indicate Requirement		5 Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	^L		Author's Addresses
	7. Author's Addresses
	Ken Carlberg Ran Atkinson		Ken Carlberg Ran Atkinson
	University College London Extreme Networks		University College London Extreme Networks
	Department of Computer Science 3585 Monroe Street		Department of Computer Science 3585 Monroe Street
	Gower Street Santa Clara, CA		Gower Street Santa Clara, CA
	London, WC1E 6BT 95051 USA		London, WC1E 6BT 95051 USA
	United Kingdom		United Kingdom
	k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com		k.carlberg@cs.ucl.ac.uk rja@extremenetworks.com
	Full Copyright Statement		Full Copyright Statement
End of changes. 12 change blocks.
	12 lines changed or deleted		22 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/