draft-ietf-tsvwg-admitted-realtime-dscp-07.txt		rfc5865.txt
	Transport Working Group F. Baker		Internet Engineering Task Force (IETF) F. Baker
	Internet-Draft J. Polk		Request for Comments: 5865 J. Polk
	Updates: 4542,4594 Cisco Systems		Updates: 4542, 4594 Cisco Systems
	(if approved) M. Dolly		Category: Standards Track M. Dolly
	Intended status: Standards Track AT&T Labs		ISSN: 2070-1721 AT&T Labs
	Expires: Sept 8, 2010 March 8, 2010		May 2010
	DSCP for Capacity-Admitted Traffic		A Differentiated Services Code Point (DSCP)
	draft-ietf-tsvwg-admitted-realtime-dscp-07		for Capacity-Admitted Traffic
	Abstract		Abstract
	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 traffic class conforms to the Expedited
	Per Hop Behavior. It is also admitted using a CAC procedure		Forwarding Per-Hop Behavior. This traffic is also admitted by the
	involving authentication, authorization, and capacity admission.		network using a Call Admission Control (CAC) procedure involving
	This differs from a real-time traffic class conforming to the		authentication, authorization, and capacity admission. This differs
	Expedited Forwarding Per Hop Behavior but not subject to capacity		from a real-time traffic class that conforms to the Expedited
	admission or subject to very coarse capacity admission.		Forwarding Per-Hop Behavior but is not subject to capacity admission
			or subject to very coarse capacity admission.
	Legal
	This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with
	the provisions of BCP 78 and BCP 79.
	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		Status of This Memo
	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		This is an Internet Standards Track document.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/shadow.html.		(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on September 8, 2010.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc5865.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with respect
	respect to this document. Code Components extracted from this		to this document. Code Components extracted from this document must
	document must include Simplified BSD License text as described in		include Simplified BSD License text as described in Section 4.e of
	Section 4.e of the Trust Legal Provisions and are provided without		the Trust Legal Provisions and are provided without warranty as
	warranty as described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Requirements Language
	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 [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 . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . 10		3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	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		(EF) [RFC3246] [RFC3247] Per-Hop Behavior. It is also admitted using
	CAC procedure involving authentication, authorization, and capacity		a CAC procedure involving authentication, authorization, and capacity
	admission. This differs from a real-time traffic class conforming		admission. This differs from a real-time traffic class that conforms
	to the Expedited Forwarding Per Hop Behavior but not subject to		to the Expedited Forwarding Per-Hop Behavior but is not subject to
	capacity 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		In addition, this document recommends that certain classes of video
	[RFC4594] be treated as requiring capacity admission as well.		described in [RFC4594] be treated as requiring capacity admission.
	Real-time traffic flows have one or more potential congestion points		Real-time traffic flows have one or more potential congestion points
	between the endpoints. Reserving capacity for these flows is		between the endpoints. Reserving capacity for these flows is
	important to application performance. All of these applications		important to application performance. All of these applications have
	have low tolerance to jitter (aka delay variation) and loss, as		low tolerance to jitter (aka delay variation) and loss, as summarized
	summarized in Section 2, and most (except for multimedia		in Section 2, and most (except for multimedia conferencing) have
	conferencing) have inelastic flow behavior from Figure 1 of		inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow
	[RFC4594]. Inelastic flow behavior and low jitter/loss tolerance		behavior and low jitter/loss tolerance are the service
	are the service characteristics that define the need for admission		characteristics that define the need for admission control behavior.
	control behavior.
	One of the reasons behind this is the need for classes of traffic		One of the reasons behind the requirement for capacity admission is
	that are handled under special policies. Service providers need to		the need for classes of traffic that are handled under special
	distinguish between special-policy traffic and other classes,		policies. Service providers need to distinguish between special-
	particularly the existing VoIP services that perform no capacity		policy traffic and other classes, particularly the existing Voice
	admission or only very coarse capacity admission and can exceed		over IP (VoIP) services that perform no capacity admission or only
	their allocated resources.		very coarse 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
	within this document for video. Instead, the recommended "best		within this document for video. Instead, the recommended "best
	practice" is to perform admission control for all traffic in three		practice" is to perform admission control for all traffic in three of
	of [RFC4594]'s video classes: the		the video classes from [RFC4594]:
	o Interactive Real-Time Traffic (CS4, used for Video conferencing		o The Interactive Real-Time Traffic (CS4, used for Video
	and Interactive gaming),		conferencing and Interactive gaming),
	o Broadcast TV (CS3) for use in a video on demand context, and		o The Broadcast TV (CS3) for use in a video on demand context, and
	o AF4 Multimedia Conferencing (video conferencing).
	Other video classes are believed to not have the current problem of		o The AF4 Multimedia Conferencing (video conferencing).
			Other video classes are believed not to 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		ISP and on inter-ISP links (i.e., within networks whose internal
	paths are uniform at hundreds of megabits per second or faster), one		paths are uniform at hundreds of megabits per second or faster), one
	would expect all of this traffic to be carried in the Real-Time		would expect all of this traffic to be carried in the Real-Time
	Traffic (RTP) Class described in [RFC5127].		Traffic (RTP) class described in [RFC5127].
	1.1. Definitions		1.1. Definitions
			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 [RFC2119].
	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		forwarding behavior applied at a Differentiated Services
	compliant node to a DS behavior aggregate [RFC2475]. It may be		compliant node to a DS behavior aggregate [RFC2475]. It may
	thought of as a program configured on the interface of an		be thought of as a program configured on the interface of an
	Internet host or router, specified in terms of drop		Internet host or router, specified in terms of drop
	probabilities, queuing priorities or rates, and other handling		probabilities, queuing priorities or rates, and other handling
	characteristics for the traffic class.		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 that is encoded in the DS field, and
	each DS Node MUST use to select the PHB which is to be		that each DS Node MUST use to select the PHB that is to be
	experienced by each packet it forwards [RFC3260]. It is a 6-bit		experienced by each packet it forwards [RFC3260]. It is a
	number embedded into the 8-bit TOS field of an IPv4 datagram or		6-bit number embedded into the 8-bit TOS (type of service)
	the Traffic Class field of an IPv6 datagram.		field of an IPv4 datagram or 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
	identifies a user, verifies the authenticity of the		that 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
	use the service under the relevant policy. "Capacity Admission"		to use the service under the relevant policy. "Capacity
	refers to any procedure that determines whether capacity exists		Admission" refers to any procedure that determines whether
	supporting a session's requirements under some policy.		capacity exists 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
	they and call routing are carried out together.		Public Switched Telephone Network (PSTN), 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		entities that do not trust each other, and in which one (the
	user) purchases connectivity services from the other (the		user) purchases connectivity services from the other (the
	network).		network).
	Figure 1 shows two user networks connected by what appears to		Figure 1 shows two user networks connected by what appears to
	each of them to be a single network ("The Internet", access to		each of them to be a single network ("The Internet", access to
	which is provided by their service provider) that provides		which is provided by their service provider) that provides
	connectivity 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
	reasons, and as a result are most subject to congestion issues		service reasons, and as a result are most subject to
	and therefore issues requiring traffic conditioning and service		congestion issues and therefore issues requiring traffic
	prioritization.		conditioning and service 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		entities that trust each other within limits, and in which the
	two are seen as trading services for value. Figure 1 shows three		two are seen as trading services for value. Figure 1 shows
	service networks that together provide the connectivity services		three service networks that together provide the connectivity
	that we call "the Internet". They are different administrations		services that we call "the Internet". They are different
	and are very probably in competition, but exchange contracts for		administrations and are very probably in competition, but
	connectivity and capacity that enable them to offer specific		exchange contracts for connectivity and capacity that enable
	services to their customers.		them to offer specific 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
	contractually agree to provision excess capacity at them, as they		providers contractually agree to provision excess capacity at
	commonly do. However, NNI performance may differ by ISP, and the		them, as they commonly do. However, NNI performance may
	performance guarantee interval may range from a month to a much		differ by ISP, and the performance guarantee interval may
	shorter period. Furthermore, a peering point NNI may not have		range from a month to a much shorter period. Furthermore, a
	contractual performance guarantees or may become overloaded under		peering point NNI may not have contractual performance
	certain conditions. They are also policy-controlled interfaces,		guarantees or may become overloaded under certain conditions.
	especially in BGP. As a result, they may require traffic		They are also policy-controlled interfaces, especially in BGP.
	prioritization policy.		As a result, they may require a traffic 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
	used to implement Weighted Fair Queuing, or WFQ) builds a list		(often used to implement Weighted Fair Queuing, or WFQ) builds
	for each time interval and queues at most a stated amount of data		a list for each time interval and queues at most a stated
	in each such list for transmission during that time interval.		amount of data in each such list for transmission during that
	While these differ dramatically in implementation, the external		time interval. While these differ dramatically in
	difference in behavior is generally negligible when they are		implementation, the external difference in behavior is
	properly configured. Consistent with the definitions used in the		generally negligible when they are properly configured.
	Differentiated Services Architecture [RFC2475], these are treated		Consistent with the definitions used in the Differentiated
	as equivalent in this document, and the lists of WRR and the		Services Architecture [RFC2475], these are treated as
	classes of a calendar queue will be referred to uniformly as		equivalent in this document, and the lists of WRR and the
	"queues".		classes of a calendar queue will be referred to uniformly as
			"queues".
	_.--------.		_.--------.
	,-'' `--.		,-'' `--.
	,-' `-.		,-' `-.
	,-------. ,',-------. `.		,-------. ,',-------. `.
	,' `. ,',' `. `.		,' `. ,',' `. `.
	/ User \ UNI / / Service \ \		/ User \ UNI / / Service \ \
	( Network +-----+ Network ) `.		( Network +-----+ Network ) `.
	\ / ; \ / :		\ / ; \ / :
	`. ,' ; `. .+ :		`. ,' ; `. .+ :
	skipping to change at page 6, line 35		skipping to change at page 6, line 38
	,' `. : ,' `+ ;		,' `. : ,' `+ ;
	/ User \ UNI / Service \ ;		/ User \ UNI / Service \ ;
	( Network +-----+ Network ) ,'		( Network +-----+ Network ) ,'
	\ / \ \ / /		\ / \ \ / /
	`. ,' `.`. ,' ,'		`. ,' `.`. ,' ,'
	'-------' `.'-------' ,'		'-------' `.'-------' ,'
	`-. ,-'		`-. ,-'
	`--. _.-'		`--. _.-'
	`--------''		`--------''
	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],
	the use of capacity admission in implementing the service, but		permits the use of capacity admission in implementing the service,
	present implementations either provide no capacity admission		but present implementations either provide no capacity admission
	services or do so in a manner that depends on specific traffic		services or do so in a manner that depends on specific traffic
	engineering. In the context of the Internet backbone, the two are		engineering. In the context of the Internet backbone, the two are
	essentially equivalent; the edge network depends on specific		essentially equivalent; the edge network depends on specific
	engineering by the service provider that might not be present,		engineering by the service provider that might not be present,
	especially in a mobile 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 RFC [RFC4190] or in Section 2.6 of
			[RFC4504].
	This requires the use of capacity admission to differentiate among		This requires the use of capacity admission to differentiate among
	users to provide services to them that are not afforded to		users to provide services to them that are not afforded to non-
	non-capacity admitted customer-to-customer IP telephony sessions.		capacity admitted customer-to-customer IP telephony sessions.
	2. Candidate Implementations of the Admitted Telephony Service Class		2. Candidate Implementations of the Admitted Telephony Service Class
	2.1. Potential implementations of EF in this model		2.1. Potential Implementations of EF in This Model
	There are at least two possible ways to implement isolation between		There are at least two possible ways to implement isolation between
	the Capacity Admitted PHB and the Expedited Forwarding PHB in this		the Capacity Admitted PHB and the Expedited Forwarding PHB in this
	model. They are to implement separate classes as a set of		model. They are to implement separate classes as a set of
	o Multiple data plane traffic classes, each consisting of a policer		o Multiple data plane traffic classes, each consisting of a policer
	and a queue, and the queues enjoying different priorities, or		and a queue, with the queues enjoying different priorities, or
	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 more than one queue, traffic from one		queue. If data is present in more than one queue, traffic from one
	of them will always be selected for transmission. This has the		of them will always be selected for transmission. This has the
	effect of transferring jitter from the higher priority queue to the		effect of transferring jitter from the higher-priority queue to the
	lower priority queues, and reordering traffic in a way that gives		lower-priority queues, and reordering traffic in a way that gives the
	the higher priority traffic a smaller average queuing delay. Each		higher-priority traffic a smaller average queuing delay. Each queue
	queue must have its own policer, however, to protect the network		must have its own policer, however, to protect the network from
	from errors and attacks; if a traffic class thinks it is carrying a		errors and attacks; if a traffic class thinks it is carrying a
	certain data rate but an abuse sends significantly more, the effect		certain data rate but an abuse sends significantly more, the effect
	of simple prioritization would not preserve the lower priorities of		of simple prioritization would not preserve the lower priorities of
	traffic, which could cause routing to fail or otherwise impact an		traffic, which could cause routing to fail or otherwise impact a
	SLA.		service level agreement (SLA).
	.		.
	policers priorities |`.		policers priorities |`.
	Admitted EF <=> ----------||----+ `.		Admitted EF <=> ----------||----+ `.
	high| `.		high| `.
	Unadmitted 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,		The multi-policer model is shown in Figure 3. In this model, traffic
	traffic from each service class is policed according to its SLA		from each service class is policed according to its SLA requirements,
	requirements, and then placed into a common priority queue. Unlike		and then placed into a common priority queue. Unlike the multi-
	the multi-priority model, the jitter experienced by the traffic		priority model, the jitter experienced by the traffic classes in this
	classes in this case is the same, as there is only one queue, but		case is the same, as there is only one queue, but the sum of the
	the sum of the traffic in this higher priority queue experiences		traffic in this higher-priority queue experiences less average jitter
	less average jitter than the elastic traffic in the lower priority.		than the elastic traffic in the lower-priority.
	policers priorities .		policers priorities .
	Admitted EF <=> -------\ |`.		Admitted EF <=> -------\ |`.
	--||----+ `.		--||----+ `.
	Unadmitted 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 containing 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,		are relatively small, on the order of only 40 to 200 bytes, depending
	depending on the codec. On lower speed links (less than 10 MBPS),		on the codec. On lower-speed links (less than 10 MBPS), the jitter
	the jitter introduced by video to voice can be disruptive, while at		introduced by video to voice can be disruptive, while at higher
	higher speeds the jitter is nominal compared to the jitter		speeds, the jitter is nominal compared to the jitter requirements of
	requirements of voice. At access network speeds, therefore,		voice. Therefore, at access network speeds, [RFC4594] recommends the
	[RFC4594] recommends separation of video and voice into separate		separation of video and voice into separate queues, while at optical
	queues, while at optical speeds [RFC5127] recommends that they use a		speeds, [RFC5127] recommends that they use a common queue.
	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
	has been proposed to be done for real-time applications. Each will		has been proposed to be done for real-time applications. Each will
	be described below, then Section 3 will judge which ones are likely		be described below, and Section 3 will judge which ones are likely to
	to meet the requirements of the Admitted Telephony service class.		meet the requirements of the Admitted Telephony service class. These
	These include:		include:
	o Drop Precedence used to force sessions to voluntarily exit,		o Drop Precedence used to force sessions to voluntarily exit,
	o Capacity admission control by assumption or engineering,		o Capacity admission control by assumption or engineering,
	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 Endpoint 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.		Resource Reservation Protocol (RSVP) or Next Steps in Signaling
			(NSIS).
	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. There is also a behavioral issue		seriously affect call quality. There is also a behavioral issue
	involved here, in which users who experience poor quality calls tend		involved here, in which users who experience poor quality calls tend
	to hang up and call again, making the problem better - then worse.		to hang up and call again, making the problem better -- then worse.
	The problem with capacity admission by assumption, which is widely		The problem with capacity admission by assumption, which is widely
	deployed in today's VoIP environment, is that it depends on the		deployed in today's VoIP environment, is that it depends on the
	assumptions made. One can do careful traffic engineering to ensure		assumptions made. One can do careful traffic engineering to ensure
	needed bandwidth, but this can also be painful, and has to be		needed bandwidth, but this can also be painful, and has to be
	revisited when the network is changed or network usage changes.		revisited when the network is changed or network usage changes.
	The problem with call counting based admission control is it gets		The problem with call-counting-based admission control is that it
	exponentially worse the farther you get from the control point		gets exponentially worse the farther you get from the control point
	(e.g., it lacks sufficient scalability out into the network).		(e.g., it lacks sufficient scalability on the outskirts of 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 (e.g., 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 cannot 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 capacity controls via a bandwidth broker is		The problem with capacity controls via a bandwidth broker is that
	centralized servers lack far away awareness, and also lack effective		centralized servers lack far away awareness, and also lack effective
	real-time reaction to dynamic changes in all part of the network		real-time reaction to dynamic changes in all parts of the network at
	at all instances of time.		all instances of time.
	The problem with mechanisms that do not enable the association of a		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		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 A user is identified and the correct policy is applied if multiple
	identified and the correct policy applied.		policies are in use in a network.
	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		2.3. Recommendations on Implementation of an Admitted Telephony
	Service Class		Service Class
	When coupled with adequate AAA and capacity admission procedures as		When coupled with adequate Authentication, Authorization, and
	described in Section 2.2, either of the two PHB implementations		Accounting (AAA) and capacity admission procedures as described in
	described in Section 2.1 is sufficient to provide the services		Section 2.2, either of the two PHB implementations described in
	required for an Admitted Telephony service class. If preemption is		Section 2.1 is sufficient to provide the services required for an
	required, as described in section 2.3.5.2 of [RFC4542], this		Admitted Telephony service class. If preemption is required, Section
	provides the tools for carrying out the preemption. If preemption is		2.3.5.2 of [RFC4542] provides the tools for carrying out the
	not in view, or if used in addition to preemptive services, the		preemption. If preemption is not in view, or if used in addition to
	application of different thresholds depending on call precedence has		preemptive services, the application of different thresholds
	the effect of improving the probability of call completion by		depending on call precedence has the effect of improving the
	admitting preferred calls at a time that other calls are being		probability of call completion by admitting preferred calls at a time
	refused. Routine and priority traffic can be admitted using the		when other calls are being refused. Routine and priority traffic can
	same DSCP value, as the choice of which calls are admitted is		be admitted using the same DSCP value, as the choice of which calls
	handled in the admission procedure executed in the control plane,		are admitted is handled in the admission procedure executed in the
	not the policing of the data plane.		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 exist at this time for bandwidth brokers,		clear standards do not exist at this time for bandwidth brokers, NSIS
	NSIS has not been finalized at this time and in any event is limited		has not been finalized at this time and in any event is limited to
	to unicast sessions, and that RSVP has been standardized and has the		unicast sessions, and that RSVP has been standardized and has the
	relevant services. We therefore RECOMMEND the use of a protocol,		relevant services. We therefore RECOMMEND the use of a protocol,
	such as RSVP, at the UNI. Procedures at the NNI are business		such as RSVP, at the UNI. Procedures at the NNI are business matters
	matters to be discussed between the relevant networks, and are		to be discussed between the relevant networks, and are RECOMMENDED
	I RECOMMENDED but NOT REQUIRED.		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
	admission that only estimates capacity, and that through static		application layer admission that only estimates
	engineering. In addition to that class, a separate Admitted		capacity, and does that through static engineering.
	Telephony Class is added which performs capacity admission		In addition to that class, a separate Admitted
	dynamically.		Telephony Class is added that performs capacity
			admission 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,
	class when used for video on demand, and the Multimedia		Broadcast TV class when used for video on demand,
	Conferencing class.		and the Multimedia Conferencing class.
	4. IANA Considerations		4. IANA Considerations
	This note requests that IANA assign a DSCP value to a second EF		IANA assigned a DSCP value to a second EF traffic class consistent
	traffic class consistent with [RFC3246] and [RFC3247] in the		with [RFC3246] and [RFC3247] in the "Differentiated Services Field
	"Differentiated Services Field Codepoints" registry. It implements		Codepoints" registry. It implements the Telephony Service Class
	the Telephony Service Class described in [RFC4594] at lower speeds		described in [RFC4594] at lower speeds and is included in the Real-
	and is included in the Real Time Treatment Aggregate [RFC5127] at		Time Treatment Aggregate [RFC5127] at higher speeds. The code point
	higher speeds. The recommended code point value should be from pool		value should be from pool 1 within the dscp-registry. The value is
	1 within the dscp-registry. This document RECOMMENDS retaining a		parallel with the existing EF code point (101110), as IANA assigned
	parallel with the existing EF code point (101110) by assigning a		the code point 101100 -- keeping the (left-to-right) first 4 binary
	value for the code point of 101100 -- keeping the (left to right)		values the same in both. The code point described in this document
	first 4 binary values the same in both. The code point described		is referred to as VOICE-ADMIT and has been registered as follows:
	within this document should be referred to as VOICE-ADMIT. Here is
	the recommended addition to the Pool 1 Codepoint registry:
	Sub-registry: Pool 1 Codepoints		Sub-registry: Pool 1 Codepoints
	Reference: [RFC2474]		Reference: [RFC2474]
	Registration Procedures: Standards Action		Registration Procedures: Standards Action
	Registry:		Registry:
	Name Space Reference		Name Space Reference
	--------- ------- ---------		--------- ------- ---------
	VOICE-ADMIT 101100 [this document]		VOICE-ADMIT 101100 [RFC5865]
	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		Interface (UNI); the use of such services at the NNI is at the option
	option of the interconnected networks.		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 as
	either as an individual or as a member of some corporate entity, and		either an individual or a member of some corporate entity, and assert
	assert a policy such as "normal", "routine" or some level of		a policy such as "normal", "routine", or some level of "priority".
	"priority".
	This capability, one has to believe, will be abused by script		This capability, one has to believe, will be abused by script kiddies
	kiddies and others if the proof of identity is not adequately strong		and others if the proof of identity is not adequately strong or if
	or if policies are written or implemented improperly by the		policies are written or implemented improperly by the carriers. This
	carriers. This goes without saying, but this section is here for it		goes without saying, but this section is here for it to be said.
	to be said...
	Much of the security considerations from RFC 3246 [RFC3246] applies		Many of the security considerations from RFC 3246 [RFC3246] apply to
	to this document, as well as the security considerations in RFC		this document, as well as the security considerations in RFC 2474 and
	2474 and RFC 4542. RFC 4230 [RFC4230] analyzes RSVP, providing some		RFC 4542. RFC 4230 [RFC4230] analyzes RSVP, providing some gap
	gap analysis to the NSIS WG as they started their work. Keep in mind		analysis to the NSIS WG as they started their work. Keep in mind
	that this document is advocating RSVP at the UNI only, while RFC		that this document is advocating RSVP at the UNI only, while RFC 4230
	4230 discusses (mostly) RSVP from a more complete point of view		discusses (mostly) RSVP from a more complete point of view (i.e., e2e
	(i.e., e2e and edge2edge). When considering the RSVP aspect of this		and edge2edge). When considering the RSVP aspect of this document,
	document, understanding Section 6 of RFC 4230 is a good source of		understanding Section 6 of RFC 4230 is a good source of information.
	information.
	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
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474, December
	December 1998.		1998.
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
	J., Courtney, W., Davari, S., Firoiu, V., and D.		J., Courtney, W., Davari, S., Firoiu, V., and D.
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		Stiliadis, "An Expedited Forwarding PHB (Per-Hop
	Behavior)", RFC 3246, March 2002.		Behavior)", RFC 3246, March 2002.
	7.2. Informative References		7.2. Informative References
	[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,		[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
	and W. Weiss, "An Architecture for Differentiated		and W. Weiss, "An Architecture for Differentiated
	Services", RFC 2475, December 1998.		Service", RFC 2475, December 1998.
	[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,		[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
	Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.		Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
	Ramakrishnan, "Supplemental Information for the New		Ramakrishnan, "Supplemental Information for the New
	Definition of the EF PHB (Expedited Forwarding Per-Hop		Definition of the EF PHB (Expedited Forwarding Per-Hop
	Behavior)", RFC 3247, March 2002.		Behavior)", RFC 3247, March 2002.
	[RFC3260] Grossman, D., "New Terminology and Clarifications for		[RFC3260] Grossman, D., "New Terminology and Clarifications for
	Diffserv", RFC 3260, April 2002.		Diffserv", RFC 3260, April 2002.
	[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., Ed., Lass, S., and C. Stredicke, "SIP
	Device Requirements and Configuration", RFC 4504,		Telephony Device Requirements and Configuration", RFC
	May 2006.		4504, 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		Telecommunications Service (ETS) for Real-Time Services in
	in the Internet Protocol Suite", RFC 4542, May 2006.		the Internet Protocol Suite", RFC 4542, May 2006.
	[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration		[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
	Guidelines for DiffServ Service Classes", RFC 4594,		Guidelines for DiffServ Service Classes", RFC 4594, August
	August 2006.		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.
	[RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties",		[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
	RFC4230, December 2005		Properties", RFC 4230, December 2005.
	Authors' Addresses		Authors' Addresses
	Fred Baker		Fred Baker
	Cisco Systems		Cisco Systems
	Santa Barbara, California 93117		Santa Barbara, California 93117
	USA		USA
	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
End of changes. 87 change blocks.
	307 lines changed or deleted		288 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/