draft-ietf-tsvwg-admitted-realtime-dscp-04.txt		draft-ietf-tsvwg-admitted-realtime-dscp-05.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: August 28, 2008 February 25, 2008		Expires: May 5, 2009 November 1, 2008
	DSCPs for Capacity-Admitted Traffic		DSCP for Capacity-Admitted Traffic
	draft-ietf-tsvwg-admitted-realtime-dscp-04		draft-ietf-tsvwg-admitted-realtime-dscp-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		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.		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
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		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 August 28, 2008.		This Internet-Draft will expire on May 5, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	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 real-time		from the Internet Assigned Numbers Authority (IANA) for real-time
	traffic classes similar to voice conforming to the Expedited		traffic classes similar to voice conforming to the Expedited
	Forwarding Per Hop Behavior, and admitted using a call admission		Forwarding Per Hop Behavior, and admitted using a call admission
	procedure involving authentication, authorization, and capacity		procedure involving authentication, authorization, and capacity
	admission.		admission.
	It also recommends that certain classes of video traffic described in		This document also recommends that certain classes of video traffic
	RFC 4594 and which have similar requirements be changed to require		described in RFC 4594 and which have similar requirements be changed
	admission using a Call Admission Control (CAC) procedure involving		to require admission using a Call Admission Control (CAC) procedure
	authentication, authorization, and capacity admission.		involving authentication, authorization, and capacity admission.
	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
	1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 7		2. Candidate Implementations of the Admitted Telephony
	2. Implementation of the Admitted Service Classes . . . . . . . . 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.2.1. Capacity admission control by assumption . . . . . . . 10		2.3. Recommendations on implementation of an Admitted
	2.2.2. Capacity admission control by call counting . . . . . 10		Telephony Service Class . . . . . . . . . . . . . . . . . 10
	2.2.3. End-point capacity admission performed by probing		3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . . 11
	the network . . . . . . . . . . . . . . . . . . . . . 11		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	2.2.4. Centralized capacity admission control . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	2.2.5. Distributed capacity admission control . . . . . . . . 12		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	2.3. Prioritized capacity admission control . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3. Recommendations on implementation of an Admitted Telephony		7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	Service Class . . . . . . . . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . . 12
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	7.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 19
	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 to
	the Expedited Forwarding Per Hop Behavior but not subject to capacity		the Expedited Forwarding Per Hop Behavior but not subject to capacity
	admission or subject to very coarse capacity admission.		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 video distribution/conferencing bridge or gaming server		between the endpoints. Reserving capacity for them is important to
	and the user(s), and 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
	behavior and low jitter/loss tolerance are the service		behavior and low jitter/loss tolerance are the service
	characteristics that define the need for admission control behavior.		characteristics that define the need for admission control behavior.
	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
	skipping to change at page 3, line 45		skipping to change at page 3, line 44
	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 special-policy
	traffic and other classes, particularly the existing VoIP services		traffic and other classes, particularly the existing VoIP services
	that perform no capacity admission or only very coarse capacity		that perform no capacity admission or only very coarse capacity
	admission and can exceed their allocated resources.		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]. The video classes addressed include the		in [RFC4594].
	o interactive real-time traffic (CS4, used for Video conferencing		Since video classes have not had the history of mixing admitted and
			non-admitted traffic in the same Per-Hop Behavior (PHB) as has
			occurred for EF, an additional DSCP code point is not recommended.
			Instead, the recommended "best practice" is to perform admission
			control for all traffic in three of [RFC4594]'s video classes: the
			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).
	Since the admitted video classes have not had the history of mixing		o AF4 Multimedia Conferencing (video conferencing).
	admitted and non-admitted traffic in the same Per-Hop Behavior (PHB)
	as has occurred for EF, an additional DSCP code point is not
	recommended. Instead, the recommended "best practice" is to perform
	admission control for the above video classes.
	Other video classes are not believed to be required by the targeted		Other video classes are believed to not have the current problem of
	services and to not have the current problem of confusion with		confusion with unadmitted traffic and therefore would not benefit
	unadmitted traffic. Within an ISP and on inter-ISP links (i.e.		from the notion of a separate DSCP for admitted traffic. Within an
	within networks whose internal paths are uniform at hundreds of		ISP and on inter-ISP links (i.e. within networks whose internal paths
	megabits or faster), one would expect all of this traffic to be		are uniform at hundreds of megabits or faster), one would expect all
	carried in the Real Time Traffic Class described in [RFC5127].		of this traffic to be carried in the Real Time Traffic 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 compliant
	node to a DS behavior aggregate [RFC2475]. It may be thought of		node to a DS behavior aggregate [RFC2475]. It may be thought of
	as a program configured on the interface of an Internet host or		as a program configured on the interface of an Internet host or
	router, specified drop probabilities, queuing priorities or rates,		router, specified drop probabilities, queuing priorities or rates,
	and other handling characteristics for the traffic class.		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 experienced
	by each packet it forwards [RFC3260]. It is a 6-bit number		by each packet it forwards [RFC3260]. It is a 6-bit number
	embedded into the 8-bit TOS field of an IPv4 datagram or the		embedded into the 8-bit TOS field of an IPv4 datagram or the
	Traffic Class field of an IPv6 datagram.		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" includes and procedure		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. "Capacity Admission" refers to any procedure		use the service under the relevant policy. "Capacity Admission"
	that determines whether capacity exists supporting a session's		refers to any procedure that determines whether capacity exists
	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 user)
	purchases connectivity services from the other (the network).		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 each
	skipping to change at page 6, line 44		skipping to change at page 6, line 44
	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 services
	or do so in a manner that depends on specific traffic engineering.		or do so in a manner that depends on specific traffic engineering.
	In the context of the Internet backbone, the two are essentially		In the context of the Internet backbone, the two are essentially
	equivalent; the edge network is depending on specific engineering by		equivalent; the edge network depends on specific engineering by the
	the service provider that may not be present.		service provider that may not be present, 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-on-IP or Video-on-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
	with special credentials) to provide services to them that are not		with special credentials) to provide services to them that are not
	afforded to non-capacity admitted customer-to-customer IP telephony		afforded to non-capacity admitted customer-to-customer IP telephony
	sessions.		sessions.
	1.3. Proposed Solution		2. Candidate Implementations of the Admitted Telephony Service Class
	The IETF is asked to differentiate, in the Telephony Service, between
	sessions that are originated without capacity admission or using
	traffic engineering and sessions that are originated using more
	robust capacity admission procedures. Sessions of the first type use
	a traffic class in which they compete without network-originated
	control as described in Section 2.2.1 or Section 2.2.2, and in the
	worst case lose traffic due to policing. Sessions of the second type
	cooperate with network control, and may be given different levels of
	preference depending on the policies that the network applies. In
	order to provide this differentiation, the IETF requests that the
	IANA assign a separate DSCP value to admitted sessions using the
	Telephony service (see Section 4 ).
	2. Implementation of the Admitted Service Classes
	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 the Expedited		There are at least two possible ways to implement isolation between
	Forwarding PHB in this model. They are to implement separate classes		the Capacity Admitted PHB and the Expedited Forwarding PHB in this
	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, and 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, including a widely reported test for NS/EP		confusion in the industry.
	services that implemented the policing model and described it as an
	implementation of the multi-priority model, and discussion in other
	environments of the intermixing of voice and video traffic at
	relatively low bandwidths in the policing model.
	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 both queues, traffic from one of them
	will always be selected for transmission. This has the effect of		will always be selected for transmission. This has the effect of
	transferring jitter from the higher priority queue to the lower		transferring jitter from the higher priority queue to the lower
	priority queue, and reordering traffic in a way that gives the higher		priority queue, and reordering traffic in a way that gives the higher
	priority traffic a smaller average queuing delay. Each queue must		priority traffic a smaller average queuing delay. Each queue must
	have its own policer, however, to protect the network from errors and		have its own policer, however, to protect the network from errors and
	attacks; if a traffic class thinks it is carrying a certain data rate		attacks; if a traffic class thinks it is carrying a certain data rate
	but an abuse sends significantly more, the effect of simple		but an abuse sends significantly more, the effect of simple
	prioritization would not preserve the lower priorities of traffic,		prioritization would not preserve the lower priorities of traffic,
	which could cause routing to fail or otherwise impact an SLA.		which could cause routing to fail or otherwise impact an SLA.
	.		.
	policers priorities |`.		policers priorities |`.
	EF ---------> <=> ----------||----+ `.		Unadmitted EF <=> ----------||----+ `.
	high| `.		high| `.
	EF2---------> <=> ----------||----+ .'-----------		Admitted 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, traffic
	from each service class is policed according to its SLA requirements,		from each service class is policed according to its SLA requirements,
	and then placed into a common priority queue. Unlike the multi-		and then placed into a common priority queue. Unlike the multi-
	priority model, the jitter experienced by the traffic classes in this		priority model, the jitter experienced by the traffic classes in this
	case is the same, as there is only one queue, but the sum of the		case is the same, as there is only one queue, but the sum of the
	traffic in this higher priority queue experiences less average jitter		traffic in this higher priority queue experiences less average jitter
	than the elastic traffic in the lower priority.		than the elastic traffic in the lower priority.
	policers priorities .		policers priorities .
	EF ---------> <=> -------\ |`.		Unadmitted EF <=> -------\ |`.
	--||----+ `.		--||----+ `.
	EF2---------> <=> -------/ high| `.		Admitted 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
	skipping to change at page 9, line 4		skipping to change at page 8, line 43
	. | .'--------		. | .'--------
	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 are relatively large (generally the		datagrams conaining video data can be relatively large (often of
	size of the path MTU) while datagrams containing voice are relatively		variable sizes up to the path MTU) while datagrams containing voice
	small, on the order of only 40 to 200 bytes, depending on the codec.		are relatively small, on the order of only 40 to 200 bytes, depending
	On lower speed links (less than 10 MBPS), the jitter introduced by		on the codec. On lower speed links (less than 10 MBPS), the jitter
	video to voice can be disruptive, while at higher speeds the jitter		introduced by video to voice can be disruptive, while at higher
	is nominal compared to the jitter requirements of voice. At access		speeds the jitter is nominal compared to the jitter requirements of
	network speeds, therefore, [RFC4594] recommends separation of video		voice. At access network speeds, therefore, [RFC4594] recommends
	and voice into separate queues, while at optical speeds [RFC5127]		separation of video and voice into separate queues, while at optical
	recommends that they use a common queue.		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 five major ways that capacity admission is done or has been		There are at least six major ways that capacity admission is done or
	proposed to be done in real-time applications:		has been proposed to be done for real-time applications. Each will
			be described below, then Section 3 will judge which ones are likely
			to meet the requirements of the Admitted Telephony service class.
			These include:
	o Capacity admission control by assumption,		o Drop Precedence used to force sessions to voluntarily exit,
			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 End-point capacity admission performed by probing the network,
	o Centralized capacity admission control, and		o Centralized capacity admission control via bandwidth broker, and
	o Distributed capacity admission control.
	There is also a mechanism that has been proposed for enhancing the
	probability of call completion in a preferential manner. This is not
	capacity admission per se, since it never actually refuses a call
	(although a session may be dropped by its user when the user finds
	continuation untenable). The central notion is that when the
	capacity available for a set of variable rate sessions has been
	overbooked, traffic may be randomly dropped from lower precedence
	sessions to allow a higher precedence session in. This has a number
	of ramifications that make it inappropriate in the Internet. A key
	issue is that it affects not a single session but a class of sessions
	- all sessions of lower precedence than the protected session(s). A
	video example will suffice for the present. Multimedia data streams
	and sensor traffic often build on information in previous frames, and
	their content spans multiple datagrams in the same frame. The loss
	of a datagram forces the codec into a recovery mode that reduces
	image quality for at least one frame, and may cause the image to
	freeze for multiple seconds. This is readily observed on television,
	where screen artifacts are very visible. Scattered random datagram
	loss results in all sessions in the class being impacted to some
	degree. Hence, it is far more suitable to drop an entire session
	(and therefore impact only one session) than to impact all sessions
	in a class in a manner that consumes the available bandwidth but
	delivers sub-SLA service to an entire class of sessions. It also
	exposes the precedence level of each session in the clear.
	2.2.1. Capacity admission control by assumption
	The first approach is to ignore the matter entirely. If one assumes
	that the capacity available to the application is uniformly far in
	excess of its requirements, it is perhaps overhead that can be
	ignored. This assumption is currently made in Internet VoIP
	offerings such as Skype and Vonage; the end user is responsible to
	place his service on a LAN connected to the Internet backbone by a
	high speed broadband connection and use capable ISPs to deliver the
	service. The only "authorization" verified is that the user pays his
	bills; no capacity admission is considered because there is a clear
	separation from the application service provider admitting the calls
	and the access network provider admitting the traffic. The two have
	no way of knowing about each other, except in the abstract sense.
	2.2.2. Capacity admission control by call counting
	The H.323 gatekeeper, originally specified in 1996, operates on the
	model that the considerations of Section 2.2.1 generally apply, and
	that it is therefore sufficient to count calls in order to ensure
	that any bottlenecks in the network are never overloaded. Which
	phone is calling which phone is configured information into the
	Gatekeeper, ensuring it doesn't admit too many calls across a low
	speed link. The area of influence of a Gatekeeper is called a Zone,
	and limits how far away a Gatekeeper can influence calls. This is
	because call counting doesn't scale when more than one server is
	admitting flows across the same limited speed links. This approach
	is consistent with the original design of H.323, which in 1996 was a
	mechanism for connecting H.320 media gateways across a LAN. VoIP has
	come a long way since then, however, and the engineering trade-offs
	this approach requires in complex networks are unsatisfactory.
	SIP provides the option to go down another path, to admit its servers
	at layer 7, have no awareness of lower layer connectivity, resulting
	in a divorce from infrastructure knowledge - save for [RFC3312],
	which binds the two, but only at the endpoints.
	In short, if there is a bottleneck anywhere in the network that might
	be used to connect two gatekeepers, SIP proxies that do not implement
	or do not configure the use of [RFC3312], or other call management
	systems, the amount of traffic between the two must be contained
	below that bottleneck even if the normal path is of much higher
	bandwidth. In addition, the multiplexing of traffic streams between
	different pairs of gatekeepers over a common LAN infrastructure is
	not handled by the application, and so must be managed in the
	engineering of the network.
	2.2.3. End-point capacity admission performed by probing the network
	The IETF started looking into the use of Pre-Congestion Notification
	mechanism to full fill the need of admission control for real-time
	traffic. The main contribution of this work for admission control is
	to allow the network to provide the network's pre-congestion
	information using encoding of a field in the IP header. This network
	pre-congestion information is then used for making admission control
	decisions. With the decision influenced by this network pre-
	congestion notification information and any applicable policy
	information with possible user credentials and situational
	information. The pre-congestion notification mechanism does not
	limit the placement of the admission control decision point or the
	signaling protocol used.
	The overview of one of the current proposals is provided by
	[I-D.chan-pcn-problem-statement]. With the pre-congestion
	notification encoding described in [I-D.briscoe-tsvwg-cl-phb]. An
	initial deployment model provided by
	[I-D.briscoe-tsvwg-cl-architecture]. Another proposal is embodied in
	[I-D.charny-pcn-single-marking]. Similar approaches have been
	proposed in [I-D.morita-tsvwg-pps] and its related drafts, by Ivars
	and Karlsson in their PBAC work, and many others.
	2.2.4. Centralized capacity admission control
	The concept of a Bandwidth Broker was first discussed in the research
	world surrounding ESNET and Internet II in the late 1990's, and has
	been discussed in the literature pertaining to the Differentiated
	Services Architecture [RFC2475]. It is, in short, a central system
	that performs a variety of services on behalf of clients of a network
	including applying AAA services (as in [RFC2904] ) and authorizing
	them to use specified capacity at specified times. Its strength is
	that it is relatively simple, at least in concept, and can keep track
	of simple book-keeping functions apart from network elements such as
	routers. Its weakness is that it has no idea what the specific
	routing of any stated data flow is, or its capacity apart from
	services such as MPLS Traffic Engineering or engineering assumptions
	specified by the designers of a network. Obtaining that information
	from the network via SNMP GET or other network management action can
	impose a severe network overhead, and is obviously not real-time.
	For scaling reasons, operational Bandwidth Brokers generally take on
	a semi-distributed or fully distributed nature. They are implemented
	on a per-point-of-presence basis, and in satellite networks might be
	implemented in each terminal. At this point, they become difficult
	to operationally distinguish from distributed capacity admission
	services such as described in Section 2.2.5.
	2.2.5. Distributed capacity admission control
	The IETF developed the Integrated Services Model [RFC1633] and the
	RSVP capacity admission protocol [RFC2205] in the early 1990's, and
	then integrated it with the Differentiated Services Architecture in
	[RFC2998]. Since then, the IETF has been working on a next
	generation signaling protocol called NSIS [RFC4080] that can be used
	for capacity admission protocol, and which is limited in scope to
	considering unicast sessions. [RFC4542] looked at the issue of
	providing preferential services in the Internet, and determined that
	RSVP with its defined extensions could provide those services to
	unicast and multicast sessions.
	As with the Bandwidth Broker model, there are concerns regarding		o Distributed capacity admission control using protocols such as
	scaling, mentioned in [RFC2208]. Present implementations that have		RSVP or NSIS.
	been measured have been found to not display the scaling concerns,
	however, and in any event the use of RSVP Aggregation enables the
	backbone to handle such sessions in a manner similar to an ATM
	Virtual Path, bundling sessions together for capacity management
	purposes.
	2.3. Prioritized capacity admission control		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.
	Emergency Telecommunication Service, the US Department of Defense's		The problem with dropping traffic to force users to hang up is that
	Assured Service, and e-911 each call for some form of prioritization		it affects a broad class of users - if there is capacity for N calls
	of some calls over others. Prioritization of the use of bandwidth is		and the N+1 calls are active, data is dropped randomly from all
	fundamentally a matter of choices - at a point where one has multiple		sessions to ensure that offered load doesn't exceed capacity. On
	choices, applying a policy that selects among them. In the PSTN,		very fast links, that is acceptable, but on lower speed links it can
	GETS operates in favor of an authorized caller either by routing a		seriously affect call quality.
	call that would otherwise be refused by a path unavailable to the
	general public or by queuing the call until some existing call
	completes and bandwidth becomes available. e-911 is similar, but the
	policy is based on the called party, the emergency call center. MLPP
	operates by preempting an existing call to make way for the new one.
	In the Internet, routing is not performed on a per-call basis, so,		There are two fundamental problems with depending on the endpoint to
	apart from interconnections to the PSTN, re-routing isn't an option.		perform capacity admission; it may not be able to accurately measure
			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
			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
			network.
	On the other hand, in the Internet there are more classes of traffic		The problem with mechanisms that don't enable the association of a
	than in the PSTN. In the PSTN, all calls are uses of circuits, while		policy with the request is that they don't allow for multi-policy
	in the Internet some bandwidth is always reserved for elastic		services, which are becoming important.
	applications - at least, it must be available for routing, and there
	is generally significant consideration of the web, instant messaging,
	and other applications. In essence, any capacity admission policy
	that differentiates between calls has the option of temporarily
	borrowing bandwidth from the capacity reserved for elastic traffic by
	accepting new sessions under some prioritized policy while refusing
	sessions of lower priority because the threshold at that priority has
	been reached.
	For example, regardless of the type of capacity admission that is		The operator's choice of admission procedure must, for this DSCP,
	used (apart from "no admission process"), one might admit prioritized		ensure the following:
	sessions using a higher bandwidth threshold than one admits lower
	priority sessions.
	If capacity admission as described in Section 2.2.2 is in use, the		o The actual links that a session uses have enough bandwidth to
	thresholds must be set low enough that bandwidth would be available		support it.
	anywhere in the network. This greatly limits the utility of such a
	service due to the level of bandwidth waste that results.
	If capacity admission as described in Section 2.2.3 is in use, then		o New sessions are refused admission if there is inadequate
	multiple thresholds must be applied in marking the traffic, multiple		bandwidth under the relevant policy.
	traffic marks must be applied, or there must be multiple ways to
	interpret the result. In any event, this is only applicable in
	domains in which the law of large numbers applies.
	If capacity admission as described in Section 2.2.4 is in use,		o If multiple policies are in use in a network, that the user is
	thresholds can be applied related to a general policy or SLA, or		identified and the correct policy applied.
	related to the network ingress and egress in use. It requires them
	to maintain state regarding network traffic routing separate from the
	network; to the extent that is variable, it requires direct
	monitoring in the OSS.
	If capacity admission as described in Section 2.2.5 is in use,		o Under periods of network stress, the process of admission of new
	thresholds can be applied to the critical points of the path that the		sessions does not disrupt existing sessions, unless the service
	traffic in question actually takes because one is asking the		explicitly allows for disruption of calls.
	equipment that the path traverses.
	3. Recommendations on implementation of an Admitted Telephony Service		2.3. Recommendations on implementation of an Admitted Telephony Service
	Class		Class
	It is the belief of the authors that either data plane PHB described		It is the belief of the authors that either PHB implementation
	in Section 2.1, if coupled with adequate AAA and capacity admission		described in Section 2.1, if coupled with adequate AAA and capacity
	procedures as described in Section 2.2.5, are sufficient to provide		admission procedures as described in Section 2.2, are sufficient to
	the services required for an Admitted Telephony service class and an		provide the services required for an Admitted Telephony service
	Admitted Multimedia Conferencing Service Class. If preemption is		class. If preemption is required, as described in section 2.3.5.2 of
	required, as described in section 2.3.5.2 of [RFC4542], this provides		[RFC4542], this provides the tools for carrying out the preemption.
	the tools for carrying out the preemption. If preemption is not in		If preemption is not in view, or if used in addition to preemptive
	view, or in addition to preemptive services, the application of		services, the application of different thresholds depending on call
	different thresholds depending on call precedence has the effect of		precedence has the effect of improving the probability of call
	improving the probability of call completion by admitting preferred		completion by admitting preferred calls at a time that other calls
	calls at a time that other calls are being refused. Routine and		are being refused. Routine and priority traffic can be admitted
	priority traffic can be admitted using the same DSCP value, as the		using the same DSCP value, as the choice of which calls are admitted
	choice of which calls are admitted is handled in the admission		is handled in the admission procedure executed in the control plane,
	procedure executed in the control plane, not the policing of the data		not the policing of the data plane.
	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 at this time exist for bandwidth brokers, NSIS
	has not at this time been finalized and in any event is limited to		has not at this time been finalized and in any event is limited 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 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
			To summarize, there are two changes to [RFC4594] discussed in this
			document:
			Telephony class: The Telephony Service Class in RFC 4594 does not
			involve capacity admission, but depends on application layer
			admission that only estimates capacity, and that through static
			engineering. In addition to that class, a separate Admitted
			Telephony Class is added which performs capacity admission
			dynamically.
			Video classes Capacity admission is added to three video classes.
			These are the Interactive Real-Time Traffic class, Broadcast TV
			class when used for video on demand, and the Multimedia
			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 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 option
	of the interconnected networks.		of the interconnected networks.
	5. Security Considerations		5. Security Considerations
	skipping to change at page 15, line 9		skipping to change at page 12, line 10
	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 kiddies
	and others if the proof of identity is not adequately strong or if		and others if the proof of identity is not adequately strong or if
	policies are written or implemented improperly by the carriers. This		policies are written or implemented improperly by the carriers. This
	goes without saying, but this section is here for it to be said...		goes without saying, but this section is here for it to be said...
	6. Acknowledgements		6. Acknowledgements
	Kwok Ho Chan offered some textual comments and rewrote Section 2.2.3.		Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe
	Georgios Karagiannis offered additional comments on the same section.		commented and offered text. The impetus for including Video in the
	The impetus for including Video in the discussion, which initially		discussion, which initially only targeted voice, is from Dave
	only targeted voice, is from Dave McDysan, and text he suggested was		McDysan,
	included. Dan Voce also commented.
	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 1998.		December 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		[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
			Guidelines for DiffServ Service Classes", RFC 4594,
	[I-D.briscoe-tsvwg-cl-architecture]		August 2006.
	Briscoe, B., "An edge-to-edge Deployment Model for Pre-
	Congestion Notification: Admission Control over a
	DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
	(work in progress), October 2006.
	[I-D.briscoe-tsvwg-cl-phb]
	Briscoe, B., "Pre-Congestion Notification marking",
	draft-briscoe-tsvwg-cl-phb-03 (work in progress),
	October 2006.
	[I-D.chan-pcn-problem-statement]
	Chan, K., "Pre-Congestion Notification Problem Statement",
	draft-chan-pcn-problem-statement-01 (work in progress),
	October 2006.
	[I-D.charny-pcn-single-marking]
	Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-
	Congestion Notification Using Single Marking for Admission
	and Termination", draft-charny-pcn-single-marking-03
	(work in progress), November 2007.
	[I-D.morita-tsvwg-pps]		7.2. Informative References
	Morita, N. and G. Karlsson, "Framework of Priority
	Promotion Scheme", draft-morita-tsvwg-pps-01 (work in
	progress), October 2003.
	[ITU.MLPP.1990]		[ITU.MLPP.1990]
	International Telecommunications Union, "Multilevel		International Telecommunications Union, "Multilevel
	Precedence and Preemption Service", ITU-T Recommendation		Precedence and Preemption Service", ITU-T Recommendation
	I.255.3, 1990.		I.255.3, 1990.
	[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
	Services in the Internet Architecture: an Overview",
	RFC 1633, June 1994.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.
	[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,
	M., Romanow, A., Weinrib, A., and L. Zhang, "Resource
	ReSerVation Protocol (RSVP) Version 1 Applicability
	Statement Some Guidelines on Deployment", RFC 2208,
	September 1997.
	[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.		Services", RFC 2475, December 1998.
	[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
	Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
	D. Spence, "AAA Authorization Framework", RFC 2904,
	August 2000.
	[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
	Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
	Felstaine, "A Framework for Integrated Services Operation
	over Diffserv Networks", RFC 2998, November 2000.
	[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.
	[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
	"Integration of Resource Management and Session Initiation
	Protocol (SIP)", RFC 3312, October 2002.
	[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
	Bosch, "Next Steps in Signaling (NSIS): Framework",
	RFC 4080, June 2005.
	[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 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
	Guidelines for DiffServ Service Classes", RFC 4594,
	August 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 19, line 44		skipping to change at line 626
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 51 change blocks.
	372 lines changed or deleted		150 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/