draft-ietf-tsvwg-admitted-realtime-dscp-06.txt		draft-ietf-tsvwg-admitted-realtime-dscp-07.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: June 4, 2010 December 4, 2009		Expires: Sept 8, 2010 March 8, 2010
	DSCP for Capacity-Admitted Traffic		DSCP for Capacity-Admitted Traffic
	draft-ietf-tsvwg-admitted-realtime-dscp-06		draft-ietf-tsvwg-admitted-realtime-dscp-07
	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 a class of
	traffic classes similar to voice conforming to the Expedited		real-time traffic. This class conforms to the Expedited Forwarding
	Forwarding Per Hop Behavior, and admitted using a call admission		Per Hop Behavior. It is also admitted using a CAC procedure
	procedure involving authentication, authorization, and capacity
	admission.
	This document also recommends that certain classes of video traffic
	described in RFC 4594 and which have similar requirements be changed
	to require admission using a Call Admission Control (CAC) procedure
	involving authentication, authorization, and capacity admission.		involving authentication, authorization, and capacity admission.
			This differs from a real-time traffic class conforming to the
			Expedited Forwarding Per Hop Behavior but 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		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with
	the provisions of BCP 78 and BCP 79.		the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 48		skipping to change at page 2, line 6
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 4, 2010.		This Internet-Draft will expire on September 8, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 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 to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	skipping to change at page 2, line 42		skipping to change at page 2, line 49
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Candidate Implementations of the Admitted Telephony		2. Candidate Implementations of the Admitted Telephony
	Service Class . . . . . . . . . . . . . . . . . . . . . . . 7		Service Class . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Potential implementations of EF in this model . . . . . . 7		2.1. Potential implementations of EF in this model . . . . . . 7
	2.2. Capacity admission control . . . . . . . . . . . . . . . 9		2.2. Capacity admission control . . . . . . . . . . . . . . . 8
	2.3. Recommendations on implementation of an Admitted		2.3. Recommendations on implementation of an Admitted
	Telephony Service Class . . . . . . . . . . . . . . . . . 10		Telephony Service Class . . . . . . . . . . . . . . . . . 10
	3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11		3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	skipping to change at page 3, line 19		skipping to change at page 3, line 24
	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		admission. This differs from a real-time traffic class conforming
	to the Expedited Forwarding Per Hop Behavior but not subject to		to the Expedited Forwarding Per Hop Behavior but 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		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		Real-time traffic flows have one or more potential congestion points
	between the endpoints. Reserving capacity for them is important to		between the endpoints. Reserving capacity for these flows is
	application performance. All of these applications have low		important to application performance. All of these applications
	tolerance to jitter (aka delay variation) and loss, as summarized in		have low tolerance to jitter (aka delay variation) and loss, as
	Section 2, and most (except for multimedia conferencing) have		summarized in Section 2, and most (except for multimedia
	inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow		conferencing) have inelastic flow behavior from Figure 1 of
	behavior and low jitter/loss tolerance are the service		[RFC4594]. Inelastic flow behavior and low jitter/loss tolerance
	characteristics that define the need for admission control behavior.		are the service 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. Service providers need to
	Emergency Telecommunication Service, the US Department of Defense's		distinguish between special-policy traffic and other classes,
	Assured Service (which is similar to Multi-Level Precedence and		particularly the existing VoIP services that perform no capacity
	Preemption [ITU.MLPP.1990] procedure), or e-911, in addition to		admission or only very coarse capacity admission and can exceed
	normal routine calls that use call admission. It is possible to use		their allocated resources.
	control plane protocols to generally restrict session admission such
	that admitted traffic should receive the desired service, and the
	policy (e.g. Routine, National Security or Emergency Preparedness
	[NS/EP] communications, e-911, etc) need not be signaled in a DSCP.
	However, service providers need to distinguish between
	special-policy traffic and other classes, particularly the existing
	VoIP services that perform no capacity admission or only 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
	Instead, the recommended "best practice" is to perform admission		within this document for video. Instead, the recommended "best
	control for all traffic in three of [RFC4594]'s video classes: the		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		o Interactive Real-Time Traffic (CS4, used for Video conferencing
	and Interactive gaming),		and Interactive gaming),
	o Broadcast TV (CS3) for use in a video on demand context, and		o Broadcast TV (CS3) for use in a video on demand context, and
	o AF4 Multimedia Conferencing (video conferencing).		o AF4 Multimedia Conferencing (video conferencing).
	Other video classes are believed to not have the current problem of		Other video classes are believed to not have the current problem of
	confusion with unadmitted traffic and therefore would not benefit		confusion with unadmitted traffic and therefore would not benefit
	from the notion of a separate DSCP for admitted traffic. Within an		from the notion of a separate DSCP for admitted traffic. Within an
	ISP and on inter-ISP links (i.e. within networks whose internal		ISP and on inter-ISP links (i.e. within networks whose internal
	paths are uniform at hundreds of megabits or faster), one would		paths are uniform at hundreds of megabits per second or faster), one
	expect all of this traffic to be carried in the Real Time Traffic		would expect all of this traffic to be carried in the Real-Time
	(RTP) Class described in [RFC5127].		Traffic (RTP) Class described in [RFC5127].
	1.1. Definitions		1.1. Definitions
	The following terms and acronyms are used in this document.		The following terms and acronyms are used in this document.
	PHB: A Per-Hop-Behavior (PHB) is the externally observable		PHB: A Per-Hop-Behavior (PHB) is the externally observable
	forwarding behavior applied at a Differentiated Services		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 be
	thought of as a program configured on the interface of an		thought of as a program configured on the interface of an
	Internet host or router, specified drop probabilities, queuing		Internet host or router, specified in terms of drop
	priorities or rates, and other handling characteristics for the		probabilities, queuing priorities or rates, and other handling
	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 which is encoded in the DS field, and which
	each DS Node MUST use to select the PHB which is to be		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		experienced by each packet it forwards [RFC3260]. It is a 6-bit
	number embedded into the 8-bit TOS field of an IPv4 datagram or		number embedded into the 8-bit TOS field of an IPv4 datagram or
	the Traffic Class field of an IPv6 datagram.		the Traffic Class field of an IPv6 datagram.
	CAC: Call Admission Control includes concepts of authorization and		CAC: Call Admission Control includes concepts of authorization and
	capacity admission. "Authorization" refers to any procedure that		capacity admission. "Authorization" refers to any procedure that
	skipping to change at page 6, line 45		skipping to change at page 6, line 45
	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		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 may 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 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 to provide services to them that are not afforded to
	preferential service contracts, or individual users gaining access		non-capacity admitted customer-to-customer IP telephony sessions.
	with special credentials) to provide services to them that are not
	afforded to non-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
	skipping to change at page 7, line 34		skipping to change at page 7, line 31
	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 queue, and reordering traffic in a way that gives the		lower priority queues, and reordering traffic in a way that gives
	higher priority traffic a smaller average queuing delay. Each queue		the higher priority traffic a smaller average queuing delay. Each
	must have its own policer, however, to protect the network from		queue must have its own policer, however, to protect the network
	errors and attacks; if a traffic class thinks it is carrying a		from 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 an
	SLA.		SLA.
	.		.
	policers priorities |`.		policers priorities |`.
	Admitted EF <=> ----------||----+ `.		Admitted EF <=> ----------||----+ `.
	high| `.		high| `.
	Unadmitted EF <=> ----------||----+ .'-----------		Unadmitted EF <=> ----------||----+ .'-----------
	skipping to change at page 10, line 37		skipping to change at page 10, line 24
	o If multiple policies are in use in a network, that the user is		o If multiple policies are in use in a network, that the user is
	identified and the correct policy applied.		identified and the correct policy applied.
	o Under periods of network stress, the process of admission of new		o Under periods of network stress, the process of admission of new
	sessions does not disrupt existing sessions, unless the service		sessions does not disrupt existing sessions, unless the service
	explicitly allows for disruption of calls.		explicitly allows for disruption of calls.
	2.3. Recommendations on implementation of an Admitted Telephony		2.3. Recommendations on implementation of an Admitted Telephony
	Service Class		Service Class
	It is the belief of the authors that either PHB implementation		When coupled with adequate AAA and capacity admission procedures as
	described in Section 2.1, if coupled with adequate AAA and capacity		described in Section 2.2, either of the two PHB implementations
	admission procedures as described in Section 2.2, are sufficient to		described in Section 2.1 is sufficient to provide the services
	provide the services required for an Admitted Telephony service		required for an Admitted Telephony service class. If preemption is
	class. If preemption is required, as described in section 2.3.5.2		required, as described in section 2.3.5.2 of [RFC4542], this
	of [RFC4542], this provides the tools for carrying out the		provides the tools for carrying out the preemption. If preemption is
	preemption. If preemption is not in view, or if used in addition to		not in view, or if used in addition to preemptive services, the
	preemptive services, the application of different thresholds		application of different thresholds depending on call precedence has
	depending on call precedence has the effect of improving the		the effect of improving the probability of call completion by
	probability of call completion by admitting preferred calls at a		admitting preferred calls at a time that other calls are being
	time that other calls are being refused. Routine and priority		refused. Routine and priority traffic can be admitted using the
	traffic can be admitted using the same DSCP value, as the choice of		same DSCP value, as the choice of which calls are admitted is
	which calls are admitted is handled in the admission procedure		handled in the admission procedure executed in the control plane,
	executed in the control plane, not the policing of the data 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 has not been finalized at this time and in any event is limited		NSIS has not been finalized at this time and in any event is limited
	to unicast sessions, and that RSVP has been standardized and has the		to unicast sessions, and that RSVP has been standardized and has the
	relevant services. We therefore recommend the use of RSVP at the		relevant services. We therefore RECOMMEND the use of a protocol,
	UNI. Procedures at the NNI are business matters to be discussed		such as RSVP, at the UNI. Procedures at the NNI are business
	between the relevant networks, and are recommended but not required.		matters to be discussed between the relevant networks, and are
			I RECOMMENDED but NOT REQUIRED.
	3. Summary: changes from RFC 4594		3. Summary: changes from RFC 4594
	To summarize, there are two changes to [RFC4594] discussed in this		To summarize, there are two changes to [RFC4594] discussed in this
	document:		document:
	Telephony class: The Telephony Service Class in RFC 4594 does not		Telephony class: The Telephony Service Class in RFC 4594 does not
	involve capacity admission, but depends on application layer		involve capacity admission, but depends on application layer
	admission that only estimates capacity, and that through static		admission that only estimates capacity, and that through static
	engineering. In addition to that class, a separate Admitted		engineering. In addition to that class, a separate Admitted
	skipping to change at page 11, line 33		skipping to change at page 11, line 22
	class when used for video on demand, and the Multimedia		class when used for video on demand, and the Multimedia
	Conferencing class.		Conferencing class.
	4. IANA Considerations		4. IANA Considerations
	This note requests that IANA assign a DSCP value to a second EF		This note requests that IANA assign a DSCP value to a second EF
	traffic class consistent with [RFC3246] and [RFC3247] in the		traffic class consistent with [RFC3246] and [RFC3247] in the
	"Differentiated Services Field Codepoints" registry. It implements		"Differentiated Services Field Codepoints" registry. It implements
	the Telephony Service Class described in [RFC4594] at lower speeds		the Telephony Service Class described in [RFC4594] at lower speeds
	and is included in the Real Time Treatment Aggregate [RFC5127] at		and is included in the Real Time Treatment Aggregate [RFC5127] at
	higher speeds. The recommended value for the code point is 101100,		higher speeds. The recommended code point value should be from pool
	paralleling the EF code point, which is 101110. The code point		1 within the dscp-registry. This document RECOMMENDS retaining a
	should be referred to as VOICE-ADMIT.		parallel with the existing EF code point (101110) by assigning a
			value for the code point of 101100 -- keeping the (left to right)
			first 4 binary values the same in both. The code point described
			within this document should be referred to as VOICE-ADMIT. Here is
			the recommended addition to the Pool 1 Codepoint registry:
	This traffic class requires the use of capacity admission such as		Sub-registry: Pool 1 Codepoints
	RSVP services together with AAA services at the User/Network		Reference: [RFC2474]
			Registration Procedures: Standards Action
			Registry:
			Name Space Reference
			--------- ------- ---------
			VOICE-ADMIT 101100 [this document]
			This traffic class REQUIRES the use of capacity admission, such as
			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 of the interconnected networks.		option of the interconnected networks.
	5. Security Considerations		5. Security Considerations
	A major requirement of this service is effective use of a signaling		A major requirement of this service is effective use of a signaling
	protocol such as RSVP, with the capabilities to identify its user		Protocol, such as RSVP, with the capabilities to identify its user
	either as an individual or as a member of some corporate entity, and		either as an individual or as a member of some corporate entity, and
	assert a policy such as "routine" or "priority".		assert a policy such as "normal", "routine" or some level of
			"priority".
	This capability, one has to believe, will be abused by script		This capability, one has to believe, will be abused by script
	kiddies and others if the proof of identity is not adequately strong		kiddies and others if the proof of identity is not adequately strong
	or if policies are written or implemented improperly by the		or if policies are written or implemented improperly by the
	carriers. This goes without saying, but this section is here for it		carriers. This 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
			to this document, as well as the security considerations in RFC
			2474 and RFC 4542. RFC 4230 [RFC4230] analyzes RSVP, providing some
			gap 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
			4230 discusses (mostly) RSVP from a more complete point of view
			(i.e., e2e and edge2edge). When considering the RSVP aspect of this
			document, understanding Section 6 of RFC 4230 is a good source of
			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
	skipping to change at page 12, line 30		skipping to change at page 12, line 42
	[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.
	[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
	Guidelines for DiffServ Service Classes", RFC 4594,
	August 2006.
	7.2. Informative References		7.2. Informative References
	[ITU.MLPP.1990]
	International Telecommunications Union, "Multilevel
	Precedence and Preemption Service", ITU-T Recommendation
	I.255.3, 1990.
	[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.
	[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.
	skipping to change at page 13, line 17		skipping to change at page 13, line 20
	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		Telecommunications Service (ETS) for Real-Time Services
	in the Internet Protocol Suite", RFC 4542, May 2006.		in 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.
			[RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties",
			RFC4230, 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
End of changes. 27 change blocks.
	88 lines changed or deleted		110 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/