Subject: [manet] Question for you

From: Fred Baker <[email-masked]>
Date: Mon, 26 Sep 2011 13:14:48 -0600

I'm trying to do a somewhat complete requirements and pro/con analysis for IPv6 routing in a small network, the obvious examples being residential and SOHO networks. What I have in pixels at this instant is:

    <section title="Contestant protocols">
        <t></t>
      <section title="Routing Information Protocol">
        <t></t>
      </section>
      <section title="Open Shortest Path First Routing Protocol">
        <t></t>
      </section>
      <section title="IS-IS Routing Protocol">
        <t></t>
      </section>
      <section title="Border Gateway Protocol">
        <t></t>
      </section>
      <section title="Routing Protocol for Low Power and Lossy Networks">
        <t></t>
      </section>
      <section title="Ad hoc On-Demand Distance Vector Routing">
        <t>
Can you say "DYMO"?
        </t>
      </section>
      <section title="Optimized Link State Routing Protocol">
        <t></t>
      </section>
    </section>

For some of these, the obvious comment is "YMBK". Some will feel that their selection is the obvious given and will be able to go on at some length as to why, and may be surprised to find that people disagree with them. 

I'd like to do several things:
(a) make the list as reasonably complete as possible consistent with openly documented protocols,
(b) provide a reasonably complete and objective analysis of each as I can,
(c) identify the key reasons one would choose each - if there is a reason at all, and
(d) identify the key reasons one would not.

What I don't want to accomplish is deep-six these lists and half a dozen others in arguments.

Do me a favor. Let's do this in private mail. If you think of a protocol I should mention that I haven't, let me know. If you think there is a really good argument for or against any of them in particular, let me know. If you think I'm nuts - I already know that, you don't need to remind me :-)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Sep 2011 13:25:22 +0200

Hello Mark :

>The majority of IP-based home networks today are neither power-constrained nor particularly lossy. So, while we can certainly learn from LLN requirements analysis, I do think the base requirements in homenet could turn out to be quite different, or at least a smaller and slightly different subset, of the overall LLN requirements. 

> Certainly, home networks have an emerging IP-based "low power and lossy" component in them. One could even argue that it will become dominant at some time in the future, but that's a leap I personally would be pretty uncomfortable in the group making without some very strong data to back it up.

In any case we have to consider the integration of the LLN (e.g. a Command and Control) component of the network within the HOMENET architecture, wouldn't you think? If so, there is a probably a RPL piece to the story, and the question becomes how that piece integrates with the rest of the architecture. We probably want to obtain a converged network, and probably would prefer to avoid running too many routing protocols, with redistribution policies etc... which can rapidly become nasty in terms of administration.

Anyway, I'd suggest that whether the home network is fully an LLN or not is not necessarily the core if the RPL applicability discussion:

* ROLL did not produce a routing protocol that is limited to LLNs, but a routing protocol that is acceptable for LLNs. IOW it is not restricted to LLNs, by far.

* RPL is designed to be simple to deploy. It inherits from mesh technologies the traditional self-* properties which make it quite autonomic thus better fit for unmanaged environments.

* RPL is designed and optimized for edge (stub) networks, with one or multiple gateway. Just like L2 mesh networks, RPL builds multilink nets and/or subnets that are oriented towards the gateways. It is possible to optimize traffic from/to certain destinations within the network, but the general goal is NOT any to any optimization. As a result, it can be desirable to have a non-RPL high speed backbone that can be a single backbone link or that can be a more complex IPv6 backbone network running, say, a link state protocol, when that's really needed.

* Associated to the support of multiple gateways, RPL incorporates natively the concept of multiple routing topologies, for instance if you want to separate a metering network that reports to some utility with your voice and video network. This comes with 6MAN drafts that enable to tag the packets so as to follow the appropriate topology.

* Finally, the brains for the routing decision is a plug in, called an objective function (OF). So even if HOMENET inherits from ROLL for the DV loop avoidance scheme and from 6MAN for the tagging/forwarding, the WG can still define one or more OFs that will dictate the shape of the resulting routing topologies. The OF is the decision maker that will, say, prefer a high speed Ethernet over an LLN, for a given class of traffic.

What do you think?

Pascal

---

From: C Chauvenet <[email-masked]>
Date: Wed, 28 Sep 2011 02:22:28 -0700

Hi all,

This is an valuable and necessary initiative.

As I follow the ROLL WG, may I point you to some doc that have been produced by this WG, and may address some of your questions :

http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07 : This draft provide a good survey of several routing protocols (OSPF/IS-IS, OLSRv2, TBRPF, RIP, AODV, DYMO, DSR) and evaluate each candidate regarding metrics that are relevant for Low-power and Lossy Networks (LLNs).
I think LLNs are applicable to Homenet networks.

RFC 5826 : http://tools.ietf.org/html/rfc5826 ("Home Automation Routing Requirements in LLNs") : This doc designed by the ROLL WG gather some requirements regarding routing in Home environments. It may provide good input for the Homenet WG.

You may also be interested in the Building version of these requirements, in RFC5867 http://tools.ietf.org/html/rfc5867.

I'm not an expert in Home's Networks, and they may have some different requirements than LLNs that ROLL is looking at.
Please educate me on that point.
But I think we should consider the work that have been done for such constrained devices.

Best regards,

Cédric.

Le 26 sept. 2011 à 21:14, Fred Baker a écrit :

Do me a favor. Let's do this in private mail. If you think of a protocol I should mention that I haven't, let me know. If you think there is a really good argument for or against any of them in particular, let me know. If you think I'm nuts - I already know that, you don't need to remind me :-)
_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Mark Townsley <[email-masked]>
Date: Wed, 28 Sep 2011 12:02:20 +0200

> But I think we should consider the work that have been done for such constrained devices.

Thank you for the pointers.

- Mark

>> [email-masked]
> [email-masked]

---

From: Mark Townsley <[email-masked]>
Date: Wed, 28 Sep 2011 16:58:04 +0200

On Sep 28, 2011, at 1:25 PM, Pascal Thubert (pthubert) wrote:

> In any case we have to consider the integration of the LLN (e.g. a Command and Control) component of the network within the HOMENET architecture, wouldn't you think?

Yes. 

> If so, there is a probably a RPL piece to the story, and the question becomes how that piece integrates with the rest of the architecture. We probably want to obtain a converged network, and probably would prefer to avoid running too many routing protocols, with redistribution policies etc... which can rapidly become nasty in terms of administration.\

> * ROLL did not produce a routing protocol that is limited to LLNs, but a routing protocol that is acceptable for LLNs. IOW it is not restricted to LLNs, by far.

Bummer of a name then ;-)

> * Finally, the brains for the routing decision is a plug in, called an objective function (OF). So even if HOMENET inherits from ROLL for the DV loop avoidance scheme and from 6MAN for the tagging/…

Since you asked, *I* think that a homenet has functional overlap (what I called "at least a smaller and slightly different subset" in my email) in terms of requirements to LLNs. At first blush, it looks like RPL has lots of functionality - perhaps more than we really need for homenet, and by your own admission more than you need for LLN's - but will hold reservation on what I think best fits the bill until we see Fred's analysis, hear from others, etc. 

But of course what's most important is what the WG thinks, not me. 

- Mark

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Sep 2011 18:43:30 +0300

> Since you asked, *I* think that a homenet has functional overlap (what I called "at least a smaller and slightly different subset" in my email) in terms of requirements to LLNs. At first blush, it…

My two yen, which may be all it's worth...

If I were a Linksys/D-Link/NetGear/* product manager asking about what protocols to put in, I wouldn't be asking about what still exists in Internet Drafts and is thought by the engineers designing it to be better than sliced bread, but about what was inexpensive to implement, likely to be close to bug-free, and definitively accomplished the goal. I note that most routers for the IPv4 residential routing marketplace implement RIPv2; I know of one that implements no routing protocol, one that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and OSPF (don't ask which they are, I don't remember). This is from a google search of residential routers a few months ago and covered perhaps 20 products from half as many vendors. So my first inclination is to say that for a residential IPv6 network, RIPng is probably an image match for those vendors.

I have a personal bias in the direction of OSPF or IS-IS; I think that once the code is debugged, SPF-based protocols are more stable (no count-to-infinity), given a reasonable set of defaults generate far more stable networks, and definitively know when there is more than one router on a LAN, which can be important in subnet distribution. 

My first choice would NOT be something that isn't proven in the field in multiple interoperable implementations. 

As a person thinking about making a recommendation, I'd suggest that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why that level of interoperability isn't mandatory.

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 28 Sep 2011 10:54:23 -0700

On Wed, 2011-09-28 at 16:58 +0200, Mark Townsley wrote:
> 
> >> The majority of IP-based home networks today are neither
> power-constrained nor particularly lossy. 

I would agree that that is the case today, but suggest we look ahead a
bit.

There's a fair head of steam building in emergency services that has the
term 'broadband' attached to it.  Lots of confusion, but...

We're about to see a repeat of what we saw in the CATV market where the
vendors thought you'd connect a computer at home to the DOCSIS network.
But we all hooked up routers instead.  This time the story is the
cellphone folks rolling out '4G' network segments and naively thinking
that we'll just hook up cellphones (which have since become computers --
mine has 8G of RAM in it!).  

Scenario for orientation.  Instead of the EMT in the ambulance having a
cellphone to call the emergency room, the EMT will be armed with several
diagnostic gadgets attached to a LAN (either ethernet or WiFi).  And a
router.  The router will, in turn be linked to the rest of internet with
a radio-WAN.  

Scenario implications.  Right now, emergency services tend to rely on a
set of high sites -- Monterey County where I live, has eleven.  But the
broadband technologies all look better with an order of magnitude more
sites (think schoolhouse roofs) and consequently more handoffs (aka
routing table volatility).  

Topology.  The radio-WAN is in interior of internet, not fringe.
	Power-constrained -- probably not much change since a lot of this will
be vehicle-mount -- ambulances, fire engines, etc.  This all changes as
soon as the trooper dismounts and exceeds WiFi range from his vehicle.
	Lossy.  Depends on how you define the term...  But radios lose more
bits (and hence more packets) than wires.

---

From: C Chauvenet <[email-masked]>
Date: Thu, 29 Sep 2011 08:22:54 -0700

Hi, 

" I don't think my wife would want a lossy network in our house ;^)" : 

Nobody wants a lossy network, but the technology you are using may create lossy links...

I may have miss something in the Homenet scope.

In the scope of Homenet, is every device in the house runing over a *robust* link (Bit Error Rate below 1 % at the PHY level) ?

Furthermore do these devices could have some high Power/Computation/Size/Cost constraints ?

I fail to see the kind of technologies and devices that are targeting.

Thanks for the clarification.

Cédric .

-----Message d'origine-----
De : Acee Lindem [mailto:[email-masked]] 
Envoyé : jeudi 29 septembre 2011 16:44
À : Fred Baker
Cc : Mark Townsley; C Chauvenet; Pascal Thubert (pthubert); MANET IETF; [email-masked]; [email-masked]
Objet : Re: [homenet] Question for you

I'm in complete agreement with Fred. The areas where the existing link-state protocols may need to be extended are auto-configuration and, potentially, inter-area policies.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 29 Sep 2011 10:43:42 -0400

I'm in complete agreement with Fred. The areas where the existing link-state protocols may need to be extended are auto-configuration and, potentially, inter-area policies.  
I don't think my wife would want a lossy network in our house ;^) 
Thanks,
Acee

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Sep 2011 10:18:10 +0200

Hello Cedric:

I have the same questions. Furthermore, I'd wish to understand better:

*** whether the goal is limited to provide a best practice based on "established" ICT technologies 

There are other "established" technologies. For instance there is extensive networking experience in industrial networks, solving different problems under different constraints. Same goes in AMI/AMR networks, and to a lesser extent in Home, commercial and building automation. Some groups in the IETF have finally started to pay attention and build on that experience. Even if the resulting technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale is such that over a few years we have seen unprecedented amounts of implementations, interop and compliance tests (e.g. under IPSO and WCI).

Also, if we map home use cases with the routing technologies that applied today, we see that at the moment the traditional IGPs do not play much role, at least from the home standpoint:
- Internet to Home (Content consumption) is not a Home problem
- Home to Internet (metering, P2P)  is a default route
- Home to Home (Content and Access sharing) is dominated by OLSR.
- Inside Home (Content and Device sharing) is single subnet, solved reactively by ARP or ND.
- Inside Home (Command & Control, Automation) meshing is proprietary though going 6LoWPAN and RPL.

In any fashion, we can solve an additional problem of our own making that would require our beloved ICT IGPs to be injected in the Home network with always-on routers in each room or we can start producing best practices on how the above can to be done with the technologies that are already in place. Or both?

*** whether we have an assumption of a plethora of power

Year over year, we've seen the simplest devices migrate from a totally-switched-off mode to some more and more power greedy sleeping and always-on modes.
Always-on displays and LEDs appears fancy to the consumer but are of consequence on the family budget and at the scale of a city, result in measurable pollution. 
And we've been connecting more and more devices to the home power distribution, devices that would not exist 10-20 years ago.
We know how power-greedy traditional ICT technologies are; people do not want a new heating system that they cannot even stop in summer.
My take is that whatever this group produces has to be justified in terms of power budget as it has to be justified in other terms like usability and security.

*** if HOMENET is targeting home gateways and large home cinema gear only, and whether we have an assumption of cat 5/6 cabling

This case is probably the low hanging fruit and that there is an immediate need to solve a number of problems there. If that's what the group is pursuing for the time being, well, that's fine as long as it's very clear to everybody. But the rest of the world is low power and lossy. Apart from certain ecological niches (that's datacenter mostly) about all Internet-connected devices have evolved the wireless trait, even if the most traditional devices can still use wires. The new trait has lowered dramatically the cost and complexity of accessing the Internet, which in turn allowed the introduction of new species of internet-connected devices that now thrive under the name of Things. At some point we'll have to address that too.

I do not know how that converts into cents at the current rate...

Pascal

-----Original Message-----
From: C Chauvenet [mailto:[email-masked]] 
Sent: jeudi 29 septembre 2011 17:23
To: Acee Lindem; Fred Baker (fred)
Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; [email-masked]; [email-masked]
Subject: RE: [homenet] Question for you

Hi, 

Cédric .

-----Message d'origine-----
De : Acee Lindem [mailto:[email-masked]] Envoyé : jeudi 29 septembre 2011 16:44 À : Fred Baker Cc : Mark Townsley; C Chauvenet; Pascal Thubert (pthubert); MANET IETF; [email-masked]; [email-masked] Objet : Re: [homenet] Question for you