Re: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPL Storing mode

Mukul Goyal <mukul@uwm.edu> Wed, 17 November 2010 19:47 UTC

Return-Path: <prvs=9304c16d4=mukul@uwm.edu>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0627E3A6996 for <roll@core3.amsl.com>; Wed, 17 Nov 2010 11:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.227
X-Spam-Level:
X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZTN5s+4ttIv for <roll@core3.amsl.com>; Wed, 17 Nov 2010 11:47:30 -0800 (PST)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 181F63A697B for <roll@ietf.org>; Wed, 17 Nov 2010 11:47:29 -0800 (PST)
Received: from mta03.pantherlink.uwm.edu ([129.89.7.134]) by ip1mta.uwm.edu with ESMTP; 17 Nov 2010 13:48:16 -0600
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D5AF41FD03E; Wed, 17 Nov 2010 13:48:15 -0600 (CST)
X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu
Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQQKLwYqXfvT; Wed, 17 Nov 2010 13:48:15 -0600 (CST)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6394A1FD03C; Wed, 17 Nov 2010 13:48:15 -0600 (CST)
Date: Wed, 17 Nov 2010 13:48:15 -0600
From: Mukul Goyal <mukul@uwm.edu>
To: Anders Brandt <abr@sdesigns.dk>
Message-ID: <1010799673.1728842.1290023295331.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD53D@zensys17.zensys.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64)
X-Authenticated-User: mukul@uwm.edu
Cc: ROLL WG <roll@ietf.org>
Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPL Storing mode
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 17 Nov 2010 19:47:31 -0000

Hi Anders,

[Anders]

The current RPL P2P draft
http://tools.ietf.org/html/draft-dt-roll-p2p-rpl-02

appears to be a little unclear on the terms

* hop-by-hop route
* source route
* RPL Storing mode
* RPL Non-storing mode

The introduction does a nice job of explaining the
difference of the two uncompatible modes but forgets
to point out the detail that the
RPL Non-storing mode is using source routes while
RPL Storing mode implements hop-by-hop routes.

[Mukul]

The introduction section does say that

"In non-storing mode operation, only the DAG root maintains downward routing
   information and hence a packet travels all the way to the DAG root,
   which then sends it towards its destination using a source route."

Then it describes the storing mode operation

"In storing mode operation, if the destination is a DAG descendant and
   the source maintains "downwards" routing state about this descendant,
   it can forward the packet along this route.  Otherwise, the source
   sends the packet to a DAG parent, which then applies the same set of
   rules to forward the packet further."

I guess I could modify the first sentence as follows

"In storing mode operation, if the destination is a DAG descendant and
   the source maintains "downwards" HOP-BY-HOP routing state about this descendant,
   it can forward the packet along this route..."

Would this change be sufficient?

[Anders]
Since a given implementation is going to be either
non-storing or storing one may consider having
dedicated sections (or documents?) explaining
what is required for making a system work for
non-storing or storing mode, respectively.

[Mukul]

Are you suggesting that hop-by-hop P2P routes can not be used in an LLN using non-storing mode RPL operation? It seems to me that both types of P2P routes (hop-by-hop; source) can be used irrespective of whether core RPL operation is storing mode or non-storing mode.

Thanks
Mukul

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll