Re: [Roll] Closure text for ticket #88

"Pascal Thubert (pthubert)" <> Fri, 13 April 2012 09:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3A9021F8608 for <>; Fri, 13 Apr 2012 02:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.113
X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q+DWITuk6LdS for <>; Fri, 13 Apr 2012 02:13:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B98A21F8606 for <>; Fri, 13 Apr 2012 02:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3212; q=dns/txt; s=iport; t=1334308430; x=1335518030; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3elICZWepC9tZPcDes2UCCD9MyhM39Ahx5+EWLRL4uQ=; b=Pb+rOPgHPVJthfxjV5F5rFe55+fmasLmZbm7DGwhyp3sBGFzjQlReQ87 AmuAB2VIjYOVwQ+e7u78cC4I96lgCPo15HG0Nf06TkN69NCPSEvmZmkzL rfQCBJCkEHZD0jguRiEfCNZ/PvWQgW0k4o6ThqTNdcSGIxpzMVBd9v6C0 E=;
X-IronPort-AV: E=Sophos;i="4.75,415,1330905600"; d="scan'208";a="135044573"
Received: from ([]) by with ESMTP; 13 Apr 2012 09:13:49 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q3D9DnUc018247; Fri, 13 Apr 2012 09:13:49 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 11:13:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 13 Apr 2012 11:12:53 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: Closure text for ticket #88
Thread-Index: Ac0YVYrCS/LQ1RiHQ6iVrnOzTjyNhwA/+UXw
References: <> <>
From: "Pascal Thubert (pthubert)" <>
To: Mukul Goyal <>,
X-OriginalArrivalTime: 13 Apr 2012 09:13:49.0680 (UTC) FILETIME=[BCF68700:01CD1955]
Subject: Re: [Roll] Closure text for ticket #88
X-Mailman-Version: 2.1.12
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, 13 Apr 2012 09:13:52 -0000


I agree with this resolution. We can close the ticket and I'll review the text once you publish.


-----Original Message-----
From: Mukul Goyal [] 
Sent: jeudi 12 avril 2012 04:40
Cc: JP Vasseur; Pascal Thubert (pthubert)
Subject: Closure text for ticket #88

#88: Data option and ULP

 An option exists for carrying payload. The use of the option (tunnel,
 transport?) is not described properly.

 Add a next header and a sequence to the data option so upper layers can  be determined.


 Can the data option be different from one DIO to the next?

 The contents of the data option are specified by the origin (for the
 DIO) or the target (for the DRO). In theory, an origin can send  different data options in different DIOs it generates for a particular  route discovery (assuming that it does generate multiple DIOs; it is  very much possible that the origin generates just one DIO and then sits  silent). But, then the origin is taking the risk that some of the data  options would never each the target(s). I guess the origin might do this  if the data sent earlier is now stale and the origin would like the
 target(s) to receive newer data.

 [Pascal2] This should be discussed in the draft. You need to set the  expectation for the upper layer(s). Is there a way to differentiate  different data sets? Eg instance or sequence nb?
 My suggestion so far is that the data should have 3 bits of next header  and 5 bits of sequence.

 [Mukul2] This sounds good to me. I will incorporate this in the draft  unless I hear a better proposal.

 [Pascal3] Cool. Please make that another LC issue and the proposed  resolution, see if there is anyone adding anything to it.

 [Mukul3] Actually, I would like the next header to be 4 bits and the  sequence number to be 4 bits. 4-bit sequence number will still allow up  to 16 different messages to be sent during a P2P-RPL discovery. 4 bit  next header will allow 16 different possibilities. We can have so many  different ways to compress UDP/TCP headers. I think 3 bit next header  may not be sufficient.

 [Pascal4] Cool. Let's use that as the proposed resolution