Re: [Roll] P2P-RPL: Data-Option in P2P-DIO
Mukul Goyal <mukul@uwm.edu> Mon, 04 June 2012 06:27 UTC
Return-Path: <prvs=49575ab5a=mukul@uwm.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2955021F8802 for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 23:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.398
X-Spam-Level:
X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqKNwnPOnkNi for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 23:27:39 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 402C421F87CC for <roll@ietf.org>; Sun, 3 Jun 2012 23:27:39 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAGRUzE9/AAAB/2dsb2JhbABFhU6xdgEBAQQBAQEgSwsMDw4DBAEBAwINFgMCKR8JCAYTiAsLpDGIWokABIEjiW6EfoESA4hAjFuPdoJ+
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4184D1FD0C9; Mon, 4 Jun 2012 01:27:38 -0500 (CDT)
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 Qq2+tuUS3BUK; Mon, 4 Jun 2012 01:27:37 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id CEB121FD0C7; Mon, 4 Jun 2012 01:27:37 -0500 (CDT)
Date: Mon, 04 Jun 2012 01:27:37 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Joseph Reddy <jreddy@ti.com>
Message-ID: <515392394.582804.1338791257726.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB37@DLEE10.ent.ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll@ietf.org
Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Mon, 04 Jun 2012 06:27:40 -0000
Hi Joseph As Jakob mentioned there is no need for the origin to modify a data option during a route discovery. So I guess I can certainly make this change in P2P-RPL. Sequence numbers were introduced in Data option in response to Pascal's question whether it was possible for the origin to modify the data option during a route discovery. I should have answered no right then. :( I guess we could consider this item closed. Thanks Mukul ----- Original Message ----- From: "Joseph Reddy" <jreddy@ti.com> To: "Mukul Goyal" <mukul@uwm.edu>, roll@ietf.org, "Jakob Buron (Jakob_Buron@sigmadesigns.com)" <Jakob_Buron@sigmadesigns.com> Sent: Sunday, June 3, 2012 11:29:51 PM Subject: RE: P2P-RPL: Data-Option in P2P-DIO Hi Jakob, If we agree to remove the sequence numbers from the data option ( and, consequently, require that the Origin must not modify the data-option during a transmission ), that would be acceptable to me. -Regards, Joseph ----- Forwarded Message ----- From: "Jakob Buron" <Jakob_Buron@sigmadesigns.com> To: "Joseph' 'Reddy" <jreddy@ti.com>, "Mukul Goyal" <mukul@uwm.edu> Cc: roll@ietf.org Sent: Tuesday, May 29, 2012 8:24:03 AM Subject: RE: P2P-RPL: Data-Option in P2P-DIO Hi, please see my comments inline. > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Reddy, Joseph > Sent: Friday, May 25, 2012 11:08 PM > To: Mukul Goyal > Cc: roll@ietf.org > Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO > > Hi Mukul, > > See response below... > > -Regards, Joseph > > -----Original Message----- > > [Joseph] > Section 9.4 > Bullet 1: > Under what conditions would a router receive the same DIO and a Data- > Option with higher sequence number? I assume that only the Originator > can include a Data-Option ? Same question also arises for section 9.5 > ( para > 1 ) > > [Mukul] > Yes, only the origin can include a data option for delivery to the > target(s). In theory, the origin might have newer data to convey to > the > target(s) while the route discovery is still going on. Sequence > numbers accounts for that possibility. Note that Data option did not > have a sequence number earlier (before the first LC). Then, Pascal > raised the possibility what if origin changes the data option. How > would intermediate routers and target know that this is the newer > data? Hence, we introduced the sequence number. > > [Joseph] > I don’t think the Origin should able to this. In fact, the Origin must > not make any changes to the contents of the DIO and retransmit it > without updating the version number. If the Origin wants to send data, > it should simply wait until the p2p route is setup and then use it. > > The whole idea of sending UDP Data messages in the ICMP message > payload itself doesn’t seem quite right. It is also not simple from an > implementation perspective to make this kind of cross layer interactions. > [Jakob] I understand the concern about the Data Option and cross-layer interactions. I also believe that it is a sensible and necessary design choice for home automation networks. Home automation frequently requires low-latency messages to be delivered to targets for which the originator has no route. An example is a remote light switch that needs to control a relocated lamp. The fastest way to do that in a reactive routing scheme is to piggyback the data on the routing packets. The other option would be to use simple flooding, with no trickle control, which would involve generating a huge number of packets. Piggybacking data on routing packets helps avoid generating extra packets. Home automation networks do not need to update the Data Option while a discovery is in progress. I am okay with removing the sequence numbers if they add too much complexity. Best regards, Jakob > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
- Re: [Roll] P2P-RPL: Data-Option in P2P-DIO Reddy, Joseph
- Re: [Roll] P2P-RPL: Data-Option in P2P-DIO Mukul Goyal
- Re: [Roll] P2P-RPL: Data-Option in P2P-DIO Jakob Buron
- Re: [Roll] P2P-RPL: Data-Option in P2P-DIO Reddy, Joseph
- Re: [Roll] P2P-RPL: Data-Option in P2P-DIO Mukul Goyal