Subject: [Roll] draft-tavakoli-hydro-00.txt

From: Arsalan Tavakoli <[email-masked]>
Date: Wed, 4 Mar 2009 16:46:10 -0800

http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt

This is the draft of a new protocol specification for a routing protocol for
L2Ns that we thought members of this working group might find interesting.
 Any comments/feedback/questions would be highly appreciated, and we will
attempt to incorporate those we receive before Monday (cutoff date for IETF
documents) into a -01 version of the draft.
Thanks in advance,
Arsalan

-----------------------------------------------------

A new version of I-D, draft-tavakoli-hydro-00.txt has been successfuly
submitted by Arsalan Tavakoli and posted to the IETF repository.

Filename:        draft-tavakoli-hydro
Revision:        00
Title:           HYDRO: A Hybrid Routing Protocol for Lossy and Low Power
Networks
Creation_date:   2009-03-04
WG ID:           Independent Submission
Number_of_pages: 27

Abstract:
HYDRO is a hybrid routing protocol for Lossy and Low power Networks
(L2Ns) that embraces centralized and distributed routing mechanisms.
Through the use of standard ICMP Route Advertisements and Route
Solicitations, Node Routers build Default Routes to Border Routers.
These routes, which maintain multiple options per each Node Router
when available, are maintained through data-driven link estimation.
Node Routers periodically report a high-quality subset of their
Default Route Table to Border Routers, which then form a global view
of the topology.  When a Node Router attempts to route to another
Node Router in the network, if no matching entry exists in the Node
Router's Flow Table, it forwards the packet to a Border Router, which
then installs the correct Flow Table Entries in the network to enable
more efficient subsequent routing.

---

From: Dominik Kaspar <[email-masked]>
Date: Thu, 5 Mar 2009 09:03:05 +0100

Hello.

Can the posting of this protocol specification be interpreted as the
strategical decision to ignore existing protocols (MANET) and move
ahead with ROLL's own solution?

Regards,
Dominik

On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli
<[email-masked]> wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 5 Mar 2009 11:15:17 +0100

Hi,

> ahead with ROLL's own solution?

Not at all. There will be multiple candidates for sure, extensions to  
MANET can be candidates of course,
as mentioned MANY times on the list.

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 11:40:58 +0100

JP Vasseur a écrit :
>> Can the posting of this protocol specification be interpreted as
>> the strategical decision to ignore existing protocols (MANET) and
>> move ahead with ROLL's own solution?
>> 
> 
>  MANET can be candidates of course, as mentioned MANY times on the
> list.

Which addressing model are you guys planning to use?

Alex

>> Regards, Dominik
>>> This is the draft of a new protocol specification for a routing 
>>> protocol for L2Ns that we thought members of this working group
>>> might find interesting. Any comments/feedback/questions would be
>>> highly appreciated, and we will attempt to incorporate those we
>>> receive before Monday (cutoff date for IETF documents) into a -01
>>> version of the draft. Thanks in advance, Arsalan 
>>> ----------------------------------------------------- A new
>>> version of I-D, draft-tavakoli-hydro-00.txt has been successfuly 
>>> Filename:        draft-tavakoli-hydro Revision:        00 Title:
>>> HYDRO: A Hybrid Routing Protocol for Lossy and Low Power Networks
>>>  Creation_date:   2009-03-04 WG ID:           Independent
>>> Submission Number_of_pages: 27
>>> 
>>> Abstract: HYDRO is a hybrid routing protocol for Lossy and Low
>>> power Networks (L2Ns) that embraces centralized and distributed
>>> routing mechanisms. Through the use of standard ICMP Route
>>> Advertisements and Route Solicitations, Node Routers build
>>> Default Routes to Border Routers. These routes, which maintain
>>> multiple options per each Node Router when available, are
>>> maintained through data-driven link estimation. Node Routers
>>> periodically report a high-quality subset of their Default Route
>>> Table to Border Routers, which then form a global view of the
>>> topology.  When a Node Router attempts to route to another Node
>>> Router in the network, if no matching entry exists in the Node 
>>> Router's Flow Table, it forwards the packet to a Border Router,
>>> which then installs the correct Flow Table Entries in the network
>>> to enable more efficient subsequent routing.
>>> 
>>> _______________________________________________ Roll mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>> 
>>> 
>> _______________________________________________ Roll mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: "David E. Culler" <[email-masked]>
Date: Thu, 05 Mar 2009 07:39:52 -0800

Dominik,

Although seeing a question such as yours may tempt one to head down
just such a path, alas, such political maneuvering is not what the IETF
is for.  The IETF encourages individual submissions in order to further
a process of informed discussion, rather than mere opinion and
positioning. Only if there is willingness to focus on the challenges at
hand can rough consensus and running code emerge.  Now that ROLL has
gone to great pains and delay to examine such protocols it has begun
the process of rechartering.  Once that is complete it will be possible
to consider extensions to existing protocols, such as those previously
proposed to address mobility in MANET.  Hopefully, individuals in MANET
will have begun thinking about such protocols might possibly made to
work in a context where resources are highly constrained and link loss
is non-negligible. These are very different issues from dealing with a
device moving out of range, so don't underestimate how much technical
work there is to address even the stationary problem.

What submission of this draft does suggest is that at least some
members of ROLL would like to have the opportunity to consider
protocols other that those historically put forward by MANET.  There
are many such protocols and a substantial body of implementation
experience and empirical analysis.  Few of them have been cast into I-D
form, so it is hard for the IETF to give them serious thought.

I do hope that representatives of MANET will participate in such
discussions regarding technical merit of options and alternatives.

D.

Dominik Kaspar wrote:

Hello.

Regards,
Dominik

Abstract:

---

From: Dominik Kaspar <[email-masked]>
Date: Thu, 5 Mar 2009 18:13:46 +0100

Hi David,

Thanks for the clarifications. I was not speaking from a MANET's point
of view, but was just probing whether ROLL has now entered the
"protocol design stage" or not.

Anyway, the draft looks very interesting. Have there been research
papers published with results from a real implementation of HYDRO?

Best regards,
Dominik

On Thu, Mar 5, 2009 at 4:39 PM, David E. Culler
<[email-masked]> wrote:
> Dominik,
>    Although seeing a question such as yours may tempt one to head down just
> such a path, alas, such political maneuvering is not what the IETF is for.
> The IETF encourages individual submissions in order to further a process of
> informed discussion, rather than mere opinion and positioning. Only if there
> is willingness to focus on the challenges at hand can rough consensus and
> running code emerge.  Now that ROLL has gone to great pains and delay to
> examine such protocols it has begun the process of rechartering.  Once that
> is complete it will be possible to consider extensions to existing
> protocols, such as those previously proposed to address mobility in MANET.
> Hopefully, individuals in MANET will have begun thinking about such
> protocols might possibly made to work in a context where resources are
> highly constrained and link loss is non-negligible. These are very different
> issues from dealing with a device moving out of range, so don't
> underestimate how much technical work there is to address even the
> stationary problem.
>    What submission of this draft does suggest is that at least some members
> of ROLL would like to have the opportunity to consider protocols other that
> those historically put forward by MANET.  There are many such protocols and
> a substantial body of implementation experience and empirical analysis.  Few
> of them have been cast into I-D form, so it is hard for the IETF to give
> them serious thought.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Mar 2009 21:23:59 +0100

Arsalan and co-authors,

Thanks for the new draft.  I will read it later in detail and comment.
I hope WG member candid opinion is useful outside the deals you may have 
already settled outside.

The first thing I did when it showed up was wow, authorship ok, ICMP ok,
maybe this is all ok.

Stimulated so I quickly searched.  Only to soon get disappointed to see
a Default Route table?  An adaptation layer?

Would this fit in the claimed requirements?  14kb RAM?  Or are the
claimed requirements just bogus?

How should I read this draft and understand it for low-power and lossy
networks?  Until you tell me I'll read it anyways and provide technical
feedback.

Alex

Arsalan Tavakoli a écrit :
> protocol for L2Ns that we thought members of this working group might
> find interesting.  Any comments/feedback/questions would be highly 
> appreciated, and we will attempt to incorporate those we receive
> before Monday (cutoff date for IETF documents) into a -01 version of
> the draft.
> 
> Thanks in advance, Arsalan
> 
> A new version of I-D, draft-tavakoli-hydro-00.txt has been
> successfuly submitted by Arsalan Tavakoli and posted to the IETF
> repository.
> 
> Creation_date:   2009-03-04 WG ID:           Independent Submission 
> Number_of_pages: 27
> 
> Abstract: HYDRO is a hybrid routing protocol for Lossy and Low power
> Networks (L2Ns) that embraces centralized and distributed routing
> mechanisms. Through the use of standard ICMP Route Advertisements and
> Route Solicitations, Node Routers build Default Routes to Border
> Routers. These routes, which maintain multiple options per each Node
> Router when available, are maintained through data-driven link
> estimation. Node Routers periodically report a high-quality subset of
> their Default Route Table to Border Routers, which then form a global
> view of the topology.  When a Node Router attempts to route to
> another Node Router in the network, if no matching entry exists in
> the Node Router's Flow Table, it forwards the packet to a Border
> Router, which then installs the correct Flow Table Entries in the
> network to enable more efficient subsequent routing.
> 
> 
> ------------------------------------------------------------------------
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Mar 2009 23:53:03 +0100

Dear co-authors of draft-tavakoli-hydro-00.txt,

I've read most of the HYDRO document.  I typed remarks as they came to 
my head.  I think I forgot all the positive remarks but please think I 
do have some positive remarks about it.  The document is more complex 
than a quick read could do.  It's way too complex for me a Friday 
evening :-)

Disapointingly, it seems too much linked to 802.15.4... couldn't run on 
ANT for example.  Doesn't use 128bit IPv6 address either.

Encouragingly, it uses ICPMv6, multicast, the whole nodes are in a 
subnet, extension headers proposals, and more.

PacketBB could be used at places, and it's not mentioned.

Following are a large set of technical remarks followed by a small set 
of nit syntax, not really important.

Thanks for the draft,

Alex

> HYDRO

Any relationship to sensor networks for watery environments, like in
oceans and such?  I'm asking not naively, I know an ANT wireless
low-power link won't work under water.

> An underlying set of routing trees are created using IPv6 Route 
> Advertisement and Route Solicitation Messages.

You may be interested in citing draft-petrescu-manemo-nano-00 (expired)
in which RAs contain prefixes, which otherwise uses RFC4191 which you
may be more tempted in mentioning.

> When a Node needs to route a packet, either as its originator or a 
> forwarder, it attempts to classify a packet against its Flow Table 
> (which is initially empty).  If an entry matches the packet, then the
>  packet is forwarded according to the rules specified by the entry. 
> Otherwise, the Node forwards the packet along a Default Route to the
>  Border Router.

Is this a plan to avoid searching the typical routing table?  Is there a
typical kernel routing table at all?  Is this 'entry matches' happening
before the node's typical routing table search?  Afterwards?

> It then forwards the packet to the destination by inserting a source
> routing header into the packet and forwarding it to the first hop in
> the source route.

Say the type upfront (detailed later in section 6.2)

>    HYDRO mechanisms require the frequent transmission (or exchange) of
>    IPv6 addresses.  Because full 128-bit addresses in this setting are
>    not practical, we assume that all Nodes are associated with a locally
>    unique 16-bit short identifier, and furthermore that all Border
>    Routers have access to the mapping between 16-bit and 64-bit
>    interface identifiers.  This 16-bit identifier should be equivalent
>    to the 16-bit form of compressed address specified by [RFC4944].  The
>    mapping may be static or dynamic, using mechanisms like DHCPv6 but is
>    beyond the scope of this document.  All routing takes place using 16-
>    bit short identifiers

Only 802.15.4 16-bit addresses?  What about IPv6 addresses?

This makes too much think HYDRO being only about bridging in 802.15.4...

>    L2N Network: a network with a single IPv6 prefix encompasing both a
>    set of Border Routers and Edge Routers.  Multiple types of links
>    connect these routers, and the Border Routers are all in a single
>    link-local multicast domain.  All interfaces on this network share a
>    single prefix (the L2N prefix).

I fully agree with this virtual picture.  A real illustration would be 
more suggestive though.  I could draw it if wish.

And a quirk: not all interfaces on this network need to share the same 
prefix.  I'm thinking about the Secondary Interfaces.  I don't agree 
saying Border Routers are all in a single link-local multicast domain. 
Maybe all interfaces of the Border Routers' L2N Interfaces - yes. 
Picture would help here too.

>    Default Route Table: A Node's table which contains information about
>    a set of Default Routes and their associated next-hop Nodes,
>    including the cost of communicating with a Border Router using that
>    particular Default Route.

I think I understand what's meant, just it dangerously approaches the 
name Default Router List of ND.

>    Neighbor: A Node or Border Router within a single IP-hop.

I agree.

>   Node Router (Node): Any node in the network that serves as a router,
>    but not as a Border Router.  Typically a constrained device.

Mobile Node...

>    Neighbor Address: 16-bit short IPv6 address of the neighboring Node
>    or Border Router.

Sorry? 16-bit short IPv6 address?  128bit IPv6 would be ok.  Or you mean 
an IPv6 address formed by adding a 64bit prefix to the 64bit IID formed 
from the 16-bit MAC address ('short') and 16_bit_PAN and 16_zero_bits?

Or am I overly optimistic trying to think what you actually don't think?

>   Route Hops: The distance to a Border Router in hops using the
>    specified Neighbor as the next-hop.

For my clarification, would this mean that a hop separates two subnets? 
  Or is it a 'hop' within the same unique link-local multicast scoped 
subnet.  This would be a MAC-layer hop and not an IP hop?

I think it's meant the former, a hop being a MAC-layer hop.  This is 
very much risking misunderstanding the 'Next Hop' in a typical routing 
table, which is IP hop.

> 5.2. Flow Table
> 
> 
>    Each Node maintains a Flow Table, whose entries are composed of two
>    parts:
> 
>    Flow Match: The Flow Match contains information against which packets
>    can be checked.  Flow Match MUST include a Packet Destination field,
>    and MAY contain certain additional fields, such as Packet Source.
> 
>    Flow Path: The Flow Path indicates the path a packet should take.
>    This can either be a full source route, or simply the next-hop to
>    which the packet should be sent to.

But earlier it was said Flow Table has a (Classification, Action) 
format.  I suppose Flow Path is the Action, and Classification is the 
Flow Match, right?

>   The 6lowpan working group has defined an adaptation layer for IPv6
>    datagrams, when carried over Low Power and Lossy links.

6lowpan hasn't mentioned Low Power and Lossy links or am I wrong.

>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Next Header  |  Hdr Ext Len  |                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
>        |                                                               |
>        .                                                               .
>        .                            Options                            .
>        .                                                               .
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    The "Hdr Ext Len" is specified in units of 8-octet chunks, not
>    including the first 8 octets.  A similar layout is used for TLV-
>    encoded options, except the 'Next Header' field is named the 'Option
>    Type' field.  We suggest that the 6lowpan working group may wish to
>    define, as part of the adaptation layer, lengths in units of single
>    octets; we will assume for the rest of this document that such a
>    modification is in effect.  Although this limits the length of
>    extension headers and options to 255 bytes, we feel that this is not
>    a significant limitation and the payload savings resulting from
>    removing unnecessary padding are significant.
> 
>    This recommendation applies specifically to Hop-by-hop, Destination,
>    and Routing extension headers (with 'next header' values 0, 60, and
>    43, respectively).  It also applies to TLV-encoded sub-headers as
>    specified in [RFC2460].

Hmm... I think I get the idea... but I find the text difficult to parse.

I guess what you intend is 6lowpan to ask IANA to define a new value for 
Next Header field of headers potentially preceding this newly introduced 
header.

I think it would be clearer if a picture were drawn precising where this 
new Extension Header could appear, with respect to _all_ the existing 
Extension Headers (also ESP, AH and MH and some I may have forgot). 
SHould also recommend whether final or non-final.  This is paramount 
recommendation to implementers.

Like e.g.

base-do-thisheader-payload  or
base-ah-esp-thisheader-mh

Too many combinations may look tedious at first (and because of that 
it's hard to propose new extension headers :-) but it could be done. 
And it would be great for potential implementers.

> 6.2. Routing Header
> 
> 
>    IPv6 Routing extension headers are defined in [RFC2460].  However,
>    the loose source routing they define is not appropriate for this
                               it         s

>    setting since (a) it uses 128-bit addresses, and (b) it is deprecated
>    by [RFC5095].

Type 0 is indeed deprecated, but not Type 2 for example (Mobile IPv6 RFC 
3775).

>    Source routing is a critical facility in this class of
>    network, and so we define a new routing type.  Alternatively, we may
>    consider this a routing type 0 header, with adaptations.
> 
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Next Header  |  Hdr Ext Len  | Routing Type=0| Segments Left |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |            Address[1]         |      Address[2]               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                               .                               .
>        .                               .                               .
>        .                               .                               .
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |          Address[n-1]         |         Address[n]            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    The addresses in this header are stored in compressed 16-bit form, as
>    specified by [RFC4944] (or later).

I get the idea.  Sounds necessary and simple.  However, I doubt it can 
fly if it doesn't hold 128bit IPv6 addresses... to see later.

> 6.3. Route Install Header
> 
> 
>    A Route Install Header may be placed either as a Destination option
>    or a Hop-by-hop option, depending on the method of install.
>    Processing of this header will depend on which of these is in effect.
> 
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Option Type  |  Option  Len  | M Len | |R| M |   Path Len    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         Flow Match (D)        |         Address[1]            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |            Address[2]         |         Address[3]            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        .                               .                               .
>        .                               .                               .
>        .                               .                               .
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     Address[Path Len - 1]     |       Address[Path Len]       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Option Type: the TLV dispatch value, TLV_TYPE_INSTALL.

I get the idea.

If you want Option Type assigned by IANA just say TBD.  If you feel like 
you could decide it, then just place a number like decimal 1, 2, etc. 
and use same numbers to explain what's meaning.

> 6.4. Router Advertisement Extension
> 
> 
>    In order to carry the Total Path Cost in a router advertisement, we
>    define a new extension header to the Router Advertisement message
>    defined in [RFC2461].
> 
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Option Type  |  Option  Len  |            Metric             |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Willingness  |
>        +-+-+-+-+-+-+-+-+
> 
>    Option type: the TLV value for this header, TLV_TYPE_MULTIHOPMETRIC
> 
>    Option length: The option length, in octets (4).
> 
>    Metric: the Overall Route Cost from a Node to the original
>    advertising router, the Border Router.  If this extension is not
>    present, a cost of zero should be assumed.
> 
>    Willingness: a value indicating the Node's willingness or capacity to
>    route traffic for other Nodes.

This one is longer.

In short: one would better use a new flag in the Flags Expansion Option 
in rfc5175.  It was designed for needs exactly like this one.

Or maybe use rfc4191, but I'm afraid this text until here doesn't seem 
intent on using 128bit IPv6 addresses and prefixes :-(

> 7.1. Link Estimation
> 
> 
>    A critical design element for good performance in L2N networks is
>    good link estimation; low power wireless links exhibit significant
>    temporal and spacial variations in quality due to a number of
>    physical and environmental phenomenon.  This poses a challenge to
>    traditional IP link abstraction since any protocol must account for
>    this behavior.

Hmm... sounds as a fallacy.  Links exhibit variations... challenge to 
traditional IP link abstractions, not.

For example IP runs ok over wifi, which does expose significant temporal 
and spatial abstractions - all dealt with ok at its layer.

>   The link layer must also provide a mechanism for 'local broadcast';
>    the 802.15.4 broadcast address (0xffff) is such a mechanism.  It MAY
>    be advantageous to replace this mechanism with a dedicated discovery
>    component in the future.

No, what may be advantageous is to have a mapping rule between this 
0xffff and a link-local scope all-nodes multicast address.  Just a 
mapping would be very useful first step.

Make state that the 0xffff 802.15.4 address is mapped into the 
FF02:0:0:0:0:0:0:1 all-nodes multicast address and into the 
FF02:0:0:0:0:0:0:2 all-routers multicast address.  And vice-versa. 
(HYDRO Node is an IPv6 Node or IPv6 Router?  Or None?)

This may even be a novelty since not even rfc4944 offers such a mapping, 
  and I believe mapping is of help to implementer.

> 7.2. Router Discovery
> 
> 
>    Router Advertisement and Router Solicitation messages and the
>    associated protocol have been standardized for IPv6 in [RFC2461].
>    While many of the mechanisms can be applied directly in L2Ns, some
>    require modification for efficiency or performance.  The 6lowpan
>    working group has created a committee to investigate these necessary
>    modifications; once their work is complete HYDRO SHOULD be modified
>    to used those mechanisms.

Ouh-la... we reject committees... maybe a design team.

But I agree with the intent...

>    When an event triggers the generation of Router Solicitation or
>    Router Advertisement messages, a binary exponential timer is started.
>    Each time the timer fires, a new Router Solicitation or Advertisement
>    is generated and sent to the IPv6 all-routers link-local multicast
>    address (ff02::2), using the link broadcast facility.

Binary exponential timer... is the basis subunitary or supra?  I mean 
will this firing happen more and more, exponentially, or less and less 
also exponentially?

Or is it exponential backoff sending upon no reception of reply?  Not clear.

>  There are two conditions which cause a reset of the Router
>    Solicitation timer, and thus the transmission of new Router
>    Solicitations:
> 
>    1.  Boot
> 
>    2.  No valid Default Route is present in the Default Route Table.
> 
>    There are two conditions which cause the Router Advertisement timer
>    to be started, if it is not running, and thus the transmission of
>    Router Advertisements:
> 
>    1.  Reception of a Router Solicitation, and the Primary Default Route
>    is valid.
> 
>    2.  The Total Route Cost of the Primary Default Route changes by more
>    then a threshold, ROUTE_COST_NOTIF_DIFF.

I thought one of the conditions of exit is either: receiving the reply 
which was expected, or not receiving an expected reply within a 
pre-defined amount of time.

With random values for the timers, within ranges, and without 
exponentially growing (or dereasing) values.

> 7.3. Default Route Formation
> 
> 
>    The Border Router is manually configured with an IPv6 address,
>    including a full 64-bit network prefix.

On which interface?  L2N Interface or Secondary Interface?  This is 
paramount importance in deciding the entire addressing scheme for HYDRO.

> 7.4. Global Topology Construction
> 
> 
>    Each Border Router maintains a global view of the topology using
>    information obtained from the Topology Reports created by each Node.

Global makes think of world and such.  I understand the world here is 
the sensor network...

Global Topology makes think of global IPv6 addresses, which this doesnt 
seem to be...

>    HYDRO receives feedback from the link layer following each
>    transmission about which Default Route next-hops the link was able to
>    successfully use.  If the number of consecutive failures of the
>    Primary Default Route is greater than MAX_CONSEC_FAILURES, HYDRO
>    initiates a search for a new Primary Default Route.

Well, how does a HYDRO node know when a transmission succeeded?  YOu 
seem to mean HYDRO receives feedback from the link layer - but how?  I'm 
afraid this is too much 802154 specific.

If it were independent of the 802154 layer then it could simply wait for 
  an IP reply (RA or other) and if no reply then do some action.

>    1.  If the destination address is a global unicast address, normal
>    IPv6 processing rules apply; the packet will be routed according to
>    the IPv6 Routing Table Entry for that destination.

Ok!  I adore that!

>    2.  If the packet contains an IPv6 Routing Header and the first hop
>    of that route is another Border Router, the packet is dropped.

In this case, what's the dst address in the IPv6 Base Header?

If first hop is another Border Router - the IPv6 address of the Border 
Router's which interface?

>    3.  If the destination is a unicast address within the L2N subnet and
>    the Border Router does not have a route in its route database, the
>    packet is dropped.  It MAY generate an ICMPv6 Host Unreachable
>    message in this case, but implementors SHOULD take care to limit the
>    rate of message generation; it MAY be advantageous in many cases not
>    to generate this message.

What's the dst address of the Host Unreachable ICMPv6 message?

And why not an ICMPv6 Redirect instead?  This would also install better 
routes to the interested parties.

> 7.8. Multicast Forwarding
> 
> 
>    In this so-called "route-over" design,

To me this is not yet route-over because it doesn't use IPv6 128bit 
addresses, and 'hops' are for you MAC-layer hops.  It is indeed 'over' 
because you stated the L2N network is an entire subnet, ok.

> the link-local multicast
>    address is mapped directly to link-local broadcast at the link layer.

How?  What are the mapping rules from 0xffff to ff02::1?

>   Additionally, it is often desirable for Nodes to send packets to all
>    Nodes in a subnet, regardless of whether or not they are within a
>    link-local broadcast domain.  For this purpose, we use the IPv6 site-
>    local scope.

Doubt doubt... because IPv6 site-local has been deprecated in an RFC, 
yet there seems to be discussion about resurrecting it because used by 
Windows for example... doubt doubt.

>  First, we define the well-known address ff05::XXXX to
>    correspond to a subnet-wide flood.

Put it in IANA section.

Depends what you mean by XXXX

ff05::some_things_are_already_reserved

> 7.9. Multiple Border Routers
> 
> 
>    It is often desirable for multiple Border Routers to be present on
>    single L2N subnet to provide a diversity of routing options and
>    failover connectivity.

I fully agree!

> If more then one Border Router is present, layer 2 connectivity
> between them will be assumed, for example using Ethernet, 802.11
> mesh, or virtual tunneled IP links (something similar to [RFC2003]).

Why this assumption?  I believe it would  work even if Border Routers' 
Secondary Interfaces  where simply reachable at IP layer, like when 
connected to the Internet.  Like this

             \  Internet   /
              --|-------|--
                /        \
               |          | Secondary Interface
              ---        ----
             |BR1|      | BR2|
              ---        ----
               |           | L2N Interface

> On startup, the Border Routers join a link-local multicast group
> ff02::XXXX on their secondary interface and begin listening for
> messages on UDP port XXXX.

On which interface?  If on the Secondary Interface then there may be 
better to join a wider than link scope, a newly defined scope like ff06 
(if it's not already there)...

IANA... TBD

> assumed to have have a relatively abundant

nit have have

> ...

nit beween

> It also not uncommon

nit is missing

> instantance

nit

---

From: Arsalan Tavakoli <[email-masked]>
Date: Thu, 5 Mar 2009 16:02:48 -0800

Dominik,    A real implementation of HYDRO exists, and we have been testing
it internally on various campus projects and testbeds, and plan to release
the code soon.  In addition, a technical report providing evaluation
results, and design details from this implementation and testing should be
released in about a month or so.

- Arsalan

On Thu, Mar 5, 2009 at 9:13 AM, Dominik Kaspar <[email-masked]>wrote:

> - Show quoted text -
> just
> members

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 7 Mar 2009 17:19:29 -0800

It's also worth mentioning that many of the core ideas in HYDRO have  
been in use commercially for over two years now, including use of  
multiple default routes going out and source routes going in, use of  
border routers for maintaining network-wide topology, data-driven link  
estimation using an additive metric as well as confidence metric, use  
of options in existing ICMP messages, trickle-style Router  
Advertisement timing, and more.

You can see published results from a complete IPv6 implementation here:
http://www.cs.berkeley.edu/~jwhui/pubs/jhui-sensys08-ipv6.pdf

You can also find more in-depth information here:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-116.html

--
Jonathan Hui

On Mar 5, 2009, at 4:02 PM, Arsalan Tavakoli wrote:

> Dominik,
>     A real implementation of HYDRO exists, and we have been testing  
> it internally on various campus projects and testbeds, and plan to  
> release the code soon.  In addition, a technical report providing  
> evaluation results, and design details from this implementation and  
> testing should be released in about a month or so.
>
> - Arsalan
>
> On Thu, Mar 5, 2009 at 9:13 AM, Dominik Kaspar <[email-masked] 
> > wrote:
> Hi David,
>
> protocol for
> successfuly
> which