Re: [Roll] Roll Digest, Vol 83, Issue 3

[Martin Turon <[e-mail]>]

Hi Carsten,

I think the semantics of the mesh header are clear: the source inserts it's
own address, and the address of a multi-hop final destination address, and
then sends it to the best next hop on "the path".  Each node that receives
it, also forwards to the next best hop on "the path", decrementing hops
left as it does.

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 0|V|F|HopsLft| originator address, final address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: Mesh Addressing Type and Header


How the best path is determined depends on the routing protocol running on
that node.  If RPL is running, it could use the tree for upstream or
unknown paths, or cached best-next-hop for downstream paths.  My
understanding of the wide research in this area is that local route
decisions are much more efficient and scalable than source routing, and I'm
frankly surprised RPL doesn't use the mesh header more!  Why not?  Just
call it a highly compressed layer 3 ip-in-ip encapsulation within 6lo.

It certainly isn't any less clear than how RPL does source routing:

      0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+
      |1|0|0|  Size   |6LoRH Type 0..4| Hop1 | Hop2 |     | HopN |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+

            Size indicates the number of compressed addresses

                          Figure 3: The RH3-6LoRH

The answers to many questions would be the same:  How are the hopN
addresses determined in RPL source routing?  Which node inserts those
addresses?  How does a single node know the optimal path through the mesh?
How is that use any more clear than the mesh header?  I would argue that
all that knowledge, coupled with an assumption that intermediate hops can
be determined locally within the mesh, could just as easily generate a
valid mesh header usable by RPL.

Regarding other candidate dispatch bits for repurposing in RFC4844, how
about 010 xxxx 0?  We know LOWPAN_HC1 has been deprecated.  Any LOWPAN_BC0
fans out there?

My personal preference with all this would be to stabilize 6lo, preserve
backwards compatibility as much as possible, similar to how x86 did, and
extend it very carefully with new, full byte dispatch sequences:

           Pattern    Header Type
         +------------+-----------------------------------------------+
         | 00  xxxxxx | NALP       - Not a LoWPAN frame               |
         | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |
         | 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |
         | 01  000011 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 01  001111 | reserved   - Reserved for future use          |
         | 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |

         | 01  010001 | reserved   - Reserved for future use          |

| ... | reserved - Reserved for future use |

         | *01  011111 | LOWPAN_RH  -
**draft-thubert-6lo-routing-dispatch-00*         |

| *01 1xxxxx | LOWPAN_IPHC - RFC6282 * | | 01 111111 | ESC - Additional
Dispatch byte follows | | 10 xxxxxx | MESH - Mesh Header | | 11 000xxx |
FRAG1 - Fragmentation Header (first) | | 11 001000 | reserved - Reserved
for future use | | ... | reserved - Reserved for future use | | 11 011111 |
reserved - Reserved for future use | | 11 100xxx | FRAGN - Fragmentation
Header (subsequent)| | 11 101000 | reserved - Reserved for future use | |
... | reserved - Reserved for future use | | 11 111111 | reserved -
Reserved for future use |
+------------+-----------------------------------------------+


As everyone seems to agree, IoT is maturing, 6lo is growing in adoption,
and we don't want to create a confused situation before it even gets
started by forking the protocol arbitrarily.  Changes should stay on the
conservative side, and adding a clear versioning method needs to be
strongly considered.

Martin


> Message: 2
> Date: Tue, 2 Dec 2014 06:41:17 +0100
> From: Carsten Bormann <[e-mail]>
> To: James Woodyatt <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, Routing Over Low power and
>         Lossy networks <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for
>         draft-thubert-6lo-routing-dispatch-00.txt
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=utf-8
>
> On 01 Dec 2014, at 20:20, James Woodyatt <[e-mail]> wrote:
> >
> > RFC 4944 is a Proposed Standard, which puts it into the same category as
> "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464],
>
> That argument would be more convincing if the situations were indeed
> comparable.
>
> RFC 2464 is the basis for widely deployed plug-and-play interoperability.
> *That* is what makes it mostly immutable, not the standards status.
> (Which probably should be upgraded to match reality.)
>
> With RFC 4944, we haven?t reached that level of interoperability yet.
> In particular, there is *no* way to achieve out-of-the-box
> interoperability with the old mesh header ? there is no defined way to use
> it, or even to find out that (and how) it should be used.
> So you already have to add configuration (as in, "use mesh forwarding
> mechanism X") to use it.
> Pascal?s proposal does not change this situation one iota: It doesn?t
> jeopardize interoperability where there was interoperability before.
>
> (Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC
> 4944 and replaced them with RFC 6282.)
>
> Again, I believe we need to learn more about those reported usages of the
> old Mesh Header before we can meaningfully continue this argument.
>
> Gr??e, Carsten
>
>