Re: [Roll] [roll] #88: Data option and ULP

[Mukul Goyal <[e-mail]>]

Hi JP, Richard

Please mark this ticket as closed. Or would it be done when I submit the new version of the draft with this change in?

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Sent: Wednesday, April 4, 2012 8:10:34 AM
Subject: [roll] #88: Data option and ULP

#88: Data option and ULP

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

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

 Discussion
 -------------

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

 [Mukul]
 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

 [Mukul4] OK.
 Pascal

-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/88>
roll <http://tools.ietf.org/wg/roll/>