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

Martin Turon <mturon@nestlabs.com> Tue, 02 December 2014 17:35 UTC

Return-Path: <mturon@nestlabs.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A751A1EF7 for <roll@ietfa.amsl.com>; Tue, 2 Dec 2014 09:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.087
X-Spam-Level: *
X-Spam-Status: No, score=1.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LDF38XOFP_v for <roll@ietfa.amsl.com>; Tue, 2 Dec 2014 09:35:42 -0800 (PST)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388EB1A6F28 for <roll@ietf.org>; Tue, 2 Dec 2014 09:35:38 -0800 (PST)
Received: by mail-ig0-f170.google.com with SMTP id r2so16657782igi.1 for <roll@ietf.org>; Tue, 02 Dec 2014 09:35:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6UMeiHxiIYjKcWflfelZBeMzAWm0ExkldtWyAGN2kWE=; b=BgMMZG2UigezVL8KqAZhyhGBGEf0CeeUukW7RTOWcdfkSeu2IF19t9fyK2OqgiyJir 67vv8Qkl0Gcue2IptnuGPD1L2redVdDZEXaHODOuxooJyRS2G1UIToc/yM30Sq3SPTrJ TxgbcsqSMVzsa1uXL1k36ixgskSjZ1Z9f4wBZjTcpvBHKcmYrnuXz4SkHOg3yuGLymzM u+WZ2eEaTw/35opCB97rTEHE2L2Z1w/bC8CldWd3ODMSZNLhTsJ6MJqGNctm5sTg2hh/ Ktr+cAXxwYJ/P5u3slqCVZEyNqc+t014pdiXC47P2RypDi22VQIVH53MxNxXQKeW4Sbs BR+A==
X-Gm-Message-State: ALoCoQlxvsGcIrJoj1TTb0bKJe3X1tWaGAIwb0s8jSel9x1SE/wmKqsWtZgypt5tXEfOFD7WmeHn
MIME-Version: 1.0
X-Received: by 10.50.103.3 with SMTP id fs3mr52326501igb.6.1417541737482; Tue, 02 Dec 2014 09:35:37 -0800 (PST)
Received: by 10.42.128.72 with HTTP; Tue, 2 Dec 2014 09:35:37 -0800 (PST)
In-Reply-To: <mailman.2117.1417537731.2908.roll@ietf.org>
References: <mailman.2117.1417537731.2908.roll@ietf.org>
Date: Tue, 2 Dec 2014 09:35:37 -0800
Message-ID: <CAH=LnKTfy5nF7_BSmHPcHkYAQee-CuHFrhN_Lqi2ncRWYi0L4g@mail.gmail.com>
From: Martin Turon <mturon@nestlabs.com>
To: Carsten Bormann <cabo@tzi.org>, James Woodyatt <jhw@nestlabs.com>, "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e15d7b7ab9605093f2718
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/wcAb0i0hSGMCcq2BHlKXqIkNR5c
Subject: Re: [Roll] Roll Digest, Vol 83, Issue 3
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2014 17:35:44 -0000

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 <cabo@tzi.org>
> To: James Woodyatt <jhw@nestlabs.com>
> Cc: "6tisch@ietf.org" <6tisch@ietf.org>rg>, Routing Over Low power and
>         Lossy networks <roll@ietf.org>rg>, "6lo@ietf.org" <6lo@ietf.org>
> Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for
>         draft-thubert-6lo-routing-dispatch-00.txt
> Message-ID: <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org>
> Content-Type: text/plain; charset=utf-8
>
> On 01 Dec 2014, at 20:20, James Woodyatt <jhw@nestlabs.com> 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
>
>