< draft-svshah-tsvwg-deterministic-forwarding-00.txt		draft-svshah-tsvwg-deterministic-forwarding-01.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: July 12, 2014 January 08, 2014		Expires: September 4, 2014 March 03, 2014
	Deterministic Forwarding PHB		Deterministic Forwarding PHB
	draft-svshah-tsvwg-deterministic-forwarding-00		draft-svshah-tsvwg-deterministic-forwarding-01
	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 also describes
	creation and forwarding treatment of the service class. The document		creation and forwarding treatment of the service class. The document
	also describes how the code-point can be mapped into one of the		also describes how the code-point can be mapped into one of the
	aggregated Diffserv service classes [RFC5127].		aggregated Diffserv service classes [RFC5127].
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 July 12, 2014.		This Internet-Draft will expire on September 4, 2014.
	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 20 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. DF code-point Behavior . . . . . . . . . . . . . . . . . . . . 5		3. DF code-point Behavior . . . . . . . . . . . . . . . . . . . . 5
	3.1. Potential implementation of DF scheduling . . . . . . . . . 6		3.1. Potential implementation of DF scheduling . . . . . . . . 6
	3.2. Conditioning DF traffic at Enqueue . . . . . . . . . . . . 8		3.2. Conditioning DF traffic at Enqueue . . . . . . . . . . . . 8
	4. Diffserv behavior through non-DF DS domains . . . . . . . . . . 8		4. Diffserv behavior through non-DF DS domains . . . . . . . . . 8
	5. Updates to RFC4594 and RFC5127 . . . . . . . . . . . . . . . . 8		5. Updates to RFC4594 and RFC5127 . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	IP Networks typically implement Diffserv to provide differentiated		IP Networks typically implement Diffserv to provide differentiated
	forwarding behavior to different class of traffic. Networks that		forwarding behavior to different class of traffic. Networks that
	implement Diffserv relies on DSCP code-point in the IP header of a		implement Diffserv relies on DSCP code-point in the IP header of a
	packet to select PHB as a specific forwarding treatment for that		packet to select PHB as a specific forwarding treatment for that
	packet [RFC2474, RFC2475]. This document describes a particular PHB		packet [RFC2474, RFC2475]. This document describes a particular PHB
	called Deterministic Forwarding (DF). The proposed new code-point		called Deterministic Forwarding (DF). The proposed new code-point
	defines a service class for the purpose of forwarding treatment of a		defines a service class for the purpose of forwarding treatment of a
	packet at determined/fixed scheduled time providing no jitter service		packet at determined/fixed scheduled time providing no jitter service
	to the class of traffic (updates RFC4594 with the addition of a new		to the class of traffic (updates RFC4594 with the addition of a new
	Service Class).		Service Class).
	DF PHB can be used for the network services that require the		DF PHB can be used for the network services that require the
	capability to ensure a predictable interaction between networked		capability to ensure a predictable interaction between networked
	systems and guarantee a very strict time scheduled services.		systems and guarantee a very strict time scheduled services.
	Applications of such networks may be able to absorb a loss but are		Applications of such networks may be able to absorb a loss but are
	very sensitive to end to end latency and jitter. Examples of such		very sensitive to timely(deterministic) delivery. Examples of such
	networks include Machine to Machine (M2M) control and monitoring		networks include Machine to Machine (M2M) control and monitoring
	deployment with IP over varieties of Layer 2 networks.		deployment with IP over varieties of Layer 2 networks.
	The definition of Expedited Forwarding (EF) [RFC2598] PHB is low		The definition of Expedited Forwarding (EF) [RFC2598] PHB is low
	latency and thus one can envision use of EF code-point for such		latency and thus one can envision use of EF code-point for such
	service. However, even though EF defines low latency and low jitter,		service. However, even though EF defines low latency and low jitter,
	it does not guarantee deterministic/fixed scheduled time service.		it does not guarantee deterministic/fixed scheduled time service.
	Depending on co-existence of the other traffic in the network, EF		Depending on co-existence of the other traffic in the network, EF
	traffic may have more or less variance on jitter and thus not		traffic may have more or less variance on jitter and thus not
	suitable for the deterministic service. DF PHB thus is more suitable		suitable for the deterministic service. DF PHB, as defined in this
	for deterministic time sensitive traffic.		document, thus is more suitable for deterministic time sensitive
			traffic.
	Typically for an application where end to end deterministic service		Typically for an application where end to end deterministic service
	is important, relevant traffic should be provisioned through DF PHB		is important, relevant traffic should be provisioned through DF PHB
	at every hop in that end to end path. However, in cases where		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		intermediate hops (or DS domains) either do not support DF PHB or
	supports only aggregated service classes described in RFC5127, DF		supports only aggregated service classes described in RFC5127, DF
	traffic in those DS domains MUST be mapped to Real Time Treatment		traffic in those DS domains MUST be mapped to Real Time Treatment
	class (EF PHB) defined in RFC5127. Traffic in such scenario MUST be		class (EF PHB) defined in RFC5127. Traffic in such scenario MUST be
	conditioned at the Edge before entering and after exiting such DS		conditioned at the Edge before entering and after exiting such DS
	domains. This is described further in later section.		domains. This is described further in later section.
	1.1. Use-cases		1.1. Use-cases
	With an introduction of machine to machine networks over IP, a new		With an introduction of machine to machine networks over IP, a new
	set of applications are emerging. Traffic types from such		set of applications are emerging. Traffic types from such
	applications/networks are some-what different from the traditional		applications/networks are some-what different from the traditional
	traffic types. Though most traffic types have characteristics		traffic types. Though most traffic types have characteristics
	similar to that of traditional ones [LLN-DIFF], certain control		similar to that of traditional ones [LLN-DIFF], certain control
	signals for some of the applications are extremely sensitive to		signals for some of the applications are extremely sensitive to
	latency and jitter. Such control signals demand much stricter		latency and jitter thus deterministic service. Such control signals
	latency and jitter, at pretty much decisive time scheduled delivery,		demand much stricter latency and jitter, at pretty much decisive time
	end to end. Industrial automation, Smart cities and automobiles/		scheduled delivery, end to end. Industrial automation, Smart cities
	planes/trains built around such networks are examples of such use-		and automobiles/planes/trains built around such networks are examples
	cases.		of such use-cases.
	Machine to machine networks may be implemented on varieties of Layer		Machine to machine networks may be implemented on varieties of Layer
	2 protocols. 802.3 and 802.15e [TiSCH] are examples of layer 2 that		2 protocols. 802.15e [TiSCH] and 802.1 are examples of layer 2 that
	are enhancing their capabilities to allow time scheduled delivery of		are enhancing their capabilities to allow time scheduled delivery of
	packets.		packets.
	In a wireless sensor networks, that are implemented over IP, multiple
	LLN (Low power and Lossy Networks) may be connected through Backbone.
	---+------------------------		---+------------------------
	| Converged Campus Network		| Converged Campus Network
	|		|
	+-----+		+-----+
	| | Gateway		| | Gateway
	| |		| |
	+-----+		+-----+
	|		|
	| Backbone		| Backbone
	+--------------------+------------------+		+--------------------+------------------+
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 41 ¶
	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 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 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 o o o o
	o o o o o		o o o o o
	LLN-1 LLN-2 LLN-3		LLN-1 LLN-2 LLN-3
	As shown in the diagram, multiple LL Networks are connected to each		Taking use-case example from [TiSCH], as shown in the diagram,
	other via Backbone through LLN Border routers. Each LL Network		multiple LL Networks are connected to each other via Backbone through
	consist of many nodes. There are different types of traffic		LLN Border routers. Each LL Network consist of many nodes. There is
	forwarded through each LL node and from one LL Network to another.		different types of traffic forwarded through each LL node and from
	Most LLN traffic types have characteristics similar to that of		one LL Network to another. Most LLN traffic types have
	traditional ones and thus can be supported through existing Diffserv		characteristics similar to that of traditional ones and thus can be
	classes except time sensitive control signals. Without segregating		supported through existing Diffserv classes except time sensitive
	such control signals to a specific Diffserv class would require		control signals. Without segregating such control signals to a
	Intserv support for LLN traffic in such networks. All traffic would		specific Diffserv class would require Intserv support for LLN traffic
	be subject to flow classification to differentiate time sensitive		in such networks. All traffic would be subject to flow
	control signals which can be a big scale concern. Supporting time		classification to differentiate time sensitive control signals which
	sensitive control signals via newly proposed DF Diffserv class allows		can be a big scale concern. Supporting time sensitive control
	implementation of Diffserv in LLN Networks.		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 code-point Behavior
	The DF PHB is to implement time scheduled forwarding treatment.		The DF PHB is to implement time scheduled forwarding treatment.
	Provisioning of such a service has two parts,		Provisioning of such a service has two parts,
	1) Provisioning of the fixed/relative time for scheduling of such		1) Provisioning of the fixed/relative time for scheduling of such
	service		service
	2) Provisioning of the max size of the data to be transmitted at		2) Provisioning of the max size of the data to be transmitted at
	each scheduled time		each scheduled time.
	Provisioned scheduled time may be absolute or relative. For example,		Provisioned scheduled time may be absolute or relative. For example,
	a DF class may be provisioned to schedule packets (or bytes) at every		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		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		definition. In a multi hop forwarding of DF traffic, absolute time
	service provisioning at each hop may require to be dependent on the		service provisioning at each hop may require to be dependent on the
	clock synchronization (clock synchronization is not in the scope of		clock synchronization (clock synchronization is not in the scope of
	this specification). In relative time scheduling, packets to be		this specification). In relative time scheduling, packets to be
	scheduled at every specific interval or it could be relative to any		scheduled at every specific interval or it could be relative to any
	other specific event/trigger. The definition of the time interval or		other specific event/trigger. The definition of the time interval or
	any other event is relevant to that specific provisioned node only.		any other event is relevant to that specific provisioned node only.
	The size of the data, to be transmitted at each scheduled time		The size of the data to be transmitted, at each scheduled time
	service, provisioned can be in the unit of bytes or time. Once DF		service, may be provisioned in the unit of bytes or time. The data
	PHB is provisioned and enabled, forwarding treatment MUST service		defined here is raw data transmitted over transmission media,
	packets (bytes) from this class at the scheduled time for max		including Layer 2 header and any other overhead. Once DF PHB is
	allowable data. Scheduling MUST pre-empt any other service,		provisioned and enabled, forwarding treatment MUST service packets
	including EF, during the schedule time service for the DF class. In		(bytes) from this class at the scheduled time for max allowable size.
	order to avoid incurred latency to EF class of traffic, it is		Scheduling MUST pre-empt any other service, including EF, during the
	expected to carefully provision DF class to limit scheduled time		schedule time service for the DF class. In order to avoid incurred
	service to as minimal data transmission that would prevent larger		latency to EF class of traffic, it is expected to carefully provision
	than expected delays to EF class of traffic.		DF class to limit scheduled time service to as minimal data
			transmission that would prevent larger than expected delays to EF
			class of traffic.
	Provisioning can be done via any of multiple possible methods. It		Provisioning can be done via any of multiple possible methods. It
	could be via command interface, or could be via external provisioning		could be via command interface, or could be via external provisioning
	agents, or could be via some sort of signaling that may dynamically		agents, or could be via some sort of signaling that may dynamically
	pre-negotiate time window of transmission at each node in a network		pre-negotiate time window of transmission at each node in a network
	path.		path.
	3.1. Potential implementation of DF scheduling		3.1. 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.		any form of guidelines or recommendations but simply a reference to
			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 sub-queues for DF traffic class, one queue for each DF
	provisioned flow		provisioned flow
	Flow here represents macro definition, it does not have to be only		Flow here represents macro definition, it does not have to be only
	5-tuple.		5-tuple.
	Any chosen DF scheduling implementation MUST run traffic conditioning		Any chosen DF scheduling implementation MUST run traffic conditioning
	at enqueue to decide if packets to be enqueued or discarded.		at enqueue to decide if packets to be enqueued or discarded.
	Discussed more in later section.		Discussed more in later section.
	1) One data-plane 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 one queue maintains, possibly a circular, indexed buffer list.
	Every time scheduled slot is an index in the buffer list. If enqueue		Each index logically maps to each scheduled time service. If enqueue
	conditioning decides not to discard a packet, packet gets en-queued		conditioning not to discard a packet, packet gets en-queued at a
	at the relevant index in the buffer list in such a way that relevant		relevant index in the buffer list that maps to a relevant scheduled
	index pointer, and thus buffered relevant packets for that index, at		time slot. If there is no packet(s) received for a specific
	the head of the list is ready to be de-queued at next scheduled time.		scheduled time service then then buffer index for that scheduled
	Subsequent buffer index is scheduled for the subsequent scheduled		service remains empty. This also means that during dequeue, at a
	time slot and so forth. If a specific flow has not received any		schedule time service, an empty index results in no dequeued packets
	packet for a scheduled time then buffer index for that flow remains		from the DF queue and thus nothing to be transmitted from the DF
	empty. A packet from other flows do not get buffered at that empty		queue at that point in time. Queuing system may de-queue packets
	index. That means during dequeue, at a schedule time service, an		from non-DF queues when an index in DF buffer list found to be an
	empty index results in no packets to dequeue and thus nothing to be		empty during a specific scheduled time service.
	transmitted from the DF queue at that point in time.
	.		.
	|`.		|`.
	EF (Low latency) ----------------||----> `.		EF (Low latency) ----------------||----> `.
	High | `.		High | `.
	. | `.		. | `.
	rate queues |`. | `.		rate queues |`. | `.
	AF1 ----||---> `. | `.		AF1 ----||---> `. | `.
	| `. | `.		| `. | `.
	AF3 ----||---> '------------------> '------>		AF3 ----||---> '------------------> '------>
	| .' Low | .'		| .' Low | .'
	BE ----||---> .' | .'		BE ----||---> .' | .'
	| .' | .'		| .' | .'
	.' | .'		.' | .'
	Deterministic| .'		Deterministic| .'
	DF ----------------||----> .'		DF ----------------||----> .'
	(scheduled time/interrupt driven de-queue)|.'		(scheduled time/interrupt driven de-queue)|.'
	2) multiple sub-queues for each DF flows		2) multiple queues to buffer each DF traffic flows
	If enqueue conditioning decides not to discard a packet, packet gets		If enqueue conditioning decides 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 sub-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		sub-queue. Every scheduled time service interrupt is mapped to a
	specific DF sub-queue to dequeue a packet from.		specific DF sub-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)|
	3.2. Conditioning DF traffic at Enqueue		3.2. Conditioning DF traffic at Enqueue
	DF traffic MUST be conditioned at the enqueue. As per PHB		DF traffic MUST be conditioned at the enqueue. As per PHB
	definition, packets are required to be scheduled and delivered at a		definition, packets are required to be scheduled and delivered at a
	precise absolute or relative time interval. Any packet that has		precise absolute or relative time interval. Any packet that has
	missed the window of its service time MUST be discarded. That would		missed the window of its service time MUST be discarded. That would
	also mean any packet coming from the previous hop MUST be conditioned		also mean any packet coming from the previous hop MUST be conditioned
	at the enqueue for validity of its scheduled service. For example if		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		a DF queue is provisioned to serve a packet with less than x ms of
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 30 ¶
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.		December 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.
	[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
			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.
	9.2. Informative References		9.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]
End of changes. 19 change blocks.
	71 lines changed or deleted		77 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/