< draft-svshah-tsvwg-deterministic-forwarding-01.txt		draft-svshah-tsvwg-deterministic-forwarding-02.txt >
	Network Working Group S. Shah		Network Working Group S. Shah
	Internet-Draft P. Thubert		Internet-Draft P. Thubert
	Intended status: Informational Cisco Systems		Intended status: Informational Cisco Systems
	Expires: September 4, 2014 March 03, 2014		Expires: March 7, 2015 September 03, 2014
	Deterministic Forwarding PHB		Deterministic Forwarding PHB
	draft-svshah-tsvwg-deterministic-forwarding-01		draft-svshah-tsvwg-deterministic-forwarding-02
	Abstract		Abstract
	This document defines a Differentiated Services Per-Hop-Behavior		This document defines a Differentiated Services Per-Hop-Behavior
	(PHB) Group called Deterministic Forwarding (DF). The document		(PHB) Group called Deterministic Forwarding (DF). The document
	describes the purpose and semantics of this PHB. It also describes		describes the purpose and semantics of this PHB. It describes
	creation and forwarding treatment of the service class. The document		creation and forwarding treatment of the service class. Also
	also describes how the code-point can be mapped into one of the		describes how the code-point can be mapped into one of the aggregated
	aggregated Diffserv service classes [RFC5127].		Diffserv service classes [RFC5127].
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on September 4, 2014.		This Internet-Draft will expire on March 7, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 21 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. DF Per Hop Behavior . . . . . . . . . . . . . . . . . . . . . 3
	3. DF code-point Behavior . . . . . . . . . . . . . . . . . . . . 5		4. Traffic Conditioning . . . . . . . . . . . . . . . . . . . . 4
	3.1. Potential implementation of DF scheduling . . . . . . . . 6		5. Diffserv behavior through non-DF DS domain . . . . . . . . . 4
	3.2. Conditioning DF traffic at Enqueue . . . . . . . . . . . . 8		6. Potential implementation of DF scheduling . . . . . . . . . . 5
	4. Diffserv behavior through non-DF DS domains . . . . . . . . . 8		7. Updates to RFC4594 and RFC5127 . . . . . . . . . . . . . . . 7
	5. Updates to RFC4594 and RFC5127 . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	IP Networks typically implement Diffserv to provide differentiated		There is a demand to provide deterministic forwarding to certain type
	forwarding behavior to different class of traffic. Networks that		of traffic in machine to machine networks over IP. With an
	implement Diffserv relies on DSCP code-point in the IP header of a		introduction of machine to machine networks over IP, a new set of IP
	packet to select PHB as a specific forwarding treatment for that		applications are emerging. Traffic types from such applications/
	packet [RFC2474, RFC2475]. This document describes a particular PHB		networks are some-what different from the traditional traffic types.
	called Deterministic Forwarding (DF). The proposed new code-point		Though most traffic types have characteristics similar to that of
	defines a service class for the purpose of forwarding treatment of a		traditional ones [LLN-DIFF], certain control signals for some of the
	packet at determined/fixed scheduled time providing no jitter service		applications are extremely sensitive to latency and jitter and thus
	to the class of traffic (updates RFC4594 with the addition of a new		timely scheduled delivery. End to end deterministic path for such
	Service Class).		traffic may be through one or more administered inter-connected
			machine to machine networks.
	DF PHB can be used for the network services that require the
	capability to ensure a predictable interaction between networked
	systems and guarantee a very strict time scheduled services.
	Applications of such networks may be able to absorb a loss but are
	very sensitive to timely(deterministic) delivery. Examples of such
	networks include Machine to Machine (M2M) control and monitoring
	deployment with IP over varieties of Layer 2 networks.
	The definition of Expedited Forwarding (EF) [RFC2598] PHB is low
	latency and thus one can envision use of EF code-point for such
	service. However, even though EF defines low latency and low jitter,
	it does not guarantee deterministic/fixed scheduled time service.
	Depending on co-existence of the other traffic in the network, EF
	traffic may have more or less variance on jitter and thus not
	suitable for the deterministic service. DF PHB, as defined in this
	document, thus is more suitable for deterministic time sensitive
	traffic.
	Typically for an application where end to end deterministic service
	is important, relevant traffic should be provisioned through DF PHB
	at every hop in that end to end path. However, in cases where
	intermediate hops (or DS domains) either do not support DF PHB or
	supports only aggregated service classes described in RFC5127, DF
	traffic in those DS domains MUST be mapped to Real Time Treatment
	class (EF PHB) defined in RFC5127. Traffic in such scenario MUST be
	conditioned at the Edge before entering and after exiting such DS
	domains. This is described further in later section.
	1.1. Use-cases
	With an introduction of machine to machine networks over IP, a new
	set of applications are emerging. Traffic types from such
	applications/networks are some-what different from the traditional
	traffic types. Though most traffic types have characteristics
	similar to that of traditional ones [LLN-DIFF], certain control
	signals for some of the applications are extremely sensitive to
	latency and jitter thus deterministic service. Such control signals
	demand much stricter latency and jitter, at pretty much decisive time
	scheduled delivery, end to end. Industrial automation, Smart cities
	and automobiles/planes/trains built around such networks are examples
	of such use-cases.
	Machine to machine networks may be implemented on varieties of Layer		Deterministic Forwarding (DF) PHB group is a means for each node in
	2 protocols. 802.15e [TiSCH] and 802.1 are examples of layer 2 that		machine to machine networks, in an end to end path, to deliver
	are enhancing their capabilities to allow time scheduled delivery of		required deterministic behavior. DF class in each DS node is
	packets.		allocated with a scheduled transmission time. DS node may be
			allocated one scheduled time for the whole aggregate DF traffic, or
			may be allocated with different schedule time for each micro-flow or
			set of micro-flows in a DF class. IP packets that wish to use
			deterministic service are assigned DF code-point, typically at the
			originator of such traffic.
	---+------------------------		In a DS node, the level of forwarding determinism of an IP packet
	| Converged Campus Network		depends on scheduled time, at which packet then serviced independent
	|		of existence and load of any other type of traffic. For example when
	+-----+		a DF packet arrives at the DS node, it is queued until its
	| | Gateway		provisioned scheduled time of service. At the trigger of that
	| |		scheduled time, service to all other traffic is pre-empted to service
	+-----+		DF traffic.
	|
	| Backbone
	+--------------------+------------------+
	| | |
	+-----+ +-----+ +-----+
	| | LLN border | | LLN border | | LLN border
	o | | router | | router | | router
	+-----+ +-----+ +-----+
	o o o o
	o o o o o o o o o o o
	o o o o o o o o o o o o o o o o o o
	o o o o o o o o o o o o o o o o
	o o M o o o o o o o o o o o o o
	o o o o o o o o o
	o o o o o
	LLN-1 LLN-2 LLN-3		This document describes the DF PHB group. DF capability is not a
			required function for a DS-compliant node, but a DS-compliant node
			that implements DF PHB group MUST conform to the specification in
			this document.
	Taking use-case example from [TiSCH], as shown in the diagram,		Typically for an application where end to end deterministic service
	multiple LL Networks are connected to each other via Backbone through		is important, relevant traffic can be serviced through DF PHB at
	LLN Border routers. Each LL Network consist of many nodes. There is		every hop in the path. However, in cases where intermediate hops (or
	different types of traffic forwarded through each LL node and from		DS domains) either do not support DF PHB or supports only aggregated
	one LL Network to another. Most LLN traffic types have		service classes described in RFC5127, DF traffic in those DS domains
	characteristics similar to that of traditional ones and thus can be		MUST be mapped to Real Time Treatment class (EF PHB) defined in
	supported through existing Diffserv classes except time sensitive		RFC5127. Traffic in such scenario MUST be conditioned at the Edge
	control signals. Without segregating such control signals to a		before entering and after exiting such DS domains. This is described
	specific Diffserv class would require Intserv support for LLN traffic		further in later section.
	in such networks. All traffic would be subject to flow
	classification to differentiate time sensitive control signals which
	can be a big scale concern. Supporting time sensitive control
	signals via newly proposed DF Diffserv class allows implementation of
	Diffserv in LLN Networks.
	2. Terminology		2. Terminology
	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 RFC2119.		document are to be interpreted as described in RFC2119.
	3. DF code-point Behavior		3. DF Per Hop Behavior
	The DF PHB is to implement time scheduled forwarding treatment.		The DF PHB is to implement deterministic scheduled, deterministic in
	Provisioning of such a service has two parts,		terms of a time, forwarding treatment. DF traffic MUST be serviced
			in a manner to meet configurable scheduled time. A DS node may pre-
			allocate dedicated resources available at configured scheduled time
			for optionally configurable maximum size of data. Every conforming
			packet, belonging to DF class, gets deterministic service
			irrespective of traffic in other Diffserv class and current load on
			the system. A DS node MAY allow though its dedicated scheduled
			resources available to other Differentiated service classes when DF
			class does not have any packets to serve during its service time.
	1) Provisioning of the fixed/relative time for scheduling of such		A DS node MAY be configured with the same parameters for the entire
	service		DF traffic class or different parameters for each micro-flow in a DF
	2) Provisioning of the max size of the data to be transmitted at		class. For the later case, DF traffic MUST be serviced in a manner
	each scheduled time.		to meet scheduled service time for each individual micro-flow. Per-
			flow DF parameters may be provisioned dynamically thru a signaling
			protocol. Use of any signaling protocol is agnostic to the DF PHB
			and thus out of scope of this specification [An example of such
			signaling protocol referred in 6TisCH]. What signaling protocol
			requires to convey, at minimum to each DS node in the end to end
			path, is request for DF service along with the flow classification
			and associated DF parameters, parameters like intended time of a
			service and size of data to be transmitted during time of service.
			In a packet path, packet first is classified if it belongs to DF PHB.
			Once classified for DF PHB, it gets deterministic treatment if
			provisioned for per-flow DF parameters or else gets aggregate DF
			treatment.
	Provisioned scheduled time may be absolute or relative. For example,		4. Traffic Conditioning
	a DF class may be provisioned to schedule packets (or bytes) at every
	fixed time. Fixed time can be time of a day or any other absolute
	definition. In a multi hop forwarding of DF traffic, absolute time
	service provisioning at each hop may require to be dependent on the
	clock synchronization (clock synchronization is not in the scope of
	this specification). In relative time scheduling, packets to be
	scheduled at every specific interval or it could be relative to any
	other specific event/trigger. The definition of the time interval or
	any other event is relevant to that specific provisioned node only.
	The size of the data to be transmitted, at each scheduled time		A DF supported DS Domain MAY condition traffic at the ingress Edge of
	service, may be provisioned in the unit of bytes or time. The data		the domain. Traffic conditioning MUST discard any incoming packet
	defined here is raw data transmitted over transmission media,		that does not conform to the configured DF service. As per PHB
	including Layer 2 header and any other overhead. Once DF PHB is		definition, packets are required to be scheduled and delivered at a
	provisioned and enabled, forwarding treatment MUST service packets		precise absolute or relative time interval. Any packet that has
	(bytes) from this class at the scheduled time for max allowable size.		missed the window of its service time MUST be discarded. For example
	Scheduling MUST pre-empt any other service, including EF, during the		if a DF queue is provisioned to serve a packet with less than x ms of
	schedule time service for the DF class. In order to avoid incurred		jitter and for an arrived packet, if next scheduled time for a packet
	latency to EF class of traffic, it is expected to carefully provision		results in more than x ms of jitter then such packet MUST be
	DF class to limit scheduled time service to as minimal data		discarded. The packet MUST also be checked against the size of the
	transmission that would prevent larger than expected delays to EF		data. If size of the packet is bigger than max size of the data a
	class of traffic.		scheduled time is provisioned to service then such packet MUST be
			discarded. In addition to DS node at the ingress Edge of the domain,
			other DS nodes in the path MAY implement Traffic Conditioning.
	Provisioning can be done via any of multiple possible methods. It		5. Diffserv behavior through non-DF DS domain
	could be via command interface, or could be via external provisioning
	agents, or could be via some sort of signaling that may dynamically
	pre-negotiate time window of transmission at each node in a network
	path.
	3.1. Potential implementation of DF scheduling		In deployments if two DF domains are connected through a domain that
			does not support DF PHB, traffic from such intermediate domain MUST
			be forwarded with low latency. DF traffic at the egress Edge of the
			sender DF domain MUST be mapped to EF PHB aggregate service, defined
			as Real Time Service aggregation in RFC5127. Such traffic when
			entered in the receiving DF domain MUST be conditioned, as described
			in earlier section, at the ingress Edge of that receiving domain.
			6. Potential implementation of DF scheduling
	Following are examples of potential implementations. They are not		Following are examples of potential implementations. They are not
	any form of guidelines or recommendations but simply a reference to		any form of guidelines or recommendations but simply a reference to
	potential implementations.		potential implementations.
	There are at least two ways to implement scheduling for DF traffic		There are at least two ways to implement scheduling for DF traffic
	class.		class.
	1) One queue to buffer and schedule all DF traffic (from all flows),		1) One queue to buffer and schedule all DF traffic (from all flows),
	2) Multiple sub-queues for DF traffic class, one queue for each DF		2) Multiple queues for DF traffic class, one queue for each DF
	provisioned flow		provisioned micro-flow
	Flow here represents macro definition, it does not have to be only
	5-tuple.
	Any chosen DF scheduling implementation MUST run traffic conditioning		Any chosen DF scheduling implementation MAY run Traffic Conditioning,
	at enqueue to decide if packets to be enqueued or discarded.		as described in earlier section. Discussed more in later section.
	Discussed more in later section.
	1) Single queue to buffer all DF traffic		1) Single queue to buffer all DF traffic
	This one queue maintains, possibly a circular, indexed buffer list.		This single queue maintains, possibly a circular, indexed buffer
	Each index logically maps to each scheduled time service. If enqueue		list. Each index logically maps to each scheduled time service. If
	conditioning not to discard a packet, packet gets en-queued at a		conditioning results in not to discard a packet, packet gets en-
	relevant index in the buffer list that maps to a relevant scheduled		queued at a relevant index in the buffer list that maps to a relevant
	time slot. If there is no packet(s) received for a specific		scheduled time slot. If there is no packet(s) received for a
	scheduled time service then then buffer index for that scheduled		specific scheduled time service then buffer index for that scheduled
	service remains empty. This also means that during dequeue, at a		service remains empty. This also means that during dequeue, at a
	schedule time service, an empty index results in no dequeued packets		schedule time service, an empty index results in no dequeued packets
	from the DF queue and thus nothing to be transmitted from the DF		from the DF queue and thus nothing to be transmitted from the DF
	queue at that point in time. Queuing system may de-queue packets		queue at that point in time. Queuing system may de-queue packets
	from non-DF queues when an index in DF buffer list found to be an		from non-DF queues when an index in DF buffer list found to be an
	empty during a specific scheduled time service.		empty during a specific scheduled time service.
	.		.
	|`.		|`.
	EF (Low latency) ----------------||----> `.		EF (Low latency) ----------------||----> `.
	skipping to change at page 7, line 24 ¶		skipping to change at page 6, line 24 ¶
	| .' Low | .'		| .' Low | .'
	BE ----||---> .' | .'		BE ----||---> .' | .'
	| .' | .'		| .' | .'
	.' | .'		.' | .'
	Deterministic| .'		Deterministic| .'
	DF ----------------||----> .'		DF ----------------||----> .'
	(scheduled time/interrupt driven de-queue)|.'		(scheduled time/interrupt driven de-queue)|.'
	2) multiple queues to buffer each DF traffic flows		2) multiple queues to buffer each DF traffic flows
	If enqueue conditioning decides not to discard a packet, packet gets		If conditioning results in not to discard a packet, packet gets
	enqueued in the relevant DF sub-queue designated for that flow. At a		enqueued in the relevant DF queue designated for that flow. At a
	scheduled time slot, scheduler dequeues a packet from the respective		scheduled time slot, scheduler dequeues a packet from the respective
	sub-queue. Every scheduled time service interrupt is mapped to a		queue for that flow. Every scheduled time service interrupt is
	specific DF sub-queue to dequeue a packet from.		mapped to a flow specific DF queue to dequeue a packet from.
	.		.
	|`.		|`.
	EF (Low latency) ----------------||----> `.		EF (Low latency) ----------------||----> `.
	High | `.		High | `.
	. | `.		. | `.
	rate queues |`. | `.		rate queues |`. | `.
	AF1 ----||---> `. | `.		AF1 ----||---> `. | `.
	| `. | `.		| `. | `.
	AF3 ----||---> '------------------> '------>		AF3 ----||---> '------------------> '------>
	| .' Low | .'		| .' Low | .'
	BE ----||---> .' | .'		BE ----||---> .' | .'
	| .' | .'		| .' | .'
	.' | .'		.' | .'
	(DF queues) Deterministic| .'		(DF queues) Deterministic| .'
	DF (at interval 1, 6, 11 ..) ----||----> .'		DF (at interval 1, 6, 11 ..) ----||----> .'
	DF (at interval 3, 8, 13 ..) ----||---->.'		DF (at interval 3, 8, 13 ..) ----||---->.'
	(scheduled time/interrupt driven de-queue)|		(scheduled time/interrupt driven de-queue)|
	3.2. Conditioning DF traffic at Enqueue		7. Updates to RFC4594 and RFC5127
	DF traffic MUST be conditioned at the enqueue. As per PHB
	definition, packets are required to be scheduled and delivered at a
	precise absolute or relative time interval. Any packet that has
	missed the window of its service time MUST be discarded. That would
	also mean any packet coming from the previous hop MUST be conditioned
	at the enqueue for validity of its scheduled service. For example if
	a DF queue is provisioned to serve a packet with less than x ms of
	jitter and for an arrived packet, if next scheduled time for a packet
	results in more than x ms of jitter then such packet MUST be
	discarded. The enqueued packet MUST also be checked against the size
	of the data. If size of the data to be enqueued in a DF queue is
	bigger than what scheduled time slot is provisioned for then such
	packet MUST be discarded.
	4. Diffserv behavior through non-DF DS domains
	In cases where DF traffic is forwarded through multiple DS domains,
	DS domains close to the source and receiver understand application's
	deterministic service requirement well and so MUST be provisioned for
	the precise time scheduled forwarding treatment. Intermediate DS
	domains MAY support DF PHB. Intermediate domains that can not
	support DF PHB, DF traffic from such domains SHOULD get EF treatment,
	as defined in RFC5127 for Real Time Service aggregation. Sender and
	Receiver DS domains, in such cases, MUST condition DF traffic at the
	respective Edge. If EF service through intermediate DS domains can
	have a predictable upper bound, receiver DS domain Edge can add a
	correction to an incurred latency/jitter with its own defined time
	interval for DF service.
	5. Updates to RFC4594 and RFC5127
	This specification updates RFC4594 with an addition of a new Diffserv		This specification updates RFC4594 with an addition of a new Diffserv
	Class. It also updates RFC5127 to aggregate DF class of traffic to		Class. It also updates RFC5127 to aggregate DF class of traffic to
	Real Time Aggregation Class.		Real Time Aggregation Class.
	6. IANA Considerations		8. IANA Considerations
	This document defines a new DSCP code-point DF. IANA maintains the		This document defines a new DSCP code-point DF. IANA maintains the
	list of existing DSCPs. Proposal is to allocate a new one for the DF		list of existing DSCPs. Proposal is to allocate a new one for the DF
	code-point.		code-point.
	7. Security Considerations		9. Security Considerations
	There is no security considerations required besides ones already		There is no security considerations required besides ones already
	understood in the context of Differentiated services architecture		understood in the context of Differentiated services architecture
	8. Acknowledgements		10. Acknowledgements
	Fred Baker and Norm Finn.		Fred Baker, Norm Finn, David Black, Brian Carpenter for their
			comments and feed-back.
	9. References		11. References
	9.1. Normative References		11.1. Normative References
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474, December
	December 1998.		1998.
	[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.
			[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
			"Assured Forwarding PHB Group", RFC 2597, June 1999.
	[RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited		[RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited
	Forwarding PHB", RFC 2598, June 1999.		Forwarding PHB", RFC 2598, June 1999.
	[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration		[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
	Guidelines for DiffServ Service Classes", RFC 4594,		Guidelines for DiffServ Service Classes", RFC 4594, August
	August 2006.		2006.
	[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of		[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
	Diffserv Service Classes", RFC 5127, February 2008.		Diffserv Service Classes", RFC 5127, February 2008.
	9.2. Informative References		11.2. Informative References
	[TiSCH] Thubert, P., Watteyne, T., and R. Assimiti, "An		[TiSCH] Thubert, P., Watteyne, T., and R. Assimiti, "An
	Architecture for IPv6 over the TSCH mode of IEEE		Architecture for IPv6 over the TSCH mode of IEEE
	802.15.4e, I-D.draft-ietf-6tisch-architecture", Nov 2013.		802.15.4e, I-D.draft-ietf-6tisch-architecture", Nov 2013.
	[LLN-DIFF]		[LLN-DIFF]
	Shah, S. and P. Thubert, "Differentiated Service Class		Shah, S. and P. Thubert, "Differentiated Service Class
	Recommendations for LLN Traffic,		Recommendations for LLN Traffic, I-D.draft-svshah-tsvwg-
	I-D.draft-svshah-tsvwg-lln-diffserv-recommendations",		lln-diffserv-recommendations", Aug 2013.
	Aug 2013.
	Authors' Addresses		Authors' Addresses
	Shitanshu Shah		Shitanshu Shah
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: svshah@cisco.com		Email: svshah@cisco.com
End of changes. 35 change blocks.
	215 lines changed or deleted		146 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/