[Roll] [roll] #102: Why have a Data Option in P2P-RPL. Why have a sequence number in the data option?

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Mon, 04 June 2012 14:15 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
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 0EABB21F889D for <roll@ietfa.amsl.com>; Mon, 4 Jun 2012 07:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 17hbeQZJrKuH for <roll@ietfa.amsl.com>; Mon, 4 Jun 2012 07:15:56 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA721F889B for <roll@ietf.org>; Mon, 4 Jun 2012 07:15:56 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1SbY4Z-0001UP-DC; Mon, 04 Jun 2012 10:15:55 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Mon, 04 Jun 2012 14:15:55 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/102
Message-ID: <055.0400b84aef3418e790354e422e9667aa@trac.tools.ietf.org>
X-Trac-Ticket-ID: 102
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: [Roll] [roll] #102: Why have a Data Option in P2P-RPL. Why have a sequence number in the data option?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
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 14:15:57 -0000

#102: Why have a Data Option in P2P-RPL. Why have a sequence number in the data
option?

 Discussion:
 -----------
 [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
 ( para1 )

 [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.

 [Joseph2]
 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.


 [Mukul2]
 I think that implementation concerns (regarding sending UDP data inside
 ICMP message) might be valid and would like to hear more opinions in this
 regard. But, I also think that LLNs need cross layer interactions and this
 experimental RFC might be the perfect place to check if this works or not.
 Certainly, the need to piggyback data on route discovery packets is real
 in many LLN applications. In my opinion, we should allow this unless there
 are overpowering reasons why this is a bad idea.

 [Jakob2]
 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.

 [Joseph3]
 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.

 [Mukul3]
 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.

-- 
-----------------------------------+---------------------
 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/102>
roll <http://tools.ietf.org/wg/roll/>