<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
	<!ENTITY RFC3561 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3561.xml">
	<!ENTITY RFC3626 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3626.xml">
	<!ENTITY RFC3756 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3756.xml">
	<!ENTITY RFC3819 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3819.xml">
    <!ENTITY RFC4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
    <!ENTITY RFC4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
]>

<rfc ipr="full3978" docName="draft-dokaspar-6lowpan-routreq-08">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="no" ?>

	<front>
		<title abbrev="6LoWPAN Routing Requirements">
			Problem Statement and Requirements for 6LoWPAN Routing
		</title>


		<author initials="E." surname="Kim" fullname="Eunsook Eunah Kim">
			<organization>ETRI</organization>
			<address>
				<postal>
					<street>161 Gajeong-dong</street>
					<street>Yuseong-gu</street>
					<city>Daejeon</city>
					<code>305-700</code>
					<country>Korea</country>
				</postal>
				<phone>+82-42-860-6124</phone>
				<email>eunah.ietf@gmail.com</email>
			</address>
		</author>
		<author initials="D." surname="Kaspar" fullname="Dominik Kaspar">
			<organization>Simula Research Laboratory</organization>
			<address>
				<postal>
					<street>Martin Linges v 17</street>
					<city>Snaroya</city>
					<code>1367</code>
					<country>Norway</country>
				</postal>
				<phone>+47-6782-8223</phone>
				<email>dokaspar.ietf@gmail.com</email>
			</address>
		</author>
		
		<author initials="C." surname="Gomez" fullname="Carles Gomez">
			<organization>Tech. Univ. of Catalonia/i2CAT</organization>
			<address>
				<postal>
					<street>Escola Politecnica Superior de Castelldefels</street>
					<street>Avda. del Canal Olimpic, 15</street>
					<city>Castelldefels</city>
					<code>08860</code>
					<country>Spain</country>
				</postal>
				<phone>+34-93-413-7206</phone>
				<email>carlesgo@entel.upc.edu</email>
			</address>
		</author>

		<author initials="C." surname="Bormann" fullname="Carsten Bormann">
			<organization>Universit&auml;t Bremen TZI</organization>
			<address>
				<postal>
					<street>Postfach 330440</street>
					<city>Bremen</city>
					<code>D-28359</code>
					<country>Germany</country>
				</postal>
				<phone>+49-421-218-63921</phone>
				<facsimile>+49-421-218-7000</facsimile>
				<email>cabo@tzi.org</email>
			</address>
		</author>

		<date month="November" year="2008" />

		<area>General</area>
		<workgroup>6LoWPAN Working Group</workgroup>
		<keyword>Internet-Draft</keyword>
		<abstract>
			<t>
				This document provides the problem statement for 6LoWPAN routing.  
				It also defines the requirements for 6LoWPAN routing considering 
				IEEE 802.15.4 specificities and the low-power characteristics of the network 
				and its devices.

			</t>
		</abstract>
	</front>

	<middle>
		<section anchor="problems" title="Problem Statement">
			<t>
				In the context of this document, low-power wireless personal area networks 
				(LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 
				standard  <xref target="refs.IEEE802.15.4"/>.  Most of the LoWPAN devices
				are distinguished by their low bandwidth, short range, scarce memory
				capacity, limited processing capability and other attributes of
				inexpensive hardware.  In this document, the characteristics of nodes
				participating in LoWPANs are assumed to be those described in RFC 4919 <xref target="RFC4919"/>.
			</t>
			<t>
				IEEE 802.15.4 networks support star and mesh topologies and consist
				of two different device types: reduced-function devices (RFDs) and
				full-function devices (FFDs).  RFDs have the most limited
				capabilities and are intended to perform only simple and basic tasks,
				such as reporting sensed data. RFDs may only associate with a single FFD 
				at a time, but FFDs may form arbitrary topologies and implement more advanced
				functions, such as multi-hop routing.
			</t>
			<t>
				However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format
				specification ("IPv6 over IEEE 802.15.4" <xref target="RFC4944"/>) define 
				how mesh topologies could be obtained and maintained.  Thus, the 6LoWPAN
				formation and multi-hop routing should be supported by higher layers,
				either the 6LoWPAN adaptation layer or the IP layer.  A number
				of IP layer routing protocols have been developed in various
				IETF working groups.  However, these existing routing protocols may not 
				satisfy the requirements of mesh routing in LoWPANs, for the following 
				reasons:
				<list style="symbols">
					<t>
						6LoWPAN nodes have special types and roles, such as primary battery-operated RFDs, battery-operated and mains-powered FFDs,
						possibly various levels of RFDs and FFDs, mains-powered and high-performance gateways, data aggregators, etc. 6LoWPAN
						routing protocols should support multiple device types and roles.
					</t>
					<t>
						The more stringent requirements that apply to 6LoWPANs, as opposed
						to higher performance or non-battery-operated networks, may not 
						suffice. 6LoWPAN nodes are characterized by small memory sizes, 
						low processing power, and are running on very limited power supplied
						by primary non-rechargeable batteries (a few KBytes of RAM, 
						a few dozens of KBytes of ROM/flash memory, and a few MHz of CPU is 
						typical).  A node's lifetime is usually defined by the lifetime of 
						its battery.
					</t>
					<t>
						Handling sleeping nodes is very critical in 6LoWPANs, more than in 
						traditional ad-hoc networks. 6LoWPAN nodes might stay in sleep-mode 
						for most of the time. Time synchronization is important for efficient
						forwarding of packets.
					</t>
					<t>
						Routing in LoWPANs might possibly translate to a simpler problem 
						than routing in higher-performance networks. 6LoWPANs might be either
						transit networks or stub networks.  Under the assumption that 6LoWPANs
						are never transit networks (as implied by <xref target="RFC4944"/> 
						and <xref target="refs.6lowpan.nd"/>), routing protocols may be 
						drastically simplified. This document will primarily focus on stub 
						networks. Based on the necessity, this document may be extended 
						with 6LoWPAN network configurations that include transit networks.

					</t>
					<t>
						Routing in 6LoWPANs might possibly translate to a harder problem 
						than routing in higher-performance networks. Routing in 6LoWPANs 
						requires  power-optimization, stable operation in harsh environments,
						data-aware routing, etc.  These requirements are not easily 
						satisfiable all at once.
					</t>
				</list>

				 This creates new challenges on obtaining robust and reliable routing within LoWPANs.
			</t>

			<t>
				The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" <xref target="RFC4919"/>)
				briefly mentions four requirements on routing protocols;
				<list>
					<t>(a) low overhead on data packets</t>
					<t>(b) low routing overhead</t>
					<t>(c) minimal memory and computation requirements</t>
					<t>(d) support for sleeping nodes considering battery saving</t>
				</list>
				These four high-level requirements only describe the need for low overhead and power saving.
				But, based on the fundamental features of LoWPAN, more detailed routing requirements are presented in this document,
				which can lead to further analysis and protocol design.
			</t>
			
			<t>
				Using the 6LoWPAN header format <xref target="RFC4944"/>, there are two layers routing protocols can be defined at, commonly referred to
				as "mesh-under" and "route-over". The mesh-under approach supports routing under the IP link and is directly based
				on the link-layer IEEE 802.15.4 standard, therefore using (64-bit or 16-bit short) MAC addresses. On the other hand,
				the route-over approach relies on IP routing and therefore supports routing over possibly various types of
				interconnected links (see also <xref target="NetworkStack"/>). Most statements in this document consider 
				both the mesh-under and route-over cases.
				<vspace/>
				[Note] The ROLL WG is now working on the protocol survey for Low power
				and Lossy Networks (LLNs), not specifically for 6LoWPAN. 
				After that survey, it will be decided whether new solutions will be 
				developed or not.  This document is focused on 6LoWPAN specific requirements,
				in alignment with the ROLL WG.
			</t>
			<t>
				Considering the problems above, detailed 6LoWPAN routing requirements 
				must be defined.  Application-specific features affect the design of 
				6LoWPAN routing requirements and the corresponding solutions. 
				However, various applications can be profiled by similar technical 
				characteristics, although the related detailed requirements might differ 
				(e.g., a few dozens of nodes for home lighting system need appropriate
				scalability for the applications, while billions of nodes for a
				highway infrastructure system also needs appropriate scalability). 
				This document states the routing requirements of 6LoWPAN applications 
				in general, while trying to give examples for different cases of routing.  
				This routing requirement document does not imply that a single 
				routing solution may be the best one for all 6LoWPAN applications.
			</t>
		</section><!-- end of Chapter 1:problem statement-->

		<section title="Design Space">
			<t>
				Apart from a wide variety of routing algorithms possible for 6LoWPAN, the question remains as to whether routing should
				be performed mesh-under (in the adaptation layer defined by the 6lowpan format document <xref target="RFC4944"/>), or
				by the IP-layer using a route-over approach. The most significant consequence of mesh-under routing is that routing would
				be directly based on the IEEE 802.15.4 standard, therefore using (64-bit or 16-bit short) MAC addresses instead of IP
				addresses, and a LoWPAN would be seen as a single IP link. In case a route-over mechanism is to be applied to a LoWPAN it
				must also support 6LoWPAN's unique properties using global IPv6 addressing. 
				One radio hop would be seen as a single IP link 
				<xref target="refs.6lowpan.nd"/>. In case a route-over mechanism is to be 
				applied to a LoWPAN it must also support 6LoWPAN's unique properties 
				of global IPv6 addressing.  

			</t>
			
			<figure anchor='NetworkStack' title="Mesh-under (left) and route-over routing (right)">
				<preamble>
					<xref target="NetworkStack"/> shows the place of 6LoWPAN routing in the entire network stack.
				</preamble>
				<artwork>
 +-----------------------------+    +-----------------------------+
 |  Application Layer          |    |  Application Layer          |
 +-----------------------------+    +-----------------------------+
 |  Transport Layer (TCP/UDP)  |    |  Transport Layer (TCP/UDP)  |
 +-----------------------------+    +-----------------------------+
 |  Network Layer (IPv6)       |    |  Network       +---------+  |
 +-----------------------------+    |  Layer         | Routing |  |
 |  6LoWPAN       +---------+  |    |  (IPv6)        +---------+  |
 |  Adaptation    | Routing |  |    +-----------------------------+
 |  Layer         +---------+  |    |  6LoWPAN Adaptation Layer   |
 +-----------------------------+    +-----------------------------+
 |  IEEE 802.15.4 (MAC)        |    |  IEEE 802.15.4 (MAC)        |
 +-----------------------------+    +-----------------------------+
 |  IEEE 802.15.4 (PHY)        |    |  IEEE 802.15.4 (PHY)        |
 +-----------------------------+    +-----------------------------+
				</artwork>
				<postamble/>
			</figure>

			<t>
				In order to avoid packet fragmentation and the overhead for reassembly, 
				routing packets should fit into a single IEEE 802.15.4 physical frame 
				and application data should not be expanded to an extent that they 
				no longer fit.
			<t>
			</t>
				If a mesh-under routing protocol is built for operation in 6LoWPAN's
				adaptation layer, routing control packets are placed after the
				6LoWPAN Dispatch, unless a new code type is assigned for mesh-under
				routing.  Multiple routing protocols can be supported by the usage of
				different Dispatch bit sequences.  In use cases where predefined layer 
				two forwarding is appropriate, the mesh-header defined in RFC 4944 
				<xref target="RFC4944"/> is sufficient.
				When a route-over protocol is built in the IPv6 layer, the Dispatch value 
				can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed 
				or uncompressed IPv6, followed by the IPv6 header.
			</t>
			<t>
				 As described in RFC 4944 <xref target="RFC4944"/>, if a 6LoWPAN is formed, 
				 the Edge Router (ER) is the only IPv6 router in the LoWPAN 
				 (see <xref target="6LoWPAN-conf"/>). A mesh-under routing mechanism MUST 
				 be provided to forward packets which require multi-hop forwarding. 
			</t>
			<t>
				If route-over routing is used in the stub-network, not only the ER but 
				also other intermediate nodes become LoWPAN router and set up IPv6 paths 
				for multi-hop transmission.
			</t>	
			<figure anchor='6LoWPAN-conf' title="An example of a 6LoWPAN">
				<preamble></preamble>
				<artwork>
    O   X
   /    |                      ER: Edge Router
  ER --- O --- O --- X          O: Intermediate node (FFD)
       / \                     X: End host (FFD or RFD)                
      X   O --- X                
          |
         / \ 
        O - O -- X
                 </artwork>
			</figure>
			<t>
				If multiple 6LoPWANs are formed with globally unique IPv6 addresses 
				in the 6LoWPANs, and node (a) of 6LoWPAN [A] wants to communicate 
				with node (b) of 6LoWPAN [B], the normal IPv6 mechanisms can be employed. 
				For mesh-under, one way is to configure the ER as the default 
				router for the outgoing packets of the 6LoWPAN.  This, of course, assumes 
				the existence of a mesh-under routing protocol in order to reach the ER.
				For route-over, a default route to the ER could be inserted
				into the routing system.
			</t>	
		</section> <!-- end of Chapter2:Design space-->

	<!-- start of section 3.scenario and parameters -->
		<section anchor="scenarios" title="Scenario Considerations and Parameters for 6LoWPAN Routing">
			<t>
				IP-based low-power WPAN technology is still in its early stage of 
				development, but the range of conceivable usage scenarios is
				tremendous.  The numerous possible applications of sensor networks
				make it obvious that mesh topologies will be prevalent in LoWPAN
				environments and robust routing will be a necessity for expedient
				communication.  Research efforts in the area of sensor networking
				have put forth a large variety of multi-hop routing algorithms
				<xref target="refs.bulusu"/>. Most related work focuses on optimizing 
				routing for specific application scenarios, which can largely be categorized
				into several models of communication, including the following ones:
				<list style="symbols">
				   <t>Flooding (in very small networks)</t>
				   <t>Data-aware routing (dissemination vs. gathering)</t>
				   <t>Event-driven vs. query-based routing</t>
				   <t>Geographic routing</t>
				   <t>Probabilistic routing</t>
				   <t>Hierarchical routing</t>
				</list>
				Depending on the topology of a 6LoWPAN and the application(s) running over it, 
				different types of routing may be used. However, this document abstracts from 
				application-specific communication and describes general routing requirements 
				valid for overall routing in 6LoWPANs.
			</t>

			<t>
				The following parameters can be used to describe specific scenarios 
				in which the candidate routing protocols could be evaluated.
			</t>

			<list style="letters">
				<t>Network Properties:</t>
				<list style="symbols">
					<t>
						Number of Devices, Density and Network Diameter: <vspace/>
						These parameters usually affect the routing state directly
						(e.g. the number of entries in a routing table or neighbor
						list).  Especially in large and dense networks, policies must
						be applied for discarding "low-quality" and stale routing
						entries in order to prevent memory overflow.
					</t>
					<t>
						Connectivity: <vspace/>
						Due to external factors or programmed disconnections, a 6LoWPAN
						can be in several states of connectivity; anything in the
						range from "always connected" to "rarely connected".  This
						poses great challenges to the dynamic discovery of routes
						across a LoWPAN.
					</t>
					<t>
						Dynamicity (including mobility): <vspace/>
						Location changes can be induced by unpredictable external
						factors or by controlled motion, which may in turn cause route
						changes.  Also, nodes may dynamically be introduced into a
						LoWPAN and removed from it later.  The routing state and the
						volume of control messages may heavily dependent on the number
						of moving nodes in a LoWPAN and their speed.
					</t>
					<t>
						Deployment: <vspace/>
						In a LoWPAN, it is possible for nodes to be scattered randomly
						or to be deployed in an organized manner.  The deployment can
						occur at once, or as an iterative process, which may also
						affect the routing state.
					</t>
					<t>
						Spatial Distribution of Nodes and Gateways: <vspace/>
						Network connectivity depends on the spatial distribution of the nodes,
						and on other factors like device number, density and transmission 
						range. For instance, nodes can be placed on a grid, or can be randomly placed in
						an area (bidimensional Poisson distribution), etc.
						In addition, if the LoWPAN is connected to other networks through
						infrastructure nodes called gateways, the number and spatial
						distribution of gateways affects network congestion and available
						bandwidth, among others.
					</t>
					<t>
						Traffic Patterns, Topology and Applications: <vspace/>
						The design of a LoWPAN and the requirements on its application
						have a big impact on the network topology and the most efficient routing type to be
						used.  For different traffic patterns (point-to-point,
						multipoint-to-point, point-to-multipoint) and network
						architectures, various routing mechanisms have been
						introduced, such as data-aware, event-driven, address-centric,
						and geographic routing.
					</t>
					<t>
						Classes of Service: <vspace/>
						For mission-critical applications, support of multiple classes of 
						service may be required in resource-constrained LoWPANs and may 
						require a certain degree of routing protocol overhead.
					</t>
					<t>
						Security: <vspace/>
						LoWPANs may carry sensitive information and require a high
						level of security support where the availability, integrity,
						and confidentiality of data are primordial.  Secured messages
						cause overhead and affect the power consumption of LoWPAN
						routing protocols.
					</t>
				</list> <!-- end of network parameters-->

				<t>Node Parameters:</t>
				<list style="symbols">
					<t>
						Processing Speed and Memory Size: <vspace/>
						These basic parameters define the maximum size of the routing
						state. LoWPAN nodes may have different performance
						characteristics beyond the common RFD/FFD distinction.
					</t>
					<t>
						Power Consumption and Power Source: <vspace/>
						The number and topology of battery- and mains-powered nodes in
						a LoWPAN affect routing protocols in their selection of
						optimal paths for network lifetime maximization.
					</t>
					<t>
						Transmission Range: <vspace/>
						This parameter affects routing.  For example, a
						high transmission range may cause a dense network, which in
						turn results in more direct neighbors of a node, higher
						connectivity  and a larger routing state.
					</t>
					<t>
						Traffic Pattern:
						This parameter affects routing since high-loaded nodes (either
						because they are the source of packets to be transmitted or due
						to forwarding) may incur a greater contribution to delivery
						delays and may consume more energy than lightly loaded nodes.  
						This applies to both data packets and routing control messages.
					</t>
				</list> <!--end of node parameters-->
				
				<t>Link Parameters: 
					<vspace/> <vspace/>
					This section discusses link parameters that apply 
					to IEEE 802.15.4 legacy mode (i.e. not making use of improved modulation schemes).
			    </t>
				<list style="symbols">
				    <t>
						Throughput:
					    <vspace/>
					    <vspace/>
						The maximum user data throughput of a bulk data transmission between a single sender and 
						a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is 
						as follows <xref target="refs.Latre"/>:
						<list style="symbols">
							<t>16-bit MAC addresses, unreliable mode: 	151.6 kbps </t> 				
							<t>16-bit MAC addresses, reliable mode: 	139.0 kbps </t>
							<t>64-bit MAC addresses, unreliable mode: 	135.6 kbps </t>
							<t>64-bit MAC addresses, reliable mode:     124.4 kbps </t>
						</list>
					    <vspace/>
					    <vspace/>
						In the case of 915 MHz band: 
						<list style="symbols">
							<t> 16-bit MAC addresses, unreliable mode: 	31.1 kbps </t>
							<t> 16-bit MAC addresses, reliable mode: 	28.6 kbps </t>
							<t> 64-bit MAC addresses, unreliable mode: 	27.8 kbps </t>
							<t> 64-bit MAC addresses, reliable mode:     25.6 kbps </t>
						</list>
					    <vspace/>	
					    <vspace/>	
						In the case of 868 MHz band: 
						<list style="symbols">
							<t> 16-bit MAC addresses, unreliable mode: 	15.5 kbps </t>
							<t> 16-bit MAC addresses, reliable mode: 	14.3 kbps </t>
							<t> 64-bit MAC addresses, unreliable mode: 	13.9 kbps </t>
							<t> 64-bit MAC addresses, reliable mode:     12.8 kbps </t>
						</list>
					</t>	
				
					<t>
						Latency: <vspace/>
						The range of latencies of a frame transmission between a single sender and 
						a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions 
						are as shown next <xref target="refs.Latre"/>. For unreliable mode, the actual latency is provided. For reliable mode, 
						the round-trip-time including transmission of a layer two acknowledgment is provided:
						<list style="symbols">						
							<t> 16-bit MAC addresses, unreliable mode: 	[1.92 ms, 6.02 ms] </t>
							<t> 16-bit MAC addresses, reliable mode: 	[2.46 ms, 6.56 ms] </t>
							<t> 64-bit MAC addresses, unreliable mode: 	[2.75 ms, 6.02 ms] </t>
							<t> 64-bit MAC addresses, reliable mode:     [3.30 ms, 6.56 ms] </t>
						</list>
					<vspace/>
						In the case of 915 MHz band:
						<list style="symbols">					
							<t> 16-bit MAC addresses, unreliable mode: 	[5.85 ms, 29.35 ms] </t>
							<t> 16-bit MAC addresses, reliable mode: 	[8.35 ms, 31.85 ms] </t>
							<t> 64-bit MAC addresses, unreliable mode: 	[8.95 ms, 29.35 ms] </t>
							<t> 64-bit MAC addresses, reliable mode:     [11.45 ms, 31.85 ms] </t>
						</list>	
					<vspace/>
						In the case of 868 MHz band:
						<list style="symbols">							
							<t> 16-bit MAC addresses, unreliable mode: 	[11.7 ms, 58.7 ms] </t>
							<t> 16-bit MAC addresses, reliable mode: 	[16.7 ms, 63.7 ms] </t>
							<t> 64-bit MAC addresses, unreliable mode: 	[17.9 ms, 58.7 ms] </t>
							<t> 64-bit MAC addresses, reliable mode:     [22.9 ms, 63.7 ms] </t>
						</list>
					</t>	
				</list> <!-- end of link parameters-->
			</list> <!-- end of parameter list-->
		</section> <!-- end of Chapter3: Scenarios and Parameters-->

    <!-- start of section 4.routing requirements -->
		<section anchor="Requirements" title="6LoWPAN Routing Requirements">
			<t>
				This section defines a list of requirements for 6LoWPAN routing.  The
				most important design property unique to low-power networks is that 6LoWPANs
				have to support multiple device types and roles, for example:
				<list style="symbols">
					<t>primarily battery-operated host nodes (called "power-constrained nodes" in the following)</t>
					<t>mains-powered host nodes (an example for what we call "power-affluent nodes")</t>
					<t>power-affluent (but not necessarily mains-powered) high-performance gateway(s)</t>
					<t>possibly various levels of nodes (data aggregators, relayers, 
      etc.)
</t>
				</list>
				<t>
					Due to these unique device types and roles 6LoWPANs need to consider
					the following two primary attributes:
				</t>
				<list style="symbols">
					<t>
						Power conservation: some devices are mains-powered, but most are
						battery-operated and need to last several months to a few years
						with a single AA battery. Many devices are mains-powered most of
						the time, but still need to function for possibly extended periods
						from batteries (e.g. on a construction site before building power
						is switched on for the first time).
					</t>
					<t>
						Low performance: tiny devices, small memory sizes, low-performance 
						processors, low bandwidth, high loss rates, etc.
					</t>
				</list>
				These fundamental attributes of LoWPANs affect the design of routing
				solutions, so that existing routing specifications should be
				simplified and modified to the smallest extent possible when there are appropriate solutions to adapt, 
				otherwise, new solutions should be introduced in order to
				fit the low-power requirements of LoWPANs, meeting the requirements 
				described in the following.
			</t>

		<!-- start of Section 4.1: Device -->
			<section anchor="reqs1" title="Support of 6LoWPAN Device Properties">
				<t>
					The general objectives listed in this section should be followed
					by 6LoWPAN routing protocols. The importance of each requirement is
					dependent on what device type the protocol is running on and what
					the role of the device is. The following requirements are based on battery-powered LoWPAN devices.
				</t>
				<t>
				    [R01] 6LoWPAN routing protocols SHOULD allow to be implemented with small code size  
					and require low routing state to fit the typical 6LoWPAN node capacity 
					(e.g., code size considering its typical flash memory size, and routing table less than 32 entries).
				</t>
				<list>
					<t> <!-- R01: small code-->
						A LoWPAN routing protocol solution should consider the limited memory size 
						typically starting at 4KB.
					    RAM size of 6LoWPAN nodes often ranges between 2KB and 10KB,
						and program flash memory normally consists of 48KB to 128KB.
						(e.g., in the current market, MICAz has 128KB program flash,
						4KB EEPROM, 512KB external flash ROM; TIP700CM has 48KB program
						flash, 10KB RAM, 1MB external flash ROM).   
					</t>
					<t>	
						Due to these hardware restrictions, code length should be considered to
						fit within a small memory size; no more than 48KB to 128KB of flash memory including
						at least a few tens of KB of application code size. 
						A routing protocol of low complexity helps to achieve
						the goal of reducing power consumption, improves robustness,
						requires lower routing state, is easier to analyze, and may be
						implicitly less prone to security attacks. 
					</t>
					<t>
						In addition, operation with low	routing state (such as routing tables and neighbor lists)
						SHOULD be maintained since some typical memory sizes preclude to store 
						state of a large number of nodes. For instance, industrial monitoring applications  
						need to support at maximum 20 hops <xref target="refs.roll.industry"/>.
	
						Small networks can be designed to support a smaller number of hops. 
						It is highly dependent on the network architecture,
						but considering the 6LoWPAN device properties, there should be at least one mode of operation that can 
						function with 32 forwarding entries or less.
					</t>
				</list> <!-- end of R01-->

				<t> <!-- R02: minimal power -->
				    [R02] 6LoWPAN routing protocols SHOULD cause minimal power
					consumption by the efficient use of control packets 
					(e.g., minimize expensive multicast which cause broadcast to the entire 
					LoWPAN) and by the efficient routing of data packets. 
				</t>
				<list>
					<t>
						One way of battery lifetime optimization is by achieving a minimal
						control message overhead. Compared to functions such as in many devices,
						computational operations or taking sensor samples, radio communications 
						is by far the dominant factor of power consumption <xref target="refs.SmartDust"/>.
						Power consumption of transmission and/or reception depends linearly 
						on the length of data units and	on the frequency of transmission 
						and reception of the data units <xref target="refs.Shih"/>.
					</t>
					<t>
						The energy consumption of two
						example RF controllers for low-power nodes is shown in <xref target="refs.Hill"/>.
						The TR1000 radio consumes 21mW when transmitting at 0.75mW, 
						and 15mW on reception (with a receiver sensitivity of -85dBm). 
						The CC1000 consumes 31.6mW when transmitting 0.75mW, and 20mW for receiving (with a receiver sensitivity 
						of -105dBm). The power continuation under the concept of
						an idealized power source is explained in <xref target="refs.Hill"/>.
						Based on the energy of an idealized AA battery, 
						the CC1000 can transmit for approximately 4 days straight or receive
						for 9 consecutive days. Note that availability for reception consumes
						power as well.
					</t>
					<t>
						One multicast packet causes reception of the entire nodes in the LoWPAN, while 
						only the nodes in the path use the reception energy at unicast. Thus, 6LoWPAN routing 
						protocol SHOULD minimize the control cost by the routing packets. 
						Another document discusses control cost of routing protocols in low power and lossy networks <xref target="refs.roll.survey"/>.
					</t>
				</list> <!-- end of R03-->
			</section> <!-- end of section 4.1 -->

		<!-- start of section 4.2 : Link -->
			<section anchor="reqs2" title="Support of 6LoWPAN Link Properties">		
				<t>
					6LoWPAN links have the characteristics of low bandwidth and possibliy high loss rates.
					The routing requirements described in this section are derived from 
					the link properties.
				</t>

				<t> <!-- R03: no fragmentation-->
				    [R03] 6LoWPAN routing protocol control messages SHOULD not create
   					fragmentation of physical layer (PHY) frames.</t>
				<list>
					<t>
						In order to save energy, routing overhead should be minimized to
						prevent fragmentation of frames on the physical layer (PHY).
						Therefore, 6LoWPAN routing should not cause packets to exceed the
						IEEE 802.15.4 frame size.  This reduces the energy required for
						transmission, avoids unnecessary waste of bandwidth, and prevents
						the need for packet reassembly.  As calculated in RFC4944
						<xref target="RFC4944"/>, the maximum size of a 6LoWPAN frame, 
						in order not to cause fragmentation on the PHY layer, is 81 octets. 
						This may imply the use of semantic fragmentation and/or algorithms 
						that can work on small increments of routing information.
					</t>
				</list> <!-- end of R03: no fragmentation-->
								
				<t> <!-- start of R04: NEWLY added on Nov. 3, by EUNAH-->
					[R04] The design of routing protocols for 6LoWPANs must consider the fact that 
					packets are to be delivered	with sufficient probability according to application requirements.
				</t>
				<list>
					<t>
						Requirements on successful end-to-end packet delivery ratio 
						(where delivery may be bounded within certain latency) vary depending 
						on applications. In industrial applications, some non-critical monitoring
						applications may tolerate successful delivery ratio of less than 90% 
						with hours of latency; in some other cases, a delivery ratio of 99.9% 
						is required <xref target="refs.roll.industry"/>. In building automation applications, 
						application layer errors must be below 0.01% <xref target="refs.roll.building"/>.
					</t>
					<t>
						Successful end-to-end delivery of packets in a IEEE 802.15.4 mesh depends on the quality of the path selected by the routing protocol and on the ability of the routing protocol to cope with short-term and long-term quality variation. The metric of the routing protocol strongly influences performance of the routing protocol in terms of delivery ratio. 
					</t>
					<t>
						The quality of a given path depends on the individual qualities of the links (including the devices) that compose that path. IEEE 802.15.4 settings affect the quality perceived at upper layers. In particular, in IEEE 802.15.4 reliable mode, if an acknowledgment frame is not received after a given period, the originator retries frame transmission up to a maximum number of times. If an acknowledgment frame is still not received by the sender after performing the maximum number of transmission attempts, 
						the MAC sub-layer assumes the transmission has failed and notifies the next
						higher layer of the failure. Note that excessive retransmission may be detrimental, 
						see RFC 3819 <xref target="RFC3819"/>.
					</t>
				</list>
				<t> <!-- start of R05: NEWLY added on Nov. 17 -->
					[R05] The design of routing protocols for 6LoWPANs must consider the 
					end-to-end latency requirements of applications and IEEE 802.15.4 link latency characteristics.
				</t>			
				<list>
					<t>
						Latency requirements may differ from a few hundreds milliseconds to minutes, depending on the
						type of application.
						Real-time building automation applications usually need response times 
						below 500 ms between egress and ingress, while 
						forced entry security alerts must be routed to one or more fixed or mobile user devices
						within 5 seconds <xref target="refs.roll.building"/>.
						Non-critical closed loop applications for industrial automation 
						have latency requirements that can be as low as 100 ms but many control loops are 
						tolerant of latencies above 1s <xref target="refs.roll.industry"/>. In contrast to this,
						urban monitoring applications allow latencies smaller than the typical intervals used for
						reporting sensed information; for instance, in the order of seconds to
						minutes <xref target="refs.roll.urban"/>. 
                    </t>
					<t>
						The range of latencies of a frame transmission between a single 
						sender and a single receiver through an ideal unslotted IEEE 802.15.4
						2.4 GHz channel is between 2.46ms and 6.02ms in 64 bit MAC address 
						unreliable mode and 2.20 ms to 6.56ms in 64 bit address reliable
						mode.  The range of latencies of 868 MHz band is from 11.7 ms to
						63.7 ms, depending on the address type and reliable/unreliable
						mode used. Note that the latencies may be larger than that depending 
						on channel load, MAC sublayer settings that regulate medium access 
						procedure, reliable/unreliable mode choice and nodes sleeping.
					</t>
					<t>
						Some routing protocols are aware of the hop count of a path. This 
						parameter may be used as an input to select paths on an end-to-end latency basis if necessary. 
					</t>
					<t>
						Note that a tradeoff exists between [R05] and [R04].
					</t>
				</list>	<!-- end of R05-->				
				
				<t> <!-- start of R06-->
				    [R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss
					caused by link failure or device unavailability either in short-term
					(e.g. due to RSSI variation, interference variation, noise and asynchrony)
					or in long-term (e.g. due to a depleted power source, hardware breakdown,
					operating system misbehavior, etc).
				</t>
				<list>
					<t>
						An important trait of 6LoWPAN devices is their unreliability due to
						limited system capabilities, and also because they might be closely
						coupled to the physical world with all its unpredictable variation.
						In harsh environments, LoWPANs easily suffer from
						link failure. Collision or link failure easily increases Send
						Queue/Receive Queue (SQ/RQ) and it can lead to queue overflow and
						packet losses.
					</t>
					<t>
						For home applications, where users expect feedback after carrying out actions
						(such as handling a remote control while moving around), 
						routing protocols must converge 
						within 2 seconds if the destination node of the packet has moved 
						and must converge within 0.5 seconds if only the sender has moved <xref target="refs.roll.home"/>.
						The tolerance of the recovery time can vary depending on the application, 
						however, the routing protocol must provide the detection of short-term unavailability
						and long-term disappearance. 
				    	The routing protocol has to exploit network resources (e.g. path redundancy) 
					    to offer good network behavior despite of node failure. 
					</t>
				</list> <!-- end of R06-->	
				<t>
					[R07] 6LoWPAN routing protocols SHOULD be designed to correctly operate in the presence of link asymmetry.
				</t>
				<list>
					<t>
						Link asymmetry occurs when the probability of successful transmission
						between two nodes is significantly higher in one direction than in 
						the other one. This phenomenon has been reported in a large number of
						experimental studies and it is expected that 6LoWPANs will exhibit 
						link asymmetry. 
					</t>
				</list>			
			</section>
		<!-- end of section 4.2: link -->	
			
		<!-- start of section 4.3 : Network-->
			<section anchor="reqs3" title="Support of 6LoWPAN Network Characteristics">		
				<t>
					6LoWPANs can be deployed in different sizes and topologies, 
					adhere to various models of mobility, tolerate various levels of interference, etc.
					In any case, 6LoWPANs must maintain low energy consumption.  
					The requirements described in the following subsection are derived 
					from the network attributes of 6LoWPANs.
				</t>	

				<t> <!-- R08: sleep node-->
				    [R08] 6LoWPAN routing protocols SHOULD be reliable despite unresponsive nodes
					due to periodic hibernation. 
				</t>
				<list>
					<t>
						Many nodes in 6LoWPAN environments might periodically hibernate
						(i.e. disable their transceiver activity) in order to save energy.
						Therefore, routing protocols must ensure robust packet
						delivery despite nodes frequently shutting off their radio
						transmission interface. Feedback from the lower IEEE 802.15.4 layer may be considered
						to enhance the power-awareness of 6LoWPAN routing protocols.
					</t>
					<t>
						CC1000-based nodes must operate at a duty cycle 
						of approximately 2% to survive for one year from idealized AA battery power source
						<xref target="refs.Hill"/>.  
						For home automation purposes, it is suggested that
						that the devices have to maximize the sleep phase with a duty cycle lower
						than 1% <xref target="refs.roll.home"/>, while in building automation applications, 
						batteries must be operational
						for at least 5 years when the sensing devices are transmitting data (e.g. 64 bytes) once
						per minute <xref target="refs.roll.building"/>. 
					</t>
					<t>
					    Dependent on the application in use, packet rates differ from 1/sec to 1/day. 
						Routing protocols need to know the cycle of the packet transmission 
						and utilize the information to calculate routing paths.
					</t>
				</list> <!-- end of R08-->
				
				<t> <!-- R09: metrics -->
				    [R09] The metric used by 6LoWPAN routing protocols MAY utilize 
					a combination of the inputs provided by the MAC layer and other measures
					to obtain the optimal path considering energy balance and link quality.
				</t>
				<list>
					<t>
						In homes, buildings, or infrastructure, some nodes will be installed 
						with mains power. Such power-installed nodes MUST be considered 
						as a relay points for more roles in packet delivery. 
						6LoWPAN routing protocols MUST know the power constraints of the nodes.
					</t>
					<t>	
						Simple hop-count-only mechanisms may be inefficient in 6LoWPANs.
						There is a Link Quality Indicator (LQI), Link Delivery Ratio (LDR), or/and RSSI from
						IEEE 802.15.4 that may be taken into account for better metrics.
						The metric to be used (and its goal) may depend on
						application and requirements.
					</t>
					<t>
						The numbers in <xref target="LDR"/> represent the Link Delivery Ratio (LDR)
						of each pair of nodes. There are studies that show a piecewise linear dependence between LQI and
						LDR <xref target="refs.Chen"/>.
					</t>
					<figure anchor='LDR' title="An example network">
						<preamble></preamble>
						<artwork>
                                  0.6
                               A-------C
                                \     /
                             0.9 \   / 0.9
                                  \ /
                                   B
						</artwork>
					</figure>

					<t>
						In this simple example, there are two options in routing from node A 
						to node C, with the following features:
					</t>
					<list style="letters">
						<t>Path AC:</t>
						<list style="symbols">
							<t>(1/0.6) = 1.67 avg. transmissions needed for each packet</t>
							<t>one-hop path</t>
							<t>good in energy consumption and end-to-end latency of data packets, bad in delivery ratio (0.6)</t>
							<t>bad in probability of route reconfigurations</t>
						</list>
						<t>Path ABC</t>
						<list style="symbols">
							<t>2*(1/0.81) = 2.47 avg. transmissions needed for each packet</t>
							<t>two-hop path</t>
							<t>bad in energy consumption and end-to-end latency of data packets, good in delivery ratio (0.81)</t>
						</list>
					</list>
					<t>
						If energy consumption of the network must be minimized, 
						path AC is the best (this path would be chosen based on a hop count 
						metric). However, if the delivery ratio in that case is not sufficient, 
						the best path is ABC (it would be chosen by an LQI based metric). 
						Combinations of both metrics can be used. 
					</t>
					<t>
						The metric also affects the probability of route reconfiguration. 
						Route reconfiguration, which may be triggered by packet losses, 
						may require transmission of routing protocol messages. 
						It is possible to use a metric aimed at selecting the path with low route 
						reconfiguration rate by using LQI as an input to the metric. 
						Such a path has good properties, including stability and low control message overhead.
					</t>
				</list> <!-- end of R09:metrics-->
			
				<t> <!-- R10-->				
					[R10] 6LoWPAN routing protocols SHOULD be designed to achieve both
					scalability from a few nodes to millions of nodes and minimality in terms of used system resources.
				</t>
				<list>
					<t>
						 A 6LoWPAN may consist of just a couple of nodes (for instance in
						 a body-area network), but may expand to much higher numbers of
						 devices (e.g. monitoring of a city infrastructure or a highway).
						 For home automation applications it is envisioned that the routing protocol 
						 must support 250 devices in the network <xref target="refs.roll.home"/>,
						 while routing protocols for metropolitan-scale sensor networks must be capable of clustering
						 a large number of sensing nodes into regions 
						 containing on the order of 10^2 to 10^4 sensing nodes each <xref target="refs.roll.urban"/>.
						 It is therefore necessary that routing mechanisms are designed
						 to be scalable for operation in various network sizes. However,
						 due to a lack of memory size and computational power, 6LoWPAN
						 routing might limit forwarding entries to a small number, such
						 as at maximum 32 routing table entries.
					</t>
				</list> <!--end of R10-->
				
				<t> <!--R11 -->
					[R11] The procedure of route repair and related control messages
					should not harm overall energy consumption from the routing protocols.
				</t>
				<list>
					<t>
						Local repair improves throughput and end-to-end latency, especially
						in large networks. Since routes are repaired quickly, fewer data
						packets are dropped, and a smaller number of routing protocol
						packet transmissions are needed since routes can be repaired without
						source initiated Route Discovery <xref target="refs.Lee"/>. 
						One important consideration here may be to avoid premature 
						depletion, even in case that impairs other requirements.
					</t>
				</list> <!-- end of R11-->

				<t> <!-- R12-->
				    [R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive
					topologies and mobile nodes. When supporting dynamic topologies and
					mobile nodes, route	maintenance should should keep in mind the goal of 
					a minimal routing state and routing protocol message overhead.
				</t>
				<list>
					<t>
						Building monitoring applications, for instance, require that the mobile devices 
						SHOULD be capable of leaving (handing-off) from an old network joining 
						onto a new network within 15 seconds <xref target="refs.roll.building"/>.
						More interactive applications such as used in home automation systems, where users are giving input
						and expect instant feedback, mobility requirements are also stricter and
						a convergence time below 0.5 seconds is commonly required <xref target="refs.roll.home"/>.
						In industrial environments, where mobile equipment such as cranes 
						move around, the support of vehicular speeds of up to 35 km/ph are 
						required to be supported by the routing protocol <xref target="refs.roll.industry"/>. 
						Currently, 6LoWPANs are not being used for such a fast mobility, 
						but dynamic association and disassociation MUST be supported in 6LoWPAN.
					</t>
					<t>
						There are several challenges that should be addressed by a 6LoWPAN
      					routing protocol in order to create robust routing in dynamic
						environments:
						<list style="symbols">
							<t> Mobile nodes changing their location inside a 6LoWPAN:
							    <vspace/>
								If the nodes' movement pattern is unknown, mobility cannot
								easily be detected or distinguished by the routing protocols. 
								Mobile nodes can be treated as nodes that disappear and re-appear 
								in another place. Movement pattern tracking increases complexity and can be
								avoided by handling moving nodes using reactive route updates.
							</t>
							<t> Movement of a 6LoWPAN with respect to other (inter)connected 6LoWPANs:
							    <vspace/>
								Within stub networks, more powerful gateway nodes need to be
								configured to handle moving 6LoWPANs.
							</t>
							<t> Nodes permanently joining or leaving the 6LoWPAN:
							    <vspace/>
								In order to ease routing table updates and reduce error
								control messages, it would be helpful if nodes leaving the network inform
								their coordinator about their intention to disassociate.
							</t>
						</list> <!--end of symbol list-->
					</t>
				</list> <!-- end of R12-->

				<t> <!-- R13: traffic pattern -->
				    [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns;
					point-to-point, point-to-multipoint, and multipoint-to-point, 
					while avoid excessive multicast traffic (broadcast in link layer) in 6LoWPAN.
				</t>
				<list>
					<t>
						6LoWPANs often have point-to-multipoint or multipoint-to-point
						traffic patterns. Many emerging applications include point-to-point
						communication as well. 6LoWPAN routing protocols should
						be designed with the consideration of forwarding packets from/to
						multiple sources/destinations. Current WG drafts in the ROLL working group
						explain that the workload or traffic pattern of use cases for
						6LoWPANs tend to be highly structured, unlike the any-to-any data
						transfers that dominate typical client and server workloads. In many
						cases, exploiting such structure may simplify difficult problems
						arising from resource constraints or variation in connectivity.
					</t>
				</list> <!-- end of R13-->
			</section>	
		<!-- end of section 4.3-->
		
		<!-- start of section :4.4 security -->
			<section anchor="reqs4" title="Support of Security">
				<t>
					The routing requirement described in this subsection allows secure
					transmission of routing messages. Solutions may take into account the
					specific features of IEEE 802.15.4 MAC layers.
				</t>

				<t> <!-- R14: security-->
				    [R14] 6LoWPAN protocols SHOULD support secure delivery of control messages.
				    A minimal security level can be achieved by utilizing AES-based mechanism 
					provided by IEEE 802.15.4.
				</t>
				<list>
					<t>
						Security threats within LoWPANs may be different from existing
						threat models in ad-hoc network environments.  Neighbor Discovery
						in IEEE 802.15.4 links may be susceptible to threats as listed in
						RFC3756 <xref target="RFC3756"/>.  Bootstrapping may also impose additional threats.
						Security is also very important for designing robust routing
						protocols, but it should not cause significant transmission
						overhead. While there are applications which require very high security,
						such as in traffic control, other applications are less easily harmed by
						wrong node behavior, such as a home entertainment system.
					</t>
					<t>
						The IEEE 802.15.4 MAC provides an AES-based security mechanism. Routing
						protocols need to define how this mechanism can be used to obtain
						the intended security. Byte overhead of the mechanism, which depends
						on the security services selected, must be considered. In the worst
						case in terms of overhead, the mechanism consumes 21 bytes of MAC
						payload.
					</t>
				</list> <!-- end of R14 --->
			</section>
		<!-- end of section: 4.4 secuirty -->

		<!-- start of section: 4.5 mesh-under -->
			<section anchor="reqs5" title="Support of Mesh-under Forwarding">		
				<t>
					Reception of an acknowledgement after a frame transmission may 
					render unnecessary the transmission of explicit Hello messages, for example.
				</t>
				
				<t>
				   [R15] In case a routing protocol operates in 6LoWPAN's adaptation layer,
					then routing tables and neighbor lists MUST support 16-bit short and
					64-bit extended addresses.
				</t>
				<t>
					[R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending
					"Hello" messages.  Instead, link-layer mechanisms (such as
					acknowledgments) MAY be utilized to keep track of
					active neighbors.
				</t>
   				<list>
					<t>
						Reception of an acknowledgement after a frame transmission may render unnecessary the transmission of explicit Hello messages, for example.
					</t>
				</list>
				<t>
					[R17] In case there are one or more nodes allocated to coordinator roles, 
					the coordinators MAY take the role of keeping track of node association and 
					de-association within the LoWPAN.
				</t>	
				<t>
					[R18] If the routing protocol functionality includes enabling IP multicast, 
					then it may want to employ coordinator roles, if any, 
					as relay points of group-targeting messages instead of using link-layer multicast 
					(broadcast).
				</t>
			</section>
		<!-- end of mesh-under req -->	
		</section> 
	<!-- end of Requirement section-->

		
		<section title="Security Considerations">
			<t>Security issues are described in Section 4.4. Security considerations 
			of RFC 4919 <xref target="RFC4919"/> and RFC 4944
			<xref target="RFC4944"/> apply as well. More security considerations will result 
			from the 6LoWPAN security analysis work.
			</t>
        	</section>

		<section title="Acknowledgements">
			<t>The authors thank Myung-Ki Shin for giving the idea of writing this draft. 
			The authors also thank to S. Chakrabarti who gave valuable comments for mesh-under requirements.</t>
		</section>
	</middle>

<back>
	<references title='Normative References'>&RFC2119;&RFC3756;&RFC4919;&RFC4944;&RFC3819;
		<reference anchor="refs.IEEE802.15.4">
		 	<front>
			   <title>IEEE Std. 802.15.4-2006 (as amended)</title>
			   <author><organization>IEEE Computer Society</organization></author>
			   <date month="" year="2007"/>
		  	</front>
		</reference>
		
		<!-- previously used references to IEEE 802.15.4 standard (before draft-dokaspar-6lowpan-routreq-07)
		<reference anchor="refs.IEEE802.15.4">
		   <front>
			   <title>IEEE Std. 802.15.4-2003</title>
			   <author><organization>IEEE Computer Society</organization></author>
			   <date month="October" year="2003"/>
		   </front>
		</reference>
		<reference anchor="refs.IEEE802.15.4-2006">
		   <front>
			   <title>IEEE Std. 802.15.4-2006</title>
			   <author><organization>IEEE Computer Society</organization></author>
			   <date month="September" year="2006"/>
		   </front>
		</reference>-->
	 </references>

	<references title='Informative References'>
		<reference anchor="refs.bulusu">
			<front>
				<title>Wireless Sensor Networks</title>
				<author initials="N." surname="Bulusu" fullname="Nirupama Bulusu"></author>
				<author initials="S." surname="Jha" fullname="Sanjay Jha"></author>
				<date month="July" year="2005"/>
			</front>
		</reference>

		<reference anchor="refs.6lowpan.nd">
		   <front>
			   <title>LoWPAN Neighbor Discovery Extensions, draft-shelby-6lowpan-nd-00 (work in progress)</title>
			   <author initials="Z." surname="Shelby" fullname=""></author>
			   <author initials="P." surname="Thubert" fullname=""></author>
			   <author initials="J." surname="Hui" fullname=""></author>
			   <author initials="S." surname="Chakrabarti" fullname=""></author>
			   <author initials="E." surname="Nordmark" fullname=""></author>
			   <date month="October" year="2008"/>
		   </front>
		</reference>

		<reference anchor="refs.SmartDust">
		   <front>
			   <title>Smart Dust: Wireless Networks of Millimeter-Scale Sensor Nodes</title>
			   <author initials="K. S. J." surname="Pister" fullname=""></author>
			   <author initials="B. E." surname="Boser" fullname=""></author>
			   <date month="" year=""/>
		   </front>
		</reference>

		<reference anchor="refs.Hill">
		   <front>
			   <title>System Architecture for Wireless Sensor Networks</title>
			   <author initials="J." surname="Hill" fullname="J. Hill"></author>
			   <date month="" year=""/>
		   </front>
		</reference>

		<reference anchor="refs.Lee">
		   <front>
			   <title>Scalability Study of the Ad Hoc On-Demand Distance-Vector Routing Protocol</title>
			   <author initials="S. J." surname="Lee" fullname=""></author>
			   <author initials="E. M." surname="Belding-Royer" fullname=""></author>
			   <author initials="C. E." surname="Perkins" fullname=""></author>
			   <date month="March" year="2003"/>
		   </front>
		</reference>

		<reference anchor="refs.Shih">
		   <front>
			   <title>Physical Layer Driven Protocols and Algorithm Design for Energy-Efficient Wireless Sensor Networks</title>
			   <author initials="E." surname="Shih" fullname=""></author>
			   <date month="July" year="2001"/>
		   </front>
		</reference>

		<reference anchor="refs.Chen">
		   <front>
			   <title>Ad-Hoc Multicast Routing on Resource-Limited Sensor Nodes</title>
			   <author initials="B." surname="Chen" fullname=""></author>
			   <author initials="K. K." surname="Muniswamy-Reddy" fullname=""></author>
			   <author initials="M." surname="Welsh" fullname=""></author>
			   <date month="" year="2006"/>
		   </front>
		</reference>
		
		<reference anchor="refs.roll.home">
		   <front>
			   <title>Home Automation Routing Requirement in Low Power and Lossy Networks, draft-ietf-roll-home-routing-reqs-04 (work in progress)</title>
			   <author initials="A." surname="Brandt" fullname="Anders Brandt"></author>
			   <author initials="J." surname="Buron" fullname="Jakob Buron"></author>
			   <author initials="G." surname="Porcu" fullname="Giorgio Porcu"></author>
			   <date month="October" year="2008"/>
		   </front>
		</reference> 

		<reference anchor="refs.roll.industry">
		   <front>
			   <title>Industrial Routing Requirements in Low Power and Lossy Networks, draft-ietf-roll-indus-routing-reqs-01 (work in progress)</title>
			   <author initials="K." surname="Pister" fullname="Kris Pister"></author>
			   <author initials="P." surname="Thubert" fullname="Pascal Thubert"></author>
			   <author initials="S." surname="Dwars" fullname="Sicco Dwars"></author>
			   <author initials="T." surname="Phinney" fullname="Tom Phinney"></author>
			   <date month="July" year="2008"/>
		   </front>
		</reference>	
		
		<reference anchor="refs.roll.urban">
		   <front>
			   <title>Urban WSNs Routing Requirements in Low Power and Lossy Networks, draft-ietf-roll-urban-routing-reqs-02 (work in progress)</title>
			   <author initials="M." surname="Dohler" fullname="Mischa Dohler"></author>
			   <author initials="T." surname="Watteyne" fullname="Thomas Watteyne"></author>
			   <author initials="T." surname="Winter" fullname="Tim Winter"></author>
			   <author initials="D." surname="Barthel" fullname="Dominique Barthel"></author>
			   <author initials="C." surname="Jacquenet" fullname="Christian Jacquenet"></author>
			   <date month="October" year="2008"/>
		   </front>
		</reference>	

		<reference anchor="refs.roll.building">
		   <front>
			   <title> Building Automation Routing Requirements in Low Power and Lossy Networks, draft-ietf-roll-building-routing-reqs-01 (work in progress)</title>
			   <author initials="J." surname="Martocci" fullname=""></author>
			   <author initials="P." surname="De Mil" fullname=""></author>
			   <author initials="W." surname="Vermeylen" fullname=""></author>
			   <author initials="N." surname="Riou" fullname=""></author>
		    </front>
		</reference>
		<reference anchor="refs.roll.survey">
		   <front>
			   <title> Overview of Existing Routing Protocols for Low Power and Lossy Networks
, draft-ietf-roll-protocols-survey-02 (work in progress)</title>
			   <author initials="P." surname="Levis" fullname=""></author>
			   <author initials="A." surname="Tavakoli" fullname=""></author>
			   <author initials="S." surname="Dawson-Haggerty" fullname=""></author>
		    </front>
		</reference>
 		<reference anchor="refs.Latre">
		   <front>
			   <title>Throughput and Delay Analysis of Unslotted IEEE 802.15.4</title>
			   <author initials="M." surname="Latre" fullname=""></author>
			   <author initials="P." surname="De Mil" fullname=""></author>
			   <author initials="I." surname="Moerman" fullname=""></author>
			   <author initials="B." surname="Dhoedt" fullname=""></author>
			   <author initials="P." surname="Demeester" fullname=""></author>
			   <date month="May" year="2006"/>
		   </front>
		</reference>	

	</references>

</back>
</rfc>