Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

C Chauvenet <c.chauvenet@watteco.com> Wed, 11 April 2012 12:02 UTC

Return-Path: <c.chauvenet@watteco.com>
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 DE43421F84B4 for <roll@ietfa.amsl.com>; Wed, 11 Apr 2012 05:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.735
X-Spam-Level:
X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5R5HoQ04F+F5 for <roll@ietfa.amsl.com>; Wed, 11 Apr 2012 05:02:26 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3EC21F84B6 for <roll@ietf.org>; Wed, 11 Apr 2012 05:02:25 -0700 (PDT)
Received: from mail6-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 12:02:25 +0000
Received: from mail6-va3 (localhost [127.0.0.1]) by mail6-va3-R.bigfish.com (Postfix) with ESMTP id 7A02724040B; Wed, 11 Apr 2012 12:02:25 +0000 (UTC)
X-SpamScore: -33
X-BigFish: VPS-33(z4b6Kzc89bh1dbaL1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h946hd25h)
X-Forefront-Antispam-Report: CIP:157.56.248.181; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail6-va3 (localhost.localdomain [127.0.0.1]) by mail6-va3 (MessageSwitch) id 1334145742858239_1486; Wed, 11 Apr 2012 12:02:22 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.235]) by mail6-va3.bigfish.com (Postfix) with ESMTP id CBB3F2004E; Wed, 11 Apr 2012 12:02:22 +0000 (UTC)
Received: from AMXPRD0510HT004.eurprd05.prod.outlook.com (157.56.248.181) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 12:02:21 +0000
Received: from AMXPRD0510MB390.eurprd05.prod.outlook.com ([169.254.3.137]) by AMXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.57.39]) with mapi id 14.16.0143.004; Wed, 11 Apr 2012 12:02:18 +0000
From: C Chauvenet <c.chauvenet@watteco.com>
To: Mukul Goyal <mukul@uwm.edu>
Thread-Topic: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
Thread-Index: AQHNEx32hh4lWAafiEaDmA/VlsX0qpaMTC1wgAUtcwCAAs5AkIABLD4AgAAbh4A=
Date: Wed, 11 Apr 2012 12:02:17 +0000
Message-ID: <D9B1858C-B90F-42D4-9943-BC1FA4500610@watteco.com>
References: <1717308358.1889035.1334139826359.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1717308358.1889035.1334139826359.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.3.4.8]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <DD1D0F67EECA0B4DA28B0CC8C6829798@eurprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: watteco.com
Cc: "<roll@ietf.org>" <roll@ietf.org>
Subject: Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
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: Wed, 11 Apr 2012 12:02:27 -0000

inline,

Le 11 avr. 2012 à 12:23, Mukul Goyal a écrit :

> Please see inline
> 
> Thanks
> Mukul
> 
> #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?
> 
> Resolution: No because multiple DROs would be generated if multiple source  routes are being discovered.
> 
> Discussion:
> 
> p15 :  Stop (S): This flag, when set to one by a target, indicates that  the P2P-RPL route discovery is over.
> 
> [Cedric]
> Is this bit really usefull ? My guess is that it will be always set to 1.
> If you hear a DRO, this indeed means that the RDO has reached the target,  so you could just stop processing RDO when you hear a DRO.
> Do we really need a flag to stop RDO processing or the hearing of a DRO  type message could do the job ?
> 
> [Mukul]
> A P2P-RPL invocation might involve discovery of multiple source routes. In  that case, receipt of a DRO does not mean route discovery is over. Only  when the target sets the stop flag in the DRO, a node could be sure that  the route discovery is over.
> 
> [Cedric2]
> OK fo multiple discovery.
> But if I want to discover a route to a multicast group of target. I set a multicast adress in the target field of the RDO. Then, do I received as many DRO message as the number of target reached ? In that case, would the first DRO with a "S" flag stop the RDO propagation to reach all the target included in the multicast group ?
> 
> [Mukul2]
> A target cannot set the S flag to one in the DRO if the target address in the P2P-RDO specified a multicast address. See the following text at the end of page 21 in P2P-RPL-9:
> 
> "The target MAY set the stop flag inside the DRO message to one if
> 
> 
> 
> Goyal, et al.           Expires September 7, 2012              [Page 21]
> 
> Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012
> 
> 
>   o  this router is the only target specified in the corresponding DIO,
>      i.e., the corresponding DIO specified a unicast address of the
>      router as the Target inside the P2P-RDO with no additional targets
>      specified via RPL Target Options; and
> 
> " 
> 
> [Cedric3] 
> So how do you stop the RDO flooding when the target adress is mulicast ? 
> 
> [Mukul3]
> 
> Stop flag cannot be used when the target address is multicast or when multiple unicast targets are there. The DIO generation will stop when the DAG dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessary message generation. Note that the draft recommends a very small value for the redundancy constant.

[Cedric4]
So in this case, the RDO (I guess this is what you mean when you mentioned "DIO" in you previous message) generation to discover the route is never ending until the temporary DAG dies ?
I guess the RDO flooding would stop according to the MaxRank/NH field  of the P2P-RDO message.
But if this field is set to 0 (meaning infinity according to section 7.1), we should find a mechanism to stop the discovery mechanism.
What do you think ?


> 
> -- 
> -----------------------------------+---------------------
> Reporter:  jpv@…                  |      Owner:  mukul@…
>     Type:  defect                 |     Status:  new
> Priority:  major                  |  Milestone:
> Component:  p2p-rpl                |    Version:
> Severity:  Submitted WG Document  |   Keywords:
> -----------------------------------+---------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/95>
> roll <http://tools.ietf.org/wg/roll/>
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 
>