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
- [Roll] Subnet Gateway Protocol Ulrich Herberg
- Re: [Roll] Subnet Gateway Protocol Carsten Bormann
- Re: [Roll] Subnet Gateway Protocol JP Vasseur
- Re: [Roll] Subnet Gateway Protocol David Culler
- Re: [Roll] Subnet Gateway Protocol Ulrich Herberg
- Re: [Roll] Subnet Gateway Protocol Carsten Bormann
- Re: [Roll] Subnet Gateway Protocol Alexandru Petrescu
- Re: [Roll] Subnet Gateway Protocol Ulrich Herberg
- [Roll] RPL P2P - Clarify that hop-by-hop is ident… Anders Brandt
- Re: [Roll] RPL P2P - Clarify that hop-by-hop is i… Philip Levis
- Re: [Roll] RPL P2P - Clarify that hop-by-hop is i… Mukul Goyal
- Re: [Roll] RPL P2P - Clarify that hop-by-hop is i… Anders Brandt
- Re: [Roll] RPL P2P - Clarify that hop-by-hop is i… Mukul Goyal