Re: [Roll] Home Requirements Feedback

Dear all

Thanks for all the comments
Having read through the comments, I see the same line as I observed
during the Philly session:

* MUST/SHOULD statements should be kept out of use cases
* Requirements should be more precise + not too narrow where not needed
* The need for Groupcast in particular should be described in more
detail
* "Constrained" is a very specific term in the IETF which we should use
with care

Concerning gateways - 
I am not sure what to think.
Basically, the idea of going to IP in wireless sensors is to get
transparent connectivity all these lovely devices.
On the other hand, the case described of having different providers
(power utilities, surveillance service, etc) or wanting to have
redundant access to the PAN leads to solutions with multiple access
paths.
I suppose these boxes are basically routers in a full-IP environment?
And the same problem applies to industrial?

Finally, the issue raised about the smoke alarm having to not only
activate an alarm but also turn on one or more groups of lights is very
interesting.
It must be so plain simple that I can trust my mother in law to set it
up correctly - remember this is consumer space ;-)
An the same type of problem applies to energy conservation / heating
control. Interesting issues, but not so simple to specify and not
simpler to implement.
I would love to add more to the draft in this area. Please feel free to
contribute.

I have done a first shot on the way to an updated draft. All
(significant) changes have been marked - starting with "[ABR ". Please
find it below.
Most of the comments posted during the last month should be addressed
but please let me know what can be further improved.

Giorgio, I look forward to see more details from you on the healthcare
section! I added a bit already.

Thanks,
  Anders
-------------------------------------------------------------------

Networking Working Group                                      A. Brandt 
Internet Draft                                             Zensys, Inc. 
Intended status: Informational                              JP. Vasseur 
Expires: October 25, 2008                           Cisco Systems, Inc. 
                                                         April 25, 2008 

    Home Automation Routing Requirement in Low Power and Lossy Networks 
                  draft-brandt-roll-home-routing-reqs-01 

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. 

   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 October 24, 2008. 

Copyright Notice 

   Copyright (C) The IETF Trust (2008). 

Abstract 

   This document presents the home control and automation application 
   specific requirements for ROuting in 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 lighting control 
   modules, heating control panels, light sensors, temperature sensors, 
   gas/water leak detector, motion detectors, video surveillance, 

Brandt                 Expires October 25, 2008                [Page 1] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   healthcare systems and advanced remote controls. Because such devices

   only cover a limited radio range, multi-hop routing is often 
   required. Such devices are usually highly constrained in terms of 
   resources such as battery and memory and operate in unstable 
   environments. The aim of this document is to specify the routing 
   requirements for networks comprising such constrained devices in a 
   home network 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 Error! 
   Reference source not found.. 

Table of Contents 

   1. Terminology....................................................3 
   2. Introduction...................................................3 
   3. Home automation applications...................................4 
      3.1. Turning off the house.....................................4 
      3.2. Moving a remote control around............................5 
      3.3. Adding a new lamp module to the system....................5 
      3.4. Controlling battery operated window shades................6 
      3.5. Networked smoke alarm.....................................6 
      3.6. Remote video surveillance.................................6 
      3.7. Healthcare................................................7 
      3.8. Alarm systems.............................................7 
   4. Unique requirements of home automation applications............7 
      4.1. Support of groupcast......................................8 
      4.2. Node constrained Routing..................................8 
      4.3. Support of Mobility.......................................9 
      4.4. Scalability..............................................10 
      4.5. Convergence Time.........................................10 
      4.6. Manageability............................................10 
   5. Traffic pattern...............................................11 
   6. Open issues...................................................11 
   7. Security Considerations.......................................12 
   8. IANA Considerations...........................................12 
   9. Acknowledgments...............................................12 
   10. References...................................................12 
      10.1. Normative References....................................12 
      10.2. Informative References..................................12 
   Author's Addresses...............................................12 
   Intellectual Property Statement..................................13 
   Disclaimer of Validity...........................................13 

Brandt                 Expires October 25, 2008                [Page 2] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

1. Terminology 

   ROLL:        ROuting in Low-power and Lossy networks 

   Access Point:  The access point is an infrastructure device that 
                 connects the low power and lossy network system to the 
                 Internet, possibly via a customer premises local area 
                 network (LAN). 

   LAN:         Local Area Network. 

   PAN:         Personal Area Network. 
                 A geographically limited wireless network based on 
                 e.g. 802.15.4 or Z-Wave radio. 

   Channel:      RF frequency band used to transmit a modulated signal 
                 carrying packets. 

   Downstream:   Data direction traveling from a LAN to a PAN device. 

   Upstream:     Data direction traveling from a PAN to a LAN device. 

   RF:          Radio Frequency. 

   Sensor:      A PAN device that measures data and/or detects an 
                 event. 

   HA:          Home Automation. 

2. Introduction 

   This document presents the home control and automation application 
   specific requirements for Routing in 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 lighting control 
   modules, heating control panels, light sensors, temperature sensors, 
   gas/water leak detector, motion detectors, video surveillance, 
   healthcare systems and advanced remote controls. 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. 

Brandt                 Expires October 25, 2008                [Page 3] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   Because such devices only cover a limited radio range, multi-hop 
   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 
   reception of weak radio signals. Reflection and absorption may cause 
   a reliable connection 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 implications on network nodes in this aspect, 
   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 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. Often, the radio uses almost just as much power for listening 
   as for transmitting. 

   Section X describes a few typical use cases for home automation 
   applications. Section X 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 requirements documents or as 
   listed in [I-D.culler-roll-routing-reqs]. 

3. Home automation applications 

   Home automation applications represent a special segment of networked

   wireless devices with its unique set of requirements. To facilitate 
   the requirements discussion in Section 4, 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. For instance a lamp may be turned on, not only be a 
   wall switch but also from a movement sensor. 

3.1. Turning off the house 

   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 

Brandt                 Expires October 25, 2008                [Page 4] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   time, at a rate so slow that it is clearly visible. This phenomenon 
   mostly applies to very low bandwidth RF systems. Some existing home 
   automation solutions use a clever mix of a "subnet groupcast" message

   with no acknowledgement and no forwarding before sending acknowledged

   singlecast messages to each lighting device. 

   [ABR REMOVED: Broadcast packets cannot be used for this since some 
   lights should stay on.] 

   The controller forms the groups and decides which nodes should 
   receive "turn-off" or "turn-on" requests. 

   [ABR REMOVED: Thus, traditional IP multicast cannot be used for such 
   applications, since multicast relies on the receivers to subscribe to

   multicasted streams.] 

   [ABR PROPOSED RE-WORDING: Thus, a solution is needed for addressing 
   groups of nodes without prior management of group membership in the 
   receiving nodes.] 

3.2. Moving a remote control around 

   A remote control is a typical example of a mobile device in a home 
   automation network. An advanced remote control may be used for 
   dimming the light in the dining room while eating and later on, 
   turning up the music while doing the dishes in the kitchen. Reaction 
   must appear to be instant (within a few hundred milliseconds) even 
   when the remote control has moved to a new location. The remote 
   control may be communicating to either a central home automation 
   controller or directly to the lamps and the media center. 

   [ABR REMOVED: The routing protocol MUST support multiple paths. The 
   routing protocol MUST be able to locate a working path within 250ms, 
   given that a working path exists and it has been used before.] 

3.3. Adding a new lamp module to the system 

   [ABR REMOVED: Small-size, low-cost modules may have no user interface

   except for a single button. Thus, an automated inclusion process is 
   needed for light controllers to find new modules. The routing 
   protocol MUST support re-discovery of neighbors when a new device is 
   added to the network. The routing protocol MAY scan for neighbors on 
   a frequent basis. This scanning process MUST NOT use significant 
   network bandwidth resources.] 

   [ABR PROPOSED RE-WORDING: Small-size, low-cost modules may have no 
   user interface except for a single button. Thus, an automated 

Brandt                 Expires October 25, 2008                [Page 5] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   inclusion process is needed for controllers to find new modules. 
   Inclusion covers the detection of neighbors and assignment of a 
   unique node ID. Inclusion should be completed within a few seconds.] 

3.4. Controlling battery operated window shades 

   In consumer premises, window shades are often battery-powered as 
   there is no access to mains power over the windows. For battery 
   conservation purposes, the receiver is sleeping most of the time. A 
   home automation controller sending commands to window shades via ROLL

   resources will have no problems delivering the packet to the router, 
   but the router will have to wait for some time before the command can

   be delivered to the window shades; e.g. up to 250ms. 

3.5. Networked smoke alarm 

   Some smoke alarms are battery powered and at the same time mounted in

   a high place. Battery-powered safety devices should only be used for 
   routing if no other alternatives exist. A smoke alarm with a drained 
   battery does not provide a lot of safety. Also, it may be 
   inconvenient to exchange battery in a smoke alarm. Finally, routing 
   via battery-powered nodes may be very slow if they are sleeping most 
   of the time. 
   [ABR ADDED: All of the above-mentioned reasons suggest that routing 
   should be avoided via this category of devices.] 

3.6. Remote video surveillance 

   Remote video surveillance is a fairly classic application for Home 
   networking providing the ability for the end user to get a video 
   stream from a Web Cam reached via the Internet, which can be 
   triggered by the end-user that has received an alarm from a movement 
   sensor 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: indeed, 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 (cell phone, PDA) 
   via the Internet. 
   By contrast with other application where for example a large number 
   of ROLL devices such as industrial sensors where the data would 
   mainly be originated by sensor to a sink and vice versa, in such 
   scenario there is a direct inter-device communication between ROLL 
   devices. 

Brandt                 Expires October 25, 2008                [Page 6] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

3.7. Healthcare 

   [ABR REMOVED: This section will be documented in further revision of 
   this document.] 

3.7.1.  [ABR ADDED: At-home health monitoring] 

   [ABR ADDED: By adding communication capability to devices, patients 
   and elderly citizens may be able to do simple measurements at home. 
   Thanks to the online devices, the doctor can keep an eye on the 
   patient's health and receive warnings if a new trend is discovered by

   automated filters.  

   Measurement applications might include: 

   o  Temperature 

   o  Weight 

   o  Blood pressure 

   o  Insulin level 

   The abovementioned applications may be realized as wearable products 
   which frequently do a measurement and automatically deliver the 
   result to a data sink locally or over the Internet. 

   Fine-grained daily measurements presented in proper ways may allow 
   the doctor to establish a more precise diagnosis. 

   From a ROLL perspective, all the above-mentioned applications may be 
   expected to be battery-powered. They 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 devices should not be used as

   routing nodes. 
   Delivery of measurement data has a limited requirement for route 
   discovery time compared to a remote control.] 

3.8. Alarm systems 

   This section will be documented in further revision of this document.

3.9. [ABR ADDED: Battery-powered devices] 

   [ABR ADDED: For convenience and low operational costs, power 
   consumption of consumer products must be kept at a very low level to 
   achieve a long battery lifetime. One implication of this fact is that

Brandt                 Expires October 25, 2008                [Page 7] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   RAM memory is limited and it may even be powered down; leaving only a

   few 100 bytes alive during the sleep phase.] 

4. Unique requirements of home automation applications 

   Home automation applications have a number of specific requirements 
   related to the set of home networking applications and the perceived 
   operation of the system. 

4.1. Support of groupcast 

   [ABR REMOVED: The routing protocol MUST support multicast routing 
   with various scopes: local subnet, all devices. In other words, ] 

   The routing protocol must provide the ability to route a packet 
   towards a single device (unicast), a set of devices (also referred to

   as "groupcast" in this document) or all devices (multicast) in the 
   house. 

   The support of unicast, groupcast and multicast also has an 
   implication on the addressing scheme and are outside the scope of 
   this document that focuses on the routing requirements aspects. 

   [ABR REMOVED Note: with IP Multicast, signaling mechanisms are used 
   by a receiver to join a group and the sender does not necessarily 
   know the receivers of the group. What is required is the ability to 
   address a group of receivers known by the sender even if the 
   receivers do not need to know that they have been grouped by the 
   sender (requesting each individual node to join a multicast group 
   would be very impractical).] 

   [ABR PROPOSED REWORDING: It MUST be to possible to address a group of

   receivers known by the sender even if the receivers do not know that 
   they have been grouped by the sender. 

   Alternatively, a companion specification SHOULD define how to 
   indirectly address a group of nodes on the application layer via 
   classic broadcast in the network layer; e.g. by use of a bitmap in a 
   header extension.] 

4.2. Metric-based Routing 

   [ABR NOTE: IETF-71 WG meeting indicated that the term "constrained" 
   has a very specific meaning in the routing community inside IETF. I 
   think a specific definition of "Constrained" in the IETF sense should

   be added to the terminology section in the beginning of the document.

Brandt                 Expires October 25, 2008                [Page 8] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   What I understood was that the draft should be using the term 
   "metric-based routing"] 

   Simple battery-powered nodes such as movement sensors on garage doors

   and rain meters may not be able to assist in routing. Depending on 
   the node type, the node never listens at all, listens rarely or makes

   contact on demand to a pre-configured target node. Attempting to 
   communicate to such nodes may require long time before getting a 
   response. 

   [ABR REMOVED: Other battery-powered node may have the capability to 
   participate to the routing protocol but it may be preferable to 
   choose a (potentially longer) route via non battery powered devices 
   or via battery powered that have more energy.] 

    [ABR ADDED: Other battery-powered nodes may have the capability to 
   participate in routing. The routing protocol should either share the 
   load between nodes to preserve battery or only route via mains-
   powered nodes if possible.] 

    [ABR REMOVED: The routing protocol MUST support constraint based 
   routing taking into account node properties (CPU, memory, level of 
   energy, sleep intervals, safety/convenience of changing battery).] 

   [ABR ADDED: The routing protocol MUST support metric-based routing 
   taking into account node properties (CPU, memory, level of energy, 
   sleep intervals, safety/convenience of changing battery).] 

4.3. Support of Mobility 

   In a home environment, although the majority of devices are fixed 
   devices, there is still a variety of mobile devices: for example a 
   multi-purpose remote control is likely to move. Another example of 
   mobile devices is wearable healthcare devices. 

   [ABR ADDED: While healthcare devices delivering measurement results 
   can tolerate route discovery times measured in seconds, a remote 
   control appears unresponsive if using more than 0.5 seconds to 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.] 

   [ABR REMOVED: The routing protocol MUST provide mobility with 
   convergence time within a few hundred milli-seconds.] 

Brandt                 Expires October 25, 2008                [Page 9] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   [ABR ADDED: The routing protocol MUST provide mobility with 
   convergence time below 0.5 second.] 

   [ABR ADDED: The routing protocol SHOULD make use of the fact that if 
   not being able to deliver a packet, it is most likely that the 
   sending node moved; rather than the rest of the network.] 

4.4. Scalability 

   Looking at the number of wall switches, power outlets, sensor 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. 

   Thus the routing protocol MUST be highly scalable supporting a large 
   number of devices (at least a few hundreds of devices). 

4.5. Convergence Time 

   A home automation PAN is subject to various instability due to signal

   strength variation, moving persons and the like. Furthermore, as the 
   number of devices increases, the probability of node failures also 
   increases.  

   [ABR ADDED: Measured from the transmission of a packet, the following

   convergence time requirements apply.] 

   [ABR REMOVED: In all cases, response time of the order of a few 
   hundreds of milliseconds are required, implying that the routing 
   protocol MUST converge (provide alternate routes upon link or node 
   failure) within a few hundreds of milliseconds.] 

   [ABR ADDED: The routing protocol MUST converge within 0.5 second if 
   no nodes have moved.] 

   [ABR ADDED: The routing protocol MUST converge within 2 seconds if 
   the destination node of the packet has moved.] 

4.6. Manageability 

   The ability of the home network to support auto-configuration is of 
   the utmost importance. Indeed, most end users will not have the 
   expertise and the skills to perform advanced configuration and 
   troubleshooting. Thus the routing protocol designed for home PAN MUST

Brandt                 Expires October 25, 2008               [Page 10] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

   provide a set of features including 0 configuration of the routing 
   protocol for a new node to be added to the network. 

   Furthermore, a failing node MUST NOT have a global impact on the 
   routing protocol. The routing protocol SHOULD support the ability to 
   isolate a misbehaving node thus preserving the correct operation of 
   overall network. 

5. Traffic pattern 

   Depending on the 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 any-to-many. In a 
   centralized system, it is a mix of any-to-one and one-to-many. 

   [ABR REMOVED: A centralized system may benefit from a tree topology 
   routing strategy; having the central light controller close to the 
   root. 

   A tree topology may prove inefficient for nodes in a distributed 
   system. A direct path from sender to receiver may be significantly 
   shorter than a path following the tree. A shorter path means lower 
   latency and less air-time use in a wireless media. Thus, routers MUST

   provide efficient any-to-many routing and MUST also support any-to-
   any routing without having to transit via a central point (e.g. tree 
   root) which would unavoidably lead to sub-optimal path in terms of 
   latency and energy consumption.] 

6. Open issues 

   Other items to be addressed in further revisions of this document 
   include: 

   o  Healthcare 

   o  Alarm systems 

   o  Load Balancing (Symmetrical and Asymmetrical) 

   o  Security 

Brandt                 Expires October 25, 2008               [Page 11] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

7. Security Considerations 

   TBD 

8. IANA Considerations 

   This document includes no request to IANA. 

9. Acknowledgments 

   This document was prepared using 2-Word-v2.0.template.dot. 

10. References 

10.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

10.2. Informative References 

   [I-D.culler-roll-routing-reqs] 
             Vasseur, J. and D. Culler, "Routing Requirements for Low

             Power And Lossy Networks", 
             draft-culler-roll-routing-reqs-* (work in progress). 

Author's Addresses 

   Anders Brandt 
   Zensys, Inc. 
   Emdrupvej 26 
   Copenhagen, DK-2100 
   Denmark 

   Email: abr@zen-sys.com <mailto:abr@zen-sys.com>  

   JP Vasseur 
   Cisco Systems, Inc. 
   1414 Massachusetts Avenue 
   Boxborough, MA 01719 
   USA 

   Email: jvasseur@cisco.com <mailto:jvasseur@cisco.com>  

Brandt                 Expires October 25, 2008               [Page 12] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

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 <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 <mailto: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. 

Brandt                 Expires October 25, 2008               [Page 13] 

Internet-Draft   draft-brandt-roll-home-routing-reqs         April 2008 

Brandt                 Expires October 25, 2008               [Page 14] 