draft-ietf-tsvwg-diffserv-class-aggr-04.txt		draft-ietf-tsvwg-diffserv-class-aggr-05.txt
	TSVWG K. Chan		TSVWG K. Chan
	Internet-Draft J. Babiarz		Internet-Draft J. Babiarz
	Intended status: Informational Nortel		Intended status: Informational Nortel
	Expires: February 4, 2008 F. Baker		Expires: April 18, 2008 F. Baker
	Cisco Systems		Cisco Systems
	August 3, 2007		October 16, 2007
	Aggregation of DiffServ Service Classes		Aggregation of DiffServ Service Classes
	draft-ietf-tsvwg-diffserv-class-aggr-04		draft-ietf-tsvwg-diffserv-class-aggr-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 February 4, 2008.		This Internet-Draft will expire on April 18, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	In the core of a high capacity network, service differentiation may		In the core of a high capacity network, service differentiation may
	still be needed to support applications' utilization of the network.		still be needed to support applications' utilization of the network.
	Applications with similar traffic characteristics and performance		Applications with similar traffic characteristics and performance
	requirements are mapped into diffserv service classes based on end-		requirements are mapped into diffserv service classes based on end-
	to-end behavior requirements of the applications as indicated by		to-end behavior requirements of the applications. However, some
	Diffserv Service Classes [5]. However, some network segments may be		network segments may be configured in such a way that a single
	configured in such a way that a single forwarding treatment may		forwarding treatment may satisfy the traffic characteristics and
	satisfy the traffic characteristics and performance requirements of		performance requirements of two or more service classes. In these
	two or more service classes. In these cases, it may be desirable to		cases, it may be desirable to aggregate two or more diffserv service
	aggregate two or more Diffserv Service Classes [5] into a single		classes into a single forwarding treatment. This document provides
	forwarding treatment. This document provides guidelines for the		guidelines for the aggregation of diffserv service classes into
	aggregation of Diffserv Service Classes [5] into forwarding		forwarding treatments.
	treatments.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overview of Service Class Aggregation . . . . . . . . . . . . 5		3. Overview of Service Class Aggregation . . . . . . . . . . . . 5
	4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6		4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6
	4.1. Mapping Service Classes into Four Treatment Aggregates . . 7		4.1. Mapping Service Classes into Four Treatment Aggregates . . 7
	4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9		4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9
	skipping to change at page 3, line 10		skipping to change at page 3, line 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	In the core of a high capacity network, it is common for the network		In the core of a high capacity network, it is common for the network
	to be engineered in such a way that a major link, switch, or router		to be engineered in such a way that a major link, switch, or router
	can fail and the result will be a routed network that still meets		can fail and the result will be a routed network that still meets
	ambient SLAs. The implication of this is that there is sufficient		ambient SLAs (Service Level Agreements). The implication of this is
	capacity on any given link such that all SLAs sold can be		that there is sufficient capacity on any given link such that all
	simultaneously supported at their respective maximum rates, and that		SLAs sold can be simultaneously supported at their respective maximum
	this remains true after re-routing (either IP re-routing or MPLS		rates, and that this remains true after re-routing (either IP re-
	protection-mode switching) has occurred.		routing or MPLS (Multi Protocol Label Switching) protection-mode
			switching) has occurred.
	Over-provisioning is generally considered to meet the requirements of		Over-provisioning is generally considered to meet the requirements of
	all traffic without further QoS treatment, and in the general case		all traffic without further QoS treatment, and in the general case
	that is true in high capacity backbones. However, as the process of		that is true in high capacity backbones. However, as the process of
	network convergence continues, and with the increasing speed of the		network convergence continues, and with the increasing speed of the
	access networks, certain services may still have issues. Delay,		access networks, certain services may still have issues. Delay,
	jitter, and occasional loss are perfectly acceptable for elastic		jitter, and occasional loss are perfectly acceptable for elastic
	applications. However, sub-second surges that occur in the best-		applications. However, sub-second surges that occur in the best-
	designed of networks [14] affect real-time applications. Moreover,		designed of networks [12] affect real-time applications. Moreover,
	DOS loads, worms, and network disruptions such as that of 11		DOS loads, worms, and network disruptions such as that of 11
	September 2001 affect routing [15]. Our objective is to prevent		September 2001 affect routing [13]. Our objective is to prevent
	disruption to routing (which in turn affects all services), protect		disruption to routing (which in turn affects all services), protect
	real-time jitter-sensitive services, while minimizing loss and delay		real-time jitter-sensitive services, while minimizing loss and delay
	of sensitive elastic traffic.		of sensitive elastic traffic.
	The document "Diffserv Service Classes" [5] defines a set of basic		The document "Diffserv Service Classes" [3] defines a set of basic
	diffserv classes from the points of view of the application requiring		diffserv classes from the points of view of the application requiring
	specific end-to-end behaviors from the network. The service classes		specific end-to-end behaviors from the network. The service classes
	are differentiated based on the application payload's tolerance to		are differentiated based on the application payload's tolerance to
	packet loss, delay, and delay variation (jitter). Different degrees		packet loss, delay, and delay variation (jitter). Different degrees
	of these criteria form the foundation for supporting the needs of		of these criteria form the foundation for supporting the needs of
	real-time and elastic traffic. The "Diffserv Service Classes" [5]		real-time and elastic traffic. The "Diffserv Service Classes" [3]
	document also provides recommendations for the treatment method of		document also provides recommendations for the treatment method of
	these service classes. But, at some network segments of the end-to-		these service classes. But, at some network segments of the end-to-
	end path, the number of levels of network treatment differentiation		end path, the number of levels of network treatment differentiation
	may be less than the number of service classes that the network		may be less than the number of service classes that the network
	segment needs to support. In such a situation, that network segment		segment needs to support. In such a situation, that network segment
	may use the same treatment to support more than one service class.		may use the same treatment to support more than one service class.
	In this document we provide guidelines on how multiple service		In this document we provide guidelines on how multiple service
	classes may be aggregated into a forwarding treatment aggregate.		classes may be aggregated into a forwarding treatment aggregate.
	Having the IP traffic belonging to service classes, expressed using		Having the IP traffic belonging to service classes, expressed using
	the DSCP, as described by "Diffserv Service Classes" [5]. Note that		the DSCP (DiffServ Code Point), as described by "Diffserv Service
	in a given domain, we may recommend that the supported service		Classes" [3]. Note that in a given domain, we may recommend that the
	classes be aggregated into forwarding treatment aggregates; however,		supported service classes be aggregated into forwarding treatment
	this does not mean all service classes need to be supported and hence		aggregates; however, this does not mean all service classes need to
	not all forwarding treatment aggregates need to be supported. A		be supported and hence not all forwarding treatment aggregates need
	domain may support fewer or greater number of forwarding treatment		to be supported. A domain may support fewer or greater number of
	aggregates. Which service classes and which forwarding treatment		forwarding treatment aggregates. Which service classes and which
	aggregates are supported by a domain is up to the domain		forwarding treatment aggregates are supported by a domain is up to
	administration and may be influenced by business reasons or other		the domain administration and may be influenced by business reasons
	reasons (e.g. operational considerations).		or other reasons (e.g. operational considerations).
	In this document, we've provided:		In this document, we've provided:
	o definitions for terminology we use in this document,		o definitions for terminology we use in this document,
	o requirements for performing this aggregation,		o requirements for performing this aggregation,
	o an example of performing the aggregation when four treatment		o an example of performing the aggregation when four treatment
	aggregates are used,		aggregates are used,
	o an example (in the appendix) of performing this aggregation over		o an example (in the appendix) of performing this aggregation over
	MPLS using E-LSP.		MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label
			Switched Path (LSP).
	The treatment aggregate recommendations are designed to aggregate the		The treatment aggregate recommendations are designed to aggregate the
	service classes [5] in such a manner as to protect real-time traffic		service classes [3] in such a manner as to protect real-time traffic
	and routing, on the assumption that real-time sessions are protected		and routing, on the assumption that real-time sessions are protected
	from each other by admission at the edge. The recommendation given		from each other by admission at the edge. The recommendation given
	is one possible way of performing the aggregation, there may be other		is one possible way of performing the aggregation, there may be other
	way of aggregation, for example into fewer treatment aggregates or		way of aggregation, for example into fewer treatment aggregates or
	more treatment aggregates.		more treatment aggregates.
	In the appendix, an example of aggregation over MPLS networks using		In the appendix, an example of aggregation over MPLS networks using
	E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path		E-LSP to realize the treatment aggregates is provided. Note that the
	(LSP), to realize the treatment aggregates is provided. Note that		MPLS E-LSP is just an example; this document does not exclude the use
	the MPLS E-LSP is just an example; this document does not exclude the		of other methods. This example only considers aggregation of IP
	use of other methods. This example only considers aggregation of IP
	traffic into E-LSP. The use of E-LSP by none-IP traffic is not		traffic into E-LSP. The use of E-LSP by none-IP traffic is not
	discussed.		discussed.
	1.1. Requirements Notation		1.1. Requirements Notation
	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 [3].		document are to be interpreted as described in RFC 2119 [1].
	2. Terminology		2. Terminology
	This document assumes the reader is familiar with the terms used in		This document assumes the reader is familiar with the terms used in
	differentiated services. This document provides the definitions for		differentiated services. This document provides the definitions for
	new terms introduced by this document and referencing information for		new terms introduced by this document and referencing information for
	existing none differentiated services terms defined in existing RFCs.		existing none differentiated services terms defined in existing RFCs.
	For new terms introduced by this document, we provide the definition		For new terms introduced by this document, we provide the definition
	here:		here:
	o Treatment Aggregate. This term is defined as the aggregate of		o Treatment Aggregate. This term is defined as the aggregate of
	DiffServ service classes [5]. A Treatment Aggregate is concerned		DiffServ service classes [3]. A Treatment Aggregate is concerned
	only with the forwarding treatment of the aggregated traffic,		only with the forwarding treatment of the aggregated traffic,
	which may be marked with multiple DSCPs. A Treatment Aggregate		which may be marked with multiple DSCPs. A Treatment Aggregate
	differs from Behavior Aggregate [4] and Traffic Aggregate [16],		differs from Behavior Aggregate [2] and Traffic Aggregate [14],
	each of which indicate the aggregated traffic having a single		each of which indicate the aggregated traffic having a single
	diffserv codepoint and utilizing a single PHB.		diffserv codepoint and utilizing a single PHB.
	For terms from existing RFCs, we provide the reference to the		For terms from existing RFCs, we provide the reference to the
	appropriate section of the relevant RFC that contain the definition:		appropriate section of the relevant RFC that contain the definition:
	o Real-Time and Elastic Applications and their traffic. Section 3.1		o Real-Time and Elastic Applications and their traffic. Section 3.1
	of RFC 1633 [6].		of RFC 1633 [4].
	o Diffserv Service Class. Section 1.3 of RFC 4594 [5].		o Diffserv Service Class. Section 1.3 of RFC 4594 [3].
	o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched		o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched
	Path (LSP). Section 1.2 of RFC 3270 [8].		Path (LSP). Section 1.2 of RFC 3270 [6].
	o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label		o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label
	Switched Path (LSP). Section 1.3 of RFC 3270 [8].		Switched Path (LSP). Section 1.3 of RFC 3270 [6].
	3. Overview of Service Class Aggregation		3. Overview of Service Class Aggregation
	In diffserv domains where less fine-grained traffic treatment		In diffserv domains where less fine-grained traffic treatment
	differentiation is provided, aggregation of the different service		differentiation is provided, aggregation of the different service
	classes [5] may be required.		classes [3] may be required.
	These aggregations have the following requirements:		These aggregations have the following requirements:
	1. The end-to-end network performance characteristic required by the		1. The end-to-end network performance characteristic required by the
	application must be supported. This performance characteristic		application MUST be supported. This performance characteristic
	is represented by the use of Diffserv Service Classes [5].		is represented by the use of Diffserv Service Classes [3].
	2. The treatment aggregate must meet the strictest requirements of		2. The treatment aggregate MUST meet the strictest requirements of
	its member service classes.		its member service classes.
	3. The treatment aggregate should only contain member service		3. The treatment aggregate SHOULD only contain member service
	classes with similar traffic characteristic and performance		classes with similar traffic characteristic and performance
	requirements.		requirements.
	4. The notion of the individual end-to-end service classes must not		4. The notion of the individual end-to-end service classes MUST NOT
	be destroyed when aggregation is performed. Each domain along		be destroyed when aggregation is performed. Each domain along
	the end-to-end path may perform aggregation differently, based on		the end-to-end path may perform aggregation differently, based on
	the original end-to-end service classes. We recommend an easy		the original end-to-end service classes. We recommend an easy
	way to accomplish this by not altering the DSCP used to indicate		way to accomplish this by not altering the DSCP used to indicate
	the end-to-end service class. But some administrative domains		the end-to-end service class. But some administrative domains
	may require the use of their own marking; when this is needed,		may require the use of their own marking; when this is needed,
	the original end-to-end service class indication must be restored		the original end-to-end service class indication must be restored
	upon exiting such administrative domains. One possible way of		upon exiting such administrative domains. One possible way of
	achieving this is with the use of tunnels to encapsulate the end-		achieving this is with the use of tunnels to encapsulate the end-
	to-end traffic.		to-end traffic.
	5. Each treatment aggregate has limited resources, hence traffic		5. Each treatment aggregate has limited resources, hence traffic
	conditioning and/or admission control should be performed for		conditioning and/or admission control SHOULD be performed for
	each service class aggregated into the treatment aggregate.		each service class aggregated into the treatment aggregate.
	Additional admission control and policing may be used on the sum		Additional admission control and policing may be used on the sum
	of all traffic aggregated into the treatment aggregate.		of all traffic aggregated into the treatment aggregate.
	In addition to the above requirements, we have the following		In addition to the above requirements, we have the following
	suggestions:		suggestions:
	1. The treatment aggregate and assigned resources may consider		1. The treatment aggregate and assigned resources may consider
	historical traffic patterns and the variability of these		historical traffic patterns and the variability of these
	patterns. For example, a point-point service (e.g., pseudowire)		patterns. For example, a point-point service (e.g., pseudowire)
	may have a very predictable pattern, while a multipoint service		may have a very predictable pattern, while a multipoint service
	(e.g., VPLS) may have a much less predictable pattern.		(e.g., VPLS, Virtual Private LAN Service) may have a much less
			predictable pattern.
	2. In addition to Diffserv, other controls are available to		2. In addition to Diffserv, other controls are available to
	influence the traffic level offered to a particular traffic		influence the traffic level offered to a particular traffic
	aggregate. These include adjustment of routing metrics, usage of		aggregate. These include adjustment of routing metrics, usage of
	MPLS-based traffic engineering techniques.		MPLS-based traffic engineering techniques.
	This document only describes the aggregation of IP traffic based on		This document only describes the aggregation of IP traffic based on
	the use of Diffserv Service Classes [5].		the use of Diffserv Service Classes [3].
	4. Service Classes to Treatment Aggregate Mapping		4. Service Classes to Treatment Aggregate Mapping
	The service class and DSCP selection in "Diffserv Service Classes"		The service class and DSCP selection in "Diffserv Service Classes"
	[5] has been defined to allow, in many instances, mapping of two or		[3] has been defined to allow, in many instances, mapping of two or
	possibly more service classes into a single forwarding treatment		possibly more service classes into a single forwarding treatment
	aggregate. Notice that there is a relationship/trade-off between		aggregate. Notice that there is a relationship/trade-off between
	link speed, queue depth, delay, and jitter. The degree of		link speed, queue depth, delay, and jitter. The degree of
	aggregation and hence the number of treatment aggregates will depend		aggregation and hence the number of treatment aggregates will depend
	on whether the speed of the links and scheduler behavior, being used		on whether the speed of the links and scheduler behavior, being used
	to implement the aggregation, can minimize the effects of mixing		to implement the aggregation, can minimize the effects of mixing
	traffic with different packet sizes and transmit rates on queue		traffic with different packet sizes and transmit rates on queue
	depth, and their impacts on loss, delay, and jitter. A general rule-		depth, and their impacts on loss, delay, and jitter. A general rule-
	of-thumb is that higher link speeds allow for more aggregation/		of-thumb is that higher link speeds allow for more aggregation/
	smaller number of treatment aggregates, assuming link utilization is		smaller number of treatment aggregates, assuming link utilization is
	within the engineered level.		within the engineered level.
	4.1. Mapping Service Classes into Four Treatment Aggregates		4.1. Mapping Service Classes into Four Treatment Aggregates
	This section provides an example of mapping all the service classes		This section provides an example of mapping all the service classes
	defined in RFC 4594 [5] into four treatment aggregates. The use of		defined in RFC 4594 [3] into four treatment aggregates. The use of
	four treatment aggregates assumes that the resources allocated to		four treatment aggregates assumes that the resources allocated to
	each treatment aggregate are sufficient to honor the required		each treatment aggregate are sufficient to honor the required
	behavior of each service class [5] in each of the four treatment		behavior of each service class [3] in each of the four treatment
	aggregates. We use the performance requirement (tolerance to loss,		aggregates. We use the performance requirement (tolerance to loss,
	delay, and jitter) from the application/end-user as a guide on how to		delay, and jitter) from the application/end-user as a guide on how to
	map the service classes into treatment aggregates. We have also used		map the service classes into treatment aggregates. We have also used
	Section 3.1 of RFC 1633 [6] to provide us with guidance on the		Section 3.1 of RFC 1633 [4] to provide us with guidance on the
	definition of Real-Time and Elastic applications. An overview of the		definition of Real-Time and Elastic applications. An overview of the
	mapping between service classes and the four treatment aggregates is		mapping between service classes and the four treatment aggregates is
	provided by Figure 1, with the mapping being based on performance		provided by Figure 1, with the mapping being based on performance
	requirements. In Figure 1, the right side columns of "Service		requirements. In Figure 1, the right side columns of "Service
	Class", "Tolerance to Loss/Delay/Jitter" are from Figure 2 of		Class", "Tolerance to Loss/Delay/Jitter" are from Figure 2 of
	Diffserv Service Classes [5].		Diffserv Service Classes [3].
	It is recommended that certain service classes be mapped into		It is recommended that certain service classes be mapped into
	specific treatment aggregates. But this does not mean that all the		specific treatment aggregates. But this does not mean that all the
	service classes recommended for that treatment aggregate need to be		service classes recommended for that treatment aggregate need to be
	supported. Hence, for a given domain, a treatment aggregate may		supported. Hence, for a given domain, a treatment aggregate may
	contain only a subset of the service classes recommended in this		contain only a subset of the service classes recommended in this
	document, they being the service classes supported by that domain. A		document, they being the service classes supported by that domain. A
	domain's treatment of non-supported service classes should be based		domain's treatment of non-supported service classes should be based
	on the domain's local policy. This local policy may be influenced by		on the domain's local policy. This local policy may be influenced by
	its agreement with its customers. Such treatment may use the Elastic		its agreement with its customers. Such treatment may use the Elastic
	skipping to change at page 9, line 37		skipping to change at page 9, line 37
	------------------------------------------------------------		------------------------------------------------------------
	Figure 2: Treatment Aggregate Behavior		Figure 2: Treatment Aggregate Behavior
	4.1.1. Network Control Treatment Aggregate		4.1.1. Network Control Treatment Aggregate
	The Network Control Treatment Aggregate aggregates all service		The Network Control Treatment Aggregate aggregates all service
	classes that are functionally necessary for the survival of a network		classes that are functionally necessary for the survival of a network
	during a DOS attack or other high traffic load interval. The theory		during a DOS attack or other high traffic load interval. The theory
	is that whatever else is true, the network must protect itself. This		is that whatever else is true, the network must protect itself. This
	includes the traffic that "Diffserv Service Classes" [5]		includes the traffic that "Diffserv Service Classes" [3]
	characterizes as being included in the Network Control Service Class.		characterizes as being included in the Network Control Service Class.
	Traffic in the Network Control treatment aggregate should be carried		Traffic in the Network Control treatment aggregate should be carried
	in a common queue or class with a PHB as described in RFC 2474 [4]		in a common queue or class with a PHB as described in RFC 2474 [2]
	section 4.2.2.2. This treatment aggregate should have a lower		section 4.2.2.2 for Class Selector (CS). This treatment aggregate
	probability of packet loss, bearing a relatively deep target mean		should have a lower probability of packet loss, bearing a relatively
	queue depth (min-threshold if RED is being used).		deep target mean queue depth (min-threshold if RED (Random Early
			Detection) is being used).
	Please notice this Network Control Treatment Aggregate is meant to be		Please notice this Network Control Treatment Aggregate is meant to be
	used for the customer's network control traffic. The provider may		used for the customer's network control traffic. The provider may
	choose to treat its own network control traffic differently, perhaps		choose to treat its own network control traffic differently, perhaps
	in its own service class that is not aggregated with the customer's		in its own service class that is not aggregated with the customer's
	network control traffic.		network control traffic.
	4.1.2. Real Time Treatment Aggregate		4.1.2. Real Time Treatment Aggregate
	The Real Time Treatment Aggregate aggregates all real-time		The Real Time Treatment Aggregate aggregates all real-time
	skipping to change at page 10, line 19		skipping to change at page 10, line 19
	admitted under some model and controlled by a SLA managed at the edge		admitted under some model and controlled by a SLA managed at the edge
	of the network prior to aggregation. As such, there is a predictable		of the network prior to aggregation. As such, there is a predictable
	and enforceable upper bound on the traffic that can enter such a		and enforceable upper bound on the traffic that can enter such a
	queue, and to provide predictable variation in delay it must be		queue, and to provide predictable variation in delay it must be
	protected from bursts of elastic traffic. The predictability of		protected from bursts of elastic traffic. The predictability of
	traffic level may be based upon admission control for a well known		traffic level may be based upon admission control for a well known
	community of interest (e.g., a point-point service) and/or based upon		community of interest (e.g., a point-point service) and/or based upon
	historical measurements.		historical measurements.
	This treatment aggregate may include the following service classes		This treatment aggregate may include the following service classes
	from the Diffserv Service Classes [5], in addition to other locally		from the Diffserv Service Classes [3], in addition to other locally
	defined classes: Telephony, Signaling, Multimedia Conferencing, Real-		defined classes: Telephony, Signaling, Multimedia Conferencing, Real-
	time Interactive, Broadcast Video.		time Interactive, Broadcast Video.
	Traffic in each service class that is going to be aggregated into the		Traffic in each service class that is going to be aggregated into the
	treatment aggregate should be conditioned prior to aggregation. It		treatment aggregate should be conditioned prior to aggregation. It
	is recommended that per service class admission control procedures be		is recommended that per service class admission control procedures be
	used followed by per service class policing so that any individual		used followed by per service class policing so that any individual
	service class does not generate more than what it is allowed.		service class does not generate more than what it is allowed.
	Furthermore, additional admission control and policing may be used on		Furthermore, additional admission control and policing may be used on
	the sum of all traffic aggregated into this treatment aggregate.		the sum of all traffic aggregated into this treatment aggregate.
	Traffic in the Real Time treatment aggregate should be carried in a		Traffic in the Real Time treatment aggregate should be carried in a
	common queue or class with a PHB as described in RFC 3246 [11] and		common queue or class with a PHB (Per Hop Behavior) as described in
	RFC 3247 [12].		RFC 3246 [9] and RFC 3247 [10].
	4.1.3. Assured Elastic Treatment Aggregate		4.1.3. Assured Elastic Treatment Aggregate
	The Assured Elastic Treatment Aggregate aggregates all elastic		The Assured Elastic Treatment Aggregate aggregates all elastic
	traffic that uses the Assured Forwarding model as described in RFC		traffic that uses the Assured Forwarding model as described in RFC
	2597 [10]. The premise of such a service is that a SLA is negotiated		2597 [8]. The premise of such a service is that a SLA is negotiated
	which includes a "committed rate" and the ability to exceed that rate		which includes a "committed rate" and the ability to exceed that rate
	(and perhaps a second "excess rate") in exchange for a higher		(and perhaps a second "excess rate") in exchange for a higher
	probability of loss using AQM [9] or ECN marking [13] for the portion		probability of loss using Active Queue Management (AQM) [7] or
			Explicit Congestion Notification (ECN) marking [11] for the portion
	of traffic deemed to be in excess.		of traffic deemed to be in excess.
	This treatment aggregate may include the following service classes		This treatment aggregate may include the following service classes
	from the Diffserv Service Classes [5], in addition to other locally		from the Diffserv Service Classes [3], in addition to other locally
	defined classes: Multimedia Streaming, Low Latency Data, OAM, High		defined classes: Multimedia Streaming, Low Latency Data, OAM, High
	Throughput Data.		Throughput Data.
	The DSCP values belonging to the AF PHB group and class selector of		The DSCP values belonging to the AF PHB group and class selector of
	the original service classes remain an important consideration and		the original service classes remain an important consideration and
	should be preserved during aggregation. This treatment aggregate		should be preserved during aggregation. This treatment aggregate
	should maintain the AF PHB group marking of the original packet. For		should maintain the AF PHB group marking of the original packet. For
	example, AF3x marked packets should remain AF3x marked within this		example, AF3x marked packets should remain AF3x marked within this
	treatment aggregate. In addition, the class selector DSCP value		treatment aggregate. In addition, the class selector DSCP value
	should not be changed. Traffic bearing these DSCPs is carried in a		should not be changed. Traffic bearing these DSCPs is carried in a
	common queue or class with a PHB as described in RFC 2597 [10]. In		common queue or class with a PHB as described in RFC 2597 [8]. In
	effect, appropriate target rate thresholds have been applied at the		effect, appropriate target rate thresholds have been applied at the
	edge, dividing traffic into AFn1 (committed, for any value of n),		edge, dividing traffic into AFn1 (committed, for any value of n),
	AFn2, and AFn3 (excess). The service should be engineered so that		AFn2, and AFn3 (excess). The service should be engineered so that
	AFn1 and CS2 marked packet flows have sufficient bandwidth in the		AFn1 and CS2 marked packet flows have sufficient bandwidth in the
	network to provide high assurance of delivery. Since the traffic is		network to provide high assurance of delivery. Since the traffic is
	elastic and responds dynamically to packet loss, Active Queue		elastic and responds dynamically to packet loss, Active Queue
	Management [9] should be used primarily to reduce the forwarding rate		Management [7] should be used primarily to reduce the forwarding rate
	to the minimum assured rate at congestion points. The probability of		to the minimum assured rate at congestion points. The probability of
	loss of AFn1 and CS2 traffic must not exceed the probability of loss		loss of AFn1 and CS2 traffic must not exceed the probability of loss
	of AFn2 traffic, which in turn must not exceed the probability of		of AFn2 traffic, which in turn must not exceed the probability of
	loss of AFn3 traffic.		loss of AFn3 traffic.
	If RED [9] is used as an AQM algorithm, the min-threshold specifies a		If RED [7] is used as an AQM algorithm, the min-threshold specifies a
	target queue depth for each of AFn1+CS2, AFn2, AFn3, and the max-		target queue depth for each of AFn1+CS2, AFn2, AFn3, and the max-
	threshold specifies the queue depth above which all traffic with such		threshold specifies the queue depth above which all traffic with such
	a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate,		a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate,
	the following inequalities should hold in queue configurations:		the following inequalities SHOULD hold in queue configurations:
	o min-threshold AFn3 < max-threshold AFn3		o min-threshold AFn3 < max-threshold AFn3
	o max-threshold AFn3 <= min-threshold AFn2		o max-threshold AFn3 <= min-threshold AFn2
	o min-threshold AFn2 < max-threshold AFn2		o min-threshold AFn2 < max-threshold AFn2
	o max-threshold AFn2 <= min-threshold AFn1+CS2		o max-threshold AFn2 <= min-threshold AFn1+CS2
	o min-threshold AFn1+CS2 < max-threshold AFn1+CS2		o min-threshold AFn1+CS2 < max-threshold AFn1+CS2
	skipping to change at page 11, line 47		skipping to change at page 11, line 48
	o max-threshold AFn1+CS2 <= memory assigned to the queue		o max-threshold AFn1+CS2 <= memory assigned to the queue
	Note: This configuration tends to drop AFn3 traffic before AFn2 and		Note: This configuration tends to drop AFn3 traffic before AFn2 and
	AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are		AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are
	used; they should be configured to achieve a similar result.		used; they should be configured to achieve a similar result.
	4.1.4. Elastic Treatment Aggregate		4.1.4. Elastic Treatment Aggregate
	The Elastic Treatment Aggregate aggregates all remaining elastic		The Elastic Treatment Aggregate aggregates all remaining elastic
	traffic. The premise of such a service is that there is no intrinsic		traffic. The premise of such a service is that there is no intrinsic
	SLA differentiation of traffic, but that AQM [9] or ECN flagging [13]		SLA differentiation of traffic, but that AQM [7] or ECN flagging [11]
	is appropriate for such traffic.		is appropriate for such traffic.
	This treatment aggregate may include the following service classes		This treatment aggregate may include the following service classes
	from the Diffserv Service Classes [5], in addition to other locally		from the Diffserv Service Classes [3], in addition to other locally
	defined classes: Standard, Low Priority Data.		defined classes: Standard, Low Priority Data.
	Treatment aggregates should be well specified, each indicating the		Treatment aggregates should be well specified, each indicating the
	service classes it will handle. But in cases where unspecified or		service classes it will handle. But in cases where unspecified or
	unknown service classes are encountered, they may be dropped or be		unknown service classes are encountered, they may be dropped or be
	treated using the Elastic Treatment Aggregate. The choice of how to		treated using the Elastic Treatment Aggregate. The choice of how to
	treat unspecified service classes should be well defined, based on		treat unspecified service classes should be well defined, based on
	some agreements.		some agreements.
	Traffic in the Elastic treatment aggregate should be carried in a		Traffic in the Elastic treatment aggregate should be carried in a
	common queue or class with a PHB as described in RFC 2474 [4] section		common queue or class with a PHB as described in RFC 2474 [2] section
	4.1: A Default PHB. The AQM thresholds for Elastic traffic MAY be		4.1: A Default PHB. The AQM thresholds for Elastic traffic MAY be
	separately set, so that Low Priority Data traffic is dropped before		separately set, so that Low Priority Data traffic is dropped before
	Standard traffic, but this is not a requirement.		Standard traffic, but this is not a requirement.
	5. Treatment Aggregates and Inter-Provider Relationships		5. Treatment Aggregates and Inter-Provider Relationships
	When Treatment Aggregates are used at provider boundaries, we		When Treatment Aggregates are used at provider boundaries, we
	recommend that the Inter-Provider Relationship be based on Diffserv		recommend that the Inter-Provider Relationship be based on Diffserv
	Service Classes [5]. This allows the admission control into each		Service Classes [3]. This allows the admission control into each
	Treatment Aggregate of a provider domain to be based on the admission		Treatment Aggregate of a provider domain to be based on the admission
	control of traffic into the supported Service Classes, as indicated		control of traffic into the supported Service Classes, as indicated
	by the discussion in section 4 of this document.		by the discussion in section 4 of this document.
	If the Inter-Provider Relationship needs to be based on Treatment		If the Inter-Provider Relationship needs to be based on Treatment
	Aggregates specified by this document, then the exact Treatment		Aggregates specified by this document, then the exact Treatment
	Aggregate content and representation must be agreed to by the peering		Aggregate content and representation must be agreed to by the peering
	providers.		providers.
	Some additional work on Inter-Provider Relationships is provided by		Some additional work on Inter-Provider Relationships is provided by
	Inter-provider QoS [17], where details on supporting realtime		Inter-provider QoS [15], where details on supporting realtime
	services between service providers are discussed. Some related work		services between service providers are discussed. Some related work
	in ITU-T provided by Appendix VI of Y.1541 [18] may also help with		in ITU-T provided by Appendix VI of Y.1541 [16] may also help with
	inter-provider relationships, especially with international		inter-provider relationships, especially with international
	providers.		providers.
	6. Security Considerations		6. Security Considerations
	This document discusses the policy of using Differentiated Services		This document discusses the policy of using Differentiated Services
	and its service classes. If implemented as described, it should		and its service classes. If implemented as described, it should
	require that the network do nothing that the network has not already		require that the network do nothing that the network has not already
	allowed. If that is the case, no new security issues should arise		allowed. If that is the case, no new security issues should arise
	from the use of such a policy.		from the use of such a policy.
	skipping to change at page 13, line 32		skipping to change at page 13, line 33
	8. Acknowledgements		8. Acknowledgements
	This document has benefited from discussions with numerous people,		This document has benefited from discussions with numerous people,
	especially Shane Amante, Brian Carpenter, and Dave McDysan. It has		especially Shane Amante, Brian Carpenter, and Dave McDysan. It has
	also benefited from detailed reviews by David Black, Marvin Krym,		also benefited from detailed reviews by David Black, Marvin Krym,
	Bruce Davie, Fil Dickinson, and Julie Ann Connary.		Bruce Davie, Fil Dickinson, and Julie Ann Connary.
	Appendix A. Using MPLS for Treatment Aggregates		Appendix A. Using MPLS for Treatment Aggregates
	RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of		RFC 2983 on DiffServ and Tunnels [5] and RFC 3270 on MPLS Support of
	DiffServ [8] provide a very good background on this topic. This		DiffServ [6] provide a very good background on this topic. This
	document provides an example of using the E-LSP, EXP Inferred PHB		document provides an example of using the E-LSP, EXP Inferred PHB
	Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS		Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS
	Support of DiffServ [8] for realizing the Treatment Aggregates.		Support of DiffServ [6] for realizing the Treatment Aggregates.
	When Treatment Aggregates are represented in MPLS using EXP Inferred		When Treatment Aggregates are represented in MPLS using EXP Inferred
	PSC LSP, we recommend the following usage of the MPLS EXP field for		PSC LSP, we recommend the following usage of the MPLS EXP field for
	Treatment Aggregates.		Treatment Aggregates.
	-------------------------------------------		-------------------------------------------
	|Treatment || MPLS || DSCP | DSCP |		|Treatment || MPLS || DSCP | DSCP |
	|Aggregate || EXP || name | value |		|Aggregate || EXP || name | value |
	|==========++======++=========|=============|		|==========++======++=========|=============|
	| Network || 110 || CS6 | 110000 |		| Network || 110 || CS6 | 110000 |
	skipping to change at page 15, line 10		skipping to change at page 15, line 10
	The above table indicates the recommended usage of EXP fields for		The above table indicates the recommended usage of EXP fields for
	Treatment Aggregates. Because many deployments of MPLS are on a per		Treatment Aggregates. Because many deployments of MPLS are on a per
	domain basis, each domain has total control of its EXP usage and each		domain basis, each domain has total control of its EXP usage and each
	domain may use a different EXP field allocation for the domain's		domain may use a different EXP field allocation for the domain's
	supported Treatment Aggregates.		supported Treatment Aggregates.
	Appendix A.1. Network Control Treatment Aggregate with E-LSP		Appendix A.1. Network Control Treatment Aggregate with E-LSP
	The usage of E-LSP for Network Control Treatment Aggregate needs to		The usage of E-LSP for Network Control Treatment Aggregate needs to
	adhere to the recommendations indicated in section 4.1.1 of this		adhere to the recommendations indicated in section 4.1.1 of this
	document and section 3.2 of "Diffserv Service Classes" [5].		document and section 3.2 of "Diffserv Service Classes" [3].
	Reinforcing these recommendations, there should be no drop precedence		Reinforcing these recommendations, there should be no drop precedence
	associated with the MPLS PSC used for Network Control Treatment		associated with the MPLS PSC used for Network Control Treatment
	Aggregate because dropping of Network Control Treatment Aggregate		Aggregate because dropping of Network Control Treatment Aggregate
	traffic should be prevented.		traffic should be prevented.
	Appendix A.2. Real Time Treatment Aggregate with E-LSP		Appendix A.2. Real Time Treatment Aggregate with E-LSP
	In addition to the recommendations provided in section 4.1.2 of this		In addition to the recommendations provided in section 4.1.2 of this
	document and in member service classes' sections of "Diffserv Service		document and in member service classes' sections of "Diffserv Service
	Classes" [5], we want to indicate that Real Time Treatment Aggregate		Classes" [3], we want to indicate that Real Time Treatment Aggregate
	traffic should not be dropped, as some of the applications whose		traffic should not be dropped, as some of the applications whose
	traffic is carried in the Real Time Treatment Aggregate do not react		traffic is carried in the Real Time Treatment Aggregate do not react
	well to dropped packets. As indicated in section 4.1.2 of this		well to dropped packets. As indicated in section 4.1.2 of this
	document, admission control should be performed on each Service Class		document, admission control should be performed on each Service Class
	contributing to the Real Time Treatment Aggregate to prevent packet		contributing to the Real Time Treatment Aggregate to prevent packet
	loss due to insufficient resources allocated to Real Time Treatment		loss due to insufficient resources allocated to Real Time Treatment
	Aggregate. Further, admission control and policing may also be		Aggregate. Further, admission control and policing may also be
	applied on the sum of all traffic aggregated into this treatment		applied on the sum of all traffic aggregated into this treatment
	aggregate.		aggregate.
	skipping to change at page 16, line 19		skipping to change at page 16, line 19
	LSP, the support of each Treatment Aggregate is on a per LSP basis.		LSP, the support of each Treatment Aggregate is on a per LSP basis.
	This document does not further specify any additional recommendation		This document does not further specify any additional recommendation
	(beyond what has been indicated in section 4 of this document) for		(beyond what has been indicated in section 4 of this document) for
	Treatment Aggregate to L-LSP mapping, leaving this to each individual		Treatment Aggregate to L-LSP mapping, leaving this to each individual
	MPLS domain administrations.		MPLS domain administrations.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[1] Postel, J., "Internet Protocol", STD 5, RFC 791,		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	September 1981.
	[2] Bradner, S., "The Internet Standards Process -- Revision 3",
	BCP 9, RFC 2026, October 1996.
	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of		[2] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
	the Differentiated Services Field (DS Field) in the IPv4 and		the Differentiated Services Field (DS Field) in the IPv4 and
	IPv6 Headers", RFC 2474, December 1998.		IPv6 Headers", RFC 2474, December 1998.
	[5] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines		[3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
	for DiffServ Service Classes", RFC 4594, August 2006.		for DiffServ Service Classes", RFC 4594, August 2006.
	[6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in		[4] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
	the Internet Architecture: an Overview", RFC 1633, June 1994.		the Internet Architecture: an Overview", RFC 1633, June 1994.
	[7] Black, D., "Differentiated Services and Tunnels", RFC 2983,		[5] Black, D., "Differentiated Services and Tunnels", RFC 2983,
	October 2000.		October 2000.
	[8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,		[6] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
	Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol		Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol
	Label Switching (MPLS) Support of Differentiated Services",		Label Switching (MPLS) Support of Differentiated Services",
	RFC 3270, May 2002.		RFC 3270, May 2002.
	[9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,		[7] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
	Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,		Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge,
	C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,		C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski,
	J., and L. Zhang, "Recommendations on Queue Management and		J., and L. Zhang, "Recommendations on Queue Management and
	Congestion Avoidance in the Internet", RFC 2309, April 1998.		Congestion Avoidance in the Internet", RFC 2309, April 1998.
	[10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured		[8] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
	Forwarding PHB Group", RFC 2597, June 1999.		Forwarding PHB Group", RFC 2597, June 1999.
	[11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,		[9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
	Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An		Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
	Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,		Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
	March 2002.		March 2002.
	[12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,		[10] 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 Definition		Ramakrishnan, "Supplemental Information for the New Definition
	of the EF PHB (Expedited Forwarding Per-Hop Behavior)",		of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
	RFC 3247, March 2002.		RFC 3247, March 2002.
	[13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of		[11] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
	Explicit Congestion Notification (ECN) to IP", RFC 3168,		Explicit Congestion Notification (ECN) to IP", RFC 3168,
	September 2001.		September 2001.
	9.2. Informative References		9.2. Informative References
	[14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,		[12] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,
	"Analysis of Point-To-Point Packet Delay in an Operational		"Analysis of Point-To-Point Packet Delay in an Operational
	Network", INFOCOMM 2004, March 2004,		Network", INFOCOMM 2004, March 2004,
	<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.		<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
	[15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11",		[13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11",
	March 2002, <http://www.renesys.com/tech/presentations/pdf/		March 2002, <http://www.renesys.com/tech/presentations/pdf/
	renesys-030502-NRC-911.pdf>.		renesys-030502-NRC-911.pdf>.
	[16] Nichols, K. and B. Carpenter, "Definition of Differentiated		[14] Nichols, K. and B. Carpenter, "Definition of Differentiated
	Services Per Domain Behaviors and Rules for their		Services Per Domain Behaviors and Rules for their
	Specification", RFC 3086, April 2001.		Specification", RFC 3086, April 2001.
	[17] MIT Communications Futures Program, "Inter-provider Quality of		[15] MIT Communications Futures Program, "Inter-provider Quality of
	Service", November 2006, <		Service", November 2006, <
	http://cfp.mit.edu/resources/papers/Interprovider QoS		http://cfp.mit.edu/resources/papers/Interprovider QoS
	MIT_CFP_WP_9_14_06.pdf>.		MIT_CFP_WP_9_14_06.pdf>.
	[18] International Telecommunications Union, "Network performance		[16] International Telecommunications Union, "Network performance
	objectives for IP-based services", February 2006.		objectives for IP-based services", February 2006.
	Authors' Addresses		Authors' Addresses
	Kwok Ho Chan		Kwok Ho Chan
	Nortel		Nortel
	600 Technology Park Drive		600 Technology Park Drive
	Billerica, MA 01821		Billerica, MA 01821
	US		US
End of changes. 71 change blocks.
	107 lines changed or deleted		104 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/