Subject: [Roll] [roll] #71: DIS Behavior

From: "roll issue tracker" <[email-masked]>
Date: Tue, 20 Jul 2010 16:08:22 -0000

#71: DIS Behavior
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  wintert@…      
     Type:  enhancement         |      Status:  new            
 Priority:  major               |   Milestone:                 
Component:  rpl                 |     Version:                 
 Severity:  Active WG Document  |    Keywords:                 
--------------------------------+-------------------------------------------
 Email From Nicola Dejean July 20

 Hello all,

 Based on our experience of having deployed many smart metering
 networks (totalling several million nodes), we have an issue with the
 way DIS and DIOs are currently handled by RPL. To solve this issue, we
 suggest minor modifications into the RPL core spec that only impacts
 the connection process of a leaf node to the LLN.

 As part of the everyday life of a smart metering network, every so
 often, a meter needs to be replaced or an extra one needs to be added.
 After physical installation, the technician stands by to witness the
 network hook-up. He/she will not leave the premises before the meter
 is satisfactorily connected. Every elapsed minute is an operation
 cost. We are talking real money. There's no way a meter will wait for
 a DIO to arrive by itself after some random number of hours. The meter
 has to solicit DIOs from yet unknown neighbor routers, and that's done
 by multicasting DIS'es. In our case of interest, the meter will be a
 leaf node, therefore its presence will not modify the network
 topology. Currently, RPL mandates that, in response to a multicast
 DIS, DIOs are multicasted and Trickle timers at the routers are reset.

 Firstly, resetting the Trickle timers generates much more control
 traffic than is needed. Neither the meter being installed nor neighbor
 nodes need the frequent repeats of the very same DIO (remember the
 topology is not changing). This is only a waste of energy at the
 routers and at the nodes that are the destination of the DIOs.

 Secondly, multicast makes the problem even worse by enlarging the
 audience for the DIO. Other than the meter being installed, nodes
 nearby do not need to receive the DIO, because they have long settled
 and the topology is not changing.

 In dense environments, the two effects combine to drastically reduce
 the network lifetime compared to our currently deployed, non-RPL,
 protocol.

 It is our industrial experience that this is a real and significant
 problem and we worked hard to solve it.
 Let's leverage that experience to the benefit of RPL users.

 Therefore, here are two possibilites for RPL.

 Option A)
 * In section 5.2, specify an L bit ("Leaf node") in the DIS format.
 * In section 7.3, change the third item of the list to read "When a
 node receives a multicast DIS with a cleared L-bit and a Solicited
 Information option and when the node matches all of the predicates in
 the Solicited Information option."
 * In section 7.3, specify the algorithm to be run for responding with
 a unicast DIO to a multicast DIS with L-bit set. This text shall be
 described in a further email. This could advantageously be a temporary
 Trickle timer.

 Option B)
 * In section 7.3, change the third item of the list to read "When a
 node receives a multicast DIS with a Solicited Information option and
 the node matches all of the predicates in the Solicited Information
 option, unless a DIS flag restricts this behavior."
 * describe the L bit and RPL behavior in a separate I-D, together with
 the DIS option TLVs.

 Would the WG please voice their opinion on these options?

 Thanks
 ________________________

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/71>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 23 Jul 2010 07:18:47 -0000

#71: DIS Behavior
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  wintert@…      
     Type:  enhancement         |       Status:  closed         
 Priority:  major               |    Milestone:                 
Component:  rpl                 |      Version:                 
 Severity:  Active WG Document  |   Resolution:  fixed          
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Email from JP on July 23:

 Dear all,

 Considering the wide consensus for option B, I have updated the text
 accordingly.

 This requires 3 changes.

 1) New text in Section 7.3, third bullet:

 OLD:

 "o  When a node receives a multicast DIS with a Solicited Information
       option and the node matches all of the predicates in the Solicited
       Information option."

 NEW:

 "o  When a node receives a multicast DIS with a Solicited Information
    option and the node matches all of the predicates in the Solicited
    Information option (carried in the DIS option field) and/or (to be
    defined) fields of the Flag field are set."

 2) DIS Packet Format

 OLD:

 "0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           Reserved            |   Option(s)...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Winter, et al.          Expires December 30, 2010              [Page 30]
 Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010

                        Figure 9: The DIS Base Object
 "

 NEW:

 "0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Reserved      |     Flags     |   Option(s)...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Winter, et al.          Expires December 30, 2010              [Page 30]
 Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010

                        Figure 9: The DIS Base Object
 "

 3) IANA Section

 to be added after 18.5.

 18.6 New Registry for the DIS (DODAG Informational Solicitation) Flags

 IANA is requested to create a registry for the DIS (DODAG Informational
 Solicitation) Flag Field.

 New fields may be allocated only by an IETF Consensus action.  Each
 field should be tracked with the following qualities:

    o  Mode of Operation

    o  Capability description

    o  Defining RFC

 No flags are currently defined.

 Thanks.

 JP.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/71#comment:1>
roll <http://tools.ietf.org/wg/roll/>