Re: [Roll] RUL and RootACK

Rahul Jadhav <> Fri, 05 June 2020 00:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5057B3A0B50 for <>; Thu, 4 Jun 2020 17:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 5MrzBnvD1-io for <>; Thu, 4 Jun 2020 17:53:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BF8F3A0B42 for <>; Thu, 4 Jun 2020 17:53:04 -0700 (PDT)
Received: by with SMTP id l27so8198777ejc.1 for <>; Thu, 04 Jun 2020 17:53:04 -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=oUrqkDRiPMbuaQkzHotqTcEqPtJiZLlTb8BnAa+wQ2c=; b=KONF1j5v7poSvSCKXRb1J9Mff0ISvW76FrwTEs3+ThNxoiTBVg2DYKWS+udBJdhivt 7azCBai41q+F4wWd1FdWPy5tuQhXHCd+ookzzucpmR9IVXJXDWIdozk6Zm87L4/Aat05 Y4RvSlGEnQXFEDDYcfQnhVvjACK9+37V2PEoWiMLlReC3oh6HmcWCNm76+U1+Drctohc JuIKk+N5tNZ7dNoyDtT2nu/6i4CqUfaUaSpKO3GRqB+BKakwP6Bm3BZZ96d7AqSUNGR8 EkZssfFzoMIYkJtSEHrA+79BXa4kygwpy7b7ad9y18+eC+tYNL2loEHACa6ZC94dIJdD qM+w==
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=oUrqkDRiPMbuaQkzHotqTcEqPtJiZLlTb8BnAa+wQ2c=; b=UZ5Q6kpKWXyy4Z7bRAclpzQya8d13jfBUVYB1+ZVdScs4fvbZMqNn2vSZQRQcQsBpX iI4eASrDWWy/XfGlY69AIKHbRCOBNXW21YEpbb8aXNiqPnco+8WsWKK4jJz2lss1SdGl DleUAeBkhf/gRGQtdyb0kGuOfguoZYMt2ZXC89LIHq0vsiWJS0PiibV8IwD0GUWCU1aV PwO8iaxzizgKsA78ivxBNj66sZCG5IfdVvQ7cEeiCdosqVfKskNmGdME7vjeTpjpm9YF itwVgAVx3lUDBI2CtWZUyMyRNrQX3yzu8C7iJCO2BS7FlVxlGu2sM6sspdy1xTu8+TQd m48w==
X-Gm-Message-State: AOAM531/9luGBqbj48H7JqxiGB70zYJGsRXgy6eDGliUx9tdj4Q7cp/d wuRqnC6+7gNir31EvnQLZVpQoK3a4GiAQ403lkKi36iG
X-Google-Smtp-Source: ABdhPJzv+5jWsqJ9wN9OgF3CTFvEPCjplOJwyTc+9NL2Y4Y2u+tWrMrx2m6lUTVuBc8rN6+P1qtZiNLoFicXrW/ILJI=
X-Received: by 2002:a17:906:19c7:: with SMTP id h7mr6114799ejd.403.1591318381302; Thu, 04 Jun 2020 17:53:01 -0700 (PDT)
MIME-Version: 1.0
References: <MAXPR01MB249312F154F630F433508545A9890@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM> <>
In-Reply-To: <>
From: Rahul Jadhav <>
Date: Fri, 05 Jun 2020 08:52:49 +0800
Message-ID: <>
To: Routing Over Low power and Lossy networks <>
Content-Type: multipart/alternative; boundary="000000000000d7966305a74bae56"
Archived-At: <>
Subject: Re: [Roll] RUL and RootACK
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: Fri, 05 Jun 2020 00:53:06 -0000

Thanks Pascal,

But I am more confused now.
Figure 5 [1] attaches the RUL in the RPL network in Non-storing mode.
Figure 9 attaches the RUL in the RPL network using storing mode.
This is what I always thought.

If RUL "always" uses non-storing signalisation then what does figure 9

Also if RUL always uses NS-MOP even if the RPL network is in storing mode,
doesn't it raise a basic question that the RPL network has to mandatorily
support source-routing regardless of the MOP? Currently in my network
source-routing is not enabled if RPL is operating in storing MOP.


On Thu, 4 Jun 2020 at 23:34, Pascal Thubert (pthubert) <pthubert=> wrote:

> Hello Rahul
> You should look at fig. 5 in
> not
> fig. 9 since we are using Non Storing signalisation for RULs in all cases.
> IOW the root ack problem does not exist for RULs.
> More details:
> The idea is for the root to answer a non storing DAO with a DAO ack to the
> sender.
> Normally In NS mode the sender is the RAL that advertises its parent as
> transit and the DAO Ack serves as root ack and confirms reachability.
> In the RUL case, the Root answers to the parent. That answer confirms to
> the parent that the RUL is reachable and serves as root ack. Then the
> parent sends the NA(EARO) which confirms reachability to the RUL.
> Are we good or do I miss something?
> Pascal
> Le 4 juin 2020 à 15:00, Rahul Jadhav <> a écrit :
> Hi Pascal,
> Last we discussed handling storing mode RUL flow with RootACK in a way
> that NA is sent to the RUL after it gets the RootACK. This way RUL can
> initiate its app traffic once e2e path is established.
> Figure 9 in
> handles Storing mode First registration flow for RULs.
> My problem is (consider the figure 9), how will the Root know whom to send
> the RootACK. In the regular cases, the target node in DAO is the
> destination for RootACK. But in this case, the target is RUL and RootAck
> cannot be sent to RUL. For external targets, can we use ParentAddr in
> Transit Information Option to send this field? Anyways the 6LR indeed is
> the parent node for RUL.
> Any thoughts/suggestions?
> Thanks,
> Rahul
> _______________________________________________
> Roll mailing list