draft-ietf-tsvwg-admitted-realtime-dscp-05.txt		draft-ietf-tsvwg-admitted-realtime-dscp-06.txt
	Transport Working Group F. Baker		Transport Working Group F. Baker
	Internet-Draft J. Polk		Internet-Draft J. Polk
	Updates: 4542,4594 Cisco Systems		Updates: 4542,4594 Cisco Systems
	(if approved) M. Dolly		(if approved) M. Dolly
	Intended status: Standards Track AT&T Labs		Intended status: Standards Track AT&T Labs
	Expires: May 5, 2009 November 1, 2008		Expires: June 4, 2010 December 4, 2009
	DSCP for Capacity-Admitted Traffic		DSCP for Capacity-Admitted Traffic
	draft-ietf-tsvwg-admitted-realtime-dscp-05		draft-ietf-tsvwg-admitted-realtime-dscp-06
			Abstract
			This document requests one Differentiated Services Code Point (DSCP)
			from the Internet Assigned Numbers Authority (IANA) for real-time
			traffic classes similar to voice conforming to the Expedited
			Forwarding Per Hop Behavior, and admitted using a call admission
			procedure involving authentication, authorization, and capacity
			admission.
			This document also recommends that certain classes of video traffic
			described in RFC 4594 and which have similar requirements be changed
			to require admission using a Call Admission Control (CAC) procedure
			involving authentication, authorization, and capacity admission.
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with
	applicable patent or other IPR claims of which he or she is aware		the provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other documents
	time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as
	material or to cite them other than as "work in progress."		reference 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.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 5, 2009.		This Internet-Draft will expire on June 4, 2010.
	Abstract		Copyright Notice
	This document requests one Differentiated Services Code Point (DSCP)		Copyright (c) 2009 IETF Trust and the persons identified as the
	from the Internet Assigned Numbers Authority (IANA) for real-time		document authors. All rights reserved.
	traffic classes similar to voice conforming to the Expedited
	Forwarding Per Hop Behavior, and admitted using a call admission
	procedure involving authentication, authorization, and capacity
	admission.
	This document also recommends that certain classes of video traffic		This document is subject to BCP 78 and the IETF Trust's Legal
	described in RFC 4594 and which have similar requirements be changed		Provisions Relating to IETF Documents
	to require admission using a Call Admission Control (CAC) procedure		(http://trustee.ietf.org/license-info) in effect on the date of
	involving authentication, authorization, and capacity admission.		publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Simplified BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the BSD License.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Candidate Implementations of the Admitted Telephony		2. Candidate Implementations of the Admitted Telephony
	Service Class . . . . . . . . . . . . . . . . . . . . . . . . 7		Service Class . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Potential implementations of EF in this model . . . . . . 7		2.1. Potential implementations of EF in this model . . . . . . 7
	2.2. Capacity admission control . . . . . . . . . . . . . . . . 9		2.2. Capacity admission control . . . . . . . . . . . . . . . 9
	2.3. Recommendations on implementation of an Admitted		2.3. Recommendations on implementation of an Admitted
	Telephony Service Class . . . . . . . . . . . . . . . . . 10		Telephony Service Class . . . . . . . . . . . . . . . . . 10
	3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . . 11		3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This document requests one Differentiated Services Code Point (DSCP)		This document requests one Differentiated Services Code Point (DSCP)
	from the Internet Assigned Numbers Authority (IANA) for a class of		from the Internet Assigned Numbers Authority (IANA) for a class of
	real-time traffic. This class conforms to the Expedited Forwarding		real-time traffic. This class conforms to the Expedited Forwarding
	[RFC3246] [RFC3247] Per Hop Behavior. It is also admitted using a		[RFC3246] [RFC3247] Per Hop Behavior. It is also admitted using a
	CAC procedure involving authentication, authorization, and capacity		CAC procedure involving authentication, authorization, and capacity
	admission. This differs from a real-time traffic class conforming to		admission. This differs from a real-time traffic class conforming
	the Expedited Forwarding Per Hop Behavior but not subject to capacity		to the Expedited Forwarding Per Hop Behavior but not subject to
	admission or subject to very coarse capacity admission.		capacity admission or subject to very coarse capacity admission.
	It also recommends that certain classes of video described in		It also recommends that certain classes of video described in
	[RFC4594] be treated as requiring capacity admission as well.		[RFC4594] be treated as requiring capacity admission as well.
	These applications have one or more potential congestion points		These applications have one or more potential congestion points
	between the endpoints. Reserving capacity for them is important to		between the endpoints. Reserving capacity for them is important to
	application performance. All of these applications have low		application performance. All of these applications have low
	tolerance to jitter (aka delay variation) and loss, as summarized in		tolerance to jitter (aka delay variation) and loss, as summarized in
	Section 2, and most (except for multimedia conferencing) have		Section 2, and most (except for multimedia conferencing) have
	inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow		inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow
	skipping to change at page 3, line 38		skipping to change at page 3, line 38
	One of the reasons behind this is the need for classes of traffic		One of the reasons behind this is the need for classes of traffic
	that are handled under special policies, such as the non-preemptive		that are handled under special policies, such as the non-preemptive
	Emergency Telecommunication Service, the US Department of Defense's		Emergency Telecommunication Service, the US Department of Defense's
	Assured Service (which is similar to Multi-Level Precedence and		Assured Service (which is similar to Multi-Level Precedence and
	Preemption [ITU.MLPP.1990] procedure), or e-911, in addition to		Preemption [ITU.MLPP.1990] procedure), or e-911, in addition to
	normal routine calls that use call admission. It is possible to use		normal routine calls that use call admission. It is possible to use
	control plane protocols to generally restrict session admission such		control plane protocols to generally restrict session admission such
	that admitted traffic should receive the desired service, and the		that admitted traffic should receive the desired service, and the
	policy (e.g. Routine, National Security or Emergency Preparedness		policy (e.g. Routine, National Security or Emergency Preparedness
	[NS/EP] communications, e-911, etc) need not be signaled in a DSCP.		[NS/EP] communications, e-911, etc) need not be signaled in a DSCP.
	However, service providers need to distinguish between special-policy		However, service providers need to distinguish between
	traffic and other classes, particularly the existing VoIP services		special-policy traffic and other classes, particularly the existing
	that perform no capacity admission or only very coarse capacity		VoIP services that perform no capacity admission or only very coarse
	admission and can exceed their allocated resources.		capacity admission and can exceed their allocated resources.
	The requested DSCP applies to the Telephony Service Class described		The requested DSCP applies to the Telephony Service Class described
	in [RFC4594].		in [RFC4594].
	Since video classes have not had the history of mixing admitted and		Since video classes have not had the history of mixing admitted and
	non-admitted traffic in the same Per-Hop Behavior (PHB) as has		non-admitted traffic in the same Per-Hop Behavior (PHB) as has
	occurred for EF, an additional DSCP code point is not recommended.		occurred for EF, an additional DSCP code point is not recommended.
	Instead, the recommended "best practice" is to perform admission		Instead, the recommended "best practice" is to perform admission
	control for all traffic in three of [RFC4594]'s video classes: the		control for all traffic in three of [RFC4594]'s video classes: the
	o Interactive Real-Time Traffic (CS4, used for Video conferencing		o Interactive Real-Time Traffic (CS4, used for Video conferencing
	and Interactive gaming),		and Interactive gaming),
	o Broadcast TV (CS3) for use in a video on demand context, and		o Broadcast TV (CS3) for use in a video on demand context, and
	o AF4 Multimedia Conferencing (video conferencing).		o AF4 Multimedia Conferencing (video conferencing).
	Other video classes are believed to not have the current problem of		Other video classes are believed to not have the current problem of
	confusion with unadmitted traffic and therefore would not benefit		confusion with unadmitted traffic and therefore would not benefit
	from the notion of a separate DSCP for admitted traffic. Within an		from the notion of a separate DSCP for admitted traffic. Within an
	ISP and on inter-ISP links (i.e. within networks whose internal paths		ISP and on inter-ISP links (i.e. within networks whose internal
	are uniform at hundreds of megabits or faster), one would expect all		paths are uniform at hundreds of megabits or faster), one would
	of this traffic to be carried in the Real Time Traffic Class		expect all of this traffic to be carried in the Real Time Traffic
	described in [RFC5127].		(RTP) Class described in [RFC5127].
	1.1. Definitions		1.1. Definitions
	The following terms and acronyms are used in this document.		The following terms and acronyms are used in this document.
	PHB: A Per-Hop-Behavior (PHB) is the externally observable		PHB: A Per-Hop-Behavior (PHB) is the externally observable
	forwarding behavior applied at a Differentiated Services compliant		forwarding behavior applied at a Differentiated Services
	node to a DS behavior aggregate [RFC2475]. It may be thought of		compliant node to a DS behavior aggregate [RFC2475]. It may be
	as a program configured on the interface of an Internet host or		thought of as a program configured on the interface of an
	router, specified drop probabilities, queuing priorities or rates,		Internet host or router, specified drop probabilities, queuing
	and other handling characteristics for the traffic class.		priorities or rates, and other handling characteristics for the
			traffic class.
	DSCP: The Differentiated Services Code Point (DSCP), as defined in		DSCP: The Differentiated Services Code Point (DSCP), as defined in
	[RFC2474], is a value which is encoded in the DS field, and which		[RFC2474], is a value which is encoded in the DS field, and which
	each DS Node MUST use to select the PHB which is to be experienced		each DS Node MUST use to select the PHB which is to be
	by each packet it forwards [RFC3260]. It is a 6-bit number		experienced by each packet it forwards [RFC3260]. It is a 6-bit
	embedded into the 8-bit TOS field of an IPv4 datagram or the		number embedded into the 8-bit TOS field of an IPv4 datagram or
	Traffic Class field of an IPv6 datagram.		the Traffic Class field of an IPv6 datagram.
	CAC: Call Admission Control includes concepts of authorization and		CAC: Call Admission Control includes concepts of authorization and
	capacity admission. "Authorization" refers to any procedure that		capacity admission. "Authorization" refers to any procedure that
	identifies a user, verifies the authenticity of the		identifies a user, verifies the authenticity of the
	identification, and determines whether the user is authorized to		identification, and determines whether the user is authorized to
	use the service under the relevant policy. "Capacity Admission"		use the service under the relevant policy. "Capacity Admission"
	refers to any procedure that determines whether capacity exists		refers to any procedure that determines whether capacity exists
	supporting a session's requirements under some policy.		supporting a session's requirements under some policy.
	In the Internet, these are separate functions, while in the PSTN		In the Internet, these are separate functions, while in the PSTN
	they and call routing are carried out together.		they and call routing are carried out together.
	UNI: A User/Network Interface (UNI) is the interface (often a		UNI: A User/Network Interface (UNI) is the interface (often a
	physical link or its virtual equivalent) that connects two		physical link or its virtual equivalent) that connects two
	entities that do not trust each other, and in which one (the user)		entities that do not trust each other, and in which one (the
	purchases connectivity services from the other (the network).		user) purchases connectivity services from the other (the
			network).
	Figure 1 shows two user networks connected by what appears to each		Figure 1 shows two user networks connected by what appears to
	of them to be a single network ("The Internet", access to which is		each of them to be a single network ("The Internet", access to
	provided by their service provider) that provides connectivity		which is provided by their service provider) that provides
	services to other users.		connectivity services to other users.
	UNIs tend to be the bottlenecks in the Internet, where users		UNIs tend to be the bottlenecks in the Internet, where users
	purchase relatively low amounts of bandwidth for cost or service		purchase relatively low amounts of bandwidth for cost or service
	reasons, and as a result are most subject to congestion issues and		reasons, and as a result are most subject to congestion issues
	therefore issues requiring traffic conditioning and service		and therefore issues requiring traffic conditioning and service
	prioritization.		prioritization.
	NNI: A Network/Network Interface (NNI) is the interface (often a		NNI: A Network/Network Interface (NNI) is the interface (often a
	physical link or its virtual equivalent) that connects two		physical link or its virtual equivalent) that connects two
	entities that trust each other within limits, and in which the two		entities that trust each other within limits, and in which the
	are seen as trading services for value. Figure 1 shows three		two are seen as trading services for value. Figure 1 shows three
	service networks that together provide the connectivity services		service networks that together provide the connectivity services
	that we call "the Internet". They are different administrations		that we call "the Internet". They are different administrations
	and are very probably in competition, but exchange contracts for		and are very probably in competition, but exchange contracts for
	connectivity and capacity that enable them to offer specific		connectivity and capacity that enable them to offer specific
	services to their customers.		services to their customers.
	NNIs may not be bottlenecks in the Internet if service providers		NNIs may not be bottlenecks in the Internet if service providers
	contractually agree to provision excess capacity at them, as they		contractually agree to provision excess capacity at them, as they
	commonly do. However, NNI performance may differ by ISP, and the		commonly do. However, NNI performance may differ by ISP, and the
	performance guarantee interval may range from a month to a much		performance guarantee interval may range from a month to a much
	shorter period. Furthermore, a peering point NNI may not have		shorter period. Furthermore, a peering point NNI may not have
	contractual performance guarantees or may become overloaded under		contractual performance guarantees or may become overloaded under
	certain conditions. They are also policy-controlled interfaces,		certain conditions. They are also policy-controlled interfaces,
	especially in BGP. As a result, they may require traffic		especially in BGP. As a result, they may require traffic
	prioritization policy.		prioritization policy.
	Queue: There are multiple ways to build a multi-queue scheduler.		Queue: There are multiple ways to build a multi-queue scheduler.
	Weighted Round Robin (WRR) literally builds multiple lists and		Weighted Round Robin (WRR) literally builds multiple lists and
	visits them in a specified order, while a calendar queue (often		visits them in a specified order, while a calendar queue (often
	used to implement Weighted Fair Queuing, or WFQ) builds a list for		used to implement Weighted Fair Queuing, or WFQ) builds a list
	each time interval and enqueues at most a stated amount of data in		for each time interval and queues at most a stated amount of data
	each such list for transmission during that time interval. While		in each such list for transmission during that time interval.
	these differ dramatically in implementation, the external		While these differ dramatically in implementation, the external
	difference in behavior is generally negligible when they are		difference in behavior is generally negligible when they are
	properly configured. Consistent with the definitions used in the		properly configured. Consistent with the definitions used in the
	Differentiated Services Architecture [RFC2475], these are treated		Differentiated Services Architecture [RFC2475], these are treated
	as equivalent in this document, and the lists of WRR and the		as equivalent in this document, and the lists of WRR and the
	classes of a calendar queue will be referred to uniformly as		classes of a calendar queue will be referred to uniformly as
	"queues".		"queues".
	_.--------.		_.--------.
	,-'' `--.		,-'' `--.
	,-' `-.		,-' `-.
	skipping to change at page 6, line 41		skipping to change at page 6, line 41
	`-. ,-'		`-. ,-'
	`--. _.-'		`--. _.-'
	`--------''		`--------''
	Figure 1: UNI and NNI interfaces		Figure 1: UNI and NNI interfaces
	1.2. Problem		1.2. Problem
	In short, the Telephony Service Class described in [RFC4594] permits		In short, the Telephony Service Class described in [RFC4594] permits
	the use of capacity admission in implementing the service, but		the use of capacity admission in implementing the service, but
	present implementations either provide no capacity admission services		present implementations either provide no capacity admission
	or do so in a manner that depends on specific traffic engineering.		services or do so in a manner that depends on specific traffic
	In the context of the Internet backbone, the two are essentially		engineering. In the context of the Internet backbone, the two are
	equivalent; the edge network depends on specific engineering by the		essentially equivalent; the edge network depends on specific
	service provider that may not be present, especially in a mobile		engineering by the service provider that may not be present,
	environment.		especially in a mobile environment.
	However, services are being requested of the network that would		However, services are being requested of the network that would
	specifically make use of capacity admission, and would distinguish		specifically make use of capacity admission, and would distinguish
	among users or the uses of available Voice-over-IP or Video-over-IP		among users or the uses of available Voice-over-IP or Video-over-IP
	capacity in various ways. Various agencies would like to provide		capacity in various ways. Various agencies would like to provide
	services as described in section 2.6 of [RFC4504] or in [RFC4190].		services as described in section 2.6 of [RFC4504] or in [RFC4190].
	This requires the use of capacity admission to differentiate among		This requires the use of capacity admission to differentiate among
	users (which might be 911 call centers, other offices with		users (which might be 911 call centers, other offices with
	preferential service contracts, or individual users gaining access		preferential service contracts, or individual users gaining access
	skipping to change at page 7, line 33		skipping to change at page 7, line 31
	o Multiple data plane traffic classes, each consisting of a policer		o Multiple data plane traffic classes, each consisting of a policer
	but feeding into a common queue or multiple queues at the same		but feeding into a common queue or multiple queues at the same
	priority.		priority.
	We will explain the difference, and describe in what way they differ		We will explain the difference, and describe in what way they differ
	in operation. The reason this is necessary is that there is current		in operation. The reason this is necessary is that there is current
	confusion in the industry.		confusion in the industry.
	The multi-priority model is shown in Figure 2. In this model,		The multi-priority model is shown in Figure 2. In this model,
	traffic from each service class is placed into a separate priority		traffic from each service class is placed into a separate priority
	queue. If data is present in both queues, traffic from one of them		queue. If data is present in more than one queue, traffic from one
	will always be selected for transmission. This has the effect of		of them will always be selected for transmission. This has the
	transferring jitter from the higher priority queue to the lower		effect of transferring jitter from the higher priority queue to the
	priority queue, and reordering traffic in a way that gives the higher		lower priority queue, and reordering traffic in a way that gives the
	priority traffic a smaller average queuing delay. Each queue must		higher priority traffic a smaller average queuing delay. Each queue
	have its own policer, however, to protect the network from errors and		must have its own policer, however, to protect the network from
	attacks; if a traffic class thinks it is carrying a certain data rate		errors and attacks; if a traffic class thinks it is carrying a
	but an abuse sends significantly more, the effect of simple		certain data rate but an abuse sends significantly more, the effect
	prioritization would not preserve the lower priorities of traffic,		of simple prioritization would not preserve the lower priorities of
	which could cause routing to fail or otherwise impact an SLA.		traffic, which could cause routing to fail or otherwise impact an
			SLA.
	.		.
	policers priorities |`.		policers priorities |`.
	Unadmitted EF <=> ----------||----+ `.		Admitted EF <=> ----------||----+ `.
	high| `.		high| `.
	Admitted EF <=> ----------||----+ .'-----------		Unadmitted EF <=> ----------||----+ .'-----------
	. medium .'		. medium .'
	rate queues |`. +-----+ .' Priority		rate queues |`. +-----+ .' Priority
	AF1------>||----+ `. / low |' Scheduler		AF1------>||----+ `. / low |' Scheduler
	| `. /		| `. /
	AF2------>||----+ .'-+		AF2------>||----+ .'-+
	| .'		| .'
	CS0------>||----+ .' Rate Scheduler		CS0------>||----+ .' Rate Scheduler
	|' (WFQ, WRR, etc)		|' (WFQ, WRR, etc)
	Figure 2: Implementation as a data plane priority		Figure 2: Implementation as a data plane priority
	The multi-policer model is shown in Figure 3. In this model, traffic		The multi-policer model is shown in Figure 3. In this model,
	from each service class is policed according to its SLA requirements,		traffic from each service class is policed according to its SLA
	and then placed into a common priority queue. Unlike the multi-		requirements, and then placed into a common priority queue. Unlike
	priority model, the jitter experienced by the traffic classes in this		the multi-priority model, the jitter experienced by the traffic
	case is the same, as there is only one queue, but the sum of the		classes in this case is the same, as there is only one queue, but
	traffic in this higher priority queue experiences less average jitter		the sum of the traffic in this higher priority queue experiences
	than the elastic traffic in the lower priority.		less average jitter than the elastic traffic in the lower priority.
	policers priorities .		policers priorities .
	Unadmitted EF <=> -------\ |`.		Admitted EF <=> -------\ |`.
	--||----+ `.		--||----+ `.
	Admitted EF <=> -------/ high| `.		Unadmitted EF <=> -------/ high| `.
	. | .'--------		. | .'--------
	rate queues |`. +-----+ .'		rate queues |`. +-----+ .'
	AF1------>||----+ `. / low | .' Priority		AF1------>||----+ `. / low | .' Priority
	| `. / |' Scheduler		| `. / |' Scheduler
	AF2------>||----+ .'-+		AF2------>||----+ .'-+
	| .'		| .'
	CS0------>||----+ .' Rate Scheduler		CS0------>||----+ .' Rate Scheduler
	|' (WFQ, WRR, etc)		|' (WFQ, WRR, etc)
	Figure 3: Implementation as a data plane policer		Figure 3: Implementation as a data plane policer
	The difference between the two operationally is, as stated, the		The difference between the two operationally is, as stated, the
	issues of loss due to policing and distribution of jitter.		issues of loss due to policing and distribution of jitter.
	If the two traffic classes are, for example, voice and video,		If the two traffic classes are, for example, voice and video,
	datagrams conaining video data can be relatively large (often of		datagrams containing video data can be relatively large (often of
	variable sizes up to the path MTU) while datagrams containing voice		variable sizes up to the path MTU) while datagrams containing voice
	are relatively small, on the order of only 40 to 200 bytes, depending		are relatively small, on the order of only 40 to 200 bytes,
	on the codec. On lower speed links (less than 10 MBPS), the jitter		depending on the codec. On lower speed links (less than 10 MBPS),
	introduced by video to voice can be disruptive, while at higher		the jitter introduced by video to voice can be disruptive, while at
	speeds the jitter is nominal compared to the jitter requirements of		higher speeds the jitter is nominal compared to the jitter
	voice. At access network speeds, therefore, [RFC4594] recommends		requirements of voice. At access network speeds, therefore,
	separation of video and voice into separate queues, while at optical		[RFC4594] recommends separation of video and voice into separate
	speeds [RFC5127] recommends that they use a common queue.		queues, while at optical speeds [RFC5127] recommends that they use a
			common queue.
	If, on the other hand, the two traffic classes are carrying the same		If, on the other hand, the two traffic classes are carrying the same
	type of application with the same jitter requirements, then giving		type of application with the same jitter requirements, then giving
	one preference in this sense does not benefit the higher priority		one preference in this sense does not benefit the higher priority
	traffic and may harm the lower priority traffic. In such a case,		traffic and may harm the lower priority traffic. In such a case,
	using separate policers and a common queue is a superior approach.		using separate policers and a common queue is a superior approach.
	2.2. Capacity admission control		2.2. Capacity admission control
	There are at least six major ways that capacity admission is done or		There are at least six major ways that capacity admission is done or
	skipping to change at page 9, line 36		skipping to change at page 9, line 34
	o Capacity admission control by call counting,		o Capacity admission control by call counting,
	o End-point capacity admission performed by probing the network,		o End-point capacity admission performed by probing the network,
	o Centralized capacity admission control via bandwidth broker, and		o Centralized capacity admission control via bandwidth broker, and
	o Distributed capacity admission control using protocols such as		o Distributed capacity admission control using protocols such as
	RSVP or NSIS.		RSVP or NSIS.
	The problem with capacity admission by assumption, which is widely
	reployed in today's VoIP environment, is that it depends on the
	assumptions made. One can do careful traffic engineering to ensure
	needed bandwidth, but this can also be painful, and has to be
	revisited when the network is changed or network usage changes.
	The problem with dropping traffic to force users to hang up is that		The problem with dropping traffic to force users to hang up is that
	it affects a broad class of users - if there is capacity for N calls		it affects a broad class of users - if there is capacity for N calls
	and the N+1 calls are active, data is dropped randomly from all		and the N+1 calls are active, data is dropped randomly from all
	sessions to ensure that offered load doesn't exceed capacity. On		sessions to ensure that offered load doesn't exceed capacity. On
	very fast links, that is acceptable, but on lower speed links it can		very fast links, that is acceptable, but on lower speed links it can
	seriously affect call quality.		seriously affect call quality. There is also a behavioral issue
			involved here, in which users who experience poor quality calls tend
			to hang up and call again, making the problem better - then worse.
			The problem with capacity admission by assumption, which is widely
			deployed in today's VoIP environment, is that it depends on the
			assumptions made. One can do careful traffic engineering to ensure
			needed bandwidth, but this can also be painful, and has to be
			revisited when the network is changed or network usage changes.
			The problem with call counting based admission control is it gets
			exponentially worse the farther you get from the control point
			(e.g., it lacks sufficient scalability out into the network).
	There are two fundamental problems with depending on the endpoint to		There are two fundamental problems with depending on the endpoint to
	perform capacity admission; it may not be able to accurately measure		perform capacity admission; it may not be able to accurately measure
	the impact of the traffic it generates on the network, and it tends		the impact of the traffic it generates on the network, and it tends
	to be greedy (eg., it doesn't care). If the network operator is		to be greedy (e.g., it doesn't care). If the network operator is
	providing a service, he must be able to guarantee the service, which		providing a service, he must be able to guarantee the service, which
	means that he can't trust systems that are not controlled by his		means that he cannot trust systems that are not controlled by his
	network.		network.
	The problem with mechanisms that don't enable the association of a		The problem with capacity controls via a bandwidth broker is
	policy with the request is that they don't allow for multi-policy		centralized servers lack far away awareness, and also lack effective
			real-time reaction to dynamic changes in all part of the network
			at all instances of time.
			The problem with mechanisms that do not enable the association of a
			policy with the request is that they do not allow for multi-policy
	services, which are becoming important.		services, which are becoming important.
	The operator's choice of admission procedure must, for this DSCP,		The operator's choice of admission procedure MUST, for this DSCP,
	ensure the following:		ensure the following:
	o The actual links that a session uses have enough bandwidth to		o The actual links that a session uses have enough bandwidth to
	support it.		support it.
	o New sessions are refused admission if there is inadequate		o New sessions are refused admission if there is inadequate
	bandwidth under the relevant policy.		bandwidth under the relevant policy.
	o If multiple policies are in use in a network, that the user is		o If multiple policies are in use in a network, that the user is
	identified and the correct policy applied.		identified and the correct policy applied.
	o Under periods of network stress, the process of admission of new		o Under periods of network stress, the process of admission of new
	sessions does not disrupt existing sessions, unless the service		sessions does not disrupt existing sessions, unless the service
	explicitly allows for disruption of calls.		explicitly allows for disruption of calls.
	2.3. Recommendations on implementation of an Admitted Telephony Service		2.3. Recommendations on implementation of an Admitted Telephony
	Class		Service Class
	It is the belief of the authors that either PHB implementation		It is the belief of the authors that either PHB implementation
	described in Section 2.1, if coupled with adequate AAA and capacity		described in Section 2.1, if coupled with adequate AAA and capacity
	admission procedures as described in Section 2.2, are sufficient to		admission procedures as described in Section 2.2, are sufficient to
	provide the services required for an Admitted Telephony service		provide the services required for an Admitted Telephony service
	class. If preemption is required, as described in section 2.3.5.2 of		class. If preemption is required, as described in section 2.3.5.2
	[RFC4542], this provides the tools for carrying out the preemption.		of [RFC4542], this provides the tools for carrying out the
	If preemption is not in view, or if used in addition to preemptive		preemption. If preemption is not in view, or if used in addition to
	services, the application of different thresholds depending on call		preemptive services, the application of different thresholds
	precedence has the effect of improving the probability of call		depending on call precedence has the effect of improving the
	completion by admitting preferred calls at a time that other calls		probability of call completion by admitting preferred calls at a
	are being refused. Routine and priority traffic can be admitted		time that other calls are being refused. Routine and priority
	using the same DSCP value, as the choice of which calls are admitted		traffic can be admitted using the same DSCP value, as the choice of
	is handled in the admission procedure executed in the control plane,		which calls are admitted is handled in the admission procedure
	not the policing of the data plane.		executed in the control plane, not the policing of the data plane.
	On the point of what protocols and procedures are required for		On the point of what protocols and procedures are required for
	authentication, authorization, and capacity admission, we note that		authentication, authorization, and capacity admission, we note that
	clear standards do not at this time exist for bandwidth brokers, NSIS		clear standards do not exist at this time for bandwidth brokers,
	has not at this time been finalized and in any event is limited to		NSIS has not been finalized at this time and in any event is limited
	unicast sessions, and that RSVP has been standardized and has the		to unicast sessions, and that RSVP has been standardized and has the
	relevant services. We therefore recommend the use of RSVP at the		relevant services. We therefore recommend the use of RSVP at the
	UNI. Procedures at the NNI are business matters to be discussed		UNI. Procedures at the NNI are business matters to be discussed
	between the relevant networks, and are recommended but not required.		between the relevant networks, and are recommended but not required.
	3. Summary: changes from RFC 4594		3. Summary: changes from RFC 4594
	To summarize, there are two changes to [RFC4594] discussed in this		To summarize, there are two changes to [RFC4594] discussed in this
	document:		document:
	Telephony class: The Telephony Service Class in RFC 4594 does not		Telephony class: The Telephony Service Class in RFC 4594 does not
	involve capacity admission, but depends on application layer		involve capacity admission, but depends on application layer
	admission that only estimates capacity, and that through static		admission that only estimates capacity, and that through static
	engineering. In addition to that class, a separate Admitted		engineering. In addition to that class, a separate Admitted
	Telephony Class is added which performs capacity admission		Telephony Class is added which performs capacity admission
	dynamically.		dynamically.
	Video classes Capacity admission is added to three video classes.		Video classes: Capacity admission is added to three video classes.
	These are the Interactive Real-Time Traffic class, Broadcast TV		These are the Interactive Real-Time Traffic class, Broadcast TV
	class when used for video on demand, and the Multimedia		class when used for video on demand, and the Multimedia
	Conferencing class.		Conferencing class.
	4. IANA Considerations		4. IANA Considerations
	This note requests that IANA assign a DSCP value to a second EF		This note requests that IANA assign a DSCP value to a second EF
	traffic class consistent with [RFC3246] and [RFC3247] in the		traffic class consistent with [RFC3246] and [RFC3247] in the
	"Differentiated Services Field Codepoints" registry. It implements		"Differentiated Services Field Codepoints" registry. It implements
	the Telephony Service Class described in [RFC4594] at lower speeds		the Telephony Service Class described in [RFC4594] at lower speeds
	and is included in the Real Time Treatment Aggregate [RFC5127] at		and is included in the Real Time Treatment Aggregate [RFC5127] at
	higher speeds. The recommended value for the code point is 101100,		higher speeds. The recommended value for the code point is 101100,
	paralleling the EF code point, which is 101110. The code point		paralleling the EF code point, which is 101110. The code point
	should be referred to as VOICE-ADMIT.		should be referred to as VOICE-ADMIT.
	This traffic class requires the use of capacity admission such as		This traffic class requires the use of capacity admission such as
	RSVP services together with AAA services at the User/Network		RSVP services together with AAA services at the User/Network
	Interface (UNI); the use of such services at the NNI is at the option		Interface (UNI); the use of such services at the NNI is at the
	of the interconnected networks.		option of the interconnected networks.
	5. Security Considerations		5. Security Considerations
	A major requirement of this service is effective use of a signaling		A major requirement of this service is effective use of a signaling
	protocol such as RSVP, with the capabilities to identify its user		protocol such as RSVP, with the capabilities to identify its user
	either as an individual or as a member of some corporate entity, and		either as an individual or as a member of some corporate entity, and
	assert a policy such as "routine" or "priority".		assert a policy such as "routine" or "priority".
	This capability, one has to believe, will be abused by script kiddies		This capability, one has to believe, will be abused by script
	and others if the proof of identity is not adequately strong or if		kiddies and others if the proof of identity is not adequately strong
	policies are written or implemented improperly by the carriers. This		or if policies are written or implemented improperly by the
	goes without saying, but this section is here for it to be said...		carriers. This goes without saying, but this section is here for it
			to be said...
	6. Acknowledgements		6. Acknowledgements
	Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe		Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe
	commented and offered text. The impetus for including Video in the		commented and offered text. The impetus for including Video in the
	discussion, which initially only targeted voice, is from Dave		discussion, which initially only targeted voice, is from Dave
	McDysan,		McDysan.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	skipping to change at page 13, line 19		skipping to change at page 13, line 14
	[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for		[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
	Supporting Emergency Telecommunications Service (ETS) in		Supporting Emergency Telecommunications Service (ETS) in
	IP Telephony", RFC 4190, November 2005.		IP Telephony", RFC 4190, November 2005.
	[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony		[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
	Device Requirements and Configuration", RFC 4504,		Device Requirements and Configuration", RFC 4504,
	May 2006.		May 2006.
	[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency		[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
	Telecommunications Service (ETS) for Real-Time Services in		Telecommunications Service (ETS) for Real-Time Services
	the Internet Protocol Suite", RFC 4542, May 2006.		in the Internet Protocol Suite", RFC 4542, May 2006.
	[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of		[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
	DiffServ Service Classes", RFC 5127, February 2008.		DiffServ Service Classes", RFC 5127, February 2008.
	Authors' Addresses		Authors' Addresses
	Fred Baker		Fred Baker
	Cisco Systems		Cisco Systems
	Santa Barbara, California 93117		Santa Barbara, California 93117
	USA		USA
	skipping to change at page 14, line 4		skipping to change at page 13, line 37
	Phone: +1-408-526-4257		Phone: +1-408-526-4257
	Email: fred@cisco.com		Email: fred@cisco.com
	James Polk		James Polk
	Cisco Systems		Cisco Systems
	Richardson, Texas 75082		Richardson, Texas 75082
	USA		USA
	Phone: +1-817-271-3552		Phone: +1-817-271-3552
	Email: jmpolk@cisco.com		Email: jmpolk@cisco.com
	Martin Dolly		Martin Dolly
	AT&T Labs		AT&T Labs
	Middletown Township, New Jersey 07748		Middletown Township, New Jersey 07748
	USA		USA
	Phone: +1-732-420-4574		Phone: +1-732-420-4574
	Email: mdolly@att.com		Email: mdolly@att.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 48 change blocks.
	150 lines changed or deleted		191 lines changed or added
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/