--- 1/draft-ietf-roll-home-routing-reqs-06.txt 2009-09-15 03:12:14.000000000 +0200 +++ 2/draft-ietf-roll-home-routing-reqs-07.txt 2009-09-15 03:12:14.000000000 +0200 @@ -1,106 +1,163 @@ Networking Working Group A. Brandt Internet Draft Zensys, Inc. Intended status: Informational G. Porcu -Expires: May 2009 Telecom Italia - November 19, 2008 +Expires: March 2010 Telecom Italia + September 14, 2009 Home Automation Routing Requirements in Low Power and Lossy Networks - draft-ietf-roll-home-routing-reqs-06 + draft-ietf-roll-home-routing-reqs-07 Status of this Memo - By submitting this Internet-Draft, each author represents that - any applicable patent or other IPR claims of which he or she is - aware have been or will be disclosed, and any of which he or she - becomes aware will be disclosed, in accordance with Section 6 of - BCP 79. + This Internet-Draft is submitted to IETF in full conformance with + the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html + http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 19, 2009. + This Internet-Draft will expire on March 14, 2010. Copyright Notice - Copyright (C) The IETF Trust (2008). + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license- + info). + Please review these documents carefully, as they describe your + rights and restrictions with respect to this document. Abstract This document presents home control and automation application specific requirements for Routing Over Low power and Lossy - networks (ROLL). In a modern home, a high number of wireless - devices are used for a wide set of purposes. Examples include - actuators (relay, light dimmer, heating valve), sensors (wall - switch, water leak, blood pressure) and advanced controllers. - Because such devices only cover a limited radio range, routing is - often required. The aim of this document is to specify the routing - requirements for networks comprising such constrained devices in a - home control and automation environment. + networks (ROLL). In the near future many homes will contain high + numbers of wireless devices for a wide set of purposes. Examples + include actuators (relay, light dimmer, heating valve), sensors + (wall switch, water leak, blood pressure) and advanced controllers + (RF-based AV remote control, Central server for light and heat + control). Because such devices only cover a limited radio range, + routing is often required. The aim of this document is to specify + the routing requirements for networks comprising such constrained + devices in a home control and automation environment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents - Terminology......................................................3 - 1. Introduction..................................................5 - 2. Home Automation Applications..................................6 - 2.1. Lighting Application In Action...........................6 - 2.2. Energy Conservation and Optimizing Energy Consumption....6 - 2.3. Moving a Remote Control Around...........................7 - 2.4. Adding A New Module To The System........................7 - 2.5. Controlling Battery Operated Window Shades...............8 - 2.6. Remote Video Surveillance................................8 - 2.7. Healthcare...............................................8 - 2.7.1. At-home Health Reporting............................9 - 2.7.2. At-home Health Monitoring...........................9 - 2.8. Alarm Systems............................................9 - 3. Unique Routing Requirements of Home Automation Applications..10 - 3.1. Constraint-based Routing................................11 - 3.2. Support of Mobility.....................................12 - 3.3. Sleeping Nodes..........................................12 - 3.4. Healthcare Routing......................................12 - 3.5. Scalability.............................................13 - 3.6. Convergence Time........................................13 - 3.7. Manageability...........................................13 - 3.8. Stability...............................................14 - 4. Traffic Pattern..............................................14 - 5. Open Issues..................................................14 - 6. Security Considerations......................................15 - 7. IANA Considerations..........................................15 - 8. Acknowledgments..............................................15 - 9. References...................................................15 - 9.1. Normative References....................................15 - 9.2. Informative References..................................16 - Disclaimer of Validity..........................................17 + 1. Introduction..............................................4 + 1.1. Terminology...........................................5 + 2. Home Automation Applications...............................6 + 2.1. Lighting Application In Action.........................6 + 2.2. Energy Conservation and Optimizing Energy Consumption...7 + 2.3. Moving a Remote Control Around.........................7 + 2.4. Adding A New Module To The System......................8 + 2.5. Controlling Battery Operated Window Shades..............8 + 2.6. Remote Video Surveillance..............................8 + 2.7. Healthcare............................................8 + 2.7.1. At-home Health Reporting..........................9 + 2.7.2. At-home Health Monitoring........................10 + 2.8. Alarm Systems........................................10 + 3. Unique Routing Requirements of Home Automation Applications.11 + 3.1. Constraint-based Routing..............................11 + 3.2. Support of Mobility..................................12 + 3.3. Sleeping Nodes.......................................13 + 3.4. Healthcare Routing...................................13 + 3.5. Scalability..........................................13 + 3.6. Convergence Time.....................................14 + 3.7. Manageability........................................14 + 3.8. Stability............................................14 + 4. Traffic Pattern...........................................14 + 5. Security Considerations...................................15 + 6. IANA Considerations.......................................17 + 7. Acknowledgments...........................................17 + 8. References...............................................17 + 8.1. Normative References.................................17 + 8.2. Informative References...............................18 + Disclaimer of Validity...............Error! Bookmark not defined. -Terminology +1. Introduction + + This document presents home control and automation application + specific requirements for Routing Over Low power and Lossy + networks (ROLL). In the near future many homes will contain high + numbers of wireless devices for a wide set of purposes. Examples + include actuators (relay, light dimmer, heating valve), sensors + (wall switch, water leak, blood pressure) and advanced + controllers. Basic home control modules such as wall switches and + plug-in modules may be turned into an advanced home automation + solution via the use of an IP-enabled application responding to + events generated by wall switches, motion sensors, light sensors, + rain sensors, and so on. + + Network nodes may be sensors and actuators at the same time. An + example is a wall switch for replacement in existing homes. The + push buttons may generate events for a controller node or for + activating other actuator nodes. At the same time, a built-in + relay may act as actuator for a controller or other remote + sensors. + + Because ROLL nodes only cover a limited radio range, routing is + often required. These devices are usually highly constrained in + term of resources such as battery and memory and operate in + unstable environments. Persons moving around in a house, opening + or closing a door or starting a microwave oven affect the + reception of weak radio signals. Reflection and absorption may + cause a reliable radio link to turn unreliable for a period of + time and then being reusable again, thus the term "lossy". All + traffic in a ROLL network is carried as IPv6 packets. + + Unlike other categories of Personal Area Networks (PANs), the + connected home area is very much consumer-oriented. The + implication on network nodes is that devices are very cost + sensitive, which leads to resource-constrained environments having + slow CPUs and small memory footprints. At the same time, nodes + have to be physically small which puts a limit to the physical + size of the battery; and thus, the battery capacity. As a result, + it is common for low-power sensor-style nodes to shut down radio + and CPU resources for most of the time. The radio tends to use the + same power for listening as for transmitting + + Section 2 describes a few typical use cases for home automation + applications. Section 3 discusses the routing requirements for + networks comprising such constrained devices in a home network + environment. These requirements may be overlapping requirements + derived from other application-specific routing requirements + presented in [I-D.Martocci-Building-reqs], [I-D.Pister-Industial- + reqs] and [RFC5548]. + + A full list of requirements documents may be found in section 9. + +1.1. Terminology ROLL: Routing Over Low-power and Lossy networks A ROLL node may be classified as sensor, actuator or controller. Actuator: Network node which performs some physical action. Dimmers and relays are examples of actuators. If sufficiently powered, actuator nodes may participate in routing network messages. @@ -122,137 +179,84 @@ DR: Demand-Response The mechanism of users adjusting their power consumption in response to actual pricing of power. DSM: Demand Side Management Process allowing power utilities to enable and disable loads in consumer premises. Where DR relies on voluntary action from users, DSM may be based on enrollment in a formal program. + HC-LLN: Home Control in Low-Power and Lossy Networks + LAN: Local Area Network. PAN: Personal Area Network. A geographically limited wireless network based on e.g. 802.15.4 or Z-Wave radio. PDA Personal Digital Assistant. A small, handheld computer. PLC Power Line Communication RAM Random Access Memory - - Sensor: Network node that measures data and/or detects an - event. + Sensor: Network node that measures some physical parameter + and/or detects an event. The sensor may generate a trap message to notify a controller or directly activate an actuator. If sufficiently powered, sensor nodes may participate in routing network messages. Upstream: Data direction traveling from a PAN to a LAN device. - Refer to the roll-terminology reference document for a full list - of terms used in the IETF ROLL WG (I-D.draft-ietf-roll-terminology). - -1. Introduction - - This document presents home control and automation application - specific requirements for Routing Over Low power and Lossy - networks (ROLL). In a modern home, a high number of wireless - devices are used for a wide set of purposes. Examples include - actuators (relay, light dimmer, heating valve), sensors (wall - switch, water leak, blood pressure) and advanced controllers. - Basic home control modules such as wall switches and plug-in - modules may be turned into an advanced home automation solution - via the use of an IP-enabled application responding to events - generated by wall switches, motion sensors, light sensors, rain - sensors, and so on. - - Network nodes may be sensors and actuators at the same time. An - example is a wall switch for replacement in existing buildings. - The push buttons may generate events for a controller node or for - activating other actuator nodes. At the same time, a built-in - relay may act as actuator for a controller or other remote - sensors. - - Because ROLL nodes only cover a limited radio range, routing is - often required. These devices are usually highly constrained in - term of resources such as battery and memory and operate in - unstable environments. Persons moving around in a house, opening - or closing a door or starting a microwave oven affect the - reception of weak radio signals. Reflection and absorption may - cause a reliable radio link to turn unreliable for a period of - time and then being reusable again, thus the term "lossy". - - Unlike other categories of PANs, the connected home area is very - much consumer-oriented. The implication on network nodes is that - devices are very cost sensitive, which leads to resource- - constrained environments having slow CPUs and small memory - footprints. At the same time, nodes have to be physically small - which puts a limit to the physical size of the battery; and thus, - the battery capacity. As a result, it is common for low-power - sensor-style nodes to shut down radio and CPU resources for most - of the time. The radio tends to use the same power for listening - as for transmitting - - Section 2 describes a few typical use cases for home automation - applications. Section 3 discusses the routing requirements for - networks comprising such constrained devices in a home network - environment. These requirements may be overlapping requirements - derived from other application-specific routing requirements. A - full list of requirements documents may be found in the end of the - document. + Refer to the roll-terminology reference document [I-D.Vasseur- + Terminology] for a full list of terms used in the IETF ROLL WG. 2. Home Automation Applications Home automation applications represent a special segment of networked devices with its unique set of requirements. Historically, such applications used wired networks or power line communication (PLC), but wireless solutions have emerged; allowing - existing buildings to be upgraded more easily. + existing homes to be upgraded more easily. To facilitate the requirements discussion in Section 3, this section lists a few typical use cases of home automation applications. New applications are being developed at a high pace and this section does not mean to be exhaustive. Most home automation applications tend to be running some kind of command/response protocol. The command may come from several places. 2.1. Lighting Application In Action A lamp may be turned on, not only by a wall switch but also by a movement sensor. The wall switch module may itself be a push- button sensor and an actuator at the same time. This will often be - the case when upgrading existing buildings as existing wiring is - not prepared for automation. + the case when upgrading existing homes as existing wiring is not + prepared for automation. One event may cause many actuators to be activated at the same time. Using the direct analogy to an electronic car key, a house owner may activate the "leaving home" function from an electronic house key, mobile phone, etc. For the sake of visual impression, all lights should turn off at the same time. At least, it should appear to happen at the same time. A well-known problem in wireless home automation is the "popcorn effect": Lamps are turned on one at a time, at a rate so slow that it is clearly visible. - Some existing home automation solutions use a clever mix of a - "subnet groupcast" message in direct range with no acknowledgement - before sending acknowledged singlecast messages to each device. - Subnet groupcast, being an application-level feature, is not - further discussed in this specification. - - The controller forms the group and decides which nodes should - receive a message. + Some existing home automation solutions address this by sending an + unacknowledged multicast message in direct range before sending + acknowledged singlecast messages to each device. 2.2. Energy Conservation and Optimizing Energy Consumption In order to save energy, air conditioning, central heating, window shades etc. may be controlled by timers, motion sensors or remotely via internet or cell. Central heating may also be set to a reduced temperature during night time. The power grid may experience periods where more wind-generated power is produced than is needed. Typically this may happen during @@ -328,21 +332,21 @@ may be triggered by the end-user after receiving an alarm from a sensor (movement or smoke detector) or the user simply wants to check the home status via video. Note that in the former case, more than likely, there will be a form of inter-device communication: Upon detecting some movement in the home, the movement sensor may send a request to the light controller to turn on the lights, to the Web Cam to start a video stream that would then be directed to the end user's cell phone or Personal Digital Assistant (PDA) via the Internet. In contrast to other applications, e.g. industrial sensors, where - data would mainly be originated by sensor to a sink and vice + data would mainly be originated by a sensor to a sink and vice versa, this scenario implicates a direct inter-device communication between ROLL devices. 2.7. Healthcare By adding communication capability to devices, patients and elderly citizens may be able to do simple measurements at home. Thanks to online devices, a doctor can keep an eye on the patient's health and receive warnings if a new trend is discovered by automated filters. @@ -360,20 +364,31 @@ processing to the receiving data sink. A more active category of applications may send an alarm if some alarm condition is triggered. This category of applications is referred to as at-home health monitoring. Measurements are interpreted in the device and may cause reporting of an event if an alarm is triggered. Many implementations may overlap both categories. + Since wireless and battery operated systems may never reach 100% + guaranteed operational time, healthcare and security systems will + need a management layer implementing alarm mechanisms for low + battery, report activity, etc. + For instance if a blood pressure sensor did not report a new + measurement, say 5 minutes after the scheduled time, some + responsible person must be notified. + The structure and performance of such a management layer is + outside the scope of the routing requirements listed in this + document. + 2.7.1. At-home Health Reporting Applications might include: o Temperature o Weight o Blood pressure o Insulin level Measurements may be stored for long term statistics. At the same @@ -452,20 +467,23 @@ +-------------------------------+-----------------------------+ |2.3. Moving a Remote Control |3.2. Support of Mobility | |Around |3.6. Convergence Time | +-------------------------------+-----------------------------+ |2.4. Adding A New Module To The |3.6. Convergence Time | |System |3.7. Manageability | +-------------------------------+-----------------------------+ |2.5. Controlling Battery |3.3. Sleeping Nodes | |Operated Window Shades | | +-------------------------------+-----------------------------+ + |2.6. Remote Video Surveillance |3.3. Sleeping Nodes | + | |3.6. Convergence Time | + +------------------------------- +-----------------------------+ |2.7. Healthcare |3.1. Constraint-based Routing| | |3.2. Support of Mobility | | |3.4. Healthcare Routing | | |3.6. Convergence Time | +-------------------------------+-----------------------------+ |2.8. Alarm Systems |3.5. Scalability | | |3.6. Convergence Time | +-------------------------------+-----------------------------+ 3.1. Constraint-based Routing @@ -514,53 +531,66 @@ e.g. pause the music. While, in theory, all battery-powered devices and mains-powered plug-in modules may be moved, the predominant case is that the sending node has moved while the rest of the network has not changed. The routing protocol MUST provide mobility with convergence time below 0.5 second if only the sender has moved. + In more rare occasions, receiving nodes may also have moved. + Examples include safety-off switch in a clothes iron or the + wireless chime of doorbell set. + + The routing protocol MUST provide mobility with convergence time + below 4 seconds if the receiver has moved. + A non-responsive node can either be caused by 1) a failure in the node, 2) a failed link on the path to the node or 3) a moved node. In the first two cases, the node can be expected to reappear at roughly the same location in the network, whereas it can return anywhere in the network in the latter case. 3.3. Sleeping Nodes Sleeping nodes may appear to be non-responsive. The routing protocol MUST take into account the delivery time to a sleeping target node. - The wake-up interval of a sleeping node MUST be less than one - second. - 3.4. Healthcare Routing Because most health care applications may run on battery, this leads to specific requirements for the routing protocol. Most health care applications may also be portable and therefore need to locate a new neighbor router on a frequent basis. Not being powered most of the time, the nodes should not be used as routing nodes. However, battery-powered nodes may be involved in routing. Examples include cases where a person falls during a power blackout. In that case it may be that no mains-powered routers are available for forwarding the alarm message to a (battery-backed) internet gateway located out of direct range. Delivery of measurement data has a more relaxed requirement for route discovery time compared to a remote control. On the other hand, it is critical that a "person fell" alarm is actually delivered. + If possible at all, the routing protocol MUST deliver a health- + care related message. It is NOT a requirement that such message is + delivered in less than a second. + + The routing protocol SHOULD support acknowledged transmission. If + the routing protocol does not support acknowledged transmission, + some higher-layer transport protocol or application MUST ensure + delivery of such messages. + 3.5. Scalability Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of low power devices may form a home automation network in a fully populated "smart" home. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol MUST support 250 devices in the network. @@ -595,20 +625,24 @@ to the network. From a routing perspective, zero-configuration means that a node can obtain an address and join the network on its own, without human intervention. 3.8. Stability The routing protocol MUST support the ability to isolate a misbehaving node thus preserving the correct operation of the overall network. + In other words, if a node is found to fail often compared to the + rest of the network, this node should not be the first choice for + routing of traffic. + 4. Traffic Pattern Depending on the design philosophy of the home network, wall switches may be configured to directly control individual lamps or alternatively, all wall switches send control commands to a central lighting control computer which again sends out control commands to relevant devices. In a distributed system, the traffic tends to be multipoint-to- multipoint. In a centralized system, it is a mix of multipoint-to- @@ -627,127 +661,181 @@ period with no movement has elapsed. The highest transmission frequency depends on the idle period used in the sensor. Sometimes, a timer will trigger a frame transmission when an extended period without status change has elapsed. All frames sent in the above examples are quite short, typically less than 5 bytes of payload. Lost frames and interference from other transmitters may lead to retransmissions. In all cases, acknowledgment frames with a size of a few bytes are used. -6. Security Considerations + As mentioned in the introduction, all messages are carried in IPv6 + packets; typically as UDP but ICMP echo and other types may also + appear. + In order to save bandwidth, the transport layer will typically be + using header compression [I-D.Hui-HeaderCompression]. - Implementing security mechanisms in ROLL network devices may - degrade energy efficiency and increase cost. +5. Security Considerations - The routing protocol chosen for ROLL MUST allow for low-power, - low-cost network devices with limited security needs. + As every network, HC-LLNs are exposed to routing security threats + that need to be addressed. The wireless and distributed nature of + these networks increases the spectrum of potential routing + security threats. This is further amplified by the resource + constraints of the nodes, thereby preventing resource-intensive + routing security approaches from being deployed. A viable routing + security approach SHOULD be sufficiently lightweight that it may + be implemented across all nodes in a HC-LLN. These issues require + special attention during the design process, so as to facilitate a + commercially attractive deployment. - Protection against unintentional inclusion in neighboring networks - MUST be provided. + The HC-LLN MUST deny any node that has not been authenticated to + the HC-LLN and authorized to participate to the routing decision + process. -7. IANA Considerations + An attacker SHOULD be prevented from manipulating or disabling the + routing function, for example, by compromising routing control + messages. To this end, the routing protocol(s) MUST support + message integrity. + + Further examples of routing security issues that may arise are the + abnormal behavior of nodes that exhibit an egoistic conduct, such + as not obeying network rules or forwarding no or false packets. + Other important issues may arise in the context of denial-of- + service (DoS) attacks, malicious address space allocations, + advertisement of variable addresses, a wrong neighborhood, etc. + The routing protocol(s) SHOULD support defense against DoS attacks + and other attempts to maliciously or inadvertently cause the + mechanisms of the routing protocol(s) to over-consume the limited + resources of LLN nodes, e.g., by constructing forwarding loops or + causing excessive routing protocol overhead traffic, etc. + + The properties of self-configuration and self-organization that + are desirable in a HC-LLN introduce additional routing security + considerations. Mechanisms MUST be in place to deny any node that + attempts to take malicious advantage of self-configuration and + self-organization procedures. Such attacks may attempt, for + example, to cause DoS, drain the energy of power-constrained + devices, or to hijack the routing mechanism. A node MUST + authenticate itself to a trusted node that is already associated + with the HC-LLN before the former can take part in self- + configuration or self-organization. A node that has already + authenticated and associated with the HC-LLN MUST deny, to the + maximum extent possible, the allocation of resources to any + unauthenticated peer. The routing protocol(s) MUST deny service + to any node that has not clearly established trust with the HC- + LLN. + + If connected to a backbone network, the HC-LLN SHOULD be capable + of limiting the resources utilized by nodes in said backbone + network so as not to be vulnerable to DoS. This should typically + be handled by border routers providing access from a backbone + network to resources in the HC-LLN. + + With low computation power and scarce energy resources, HC-LLNs' + nodes may not be able to resist any attack from high-power + malicious nodes (e.g., laptops and strong radios). However, the + amount of damage generated to the whole network SHOULD be + commensurate with the number of nodes physically compromised. For + example, an intruder taking control over a single node SHOULD NOT + be able to completely deny service to the whole network. + + In general, the routing protocol(s) SHOULD support the + implementation of routing security best practices across the HC- + LLN. Such an implementation ought to include defense against, for + example, eavesdropping, replay, message insertion, modification, + and man-in-the-middle attacks. + + The choice of the routing security solutions will have an impact + on the routing protocol(s). To this end, routing protocol(s) + proposed in the context of HC-LLNs MUST support authentication and + integrity measures and SHOULD support confidentiality (routing + security) measures. + +6. IANA Considerations This document includes no request to IANA. -8. Acknowledgments +7. Acknowledgments J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler and Massimo Maggiorotti are gratefully acknowledged for their contributions to this document. This document was prepared using 2-Word-v2.0.template.dot. -9. References +8. Disclaimer for pre-RFC5378 work - As an exception, this internet draft contains references to other - internet drafts. The reason is that the referenced internet drafts - are developed in parallel to this document. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) + controlling the copyright in such materials, this document may not + be modified outside the IETF Standards Process, and derivative + works of it may not be created outside the IETF Standards Process, + except to format it for publication as an RFC or to translate it + into languages other than English. - When promoted to an RFC, the references MUST be updated to RFCs as - well or removed from the references section. +9. References 9.1. Normative References + [I-D.Vasseur-Terminology] Vasseur, JP. "Terminology in Low power + And Lossy Networks", draft-vasseur-roll-terminology-02 + (work in progress), October 2008. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [I-D.Hui-HeaderCompression] Hui, J., "Compression Format for IPv6 + Datagrams in 6LoWPAN Networks ", draft-ietf-6lowpan-hc + (work in progress), December 2008. + 9.2. Informative References - [I-D.draft-ietf-roll-terminology] - "Terminology in Low power And Lossy Networks", - JP Vasseur, draft-ietf-roll-terminology-00 - (work in progress), October 2008 + [RFC5548] Dohler, M., "Routing Requirements for Urban Low-Power + and Lossy Networks", BCP 14, RFC 5548, May 2009. + + [I-D.Pister-Industial-reqs] Pister, K., "Industrial Routing + Requirements in Low Power and Lossy Networks ", draft- + ietf-roll-indus-routing-reqs (work in progress) + + [I-D.Martocci-Building-reqs] Martocci, J., "Building Automation + Routing Requirements in Low Power and Lossy Networks ", + draft-ietf-roll-building-routing-reqs (work in progress) + + [I-D.Levis-Protocols-survey] Lewis, P. "Overview of Existing + Routing Protocols for Low Power and Lossy Networks", + draft-ietf-roll-protocols-survey (work in progress) Author's Addresses Anders Brandt - Zensys, Inc. + + Sigma Designs, Inc. Emdrupvej 26 Copenhagen, DK-2100 Denmark Email: abr@zen-sys.com Jakob Buron - Zensys, Inc. + Sigma Designs, Inc. Emdrupvej 26 Copenhagen, DK-2100 Denmark Email: jbu@zen-sys.com Giorgio Porcu Telecom Italia Piazza degli Affari, 2 20123 Milan Italy Email: giorgio.porcu@guest.telecomitalia.it -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology - described in this document or the extent to which any license - under such rights might or might not be available; nor does it - represent that it has made any independent effort to identify any - such rights. Information on the procedures with respect to rights - in RFC documents can be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights that may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on - an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE - IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL - WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY - WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE - ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS - FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.