draft-ietf-lwig-terminology-06.txt		draft-ietf-lwig-terminology-07.txt
	LWIG Working Group C. Bormann		LWIG Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Informational M. Ersue		Intended status: Informational M. Ersue
	Expires: June 21, 2014 Nokia Siemens Networks		Expires: August 14, 2014 Nokia Siemens Networks
	A. Keranen		A. Keranen
	Ericsson		Ericsson
	December 18, 2013		February 10, 2014
	Terminology for Constrained Node Networks		Terminology for Constrained Node Networks
	draft-ietf-lwig-terminology-06		draft-ietf-lwig-terminology-07
	Abstract		Abstract
	The Internet Protocol Suite is increasingly used on small devices		The Internet Protocol Suite is increasingly used on small devices
	with severe constraints on power, memory and processing resources,		with severe constraints on power, memory and processing resources,
	creating constrained node networks. This document provides a number		creating constrained node networks. This document provides a number
	of basic terms that have turned out to be useful in the		of basic terms that have turned out to be useful in the
	standardization work for constrained node networks.		standardization work for constrained node networks.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 June 21, 2014.		This Internet-Draft will expire on August 14, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 23		skipping to change at page 2, line 23
	2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5		2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5
	2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6		2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6
	2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 6		2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 6
	2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 7		2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 7
	2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7		2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7
	3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8		3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8
	4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10		4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10		4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10
	4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10		4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10
	4.3. Strategies of Using Power for Communication . . . . . . . 11		4.3. Strategies of Using Power for Communication . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	8. Informative References . . . . . . . . . . . . . . . . . . . 14		8. Informative References . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Small devices with limited CPU, memory, and power resources, so		Small devices with limited CPU, memory, and power resources, so
	called constrained devices (often used as a sensor/actuator, a smart		called constrained devices (often used as a sensor/actuator, a smart
	object, or a smart device) can form a network, becoming "constrained		object, or a smart device) can form a network, becoming "constrained
	nodes" in that network. Such a network may itself exhibit		nodes" in that network. Such a network may itself exhibit
	constraints, e.g. with unreliable or lossy channels, limited and		constraints, e.g. with unreliable or lossy channels, limited and
	skipping to change at page 5, line 27		skipping to change at page 5, line 27
	_constrained node networks_.		_constrained node networks_.
	2.2. Constrained Networks		2.2. Constrained Networks
	We define "constrained network" in a similar way:		We define "constrained network" in a similar way:
	Constrained Network: A network where some of the characteristics		Constrained Network: A network where some of the characteristics
	pretty much taken for granted with link layers in common use in		pretty much taken for granted with link layers in common use in
	the Internet at the time of writing, are not attainable.		the Internet at the time of writing, are not attainable.
			Constraints may include:
			o low achievable bit rate/throughput (including limits on duty
			cycle),
			o high packet loss, high packet loss (delivery rate) variability,
			o highly asymmetric link characteristics,
			o severe penalties for using larger packets (e.g., high packet loss
			due to link layer fragmentation),
			o limits on reachability over time (a substantial number of devices
			may power off at any point in time but periodically "wake up" and
			can communicate for brief periods of time)
			o lack of (or severe constraints on) advanced services such as IP
			multicast.
			More generally, we speak of constrained networks whenever at least
			some of the nodes involved in the network exhibit these
			characteristics.
	Again, there may be several reasons for this:		Again, there may be several reasons for this:
	o cost constraints on the network,		o cost constraints on the network,
	o constraints of the nodes (for constrained node networks),		o constraints of the nodes (for constrained node networks),
	o physical constraints (e.g., power constraints, environmental		o physical constraints (e.g., power constraints, environmental
	constraints, media constraints such as underwater operation,		constraints, media constraints such as underwater operation,
	limited spectrum for very high density, electromagnetic		limited spectrum for very high density, electromagnetic
	compatibility),		compatibility),
	o regulatory constraints, such as very limited spectrum availability		o regulatory constraints, such as very limited spectrum availability
	(including limits on effective radiated power and duty cycle), or		(including limits on effective radiated power and duty cycle), or
	explosion safety,		explosion safety,
	skipping to change at page 5, line 46		skipping to change at page 6, line 19
	compatibility),		compatibility),
	o regulatory constraints, such as very limited spectrum availability		o regulatory constraints, such as very limited spectrum availability
	(including limits on effective radiated power and duty cycle), or		(including limits on effective radiated power and duty cycle), or
	explosion safety,		explosion safety,
	o technology constraints, such as older and lower speed technologies		o technology constraints, such as older and lower speed technologies
	that are still operational and may need to stay in use for some		that are still operational and may need to stay in use for some
	more time.		more time.
	Constraints may include:
	o low achievable bit rate (including limits on duty cycle),
	o high packet loss, packet loss (delivery rate) variability,
	o highly asymmetric link characteristics,
	o severe penalties for using larger packets (e.g., high packet loss
	due to link layer fragmentation),
	o lack of (or severe constraints on) advanced services such as IP
	multicast.
	2.2.1. Challenged Networks		2.2.1. Challenged Networks
	A constrained network is not necessarily a _challenged_ network		A constrained network is not necessarily a _challenged_ network
	[FALL]:		[FALL]:
	Challenged Network: A network that has serious trouble maintaining		Challenged Network: A network that has serious trouble maintaining
	what an application would today expect of the end-to-end IP model,		what an application would today expect of the end-to-end IP model,
	e.g., by:		e.g., by:
	o not being able to offer end-to-end IP connectivity at all;		o not being able to offer end-to-end IP connectivity at all;
	skipping to change at page 7, line 10		skipping to change at page 7, line 14
	The rest of this subsection introduces two additional terms that are		The rest of this subsection introduces two additional terms that are
	in active use in the area of constrained node networks, without an		in active use in the area of constrained node networks, without an
	intent to define them: LLN and (6)LoWPAN.		intent to define them: LLN and (6)LoWPAN.
	2.3.1. LLN ("low-power lossy network")		2.3.1. LLN ("low-power lossy network")
	A related term that has been used to describe the focus of the IETF		A related term that has been used to describe the focus of the IETF
	working group on Routing Over Low power and Lossy networks (ROLL) is		working group on Routing Over Low power and Lossy networks (ROLL) is
	"low-power lossy network" (LLN). The ROLL terminology document		"low-power lossy network" (LLN). The ROLL terminology document
	[I-D.ietf-roll-terminology] defines LLNs as follows:		[RFC7102] defines LLNs as follows:
	LLN: Low power and Lossy networks (LLNs) are typically composed of		LLN: Low power and Lossy networks (LLNs) are typically composed of
	many embedded devices with limited power, memory, and processing		many embedded devices with limited power, memory, and processing
	resources interconnected by a variety of links, such as IEEE		resources interconnected by a variety of links, such as IEEE
	802.15.4 or Low Power WiFi. There is a wide scope of application		802.15.4 or Low Power WiFi. There is a wide scope of application
	areas for LLNs, including industrial monitoring, building		areas for LLNs, including industrial monitoring, building
	automation (HVAC, lighting, access control, fire), connected home,		automation (HVAC, lighting, access control, fire), connected home,
	healthcare, environmental monitoring, urban sensor networks,		healthcare, environmental monitoring, urban sensor networks,
	energy management, assets tracking and refrigeration.. [sic]		energy management, assets tracking and refrigeration.. [sic]
	Beyond that, LLNs often exhibit considerable loss at the physical		Beyond that, LLNs often exhibit considerable loss at the physical
	layer, with significant variability of the delivery rate, and some		layer, with significant variability of the delivery rate, and some
	short-term unreliability, coupled with some medium term stability		short-term unreliability, coupled with some medium term stability
	that makes it worthwhile to construct medium-term stable directed		that makes it worthwhile to construct medium-term stable directed
	acyclic graphs for routing and do measurements on the edges such as		acyclic graphs for routing and do measurements on the edges such as
	ETX [RFC6551]. Actual "low power" does not seem to be a defining		ETX [RFC6551]. Not all LLNs comprise low power nodes
	characteristic for an LLN [I-D.hui-vasseur-roll-rpl-deployment].		[I-D.hui-vasseur-roll-rpl-deployment].
	LLNs typically are composed of constrained nodes; this leads to the		LLNs typically are composed of constrained nodes; this leads to the
	design of operation modes such as the "non-storing mode" defined by		design of operation modes such as the "non-storing mode" defined by
	RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks		RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks
	[RFC6650]). So, in the terminology of the present document, an LLN		[RFC6650]). So, in the terminology of the present document, an LLN
	is a constrained node network with certain network characteristics,		is a constrained node network with certain network characteristics,
	which include constraints on the network as well.		which include constraints on the network as well.
	2.3.2. LoWPAN, 6LoWPAN		2.3.2. LoWPAN, 6LoWPAN
	skipping to change at page 8, line 34		skipping to change at page 8, line 39
	As of the writing of this document, these characteristics correspond		As of the writing of this document, these characteristics correspond
	to distinguishable clusters of commercially available chips and		to distinguishable clusters of commercially available chips and
	design cores for constrained devices. While it is expected that the		design cores for constrained devices. While it is expected that the
	boundaries of these classes will move over time, Moore's law tends to		boundaries of these classes will move over time, Moore's law tends to
	be less effective in the embedded space than in personal computing		be less effective in the embedded space than in personal computing
	devices: Gains made available by increases in transistor count and		devices: Gains made available by increases in transistor count and
	density are more likely to be invested in reductions of cost and		density are more likely to be invested in reductions of cost and
	power requirements than into continual increases in computing power.		power requirements than into continual increases in computing power.
	Class 0 devices are very constrained sensor-like motes. Most likely		Class 0 devices are very constrained sensor-like motes. They are so
	they will not be able to communicate directly with the Internet in a		severely constrained in memory and processing capabilities that most
	secure manner. Class 0 devices will participate in Internet		likely they will not have the resources required to communicate
	communications with the help of larger devices acting as proxies,		directly with the Internet in a secure manner (rare heroic, narrowly
	gateways or servers. Class 0 devices generally cannot be secured or		targeted implementation efforts notwithstanding). Class 0 devices
	managed comprehensively in the traditional sense. They will most		will participate in Internet communications with the help of larger
	likely be preconfigured (and will be reconfigured rarely, if at all),		devices acting as proxies, gateways or servers. Class 0 devices
	with a very small data set. For management purposes, they could		generally cannot be secured or managed comprehensively in the
	answer keepalive signals and send on/off or basic health indications.		traditional sense. They will most likely be preconfigured (and will
			be reconfigured rarely, if at all), with a very small data set. For
			management purposes, they could answer keepalive signals and send on/
			off or basic health indications.
	Class 1 devices cannot easily talk to other Internet nodes employing		Class 1 devices are quite constrained in code space and processing
	a full protocol stack such as using HTTP, TLS and related security		capabilities, such that they cannot easily talk to other Internet
	protocols and XML-based data representations. However, they have		nodes employing a full protocol stack such as using HTTP, TLS and
	enough power to use a protocol stack specifically designed for		related security protocols and XML-based data representations.
	constrained nodes (such as CoAP over UDP [I-D.ietf-core-coap]) and		However, they have enough power to use a protocol stack specifically
	participate in meaningful conversations without the help of a gateway		designed for constrained nodes (such as CoAP over UDP
	node. In particular, they can provide support for the security		[I-D.ietf-core-coap]) and participate in meaningful conversations
	functions required on a large network. Therefore, they can be		without the help of a gateway node. In particular, they can provide
	integrated as fully developed peers into an IP network, but they need		support for the security functions required on a large network.
	to be parsimonious with state memory, code space, and often power		Therefore, they can be integrated as fully developed peers into an IP
	expenditure for protocol and application usage.		network, but they need to be parsimonious with state memory, code
			space, and often power expenditure for protocol and application
			usage.
	Class 2 can already support mostly the same protocol stacks as used		Class 2 devides are less constrained and fundamentally capable of
	on notebooks or servers. However, even these devices can benefit		supporting most of the same protocol stacks as used on notebooks or
	from lightweight and energy-efficient protocols and from consuming		servers. However, even these devices can benefit from lightweight
	less bandwidth. Furthermore, using fewer resources for networking		and energy-efficient protocols and from consuming less bandwidth.
	leaves more resources available to applications. Thus, using the		Furthermore, using fewer resources for networking leaves more
	protocol stacks defined for very constrained devices also on Class 2		resources available to applications. Thus, using the protocol stacks
	devices might reduce development costs and increase the		defined for more constrained devices also on Class 2 devices might
	interoperability.		reduce development costs and increase the interoperability.
	Constrained devices with capabilities significantly beyond Class 2		Constrained devices with capabilities significantly beyond Class 2
	devices exist. They are less demanding from a standards development		devices exist. They are less demanding from a standards development
	point of view as they can largely use existing protocols unchanged.		point of view as they can largely use existing protocols unchanged.
	The present document therefore does not make any attempt to define		The present document therefore does not make any attempt to define
	classes beyond Class 2. These devices can still be constrained by a		classes beyond Class 2. These devices can still be constrained by a
	limited energy supply.		limited energy supply.
	With respect to examining the capabilities of constrained nodes,		With respect to examining the capabilities of constrained nodes,
	particularly for Class 1 devices, it is important to understand what		particularly for Class 1 devices, it is important to understand what
	skipping to change at page 13, line 14		skipping to change at page 13, line 14
	Note that the discussion above is at the device level; similar		Note that the discussion above is at the device level; similar
	considerations can apply at the communications interface level. This		considerations can apply at the communications interface level. This
	document does not define terminology for the latter.		document does not define terminology for the latter.
	A term often used to describe power-saving approaches is "duty-		A term often used to describe power-saving approaches is "duty-
	cycling". This describes all forms of periodically switching off		cycling". This describes all forms of periodically switching off
	some function, leaving it on only for a certain percentage of time		some function, leaving it on only for a certain percentage of time
	(the "duty cycle").		(the "duty cycle").
	[I-D.ietf-roll-terminology] only distinguishes two levels, defining a		[RFC7102] only distinguishes two levels, defining a Non-sleepy Node
	Non-sleepy Node as a node that always remains in a fully powered on		as a node that always remains in a fully powered on state (always
	state (always awake) where it has the capability to perform		awake) where it has the capability to perform communication (P9), and
	communication (P9), and a Sleepy Node as a node that may sometimes go		a Sleepy Node as a node that may sometimes go into a sleep mode (a
	into a sleep mode (a low power state to conserve power) and		low power state to conserve power) and temporarily suspend protocol
	temporarily suspend protocol communication (P0); there is no explicit		communication (P0); there is no explicit mention of P1.
	mention of P1.
	5. Security Considerations		5. Security Considerations
	This document introduces common terminology that does not raise any		This document introduces common terminology that does not raise any
	new security issue. Security considerations arising from the		new security issue. Security considerations arising from the
	constraints discussed in this document need to be discussed in the		constraints discussed in this document need to be discussed in the
	context of specific protocols. For instance, [I-D.ietf-core-coap]		context of specific protocols. For instance, [I-D.ietf-core-coap]
	section 11.6, "Constrained node considerations", discusses		section 11.6, "Constrained node considerations", discusses
	implications of specific constraints on the security mechanisms		implications of specific constraints on the security mechanisms
	employed. A wider view at security in constrained node networks is		employed. [I-D.ietf-roll-security-threats] provides a security
	provided in [I-D.garcia-core-security].		threat analysis for the RPL routing protocol. Implementation
			considerations for security protocols on constrained nodes are
			discussed in [I-D.ietf-lwig-ikev2-minimal] and
			[I-D.ietf-lwig-tls-minimal]. A wider view at security in constrained
			node networks is provided in [I-D.garcia-core-security].
	6. IANA Considerations		6. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Acknowledgements		7. Acknowledgements
	Dominique Barthel and Peter van der Stok provided useful comments;		Dominique Barthel and Peter van der Stok provided useful comments;
	Charles Palmer provided a full editorial review.		Charles Palmer provided a full editorial review.
	skipping to change at page 15, line 19		skipping to change at page 14, line 43
	[I-D.ietf-core-coap]		[I-D.ietf-core-coap]
	Shelby, Z., Hartke, K., and C. Bormann, "Constrained		Shelby, Z., Hartke, K., and C. Bormann, "Constrained
	Application Protocol (CoAP)", draft-ietf-core-coap-18		Application Protocol (CoAP)", draft-ietf-core-coap-18
	(work in progress), June 2013.		(work in progress), June 2013.
	[I-D.ietf-lwig-cellular]		[I-D.ietf-lwig-cellular]
	Arkko, J., Eriksson, A., and A. Keranen, "Building Power-		Arkko, J., Eriksson, A., and A. Keranen, "Building Power-
	Efficient CoAP Devices for Cellular Networks", draft-ietf-		Efficient CoAP Devices for Cellular Networks", draft-ietf-
	lwig-cellular-00 (work in progress), August 2013.		lwig-cellular-00 (work in progress), August 2013.
	[I-D.ietf-roll-terminology]		[I-D.ietf-lwig-ikev2-minimal]
	Vasseur, J., "Terms used in Routing for Low power And		Kivinen, T., "Minimal IKEv2", draft-ietf-lwig-
	Lossy Networks", draft-ietf-roll-terminology-13 (work in		ikev2-minimal-01 (work in progress), October 2013.
	progress), October 2013.
			[I-D.ietf-lwig-tls-minimal]
			Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's
			Guide to the (Datagram) Transport Layer Security Protocol
			for Smart Objects and Constrained Node Networks", draft-
			ietf-lwig-tls-minimal-00 (work in progress), September
			2013.
			[I-D.ietf-roll-security-threats]
			Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
			and M. Richardson, "A Security Threat Analysis for Routing
			Protocol for Low-power and lossy networks (RPL)", draft-
			ietf-roll-security-threats-06 (work in progress), December
			2013.
	[I-D.mariager-6lowpan-v6over-dect-ule]		[I-D.mariager-6lowpan-v6over-dect-ule]
	Mariager, P., Petersen, J., and Z. Shelby, "Transmission		Mariager, P., Petersen, J., and Z. Shelby, "Transmission
	of IPv6 Packets over DECT Ultra Low Energy", draft-		of IPv6 Packets over DECT Ultra Low Energy", draft-
	mariager-6lowpan-v6over-dect-ule-03 (work in progress),		mariager-6lowpan-v6over-dect-ule-03 (work in progress),
	July 2013.		July 2013.
	[ISQ-13] International Electrotechnical Commission, "International		[ISQ-13] International Electrotechnical Commission, "International
	Standard -- Quantities and units -- Part 13: Information		Standard -- Quantities and units -- Part 13: Information
	science and technology", IEC 80000-13, March 2008.		science and technology", IEC 80000-13, March 2008.
	skipping to change at page 16, line 11		skipping to change at page 15, line 47
	[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem		[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
	Statement and Requirements for IPv6 over Low-Power		Statement and Requirements for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Routing", RFC		Wireless Personal Area Network (6LoWPAN) Routing", RFC
	6606, May 2012.		6606, May 2012.
	[RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email		[RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email
	Feedback Reports: An Applicability Statement for the Abuse		Feedback Reports: An Applicability Statement for the Abuse
	Reporting Format (ARF)", RFC 6650, June 2012.		Reporting Format (ARF)", RFC 6650, June 2012.
			[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
			Lossy Networks", RFC 7102, January 2014.
	[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded		[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
	Internet", ISBN 9780470747995, 2009.		Internet", ISBN 9780470747995, 2009.
	[fifty-billion]		[fifty-billion]
	Ericsson, "More Than 50 Billion Connected Devices",		Ericsson, "More Than 50 Billion Connected Devices",
	Ericsson White Paper 284 23-3149 Uen, February 2011,		Ericsson White Paper 284 23-3149 Uen, February 2011,
	<http://www.ericsson.com/res/docs/whitepapers/		<http://www.ericsson.com/res/docs/whitepapers/
	wp-50-billions.pdf>.		wp-50-billions.pdf>.
	Authors' Addresses		Authors' Addresses
End of changes. 18 change blocks.
	66 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/