Re: [Roll] naming and other goals for RPL Unaware Leaves

Ines Robles <> Tue, 22 October 2019 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0197A120255 for <>; Tue, 22 Oct 2019 06:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o5KPPk6mYHbN for <>; Tue, 22 Oct 2019 06:03:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E0FF120227 for <>; Tue, 22 Oct 2019 06:03:15 -0700 (PDT)
Received: by with SMTP id u8so20251598iom.5 for <>; Tue, 22 Oct 2019 06:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H9OUj+HLxPa7xVOmfbKnCEf2+QRw3pH3kVZxBpoRubc=; b=nZDc+JX3N9wKmVO7vuBb+m4CuFoo/vq6kEq3/1V5eddl361WAIAlMW9vEnbn8XtzkS PCfMkB3QnuFD4I4+0mBTXQV6HSqGPivAR6vFwKcYBQeRXccMJ5Ef3Me68eewcS1hyiZO xT27ClFPGCSW6gr2+Yr3dYY6+tIy/Y//tvIAZSJexiE9mcMNGDWCG0XVEM5UkqS0catg Vf/YI4QQqA/C2qFC+m0JyUt81h/eHOSpGKuOPkqdJ1rxZ7lN7fm0LTmwslzClvQexxJE QCMRqaW8Wjsj3EkdA7LgI2XhNUqXaKVRSEehCmQ4GmKWz4m3mYSXW5mXDd2tQGqCs4Eg JKiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H9OUj+HLxPa7xVOmfbKnCEf2+QRw3pH3kVZxBpoRubc=; b=P+QVupR/AFdjtTmsIXeYvRkhEu3MlURxl1E46z+8aoVnxbmXrurnzGx6v7xd65eYl9 HoYcocjbCjxc3csoVuNFAqeiKPo51k1lazfnzteyWW8SdroAdRxMJiGGLYAuPztWtYTI 4bju4V86kmm/Yc851CIS45gTrI2j/f102AYMFrYw4pFoxc3M2hObWJD+i4Lce57Wmp3Q dvwWJs2zVF2Bo2Uc9mTGodtDFVDuNeJx/lG0+fxxNzJoWHr2n/Bmgx9EgjcyFaieeGQ+ AvAZA3zlNTeu935voVCYtpxTZKB9wDar4qQS13Kr+ugj35Oe6OFzVweD6087sgmXPOmz 07Aw==
X-Gm-Message-State: APjAAAWMtDQHrNLQToU9vK3qQoSYbXyLBkgXSmi25DpPi80LH1o5ovAK dXnNzwI1cJ9k5APAIUWgQ/+Zod4BT63jjn+fuiYcpuiu
X-Google-Smtp-Source: APXvYqzdLPR9ofT1UrIAXCW8uPRHtfVPu1v83kj+tAgUeic6r8AsIlGK9Afs7dvpvE1eCChLV4kivruVXFJEpjfRlz8=
X-Received: by 2002:a6b:ab45:: with SMTP id u66mr3495185ioe.282.1571749393673; Tue, 22 Oct 2019 06:03:13 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ines Robles <>
Date: Tue, 22 Oct 2019 16:02:36 +0300
Message-ID: <>
To: Routing Over Low power and Lossy networks <>
Cc: Michael Richardson <>
Content-Type: multipart/alternative; boundary="00000000000049320c05957f6c03"
Archived-At: <>
Subject: Re: [Roll] naming and other goals for RPL Unaware Leaves
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2019 13:03:18 -0000


Currently the useofrplinfo draft states:

   RPL-aware-node: A device which implements RPL.  Please note that the
   device can be found inside the LLN or outside LLN.

   <<< This would be the number 3 of Michael descriptions
   Should we extend the definition to insert 3.A, 3.b, 3.C, 3D
descriptions???? >>>>

   RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a
   (Destination Oriented Directed Acyclic Graph) DODAG.

   RPL-unaware-node: A device which does not implement RPL, thus the
   device is not-RPL-aware.  Please note that the device can be found
   inside the LLN.

   <<< This would be the number 2 of Michael descriptions,
   I am wondering if we could add the need of RFCs6775, RFC8138 and the
others that Michael mentioned
   into section 9 Operational Considerations of supporting
not-RPL-aware-leaves. >>>>

   RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a
   (Destination Oriented Directed Acyclic Graph) DODAG.

   6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any
   host or router participating in a LoWPAN.  This term is used when
   referring to situations in which either a host or router can play the
   role described.".  In this document, a 6LN acts as a leaf.

   6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate
   router in the LoWPAN that is able to send and receive Router
   Advertisements (RAs) and Router Solicitations (RSs) as well as
   forward and route IPv6 packets.  6LoWPAN routers are present only in
   route-over topologies."

   We would appreciate to know what the WG thinks about this topic?

   Thank you very much,


On Fri, Oct 11, 2019 at 5:56 PM Michael Richardson <>

> At the virtual interim a few weeks ago, Pascal and I discussed different
> possible goals for the documents.  Some of the confusion comes down to
> mis-understandings resulting from the choices of names.
> Let me go through a series of descriptions and connect some terms as I can
> to
> them.
> 1) Host. It was Carsten who first pointed that things that do not route are
>    hosts, and RFC8504 says what a host is supposed to do.
>    RFC8504 does not say anything about being able to decapsulate
> IP(dst:me)IP(dst:me)
>    packets.  I tried to get that in, but 6man was rather hostile to this.
>    RFC8504 also says nothing about supporting 6lowpan stuff!
> 2) 6lowpan host.
>    Everything from (1), plus ability to do
>       rfc4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks
>    which means doing some amount of header compression.
>    Does it include any of:
>    rfc6775: Neighbor Discovery Optimization for IPv6 over Low-Power
> Wireless
>             Personal Area Networks (6LoWPANs)
>    rfc7400: 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power
>             Wireless Personal Area Networks
>    rfc8025: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
>             Paging Dispatch
>    rfc8066: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
>             Dispatch Code Points and Guidelines
>    rfc8505: Registration Extensions for IPv6 over Low-Power Wireless
> Personal
>             Area Network (6LoWPAN) Neighbor Discovery
>    rfc8138: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
>             Routing Header
>    I have no idea.  If someone says a product does "rfc6775", then 4944 is
>    clearly included.   Some of the more recent radios (DECT) may have
> nailed
>    down that they need additional things, but I didn't check.
> 3) RPL host.
>    Pascal and I disagree whether to call this an RPL *AWARE* host (because
> it
>    speaks RPL data plane), or an RPL *UNAWARE* host (because it does not
>    speak 6550).  It being a host, it is by definition a leaf.
>    We are we want is a definition which includes:
>    A) All the stuff above which we were uncertain about.  Specifically, we
>       really want RFC8505 and RFC6775 to be supported.
>       Specifically, EARO with the TID.
>    B) We want these devices to ignore RPI and RH3 headers according
> rfc8200,
>       as useofrplinfo envisions.
>    C) We want these devices to accept IP(dst:me),headers,IP(dst:me)
> constructs,
>       as it simplies the useofrplinfo situation for storing mode.  But,
>       we have some ways to work around this in the 6LR in storing mode, but
>       it is a spec change.
>    D) Ideally, these hosts would send IPv6 packets with an RPI header
> already
>       inserted.  This eliminates the need to do an IPIP encapsulation at
> the
>       first 6LR.
>    A typical example of such a device is a window smash sensor that might
> be
>    part of a (home) security system.  When installed, it might be
> provisioned
>    with some cable for power and control.  Then, having sent out an
>    to register with the 6LR/6LBR, it goes into a deep sleep, waking up
>    perhaps weekly or monthly.  If the window is smashed, it send packets,
>    probably until the battery runs dry.  If it is re-used, it is
> effectively
>    refurbished with a new battery and rejoins as if it was a new device.
>    There are other examples of sleepy devices which would never be able to
>    forward packets.
> 4) 6LR with incompatible MOP, or other handicap.
>    Such a device is forced by the rules of 6550 to join the network as a
> leaf.
>    It is unclear to me if it is allowed to send DAOs for itself, or if it
> has
>    to use ND like (3) above.  Clearly it listens to DIOs, because that's
> how
>    it learnt that it couldn't join as a router.  The key thing is that it
>    does not emit DIOs, and thus never attracts any children.
>    {It is distinguished from a 6LR which just happens to be leaf, because
>    there are no children that have picked it as a parent.  Such a 6LR sends
>    out peridic DIOs according trickle}
> =====
> I would have called (2), RPL Unaware Leaves, and I would have called (3)
> Aware Leaves.
> Pascal calls (1) RPL Unaware Leaves, and (2) are RPL Aware Leaves (I
> think).
> Well, maybe my description is wrong!
> Flame away!
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]        |   ruby on
> rails    [
> _______________________________________________
> Roll mailing list